Skip to main content

Google Pay

paymentType: "GOOGLE_PAY_US".

This page covers what's specific to the Google Pay express button of <swirepay-checkout>. For the shared integration flow, props reference, error/success payloads, theming, and testing, see SDK setup & flow; for minting the checkout session, see Checkout session.

Behavior​

  • Not supported for inventory-order checkouts — if included in an order-scope session's paymentType, it's silently dropped and the button won't render.
  • The button is not guaranteed to render just because GOOGLE_PAY_US is in paymentType. At mount time the widget:
    1. Loads Google's Pay JS API alongside a PayPal-powered configuration bridge (the same underlying integration that backs Apple Pay).
    2. Calls Google's own isReadyToPay(...) device/browser eligibility check.
    3. Also checks merchant-level eligibility via that configuration bridge (whether Google Pay is actually enabled for your merchant account/currency).
  • These two checks behave differently:
    • Device-level — isReadyToPay(...) (the shopper's browser/device genuinely can't do Google Pay) is silent by design: no errorCallback, the button simply doesn't render.
    • Merchant-level — whether Google Pay is enabled for your account/currency — fires errorCallback if ineligible, so you can observe and log it. This differs from Apple Pay, whose equivalent device-level check does fire errorCallback — see Apple Pay.
  • Requires the page be served over HTTPS (Google Pay's API requires a secure context).
  • Test mode runs against the PayPal-powered configuration bridge's own sandbox — no real charge occurs, and no separate Google Pay merchant configuration is needed to test (see SDK setup & flow → Live vs. Test mode).
  • Merchant currency determines which country Google Pay is configured for: USD → US, INR → IN, CAD → CA (defaults to US for any other currency).
  • Always combine GOOGLE_PAY_US with at least one other paymentType (typically "CARD") so shoppers on unsupported browsers still have a way to pay.

Pitfalls​

  • Testing over plain HTTP — the button will not render.
  • Expecting an error when the button doesn't render due to device ineligibility — that's silent by design. A merchant-level ineligibility, though, does fire errorCallback — don't assume every non-render is silent.

See SDK setup & flow → Common pitfalls for pitfalls that apply across all payment methods.

On this page