Don’t do business without options. Risk comes from not having options, and as Tony Soprano would like to remind you, “You’ve always got options.”
Consider having options when supporting Apple and Google Pay.
When a merchant considers a multi-PSP strategy, it’s primarily for accepting and collecting credit card information. And for good reason, with global credit card transaction volumes exceeding $3.6 trillion.
Right alongside is Apple Pay and Google Pay usage, two contactless payment options growing in popularity. Apple Pay is accepted in 90 countries and can be activated on nearly all iPhones—while Google Pay is accepted at millions of supermarkets, pharmacies, gas stations, and clothing stores. Full-service PSPs can set up both Apple Pay and Google Pay to a checkout or hosted payment page with very little work from the merchant.
As more merchants form multiple PSP relationships, being able to debundle Apple Pay and Google Pay from a single processor unlocks similar authorization and retention benefits afforded to merchants with credit card transactions. Churn can be reduced by implementing a backup PSP or more sophisticated intelligent routing.
From the merchant’s perspective, executing a multi-PSP approach with these two payment methods is not as simple. The complexity of the different data types, paired with the challenge of finding multiple processors who can support the encrypted payloads, is enough to outweigh the conversion or retention bonus.
To assist merchants in setting up Apple Pay and Google Pay, Basis Theory streamlined the implementation of these payment methods and a programmable payment vault. Our documentation on each is below.
Apple Pay Implementation
Know some of the key concepts about Apple Pay:
- Device Primary Account Number (DPAN): Apple’s equivalent to a Network Token. Also known as “DAN” or “Application PAN.”
- Funding Primary Account Number (FPAN): The physical or virtual card number.
- Apple Pay Token: This is a payment token issued by the device upon user approval via biometric authentication (Face ID or Touch ID). It carries transaction information, including an encrypted form of DPAN and payment cryptogram.
- Merchant ID: An Apple Identifier refers to a Merchant when processing payments with Apple Pay.
- Certificate Private Key: private key used to generate the Certificate Signing Request and to decrypt Apple Pay tokens.
- Certificate Signing Request: a message file (.csr) uploaded to Apple requesting the issuance of a Certificate.
- Payment Processing Certificate: an Apple-issued certificate used to decrypt Apple Pay tokens. This is associated with a Merchant ID.
- Merchant Identity Certificate: an Apple-issued certificate used to perform two-way TLS against Apple servers when consuming their services. For example: authorizing a new Apple Pay session.
- Merchant Domain: a verified domain authorized to create browser Apple Pay sessions.
Apple created the DPAN, which is essentially a network token that is not bound to a single merchant. When a card is added to a mobile device, but used in two different websites, the DPAN will remain the same. The merchant is not exposed to the DPAN.
When the card is added to a new mobile device, a new DPAN is created. Merchants are not exposed to the PAN; they are exposed to the DPAN.
Google Pay Implementation
The Apple Pay and Google Pay implementations are quite similar, with Google offering a version of the DPAN or PAN depending on how the card was added.
Know some of the key concepts about Google Pay:
- Google Pay Token: A payment token issued upon user approval. It carries transaction information, including an encrypted form of the payment method selected. It is returned to the integrating party (usually a merchant) frontend (web or mobile.)
- Tokenization specification/method: The strategy chosen by a merchant while integrating with Google Pay. Options are Payment Gateway and Direct, which can be informed in the tokenizationSpecification.type parameter of a Payment Request:
- PAYMENT_GATEWAY: The resulting Google Pay Token is encrypted with the Gateway's public key, and merchants are instructed to pass the token directly to the Gateway without modification
- DIRECT: The resulting Google Pay Token is encrypted with the Merchant's public key, and they must decrypt it on their own. To qualify for this, merchants must be PCI DSS Level 1 compliant.
- Authentication Method: Condition used to authenticate a card against a processor. Google Pay supports two: PAN only and Cryptogram 3DS. Google Pay also enables developers to inform the allowedAuthMethods parameter, in order to filter cards for payers when selecting which card to pay for the transaction:
- PAN_ONLY: This authentication method is associated with payment cards stored on file with the user's Google Account. Returned payment data includes personal account number (PAN) with the expiration month and the expiration year.
- CRYPTOGRAM_3DS: This authentication method is associated with cards stored as Android device tokens. Returned payment data includes a 3-D Secure (3DS) cryptogram generated on the device.
Google has an overview page that shows the workflow of Google Pay for merchants and processors.
PCI Level 1 merchants can create a Reactor and leverage our decryption package to debundle the Google Pay token. Non-PCI Level 1 merchants can become verified payment providers for Google Pay with the token decryption happening in the background and is managed by Basis Theory.
Basis Theory can receive payment tokens from Google Pay in the background, which can contain the PAN or an authorized Device PAN (essentially a Network Token), along with a 3DS cryptogram.
A token is returned to the merchant, which can be used to route the payment information to any processor. In cases where the PAN is returned, the merchant can prompt the user to recollect the CVC and perform a pristine credit card transaction against the PSP.
Debundling Apple and Google Pay
Most merchants will work with a single PSP and send all of their Google Pay or Apple Pay transactions to that processor. However, the need for redundancy becomes clear as authorization rates decrease, customers churn, and money is left on the table.
What used to take a week can now take an hour, and be as configurable as adding a button on a checkout page—then sending the payload to Basis Theory using a token or token intent.
“This is more about having fewer things that can go wrong,” explains James Armstead, VP of Product at Basis Theory. “There used to be more than 20 steps to implement Apple Pay or Google Pay. Now if you want to send that transaction between three PSPs, the merchant doesn’t have to go through those steps to implement. It’s much more streamlined.”
When a merchant wants to use the DPAN more flexibly, it can be decrypted, tokenized, and used through the Basis Theory proxy!
