> 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/google-pay.md). # Google Pay Let customers pay in a few taps with the cards saved to their Google Account – on Android devices, in Chrome, and across the web. Google Pay is Google’s digital wallet that enables customers to pay online using payment cards saved to their Google Account or stored on their Android device. Instead of typing card numbers, billing details, and contact information, the customer selects a saved card in the Google Pay payment sheet and confirms the purchase. Using the SEB Ecommerce Payment Gateway, merchants can accept Google Pay on the web and in native applications through a secure, tokenized, and PCI DSS compliant payment solution. The customer’s payment credentials are delivered to the gateway as an encrypted Google Pay payment token – card data is never exposed to your systems. A distinctive strength of Google Pay is its reach: it works on Android devices and in Chrome and other supported browsers on any platform, wherever the customer is signed in to their Google Account. This makes Google Pay available to a broad audience across desktop and mobile, reducing checkout friction and cart abandonment. ### Capability Summary
CapabilitySupport
Payment TypeDigital Wallet
Supported CardsVisa, Mastercard*
ChannelsGoogle Pay on the web, native in-app payments
Customer AuthenticationGoogle Account sign-in; device screen lock or biometrics where applicable
TokenizationSupported – encrypted Google Pay payment tokens
EMV® 3-D SecureSupported – applied automatically where required (see Authentication and 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 Google Pay Works Google Pay is built on payment tokenization. When the customer pays, Google packages the selected payment credentials into an encrypted payment token and passes it to the gateway. The gateway securely receives and decrypts the token and routes the transaction through the same acquiring infrastructure as standard card payments. The payment token can contain one of two credential types, depending on how the customer’s card is stored: * Device token (CRYPTOGRAM\_3DS). The card is stored as a device token on the customer’s Android device – a scheme-issued token that replaces the actual card number. Each payment includes a one-time cryptogram generated on the device, and the customer confirms the payment with their screen lock or biometrics. This is conceptually similar to how Apple Pay works. * Card on file with Google (PAN\_ONLY). The card is saved to the customer’s Google Account and can be used on any device or browser where the customer is signed in – including desktop computers. The card details are delivered to the gateway in encrypted form, but no device-generated cryptogram is included, so additional authentication may be applied (see Authentication and SCA). Which credential type is used is determined automatically by the customer’s device, browser, and card – you do not need to distinguish between them in your integration. The gateway recognizes the credential type and applies the appropriate processing and authentication. A typical payment: 1. The customer selects Google Pay. The Google Pay button is shown at checkout on supported devices and browsers. 2. The customer confirms the payment. The Google Pay payment sheet displays the customer’s saved cards. The customer selects a card and confirms – with their screen lock or biometrics where applicable. 3. The gateway processes the payment token. The encrypted payment token is delivered to the gateway, which decrypts it and initiates authorization. Where required, the gateway applies EMV® 3DS authentication. 4. Authorization. The issuer approves or declines the transaction. The result is returned to your systems in the payment response and via callback notifications. {% hint style="info" %} Google Pay uses the wallet provider’s tokenization mechanism, which is distinct from the gateway and network tokens described under Tokenization. From your perspective, processing is transparent: Google Pay transactions flow through the standard authorization, capture, reversal, and refund operations. {% endhint %} ### Supported Features Google Pay provides a secure and convenient payment experience while supporting modern ecommerce payment capabilities: * Secure payment tokenization * 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 Google Pay as the payment method. The Google Pay button is displayed on supported devices and browsers. 2. Chooses a saved card. The Google Pay payment sheet appears with the customer’s saved cards and the payment amount. 3. Confirms the payment. Depending on the device and card, the customer verifies with their screen lock, biometrics, or Google Account. 4. Completes authentication where required. If additional EMV® 3DS authentication is required, it is applied automatically as part of the payment flow. 5. Returns to your checkout flow after payment authorization. No manual data entry is required. ### Authentication and SCA How Strong Customer Authentication (SCA) is satisfied depends on the credential type contained in the Google Pay payment token: * Device tokens (CRYPTOGRAM\_3DS). The payment is authenticated on the customer’s device – the combination of the device and the customer’s screen lock or biometrics typically satisfies SCA requirements, and the payment token carries the corresponding cryptogram. A separate 3DS step is usually not required. * Cards on file with Google (PAN\_ONLY). No device-based authentication accompanies the payment credentials. To meet SCA requirements and avoid issuer declines, the gateway applies EMV® 3DS authentication where required – automatically, as part of its standard 3DS support. The customer may be asked to complete a frictionless or challenge flow. You do not need to implement separate logic for the two cases – the gateway recognizes the credential type and applies the appropriate authentication. The final authorization decision always remains with the issuer. ### What You Need to Accept Google Pay The only step required in all cases: * Google Pay is enabled as a payment method in your e-shop agreement. Contact your SEB representative to have Google Pay activated for your shop. Anything beyond that depends on your integration type. #### If You Use Hosted Checkout No additional Google-specific steps are required. Once Google Pay is enabled for your shop, the Google Pay button appears automatically on the gateway-hosted payment page for eligible customers – the gateway handles the interaction with Google on your behalf. #### If You Build Your Own Checkout (Merchant API or Mobile SDKs) When the Google Pay button is placed in your own checkout, Google’s requirements apply to your website or application: * Accept the Google Pay API Terms of Service. * Serve your checkout pages over HTTPS – Google Pay is not offered on insecure connections. * Register your business in the Google Pay & Wallet Console, configure your merchant profile, and complete Google’s review of your website or application before production use. * Validate your integration in the Sandbox environment before your production environment is activated. Your SEB representative will guide you through the activation steps applicable to your integration type. #### Onboarding Activation of Google Pay involves registration with Google. How much of it you see depends on your integration. * Automatic onboarding via the gateway. Merchant onboarding for Google Pay may be performed automatically through the gateway under SEB’s Google Pay Payment Service Provider registration, without a separate migration process – registration is triggered when your merchant agreement is created. In this model, most Google-specific setup is handled for you. * Direct integrations. If you build your own checkout using the Merchant API or Mobile SDKs, additional steps may apply, such as registering in the Google Pay & Wallet Console and submitting your integration for Google’s review before production use. {% hint style="info" %} SEB acts as a technical service provider within the transaction flow. Wallet provider approvals, merchant onboarding decisions, and compliance with Google’s terms remain subject to Google’s requirements and processes. {% endhint %} ### Payment Processing Google 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 an encrypted payment token instead of manually entered card details. 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 Google Pay Google Pay supports stored-credential scenarios in the same way as regular card payments. During an initial Customer-Initiated Transaction, the customer pays with Google 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. If you already process MIT flows for card payments, no additional integration steps are required. See Stored Credentials and Merchant-Initiated Transactions (MIT) for the applicable consent and processing rules. ### Availability Google Pay is available to customers: * On Android devices, in apps and in the browser. * In Chrome and other supported browsers on any platform – including desktop – where the customer is signed in to their Google Account and has an eligible saved card. The Google Pay button is displayed only when the customer’s device or browser supports Google Pay and an eligible card is available. Availability is subject to device compatibility, browser support, regional availability, merchant eligibility criteria, and the customer’s issuing bank participating in Google Pay. Always provide alternative payment methods for customers who cannot use Google Pay. ### Displaying Google Pay Google defines mandatory requirements for how Google Pay is presented at checkout: * Use the official Google Pay button and mark provided by Google; do not create custom versions, modify the artwork, or alter its proportions. * Follow the Google Pay brand guidelines for button placement, sizing, color variants, and clear space. * Display Google Pay with at least equal prominence to other payment marks where it is offered. * Show the Google Pay button only when Google Pay is actually available to the customer. Hosted Checkout renders the Google Pay button in accordance with Google’s requirements automatically. If you build your own checkout using the Merchant API or Mobile SDKs, you are responsible for compliance with Google’s brand guidelines. ### Testing Complete all development and validation using the Sandbox environment before processing live transactions. Google provides test cards that can be used in its test environment, so no real transactions take place during development. Before requesting Production activation, verify: * Google Pay is displayed on supported devices and browsers – and hidden where not supported. * Successful payment processing, including the Google Pay payment sheet. * Payments with both credential types where possible – a device token on an Android device and a card on file in a desktop browser – including the 3DS flow where it applies. * Declined payment scenarios. * Refund processing, full and partial. * Callback or webhook notifications. * Order confirmation and status updates. * Recurring payment scenarios (where applicable). ### Merchant Responsibilities Merchants are responsible for: * Displaying Google Pay in accordance with Google’s brand guidelines. * Providing an alternative payment method if Google Pay is unavailable. * Obtaining customer consent before initiating recurring payments. * Keeping merchant profile configuration and any Google-specific registrations valid, where applicable to the integration. * Complying with the Google Pay API Terms of Service, acceptable use policies, card scheme rules, and regulatory requirements. * Following PCI DSS requirements applicable to their payment environment. ### Frequently Asked Questions #### What is the difference between Google Pay and Apple Pay for my integration? Both are digital wallets that deliver tokenized payment credentials to the gateway and are processed like standard card payments. The main practical differences: Google Pay is available on Android devices and in supported browsers on any platform – including desktop – while Apple Pay requires an Apple device; and Google Pay payments made with a card on file (rather than a device token) may involve an additional 3DS authentication step, which the gateway applies automatically. #### Does the merchant ever see the customer’s card number? No. The payment credentials are delivered to the gateway as an encrypted payment token and are never exposed to your systems. Depending on the credential type, the token contains either a scheme-issued device token or the card details in encrypted form – in both cases, decryption and processing happen entirely within the gateway’s PCI DSS compliant environment. #### Do Google Pay payments require 3-D Secure? It depends on the credential type. Payments with device tokens carry device-based authentication and typically do not require a separate 3DS step. Payments with cards on file with Google do not include device authentication, so the gateway applies EMV® 3DS where required. This is handled automatically – no additional integration logic is needed. #### Why is the Google Pay button not displayed to some customers? The button appears only when the customer’s device or browser supports Google Pay and the customer is signed in to a Google Account with an eligible saved card. Regional availability and issuer participation also apply. For merchant-built checkouts, the page must additionally be served over HTTPS. Always offer alternative payment methods. #### Can I use Google Pay for subscriptions? Yes. Google 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. #### Does accepting Google Pay cost extra? Google does not charge customers or merchants transaction fees for using Google Pay. Your standard card processing terms under your merchant agreement apply. ### Related Documentation Continue with the following topics: * [Apple Pay](/payment-methods/wallets/apple-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/google-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.