> 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/apple-pay.md). # Apple Pay Let customers pay in seconds with the cards stored in Apple Wallet – authenticated with Face ID, Touch ID, or their device passcode. Apple Pay is Apple’s digital wallet that enables customers to make fast and secure online payments using payment cards stored in Apple Wallet. Customers confirm the payment with Face ID, Touch ID, or their device passcode – without manually entering card details, billing information, or contact data. Using the SEB Ecommerce Payment Gateway, merchants can accept Apple Pay on the web and in native applications through a secure, tokenized, and PCI DSS compliant payment solution. Apple Pay combines device-based authentication with payment tokenization to provide a seamless checkout experience while helping protect cardholder data. Because Apple Pay removes manual card entry and uses biometric authentication, it reduces checkout friction – wallet payments consistently show faster completion times and higher conversion than manual card entry, particularly on mobile devices. ### Capability Summary
CapabilitySupport
Payment TypeDigital Wallet
Supported CardsVisa, Mastercard*
ChannelsApple Pay on the Web, native in-app payments
Customer AuthenticationFace ID, Touch ID, or Device Passcode
TokenizationSupported – Apple Pay payment tokens
EMV® 3-D SecureSupported where applicable; wallet authentication typically satisfies SCA
Customer-Initiated Transactions (CIT)Supported
Merchant-Initiated Transactions (MIT)Supported
Recurring PaymentsSupported
RefundsFull and Partial
Integration OptionsHosted Checkout, Merchant API, Mobile SDKs (where applicable)
Sandbox TestingAvailable
\*Support depends on the customer’s device, issuing bank, and merchant configuration. Availability of individual features depends on your merchant agreement and enabled services. ### How Apple Pay Works Apple Pay is built on payment tokenization. When a customer adds a card to Apple Wallet, the card is not stored on the device or on Apple’s servers. Instead, the issuer and the card scheme provision a device-specific token – the Device Account Number – which is encrypted and stored in the Secure Element, a certified security chip on the customer’s device. During a payment: 1. The customer authenticates. The customer confirms the payment with Face ID, Touch ID, or their device passcode. 2. A dynamic cryptogram is created. The device generates a one-time payment cryptogram, valid only for this transaction. 3. The gateway processes the payment token. The gateway securely receives the Apple Pay payment token and routes the transaction through the same acquiring infrastructure as standard card payments – using the token instead of the customer’s actual card number. 4. Authorization. The card scheme resolves the token, and the issuer approves or declines the transaction. The result is returned to your systems in the payment response and via callback notifications. The customer’s actual card number is never shared with Apple, the merchant, or the gateway during a transaction. Even if intercepted, the payment token and the one-time cryptogram cannot be reused. {% hint style="info" %} Apple Pay uses the wallet provider’s tokenization mechanism, which is distinct from the gateway and network tokens described under Tokenization. From your perspective, the processing is transparent: Apple Pay transactions flow through the standard authorization, capture, reversal, and refund operations. {% endhint %} ### Supported Features Apple Pay provides a secure and convenient payment experience while supporting modern ecommerce payment capabilities: * Secure payment tokenization * Device-based customer authentication (Face ID, Touch ID, device passcode) * Customer-Initiated Transactions (CIT) * Merchant-Initiated Transactions (MIT) * Recurring payments * One-click payments * Full and partial refunds * Integration with Hosted Checkout, Merchant API, and Mobile SDKs (where applicable) The availability of individual features depends on your merchant agreement and enabled services. ### Customer Experience Customers complete the payment without manually entering their card details. During checkout, the customer: 1. Selects Apple Pay as the payment method. The Apple Pay button is displayed on supported Apple devices and browsers. 2. Authenticates on their device. The Apple Pay payment sheet appears, showing the selected card and payment amount. The customer confirms with Face ID, Touch ID, or their device passcode. 3. Confirms the payment. The payment is authorized in the background. 4. Returns to your checkout flow after payment authorization. No manual data entry or redirect to third-party pages is required. ### Authentication and SCA Apple Pay performs strong device-based customer authentication as part of every payment: the combination of the customer’s device (possession) and Face ID, Touch ID, or passcode (inherence or knowledge) satisfies the two-factor requirements of Strong Customer Authentication (SCA) under PSD2. Because the wallet typically performs strong customer authentication, a separate EMV® 3-D Secure authentication step may not be required for Apple Pay payments. Where 3DS processing applies, the gateway handles it as part of its standard 3DS support. ### Merchant Requirements Before accepting Apple Pay, ensure that: * Apple Pay is enabled as a payment method in your e-shop agreement. Contact your SEB representative to have Apple Pay activated for your shop. * Your website or application uses HTTPS. Apple Pay is not displayed on pages served over insecure connections. * Any Apple-specific requirements – such as merchant registration, domain verification, and certificate provisioning where applicable – have been completed. * Your integration has been successfully validated and your production environment has been activated. Your SEB representative will guide you through the activation steps applicable to your integration type. #### Onboarding and Domain Verification Depending on your integration, activation of Apple Pay involves registration with Apple, validation of the domains on which Apple Pay is offered, and provisioning of the required certificates. * Automatic onboarding via the gateway. Merchant onboarding for Apple Pay may be performed automatically through the gateway using the Apple Pay Merchant Registration API, without a separate migration process – registration is triggered when your merchant agreement is created. In this model, most Apple-specific setup is handled for you. * Domain verification. Where domain verification applies to your integration, each web domain (including subdomains) on which the Apple Pay button is displayed must be verified with Apple by hosting a domain association file at the location specified during activation. The file must remain accessible for the verification to stay valid. {% hint style="info" %} SEB acts as a technical service provider within the transaction flow. Wallet provider approvals, registrations, and compliance with Apple’s terms remain subject to Apple’s requirements and processes. {% endhint %} ### Payment Processing Apple Pay uses payment tokenization to protect the customer’s payment credentials throughout the payment process: *Merchant → SEB Gateway → Visa / Mastercard → Issuer* The payment is processed through the same acquiring infrastructure as standard card payments while using a secure payment token instead of the customer’s actual card number. All standard post-payment operations – capture, refund (full and partial), and reversal – are available through the same flows as for other card payments. #### Recurring Payments and MIT with Apple Pay Apple Pay supports stored-credential scenarios in the same way as regular card payments. During an initial Customer-Initiated Transaction, the customer authenticates through Apple Pay and consents to storing their payment credentials; the gateway returns a token ID that you use for subsequent one-click payments and Merchant-Initiated Transactions. See Stored Credentials and Merchant-Initiated Transactions (MIT) for the applicable consent and processing rules. ### Availability Apple Pay is available to customers on supported Apple devices – iPhone, iPad, Apple Watch, and Mac – in Safari and other supported browsers and applications. The Apple Pay button is only displayed when the customer’s device and browser support Apple Pay and the customer has an eligible card in Apple Wallet. Availability is subject to device compatibility, browser support, regional availability, and the customer’s issuing bank participating in Apple Pay. Always provide alternative payment methods for customers who cannot use Apple Pay. ### Displaying Apple Pay Apple defines mandatory requirements for how Apple Pay is presented at checkout: * Use the official Apple Pay button and mark provided by Apple; do not create custom versions, modify the artwork, or alter its proportions. * Follow Apple’s Human Interface Guidelines and identity guidelines for button placement, sizing, and styling. * Display Apple Pay with at least equal prominence to other payment marks where it is offered. * Show the Apple Pay button only when the customer’s device and browser support Apple Pay. Hosted Checkout renders the Apple Pay button in accordance with Apple’s requirements automatically. If you build your own checkout using the Merchant API or Mobile SDKs, you are responsible for compliance with Apple’s branding guidelines. ### Testing Complete all development and validation using the Sandbox environment before processing live transactions. Testing Apple Pay requires a supported Apple device or browser. Before requesting Production activation, verify: * Apple Pay is displayed on supported Apple devices and browsers – and hidden where not supported. * Successful payment processing, including the Apple Pay payment sheet and device authentication. * Declined payment scenarios. * Refund processing, full and partial. * Callback or webhook notifications. * Order confirmation and status updates. * Recurring payment scenarios (where applicable). * Domain verification remains valid on all production domains (where applicable). ### Merchant Responsibilities Merchants are responsible for: * Displaying Apple Pay in accordance with Apple’s branding guidelines. * Providing an alternative payment method if Apple Pay is unavailable. * Obtaining customer consent before initiating recurring payments. * Keeping domain verification and any Apple-specific registrations valid, where applicable to the integration. * Complying with Apple’s applicable terms, card scheme rules, and regulatory requirements. * Following PCI DSS requirements applicable to their payment environment. ### Frequently Asked Questions #### Does the merchant ever see the customer’s card number? No. Apple Pay transactions use a device-specific payment token instead of the actual card number. The card number is not stored on the customer’s device or on Apple’s servers, and it is never exposed to your systems. #### Why is the Apple Pay button not displayed to some customers? The button appears only when the customer uses a supported Apple device and browser, has an eligible card added to Apple Wallet, and the page is served over HTTPS. If domain verification applies to your integration, it must also be valid for the domain in question. Always offer alternative payment methods. #### Do Apple Pay payments require 3-D Secure? Apple Pay performs strong device-based authentication as part of every payment, which typically satisfies SCA requirements – so a separate 3DS step is usually not required. Where 3DS processing applies, the gateway handles it as part of its standard 3DS support. #### Can I use Apple Pay for subscriptions? Yes. Apple Pay supports stored-credential scenarios in the same way as regular card payments: after an initial Customer-Initiated Transaction with the customer’s consent, you can process recurring charges as Merchant-Initiated Transactions using the returned token ID. #### Are refunds supported for Apple Pay payments? Yes. Full and partial refunds are processed through the standard refund flow, the same as for other card payments. #### Does accepting Apple Pay cost extra? Apple does not charge customers or merchants transaction fees for using Apple Pay. Your standard card processing terms under your merchant agreement apply. ### Related Documentation Continue with the following topics: * [Google Pay](/payment-methods/wallets/google-pay.md) * [Click to Pay](/payment-methods/wallets/click-to-pay.md) * [Tokenization](/payment-methods/cards/tokenization.md) * [Stored Credentials](/payment-methods/cards/stored-credentials.md) * [Merchant-Initiated Transactions](/payment-methods/cards/stored-credentials/merchant-initiated-transactions-mit.md) (MIT) * [EMV® 3-D Secure ](/payment-methods/cards/emv-r-3-d-secure-emv-3ds.md)(EMV 3DS) * [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/apple-pay.md?ask=&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.