Google Pay and Apple Pay liability shift & authentication – a merchant’s guide

One in four merchants rank Google Wallet and Apple Pay in their top two most fraudulent payment methods, per Ravelin’s latest Payments Report. We’ve discussed fraud on digital wallets before, presenting an intro to how it’s done and the basics of how it can be stopped.

Today, we’ll look at how Google Wallet and Apple Pay payments are processed, authenticated – and consequently treated by issuers and card schemes when there are suspicious transactions.

Along the way, we’ll also give you advice for accepting these payment methods without compromising your security.

Google Wallet payments & chargebacks

Linked to a consumer’s Google account, the convenience of Google Wallet, also known as Google Pay, is unmistakable. Adding it as an option for customers can therefore increase traffic as well as reduce friction.

It enables 820+ million shoppers globally to enjoy minimal friction when buying from a merchant, even if they have never visited that shop before. Considering the estimated 2.5 billion active Google accounts around the world, future opportunities for those who accept the method seem lucrative.

However, if you accept this payment type without considering how it affects your dispute/chargeback rate and liability, you’re both missing a trick and risk getting on merchant monitoring programs such as Visa’s VAMP “excessive disputes” tier.

According to the official Google Pay help center, users can dispute payments by going through their card issuing bank: “If you find a payment that you don’t recognize, contact your bank or the branch where the payment was made.”

However, merchants report that these chargebacks are among the most difficult to challenge successfully. In three separate annual surveys, merchants ranked Google Pay disputes as the most difficult payment method to challenge.

At Ravelin, internal investigations have seen cases where fraud attacks leverage inconsistencies in payment data. These attacks can sometimes be linked to specific banks or regions.

Where does SCA liability fall when you use Google Pay?

For merchants using 3DS protocols, Google Pay can support liability shift in Europe under certain conditions. However, implementation and effectiveness may vary, so pre-auth checks remain strongly recommended.

Liability shift to issuers is supported by Google Pay only for qualified facilitated transactions that use Mastercard and Visa Android device tokens – CRYPTOGRAM_3DS.

In the context of this, it’s important to understand that there are two types of Google payments, grouped according to the presence of Android device tokens:

1. CRYPTOGRAM_3DS payments – the safer, tokenized option

With CRYPTOGRAM_3DS, the shopper’s cards are both added to Google Wallet and stored as Android device tokens. Returned payment data includes a 3D Secure cryptogram generated on the device. Often, when Google Pay is discussed, it is the CRYPTOGRAM_3DS method that is considered the only type of payment.

This type of cryptogram payment is fully authenticated by the issuer and therefore also SCA compliant. Merchants will achieve a liability shift (to the issuer) on any transactions globally with Mastercard, Visa and Discover, but not American Express or JCB.

There is increased security for customers using this method, because it only uses a tokenized version of the PAN (DPAN).

2. PAN_ONLY Google payments – not SCA compliant, with considerably more risk

The shopper’s cards are added to Google Wallet, stored on file with the user’s Google Account, but not tokenized on an Android device.

PAN_ONLY payment cards can be added without any issuer authentication and carry considerably more risk. These use the full PAN (FPAN), with the expiration month and expiration year.

PAN_ONLY payments are not Secure Customer Authentication (SCA) compliant and do not support liability shift.

How should merchants approach Google Pay payments?

There are three options available to merchants, depending on their integration with their PSP(s), their integration with any 3DS solutions, as well as their own risk tolerance to handle payments coming through Google Pay:

1. Accept both CRYPTOGRAM_3DS and PAN_ONLY transactions. When doing so, send all PAN_ONLY payments to 3DS and decline any that fail authentication. The data that is needed to do this can be sent in two standard fields in the payment method object – accountVerified and cardHolderAuthenticated Google Pay response fields.
   
   

2. Accept only CRYPTOGRAM_3DS transactions and do not offer PAN_ONLY as a payment option. This can be achieved through configuring the allowedAuthMethods of your Google Pay integration.
   
   

3. Do not accept any Google Pay/Wallet. If a merchant is not able to receive the required fields to distinguish between the Google Pay traffic for whatever reason, there is a risk of increased fraud. If this risk is too great, choosing not to offer Google Pay at all might be a better solution.

Ravelin’s advice for accepting Google payments

We consider the best option for merchants to be accepting both CRYPTOGRAM_3DS and PAN_ONLY transactions, sending PAN_ONLY to 3DS. This maximizes the number of customers you can serve, but it also depends on your technical setup.

Refusing PAN_ONLY transactions would discourage some shoppers and reduce checkouts, so you will want to be confident that the vast majority of your customers only use Google Pay via Android devices.

The third option, not accepting Google Pay at all, is recommended for merchants who have limited capability to distinguish between the two types – CRYPTOGRAM_3DS and PAN_ONLY. However, one could, in theory, still support this payment method and send all transactions to 3DS, erring on the side of caution. While this is likely to cause some customer insults and churn, this would probably happen to fewer customers than not supporting Google Pay at all.

Apple Pay payments & chargebacks

Apple Pay fraud primarily occurs when fraudsters add stolen or fake credit card details to Apple Pay wallets and use them for purchases. Even though Apple Pay uses biometric authentication and encryption, these measures can be bypassed if onboarding is not strictly verified, allowing fraudulent transactions to happen both online and in-store.

The fraud happens at the point of adding the card to the device, rather than when the Apple Pay transaction occurs. The lack of a contactless spend limit makes high-value in-person fraud feasible if a stolen card is added to a phone.

Fraud rates with Apple Pay tend to vary by sector. Fraud tends to be higher in sectors with more physical goods and higher-value transactions – including luxury clothing, beauty and electronics retail. Such goods have higher resale value, so the fraudsters have more to gain from targeting them.

Where does SCA liability fall for Apple Pay?

Authentication is also important when considering liability for Apple Pay. Generally speaking, when the payment is authenticated, the liability shifts away from the merchant.

Apple Pay uses network tokens (DPAN) plus a device cryptogram for tokenization. This would be the equivalent of the CRYPTOGRAM_3DS method we saw above on Google Pay.

Having the shopper confirm using any type of on-device authentication – FaceID, TouchID or passcode – is treated exactly as if the shopper has passed 3D Secure authentication and counts as equivalent to SCA.

Specifically:

• For Apple Pay payments that have passed 3D Secure, FaceID, TouchID or passcode, the liability typically shifts to the card issuer, although the specifics can vary by country, card scheme and merchant acquirer.

• In regions that require PSD2 SCA, including the UK and EEA, Apple Pay satisfies SCA. Generally speaking, the liability sits with the issuer.
  
  

• If an authentication exemption was used per SCA requirements, expect no liability shift unless the exemption was issuer-side. For merchant-requested exemptions, the liability will sit with the merchant.

Note that exact outcomes depend on card scheme rules, region, acquirer, and whether all the required auth data made it into authorization.

How should merchants approach Apple Pay payments?

As a merchant looking to make customer journeys as smooth as possible while minimizing risk, look at when and if your liability shifts and take this into account in your fraud strategy:

• Spot check the authorization data on some Apple Pay transactions. Look for an ECI value and CAVV/AAV.

• For Visa, look for codes 05 (authenticated) and 06 (attempted) – liability has shifted. For Mastercard, look for 02 (authenticated) and 01 (attempted). Visa 07 or MC 00 signal no shift.

• Check your PSP, acquirer and/or 3DS product dashboard for liability shift indicators.

• Remember that even with liability shift, disputes may still appear in monitoring programs such as Visa’s VAMP. While the financial liability may sit with issuers, the activity may still count for card scheme monitoring.

Fraud risks from Apple Pay and Google Pay payments

Fraud risk and operational burden on alternative payment methods, including Google Pay and Apple Pay, are generally higher than on traditional credit/debit cards. This is largely due to the historical prevalence of traditional methods.

However, as we’ve seen, options such as the CRYPTOGRAM_3DS flow make these more secure. For PAN_ONLY – without 3DS – transactions (only applicable to Google Pay and those Apple Pay transactions where authentication exemptions is used by merchants, the fraud threat can be higher.

What’s more, Account takeover (ATO) and synthetic identity fraud remain risks related to these digital wallets.

Fraudsters can combine stolen Google accounts and stolen card credentials to further obscure themselves and attempt enumeration/card testing payments, as well as other fraudulent schemes.

How to stop fraud on Google and Apple Pay

To mitigate fraud on Google and Apple Pay, best practices include:

• performing pre-authentication fraud checks,

• monitoring for unusual activity (device or IP anomalies)

• Implement ATO solutions at both login and checkout

• encouraging the use of biometric authentication and strong passwords
  

It’s important to update fraud detection models or rules, especially if certain thresholds or patterns (such as order amount ranges) are being manipulated by fraudsters.

It's been observed that using simple order price thresholds can be gamed, as fraudsters place orders just below the block limit. Moreover, with Visa’s new enumeration penalties per the VAMP program, even low price transactions can become a major issue.

Ravelin offers sophisticated fraud prevention solutions that protect the entire user journey, including a payment fraud solution and 3D Secure Server & SDKs.