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.

​

Prerequisites

Google Pay is a wallet, not a payment processor. The system integrates with Google directly for the wallet itself: it runs the Google Pay session and decrypts the payment token, which is why no Google gateway setup is needed. The result is still a card payment, and one of your card connections has to authorize it. To accept Google Pay, you need:

• A card connection that supports the transaction’s currency and country.
• A payment service that accepts decoded Google Pay tokens. Because the system decrypts the token, it sends decoded device tokens to your payment service instead of encrypted gateway tokens. Not all payment services support these, and some need the feature switched on, so check with your payment service provider.

Google Pay payments are routed like any other card transaction, through the card transactions Flow. To send them to a particular connection, add a rule with the Card source condition set to Google Pay. 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.

​

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

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.