Ways to tokenize Google Pay instruments
Before a Google Pay token can be used in Instant proxy, we need to tokenize it and create an Instrument for it. Check our Google Pay guide for detailed information on how to set up a new integration. Payrails offers multiple ways to tokenize the card information, depending on the PCI DSS scope you are willing to own, the requirements about the level of control you need on your checkout page, and ease of implementation. Here’s a table comparing your options from a high-level perspective:Server-to-Server (Merchant decryption)
This integration method allows merchant to maintain control over their Google Pay integration. Merchants implement the Google Pay SDK integration and decryption of the Google Pay token and directly provide the decrypted token to Payrails.Server-to-Server (Payrails decryption)
In this integration method, the merchant maintains control over their Google Pay integration, but they do not maintain the keys needed to decrypt the Google Pay tokens. This provides increased PCI compliance on the merchant side while still allowing merchants to customize the SDK integration as they see fit.Elements SDK
Payrails Elements are payment UI components you can assemble together to build a payment form, giving better flexibility than Drop-in with the ability to manage each element separately. Check our Elements guide for more detailed information. Elements provides merchants with easy integration to Google Pay tokenization without having the need to set up any integration with the Google Pay SDK directly. Payrails manages all the keys needed for completing the Google Pay session and detokenization, reducing all merchant overhead. Check out the Google Pay Button Element for a detailed guideSetting up the Google Pay button element for tokenization
Perform Client init with Intent “tokenization”
- Perform a Client init with intent “tokenization`
- Provide the amount in
amount
Render the Google Pay button
- Listen to the
onSuccesscallback for an event of typetokenizeto get the details for the newly created Google Pay Instrument
Using Google Pay instrument in Instant Proxy
With the instrument created you can now forward it your payment providers via Instant Proxy. Checkout out the Instant Proxy a detail guide.Figuring out if the instrument contains a Card or Network token
Google Pay payment tokens can provide either a FPAN (real card) or DPAN (network token) information when decrypted. Most payment providers require a subtle difference in the request based on what type of card information was provided by the payment token. You can find out what type of card information was present in the payment token by looking at the type of instrument token created for it. Fetch the instrument details using the Get Instrument withinclude_tokens true.
- If type is
vaultit means the payment token contains a Card FPAN - If type is
networkTokenit means the payment token contains a Network Token DPAN
Prepare the request body you want to pass to the payment provider based on the provider’s API contract.
This request will include fields that are non-sensitive (i.e. amount), as well as the card information that is PCI sensitive. You will put{{key}} in the place of the sensitive fields, while forwarding the rest of the payload as it is. Read in the next section what the key variables you will use are in more detail.
This is the body object you will see under Vault Proxy API.
Prepare the request headers that are needed to be passed to the payment provider
The payment providers typically require certain headers to securely receive a request from the senders, such as authentication or authorization keys. In order for us to send a request to the payment provider, we need to provide those headers when forwarding your request to the provider. You will provide all required header information defined by the provider’s API contract. This is theheaders object in Vault Proxy API.
Prepare the URL of the provider that you want Payrails to forward the request.
You have to define a destination URL path for every proxy request that you want to send. This is the URL of the API endpoint of the payment provider. You will pass it to Payrails, so that we can send your request body and headers you prepared in the previous steps to the designated URL. This isurl object in Vault Proxy API.
Below you can find some examples of some well-known providers and how you should map the card data using our instruments.
Checkout
Stripe
{{key}}s for cards and network tokens, when sending payment authorization requests to payment providers.
Cards
- For card number, use
{{cardNumber}} - For cardholder name, use
{{cardHolderName}} - For card security code (or CVV, CVC, etc), use
{{cardSecurityCode}} - For the card expiry month, use
{{cardExpiryMonth}}or{{MM}} - For the card expiry year, if:
- 4-digit card expiry year, use
{{cardExpiryYear}}or{{YYYY}} - 2-digit card expiry year, use
{{cardExpiryYear2Digits}}or{{YY}}.
- 4-digit card expiry year, use
Network tokens
- For network token number, use
{{networkTokenNumber}} - For cryptogram, use
{{networkTokenCryptogram}} - For the expiry month of the network token, use
{{networkTokenExpiryMonth}} - For the expiry year of the network token, if:
- 4-digit expiry year of the network token, use
{{networkTokenExpiryYear}} - 2-digit expiry year of the network token, use
{{networkTokenExpiryYear2Digits}}
- 4-digit expiry year of the network token, use