Overview
Google Pay uses the same parent-hosted model as Apple Pay: the Google Pay button is mounted on your page (outside the widget iframe) so the browser payment flow is not blocked by cross-origin restrictions. The widget iframe and SDK coordinate viapostMessage to create the transaction and complete payment.
How it works
- You enable Google Pay in
WidgetConfigand provide a container on the host page (default idgoogle-pay-slot, or a custom id viagooglePayContainerId). - The SDK injects a wallet stack above the iframe when Apple Pay and/or Google Pay are enabled (Apple row above Google when both are on).
- The iframe sends transaction parameters to the parent; the parent loads the Paysight client SDK, mounts the Google Pay UI, and returns the wallet result to the iframe for tokenization and
initPayment.
Google Pay collector options (for example requiring payer email and full billing address) are fixed in the widget for consistency with backend expectations. You do not configure those flags in
WidgetConfig.Prerequisites
Widget SDK
Load the Paysight Widget SDK on the same top-level page that will host the wallet button. See Installation.
Google Pay setup
Work with Paysight to ensure your merchant Google Pay configuration and domains match your checkout host. Use HTTPS in production.
Configuration
Widget config
googlePayEnabled(boolean, optional): Turn Google Pay on.googlePayOptions(object, optional): Merchant and button styling.googlePayMerchantId(string, required when Google Pay is enabled): Merchant identifier for Google Pay (from Paysight).style(optional): Presentation options for the Google Pay button.buttonStyle:'black' | 'white' | 'white-outline'buttonType: e.g.pay,checkoutborderRadius,size.width,size.height,locale
SDK / createWidget options
googlePayContainerId(string, optional): DOM id for the Google Pay slot. Defaults togoogle-pay-slot. The vanilla SDK can create the stack and slot if missing; you can also place the element yourself.
applePayContainerId alongside googlePayContainerId when offering both wallets.
Related flags
showOnlyWalletMethods: Wallet-first checkout—hide the card form and “OR” divider when wallets are ready; automatic fallback when needed. See Wallet-only checkout and the Configuration Guide.threeDSRequired: Whentrue, Google Pay follows the same 3DS path as card payments (in-widget challenge + outcome reporting).
Implementation examples
Customer and billing data
Google Pay may return billing contact in a different shape than Apple Pay (for example a singlename and address lines). The widget normalizes billing contact for the payment API and still uses your customer / form data where the wallet does not supply a value.
Testing and troubleshooting
Chrome + HTTPS
Prefer HTTPS and a normal Chrome profile with Google Pay configured. On
http://localhost, the browser may log manifest or permission warnings that are usually benign for local development.Iframe URL vs environment
Keep
environment aligned with the Paysight deployment you are testing (sandbox vs production) so the iframe origin and your credentials match. See Apple Pay via Widget for host vs iframe deployment notes.Payment manifest console message
Chrome may log messages about loading Google’s payment method manifest. This is part of the standard Payment Request / wallet pipeline and is not something you proxy through your app. If Google Pay were inside a cross-origin iframe, that iframe would needallow="payment"; the Paysight pattern avoids that by mounting the button on the parent page.
See also
Wallet-only checkout
Hide the card form and lead with Apple Pay and/or Google Pay.
Configuration Guide
All widget options, including
showOnlyWalletMethods.Apple Pay via Widget
Parent-hosted Apple Pay (same architecture).
3DS via Widget
threeDSRequired and wallet payments.Configuration Reference
Field-by-field reference tables.