Google Pay
Google Pay lets customers pay using cards saved to their Google account with a single tap.
Prerequisites
PaymentKit.js checks Google Pay availability automatically when it initializes — there’s no manual prepare step. You reveal your button once the SDK reports it’s ready (see Show the express button), and the customer’s tap submits the payment.
PaymentKit.js routes Google Pay through whichever processor your account has configured, and each processor relies on a different browser library. PaymentKit does not inject these scripts for you—add the one matching your processor (or both, if you’re unsure which one the backend will select).
Google Pay readiness only succeeds when the checkout session’s account has an express-checkout processor configured with Google Pay enabled. If none is configured, the SDK stays in the not-ready state and your onGooglePayReady callback reports false — so your button never appears.
Stripe processor
Airwallex processor
Add Stripe.js to your page. Google Pay rides Stripe’s Payment Request API:
The processor is selected by the backend, so if your account can route to either processor, include both scripts. Loading only Stripe.js will cause Google Pay to fail on Airwallex processors with Google Pay API not loaded.
Airwallex processors must also have Google Pay activated in your Airwallex dashboard. Enabling Google Pay in your PaymentKit dashboard alone is not enough — Google Pay must be enabled as a payment method on your Airwallex account before it can be tested or charged. If it isn’t activated on the Airwallex side, the Google Pay sheet will fail to complete even when your PaymentKit configuration and page scripts are correct.
Setup
CDN
NPM/ES Modules
Choose the wallet processor
By default the SDK auto-selects your account’s Google Pay express-checkout processor. If you have more than one account (Stripe or Airwallex) and want a specific one to handle Google Pay, pass processorIds when you construct PaymentKit — a map of payment method to processor id. The SDK then mints and charges Google Pay on the exact account you name (Stripe PaymentMethods are account-scoped, so mint and charge must stay on the same account — this keeps them aligned).
Pass ids only; the processor family (Stripe/Airwallex) is resolved from your account. Apple Pay and Google Pay are set independently — use the googlePay key here:
processorIds is read once, when PaymentKit is constructed, and applies for that instance’s lifetime. To steer Google Pay per checkout — e.g. the EU account for EU shoppers, the US account for US shoppers — compute the id and pass it when you initialize PaymentKit for that session. A single instance reused across checkouts keeps its original value until you re-init.
Leave googlePay out of processorIds (or omit processorIds entirely) to keep the automatic express-checkout selection. The processor family (Stripe or Airwallex) is resolved from your account — the SDK looks the pinned id up in the account’s wallet processors — so pinning an Airwallex processor routes through the Airwallex flow automatically, with no type field to set. If the pinned id isn’t one of the account’s Google-Pay-eligible processors for the session, Google Pay simply stays unavailable (onGooglePayReady stays false) rather than failing mid-payment.
Show the express button
The SDK checks Google Pay availability automatically when it initializes. Use onGooglePayReady to show or hide your express button, and notifyAmountChanged to re-prepare whenever the amount changes.
React to readiness
Register a callback with onGooglePayReady. It fires immediately with the current state, then again on every change. Register as many callbacks as you need — none are overwritten.
While the SDK is re-preparing (see below), it reports isReady: false, then true again once it’s ready — so the same callback naturally hides the button during the gap.
Re-prepare after the amount changes
Whenever the cart total changes — a coupon is applied, quantity is updated, shipping is added — call notifyAmountChanged() so the SDK clears the stale session and prepares a fresh one with the new amount. It returns a promise that resolves once Google Pay is ready again.
Your onGooglePayReady callback fires across the re-prepare (false while in flight, then true), so the button hides and reappears on its own. Calling it again while a prepare is already running coalesces the calls — the promise resolves once the latest prepare completes.
onGooglePayReady and notifyAmountChanged are methods on paymentKit.google_pay.
Submit payment
Attach submit to the same button you reveal with onGooglePayReady. In the auto-prepare flow the SDK fills the processor from the checkout session, and Google Pay collects the payer’s details from the sheet — so you don’t pass processorId.
Which account handles the wallet. For Stripe, the Google Pay PaymentMethod is minted in the browser on the processor used to prepare the sheet, and Stripe PaymentMethods are account-scoped — so the payment is always charged on that same processor. Choose the account with the processorIds init option (or the account’s express-checkout processor when unset). A different processorId passed at submit is ignored for an already-prepared sheet and logs a warning — the SDK keeps mint and charge on one account.
Options
Browser support
Google Pay works on:
- Chrome 61+ on Android devices (with a card saved to Google Pay)
- Chrome 61+ on desktop (with a card saved to Google Pay)
- Microsoft Edge on desktop (with a card saved to Google Pay)
Depending on your processor, PaymentKit.js routes Google Pay through either Stripe’s Payment Request API (Stripe) or Google’s native Pay API (Airwallex). Both have specific browser requirements. Safari on iOS does not support Google Pay—use Apple Pay instead.
Google Pay isn’t available on all devices. Always provide card payments as a fallback.