Best practices

When you accept Google Pay, the wallet returns a Device Token (DPAN) rather than the customer's real card number. Processing a DPAN correctly — especially when you plan to vault it and charge it again later — requires a few rules that aren't obvious from the API alone. This page covers the compliance rules and recommended patterns for vaulting Google Pay DPANs and transacting against them more than once.

Understand how Google Pay tokens work

Google Pay uses a network token, called a Device Token (DPAN), that adds a layer of security beyond the customer's actual card number. The payment data for a DPAN includes:

When Braintree processes a DPAN:

1. Braintree sends some or all of this payment data to the processor.
2. The processor sends the data to the card network.
3. The card network validates the data. It may decline the transaction if the data is invalid, fraud is suspected, or the DPAN's usage doesn't meet the network's specifications and mandates.
4. The card network passes the data to the issuing bank, which makes the final approval decision.

Complete the first transaction before the cryptogram expires

When a customer completes a Google Pay payment, the wallet returns the DPAN along with a newly generated, one-time-use cryptogram. These cryptograms expire in under an hour. If you don't create a transaction or verification soon after receiving the DPAN, the cryptogram can go stale.

A stale cryptogram is declined by the card network, which no longer considers it valid — the customer must re-authenticate to get a fresh one.

The first Customer Initiated Transaction (CIT) must reach Braintree with a valid, unexpired cryptogram. If that first CIT doesn't complete in time, the transaction fails — and because every later Merchant Initiated Transaction (MIT) on that vaulted card links back to this initial CIT, a failed first CIT causes all subsequent MITs to fail too.

Most integrations run an authorization or sale immediately. If your use case needs to delay the charge (for example, free trials or subscriptions), run a $0 authorization as a verification instead of a full charge.

Send the first transaction as customer initiated (CIT)

By definition, the initial transaction on any payment method is customer initiated. Set this with the transaction_source flag when you call transaction.sale().

Customer initiated transactions (CITs) are customer-present transactions.

Send subsequent transactions as merchant initiated (MIT)

Every transaction after the first one on a vaulted DPAN must be sent as merchant initiated (MIT). Set this with the same transaction_source flag.

This distinction matters enough to the network that Braintree forces any later transaction on a vaulted DPAN to be treated as MIT, even if your integration mistakenly specifies CIT.

• If you process decrypted payloads, include the Network Transaction Identifier (NTI) that corresponds to the original CIT on each MIT.
• If you vault externally, or transact across multiple PSPs, provide the correct NTI through the external_vault parameters on the transaction.sale() call, and omit the cryptogram.

Always collect a fresh DPAN when the customer is present

Never reuse a previously vaulted DPAN for a transaction where the customer is present at checkout. For example, don't let a returning customer select a stored Google Pay card from a list of saved payment methods — doing so results in elevated declines.

Instead, present the Google Pay button again and have the customer complete the wallet's authorization flow (device PIN, pattern, fingerprint, or face unlock) to generate a fresh DPAN and cryptogram for that transaction.

Quick reference