Google Pay™

Accept Google Pay payments through PayNext.

Google Pay allows customers to make payments using any credit or debit card saved to their Google Account, including those from Google Play, YouTube, Chrome, or an Android device.

Payment Method Details

Customer locations	Worldwide
Supported currencies	All currencies
Recurrent payments	✓
Manual capture support	✓
Refunds	✓
Supported processors	Stripe Braintree Unlimit Worldpay

Overview

PayNext exposes Google Pay wherever your checkout runs as soon as a connected processor supports it. Stripe, Braintree, and Unlimit all provide Google Pay capabilities; PayNext handles token encryption and stores the resulting payment methods for reuse.

PayNext supports two approaches for processing Google Pay tokens — Standard and Native Decryption. Both run in parallel, and you choose which one to use per checkout configuration from the Dashboard.

Prerequisites

• A processor connection (Stripe, Braintree, or Unlimit) with Google Pay enabled
• A Google Pay–capable browser or Android device for testing

Enable Google Pay with your processor

• Stripe: Activate Google Pay under Payments → Payment methods in the Stripe Dashboard. Stripe automatically provisions the Google Pay merchant ID.
• Braintree: Follow Braintree’s Google Pay onboarding (including registering your domain if prompted) and enable the method for the merchant account that PayNext uses.
• Unlimit: Ask your Unlimit account manager to turn on Google Pay for the wallet connected to PayNext.

No additional configuration is required inside PayNext—once the processor reports Google Pay as enabled, the method appears automatically in the dashboard and checkout experiences.

Decryption Approaches

PayNext offers two approaches for handling Google Pay payment tokens. Both coexist and you can switch between them at any time from the Dashboard.

Standard (Evervault Relay)

The default approach. The SDK sends the Google Pay token through Evervault’s relay proxy, which encrypts sensitive card data before it reaches PayNext servers. The encrypted token is then forwarded to the processor.

How it works:

1. Customer authorizes payment via Google Pay
2. SDK sends the token through the Evervault relay
3. Evervault encrypts sensitive fields in transit
4. PayNext receives the encrypted token and routes it to the processor

This is the default behavior when Native Google Pay decryption is turned off in the Dashboard. No additional server-side configuration is required.

Native Decryption

An alternative approach where PayNext decrypts Google Pay ECv2 tokens server-side in a secure isolated environment. Sensitive fields (card number, network token, cryptogram) are re-encrypted before they enter the standard payment pipeline.

How it works:

1. Customer authorizes payment via Google Pay
2. SDK sends the raw ECv2 token directly to PayNext
3. PayNext decrypts the token in a secure environment and re-encrypts sensitive fields
4. PayNext continues standard payment processing with the tokenized result

Native decryption gives PayNext full control over the decryption pipeline, enabling deeper validation and custom logic before the data reaches the processor.

Compare Approaches

	Standard (Relay)	Native Decryption
Token handling	Encrypted in transit by Evervault relay	Decrypted and re-encrypted server-side in a secure environment
Dashboard toggle	Default (off)	Enable Native Google Pay decryption
3DS support	Full (PAN_ONLY + CRYPTOGRAM_3DS)	Full (PAN_ONLY + CRYPTOGRAM_3DS)

Configure Decryption Approach

Switch between Standard and Native decryption from the Dashboard. The SDK reads this setting automatically — no code changes are required on the client side.

1. Open Checkout settings

   Go to Dashboard → Checkout and select Google Pay from the payment methods list.

2. Toggle native decryption

   Enable or disable Native Google Pay decryption. When enabled, PayNext decrypts Google Pay tokens server-side instead of routing them through the relay.

3. Publish changes

   Click Publish to apply the configuration. The SDK picks up the new setting on the next checkout load.

Test the decryption approach in Sandbox before enabling Native Decryption in Production. Verify that payments complete successfully and 3DS triggers as expected.

How the Flag Works

The use_native_decryption flag in the checkout configuration is a client-side signal. It tells the SDK which Google Pay token format to send — the server does not check the flag itself.

1. SDK reads the checkout configuration

   On initialization, the SDK fetches the checkout config from PayNext. Each payment method entry includes use_native_decryption (for Google Pay).

2. SDK chooses the token format

   If use_native_decryption is true, the SDK sends the raw ECv2 token in the google_pay_direct field. If false (default), the SDK routes the token through the relay and sends it in the google_pay field.

3. Server routes by payload

   The server inspects which field is present in the payment request — google_pay_direct or google_pay — and routes accordingly. It does not read use_native_decryption at payment time.

This design means the flag and the payload are always in sync — the SDK is the single source of truth for which format to use, and the server simply reacts to what it receives.

Checkout Implementation

• Checkout SDK: Google Pay buttons render automatically when PayNext detects support from at least one connected processor and the customer’s device meets Google Pay requirements. The SDK reads use_native_decryption from the checkout configuration and chooses the appropriate token format.
• Server-led API: Submit the Google Pay token to the PayNext Payments API using google_pay_direct (for native decryption) or google_pay (for standard relay). The server routes based on which field is present.

Testing

• Add a test card to Google Pay and use Chrome (Desktop) or an Android device to complete flows.
• Stripe and Braintree both provide Google Pay test cards—refer to Stripe’s test cards and Braintree’s Google Pay guide for sample payloads. Confirm the currency matches your merchant account configuration.
• Verify that PayNext records the Google Pay wallet in the payment timeline and that Workflows execute as expected (including 3DS, where applicable).
• When testing Native Decryption, confirm the payment completes successfully end-to-end.

3DS Behavior

Google Pay behavior depends on how the card is tokenized:

• Device-tokenized cards (on Android): Embed 3DS natively with biometric authentication. The first charge includes a wallet-generated 3DS cryptogram, and all subsequent payments use MIT exemptions. 3RI is not supported, as these flows rely on MIT exemptions
• Raw card data: PayNext can run interactive 3DS on the card payment.

Both Standard and Native Decryption approaches support the same 3DS behavior. The decryption method does not affect authentication flow — CRYPTOGRAM_3DS tokens include embedded 3DS, while PAN_ONLY tokens go through PayNext’s external 3DS.

See the 3D Secure guide for full details on wallet authentication behavior.