Skip to main content
Google Pay Google Pay is supported both on the web and in Android apps. In both environments, Google Pay can be integrated using the SDK and without the SDK. Both PAN_ONLY and CRYPTOGRAM_3DS authentication methods are supported for Google Pay.
  • PAN_ONLY - the card is stored on file within your customer’s Google Account and not bound to an Android device.
  • CRYPTOGRAM_3DS - the payment credentials are bound to an Android device.
On a Google Pay transaction, payment_method.method describes how the buyer paid, while payment_method.scheme holds the brand of the underlying card, for example amex. Depending on the card, Google Pay returns either a device token with a cryptogram or the card’s own number without a cryptogram. Google calls these CRYPTOGRAM_3DS and PAN_ONLY. A CRYPTOGRAM_3DS payment has a method of googlepay, and a PAN_ONLY payment has a method of googlepay_pan_only. The system passes either kind to your card connection, and the connection and issuer can treat them differently.

​
Web (Embed)

On the web, Google Pay can be easily integrated both with and without Embed. In both offerings, the need to sign up for a Google Developer account has been removed, reducing additional financial and maintenance costs.
An OR_BIBED error from Google Pay on the web usually means the domain passed to the API doesn’t match the page’s domain. See Set the merchant info.

​
Mobile (Android)

On Android, Google Pay can be easily integrated both with and without the SDK. In both offerings, the need to sign up for a Google Developer account has been removed, reducing additional financial and maintenance costs.

​
3-D Secure

Google Pay can return two kinds of credentials:
  • A device token (CRYPTOGRAM_3DS), which carries a cryptogram. Gr4vy doesn’t run 3-D Secure for these.
  • A card saved in the buyer’s Google Account (PAN_ONLY), which is common on the web. Gr4vy processes these like any other card, so 3-D Secure can apply when it’s turned on for the connection.
When 3-D Secure applies, the transaction returns the status buyer_approval_pending. Send the buyer to the payment_method.approval_url, even if no challenge is shown, and include a redirect_url when you create the transaction. If the buyer isn’t sent to the approval URL, the transaction fails when the approval expires. Embed handles this for you. For integrations without Embed, see handle a redirect.

​
Recurring payments

This is in limited release and is being made generally available soon.
Recurring payments are supported on Google Pay in a similar way to how recurring payments are supported for regular card payments.
  1. Take the first payment with the Google Pay token and store: true, with merchant_initiated and is_subsequent_payment set to false and a payment_source such as recurring. This stores the Google Pay payment method.
  2. Charge later payments with the stored payment method id, the same payment_source, and merchant_initiated and is_subsequent_payment set to true.
A stored Google Pay payment method has no cryptogram, because the cryptogram only exists for the original payment on the buyer’s device. Later payments rely on the recurring flags and the scheme transaction ID from the first payment instead, so payment services may decline a later payment that’s sent with the flags of a first payment.