> For the complete documentation index, see [llms.txt](https://docs.ecommerce.seb.ee/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ecommerce.seb.ee/payment-methods/wallets/click-to-pay.md).

# Click to Pay

The card schemes’ shared online checkout – customers pay with their enrolled cards in a few clicks, on any device and in any browser, without typing card details.

Click to Pay is a unified online checkout solution operated by the card schemes and built on the EMV® Secure Remote Commerce (SRC) standard developed by EMVCo – the same industry body behind chip card technology. It replaces manual card entry with a single, secure payment profile: the customer enrolls their cards once and can then pay at any participating merchant, on any device, wherever they see the Click to Pay icon.

Unlike device-based wallets, Click to Pay does not depend on a specific operating system, device, or browser. The customer’s cards are held in a scheme-managed Click to Pay profile linked to their email address or mobile number – which makes Click to Pay particularly effective for guest checkout, where customers would otherwise have to type in their card details.

The SEB Ecommerce Payment Gateway integrates Click to Pay through the Mastercard Unified Checkout Solution. Card credentials obtained through the Click to Pay flow are processed through the gateway’s standard authorization, capture, reversal, and refund flows – the same as regular card payments.

### Capability Summary

<table><thead><tr><th valign="top">Capability</th><th valign="top">Support</th></tr></thead><tbody><tr><td valign="top">Payment Type</td><td valign="top">Digital card-based payment (scheme-operated checkout)</td></tr><tr><td valign="top">Underlying Standard</td><td valign="top">EMV® Secure Remote Commerce (SRC)</td></tr><tr><td valign="top">Supported Cards</td><td valign="top">Visa, Mastercard*</td></tr><tr><td valign="top">Customer Recognition</td><td valign="top">Device/browser recognition; email or mobile number lookup</td></tr><tr><td valign="top">Customer Verification</td><td valign="top">One-time passcode (OTP) or passkey, managed by the Click to Pay system</td></tr><tr><td valign="top">EMV® 3-D Secure</td><td valign="top">Supported – applied where required</td></tr><tr><td valign="top">Tokenization</td><td valign="top">Built on card scheme network tokenization</td></tr><tr><td valign="top">Enrollment at Checkout</td><td valign="top">Supported – new customers can create a Click to Pay profile during payment</td></tr><tr><td valign="top">Post-Payment Operations</td><td valign="top">Capture, reversal, refunds (full and partial)</td></tr><tr><td valign="top">Integration Options</td><td valign="top">Hosted Checkout, Merchant API (where applicable)</td></tr><tr><td valign="top">Sandbox Testing</td><td valign="top">Available</td></tr></tbody></table>

\*Support depends on the customer’s enrolled cards, issuing bank, and merchant configuration. Availability of individual features depends on your merchant agreement and enabled services.

### How Click to Pay Works

Click to Pay is built around a scheme-managed payment profile and intelligent customer recognition:

* One profile, all cards. The customer’s cards are enrolled in a Click to Pay profile identified by their email address or mobile number. The profile is managed by the card schemes – not stored at the merchant and not tied to a specific device. Cards in the profile are kept up to date automatically when they are reissued or replaced.
* Intelligent recognition. On a trusted device or browser, a returning customer is recognized automatically and taken straight to their card list. On a new device, the customer enters their email address or mobile number; the Click to Pay system verifies their identity with a one-time passcode or a passkey before showing the enrolled cards.
* Tokenized credentials. The payment credentials delivered to the gateway are protected by scheme network tokenization and transaction-specific dynamic data – the customer’s card details are not typed on your page and are not exposed to your systems.

A typical payment:

1. The customer selects Click to Pay. The customer chooses Click to Pay at checkout, marked by the Click to Pay icon.
2. The Click to Pay system identifies the customer. A recognized customer proceeds directly; otherwise the customer enters their email address or mobile number and confirms a one-time passcode or uses a passkey.
3. The customer selects a card. The customer’s enrolled cards are displayed; the customer picks a card and confirms the payment.
4. The gateway processes the payment. The gateway receives the tokenized payment credentials from the Click to Pay flow, applies EMV® 3DS authentication where required, and routes the transaction through the standard authorization flow. The result is returned in the payment response and via callback notifications.

{% hint style="info" %}
Click to Pay is the successor of Masterpass and Visa Checkout, which have been consolidated into the single EMV® SRC-based experience. Customers who previously used those wallets are transitioned to Click to Pay by the schemes.
{% endhint %}

#### First-Time Customers – Enrollment at Checkout

Customers who do not yet have a Click to Pay profile can create one directly during checkout: they enter their card details and contact information once, and – with their consent – a Click to Pay profile is created alongside the payment. On future visits, to your shop or to any other participating merchant, they check out in a few clicks without entering card details again.

This turns a one-time guest checkout into a returning fast-checkout experience – without the customer creating an account at your shop and without your systems storing any card data.

### Customer Experience

How checkout looks depends on whether the customer is recognized:

* Returning customer, trusted device. The customer clicks the Click to Pay icon, sees their cards immediately, selects one, and confirms. No data entry at all.
* Returning customer, new device. The customer enters their email address or mobile number, confirms a one-time passcode sent by the Click to Pay system (or uses a passkey), then selects a card and confirms.
* First-time customer. The customer enters their card and contact details once and can opt in to Click to Pay for future purchases everywhere the icon is accepted.

Where additional EMV® 3DS authentication is required, it is applied automatically as part of the payment flow before the result is returned to your systems.

### Authentication and SCA

Click to Pay includes cardholder verification as part of its checkout flow – device or browser recognition on trusted devices, and one-time passcode or passkey verification otherwise. Where Strong Customer Authentication (SCA) is required by regulation, EMV® 3DS authentication is applied as part of the payment flow – the gateway handles this as part of its standard 3DS support, and no additional integration logic is required on your side. The final authorization decision always remains with the issuer.

#### Mastercard Token Authentication Service

Mastercard Token Authentication Service (TAS) provides transaction authentication during Click to Pay checkout. It supports passkey-based authentication for eligible cardholders.

TAS authentication methods depend on regional availability, device type, and the cardholder's account.

**Create a passkey**

After adding a new card to their Click to Pay profile and successfully completing the required authentication challenge, the cardholder is presented with an option to create a passkey.

Once the cardholder consents, the Mastercard Checkout solution performs device binding to securely register the passkey to the device.

**Use a passkey**

During checkout, the Mastercard Checkout solution uses an existing passkey to authenticate the transaction. If the cardholder signs in to Click to Pay with a passkey and selects a card linked to that device, authentication is performed automatically as part of the checkout experience. No additional passkey verification is required.

### What You Need to Accept Click to Pay

The only step required in all cases:

* Click to Pay is enabled as a payment method in your e-shop agreement. Contact your SEB representative to have Click to Pay activated for your shop.

Scheme program registrations and enablement for Click to Pay are managed at the bank level – you do not register with the card schemes yourself.

#### If You Use Hosted Checkout

No additional steps are required. Once Click to Pay is enabled for your shop, it appears on the Hosted Checkout page – the gateway manages the Click to Pay interaction, customer recognition, and verification flows on your behalf.

#### If You Build Your Own Checkout (Merchant API)

Where Click to Pay is available for merchant-built checkouts, additional integration steps apply – including presenting the Click to Pay experience in accordance with the scheme’s program requirements and customer experience guidelines. Contact your SEB representative to confirm availability for your integration type and to receive the applicable integration guidance.

{% hint style="info" %}
SEB acts as a technical service provider within the transaction processing flow. Scheme program approvals, participation, and certification decisions remain subject to the card scheme’s requirements and processes.
{% endhint %}

### Payment Processing

Click to Pay delivers tokenized card credentials that are processed like standard card payments:

*Merchant → SEB Gateway → Visa / Mastercard → Issuer*

All standard post-payment operations – capture, reversal, and refunds (full and partial) – are available through the same flows as for other card payments, and transactions are visible in the Merchant Portal alongside your other card transactions.

### Why Offer Click to Pay

* Higher conversion at guest checkout. Manual card entry is one of the biggest sources of checkout abandonment, especially on mobile. Click to Pay removes it for enrolled customers – including guests who have never shopped with you before.
* A network effect. Recognition works across participating merchants: a customer enrolled anywhere can use fast checkout at your shop from the first visit.
* Security by design. Credentials are protected by scheme network tokenization and dynamic transaction data; card details are not typed on your page and are not exposed to your systems.
* Up-to-date cards. Cards in Click to Pay profiles are updated by the schemes when reissued or replaced – reducing declines caused by outdated card details.
* No device dependency. Because Click to Pay works in any browser on any device, it complements Apple Pay and Google Pay rather than competing with them – covering customers outside those ecosystems.

### Displaying Click to Pay

Click to Pay is identified by the Click to Pay icon licensed by EMVCo, displayed together with the marks of the participating card schemes:

* Use the official Click to Pay icon; do not modify the artwork or create custom versions.
* Follow the EMV® Secure Remote Commerce – Click to Pay Customer Experience (CX) Guidelines and the applicable scheme program requirements for placement and presentation.
* Display Click to Pay with at least equal prominence to other payment marks where it is offered.

Hosted Checkout presents Click to Pay in accordance with these requirements automatically. If you build your own checkout, you are responsible for compliance with the applicable guidelines.

### Availability

Click to Pay works on any device and in any modern browser – desktop and mobile – without dependence on a specific operating system or hardware. Availability is subject to scheme program eligibility criteria, merchant enrollment status, regional availability, and the customer’s issuing bank participating in Click to Pay. Always provide alternative payment methods for customers who do not use Click to Pay.

### Testing

Complete all development and validation using the Sandbox environment before processing live transactions. Before requesting Production activation, verify:

* Click to Pay is presented at checkout and the Click to Pay flow completes successfully.
* The recognized-customer flow and the email/mobile lookup flow with one-time passcode verification.
* First-time enrollment during checkout (where applicable).
* EMV® 3DS scenarios where authentication is required.
* Declined payment scenarios, including the customer switching to another payment method.
* Refund processing, full and partial.
* Callback or webhook notifications, order confirmation, and status updates.

### Merchant Responsibilities

Merchants are responsible for:

* Displaying Click to Pay in accordance with the EMVCo and scheme guidelines.
* Providing an alternative payment method if Click to Pay is unavailable or the customer cannot complete verification.
* Complying with applicable scheme program requirements, card scheme rules, and regulatory requirements.
* Following PCI DSS requirements applicable to their payment environment.

### Frequently Asked Questions

#### How is Click to Pay different from Apple Pay and Google Pay?

All three replace manual card entry with tokenized credentials. The key difference is where the cards live and how the customer is verified: Apple Pay and Google Pay store credentials on the customer’s device or account and authenticate with device biometrics, while Click to Pay keeps cards in a scheme-managed profile linked to the customer’s email or mobile number – so it works in any browser on any device, with verification by one-time passcode or passkey. In practice the three complement each other, covering different customer segments.

#### Does the customer need an account at my shop?

No. Click to Pay works independently of your shop accounts. A customer enrolled in Click to Pay – at any participating merchant or through their bank – gets the fast checkout experience at your shop from their first visit.

#### Does my shop store the customer’s card data?

No. The customer’s cards are held in the scheme-managed Click to Pay profile, and the credentials delivered to the gateway are protected by network tokenization. Card details are not typed on your page and are not exposed to your systems.

#### What happens if the customer cannot receive the one-time passcode?

If verification cannot be completed – for example, the customer no longer has access to the registered email or phone – the customer should complete the purchase with another payment method, such as manual card entry. Always keep alternative payment methods available at checkout.

#### Do Click to Pay payments require 3-D Secure?

Where Strong Customer Authentication is required by regulation, EMV® 3DS is applied as part of the payment flow – automatically, with no additional integration logic on your side. The issuer makes the final authorization decision.

#### Are refunds supported for Click to Pay payments?

Yes. Full and partial refunds are processed through the standard refund flow, the same as for other card payments.

### Related Documentation

Continue with the following topics:

* [Apple Pay](/payment-methods/wallets/apple-pay.md)
* [Google Pay](/payment-methods/wallets/google-pay.md)
* [Card Payment Lifecycle](/payment-methods/cards/card-payment-lifecycle.md)
* [Tokenization](/payment-methods/cards/tokenization.md)
* [EMV® 3-D Secure](/payment-methods/cards/emv-r-3-d-secure-emv-3ds.md) (EMV 3DS)
* [Supported Operations](/payment-methods/cards/supported-operations.md)
* [Testing](/payment-methods/cards/testing.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.ecommerce.seb.ee/payment-methods/wallets/click-to-pay.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
