In a recent conversation with Nilesh Payghan, it was revealed that there’s exciting news for users and developers involved with Google Pay. Specifically, the conversation brought to light that Visa device tokens are now generally available and come with a significant enhancement: the liability shift. This means that, similar to Mastercard device tokens where the issuing bank takes on the liability, Visa has updated its policy. However, there’s a catch; this advantageous shift applies only to certain eligible device tokens. To be more precise, it benefits those with issuing banks located in the European region. This development marks a notable milestone in the evolution of payment security and efficiency within the Google Pay ecosystem, reflecting a proactive approach to addressing the complex needs of its global user base.
Table of Contents
Understanding Liability Shift in Google Pay Transactions
What is Liability Shift?
Liability shift is a concept that, when applied to a transaction, transfers the responsibility for covering losses due to fraudulent transactions from the merchant to the issuing bank. This means that for specific Google Pay transactions made with a Visa device token that qualify, the liability shift will apply, offering an added layer of protection to merchants.
Join Our Whatsapp Group
Join Telegram group
Identifying Transactions with Shifted Liability
To determine whether a transaction has had its liability shifted to the issuing bank, there’s a simple method. Eligible Visa transactions will have an eciIndicator value of 05. Payment Service Providers (PSPs) can find the eciIndicator value by decrypting the payment method token. Merchants are encouraged to communicate with their PSPs to obtain reports on transactions eligible for liability shift.
Example of a Decrypted Payment Token
Consider the following decrypted payment token as an example for a Google Pay Visa transaction:
- gatewayMerchantId: “some-merchant-id”
- messageExpiration: “1561533871082”
- messageId: “AH2Ejtc8qBlP_MCAV0jJG7Er”
- paymentMethod: “CARD”
- paymentMethodDetails:
- expirationYear: 2028
- expirationMonth: 12
- pan: “4895370012003478”
- authMethod: “CRYPTOGRAM_3DS”
- eciIndicator: “05” (indicating liability has shifted)
- cryptogram: “AgAAAAAABk4DWZ4C28yUQAAAAAA=”
This is a prime example of a transaction where the liability has successfully shifted, indicated by the eciIndicator value of 05.
Understanding eciIndicator Values
It’s helpful to know the eciIndicator values and their meanings. Below is a concise table summarizing the values, the card network they apply to, the liable party, and the authorization method:
eciIndicator Value | Card Network | Liable Party | authMethod |
---|---|---|---|
“” (empty) | Mastercard | Merchant/Acquirer | CRYPTOGRAM_3DS |
“02” | Mastercard | Card issuer | CRYPTOGRAM_3DS |
“06” | Mastercard | Merchant/Acquirer | CRYPTOGRAM_3DS |
“05” | Visa | Card issuer | CRYPTOGRAM_3DS |
“07” | Visa | Merchant/Acquirer | CRYPTOGRAM_3DS |
“” (empty) | Other networks | Merchant/Acquirer | CRYPTOGRAM_3DS |
It’s important to note that any eciIndicator values for Visa and Mastercard not listed in the table above will not be returned. This table serves as a guide for merchants and PSPs to better understand the liability status of their transactions in the context of Google Pay.
Guide to Enrolling in Liability Shift with Google Pay
Starting the Enrollment Process
Merchants interested in opting for the liability shift with Google Pay can begin the process from within the Google Pay & Wallet console, starting this month. For merchants operating in Europe, who are already enjoying the benefits of liability shift, there’s good news: you’re set to be automatically enrolled, so no further action is required on your part.
Key Requirements for Liability Shift Eligibility
For a Google Pay transaction to be eligible for the liability shift, certain API parameters must be meticulously followed:
- TotalPrice: It’s crucial that the
totalPrice
accurately reflects the charge made to the user. Note that transactions listed with atotalPrice
of 0 are automatically disqualified from the liability shift process. - TotalPriceStatus: This parameter can either be set to
FINAL
orESTIMATED
. Transactions marked with atotalPriceStatus
ofNOT_CURRENTLY_KNOWN
are ineligible for liability shift.
Understanding Restrictions
Not every merchant or transaction is eligible for liability shift. Here are some specific exclusions to keep in mind:
- Ineligible Merchants in the US: Certain Merchant Category Codes (MCC) do not qualify for liability shift. These include sectors like money transfer services, direct marketing inbound services, non-financial institutions dealing with non-fiat currency, stored value card purchase/load, online gambling licensed by the government, licensed horse/dog racing, and betting establishments including those dealing with lottery tickets, casino chips, off-track betting, and other games of chance.
- Ineligible Transactions: To ensure your transactions are eligible, include the necessary
totalPrice
andtotalPriceStatus
parameters. Transactions that do not meet these criteria, including those with a hard-codedtotalPrice
that doesn’t match the charged amount, will not qualify.
Processing Transactions for Liability Shift
While Google Pay API transactions using Visa device tokens can qualify for liability shift at the time of facilitation, it’s important to note that eligibility can be downgraded by the network during the authorization process of the transaction.
Getting Started with Google Pay
If you’re not already utilizing Google Pay, now is the perfect time to integrate this payment method. Extensive documentation is available to guide you through the process, along with a sample application for Android on GitHub for a hands-on understanding. For web integrations, Google provides button components to ease the process. Once you’re set up, simply submit your integration through the Google Pay & Wallet console to gain production access. This is your gateway to a smoother, more secure transaction process that benefits both you and your customers.
Join Our Whatsapp Group
Join Telegram group
FAQs on Liability Shift with Google Pay
What is Liability Shift in Google Pay Transactions?
Liability shift in Google Pay transactions refers to the transfer of responsibility for losses from fraudulent transactions from the merchant to the issuing bank. This applies to specific transactions made with a Visa device token that meet the criteria, offering merchants added protection.
How Can I Identify Transactions with Shifted Liability?
Transactions with shifted liability can be identified by an eciIndicator
value of 05. Payment Service Providers (PSPs) can find this value by decrypting the payment method token. Merchants should contact their PSPs to obtain reports on transactions eligible for liability shift.
What Does a Decrypted Payment Token Look Like for Transactions with Shifted Liability?
A decrypted payment token example for a Google Pay Visa transaction with shifted liability would include details like gatewayMerchantId
, messageExpiration
, messageId
, paymentMethod
, and paymentMethodDetails
with eciIndicator
set to “05”.
What are the eciIndicator Values and Their Meanings?
The eciIndicator
values indicate who is liable (the merchant or the card issuer) and the authentication method used. For Visa transactions showing “05”, the liability shifts to the card issuer. Other values are designated for different scenarios and card networks.
How Do I Enroll in Liability Shift with Google Pay?
Merchants can opt-in for the liability shift within the Google Pay & Wallet console. European merchants benefiting from liability shift are automatically enrolled and do not need to take further action.
What Are the Key Requirements for a Transaction to Qualify for Liability Shift?
The transaction must include accurate totalPrice
reflecting the charge to the user and a totalPriceStatus
of either FINAL or ESTIMATED. Transactions marked as NOT_CURRENTLY_KNOWN for totalPriceStatus
do not qualify.
Are There Restrictions on Which Merchants or Transactions Can Qualify for Liability Shift?
Yes, certain Merchant Category Codes (MCC) in the US are excluded from liability shift, including money transfer services, direct marketing inbound services, and sectors dealing with non-fiat currency, among others. Transactions with a totalPrice
of 0 or with mismatched charge amounts do not qualify.
What Should I Do if My Transactions Don’t Qualify for Liability Shift?
Ensure your transactions include the necessary totalPrice
and totalPriceStatus
parameters. If your business falls under the excluded MCC codes or if your transactions consistently do not meet the criteria, consult with a PSP or financial advisor for tailored advice.
How Are Transactions Processed for Liability Shift?
Google Pay API transactions with Visa device tokens can qualify for liability shift at facilitation if all conditions are met. However, eligibility can be downgraded by the network during transaction authorization processing.
How Can I Get Started with Google Pay?
To integrate Google Pay, refer to the extensive documentation available, consider exploring the sample application for Android on GitHub, and use Google’s button components for web integration. Submit your integration through the Google Pay & Wallet console for production access.
Your means of explaining all in this paragraph
is really fastidious, every one can without difficulty be aware of it, Thanks a lot.
Welcome.
Ahaa, its good dialogue concerning this piece of writing at this place at this web site, I have read all that, so now me also commenting at this place.
Thank you
If some one needs to be updated with most up-to-date technologies
afterward he must be visit this web site and be up to date daily.
Having read this I thought it was rather enlightening.
I appreciate you taking the time and energy to put this information together.
I once again find myself personally spending way too
much time both reading and posting comments.
But so what, it was still worth it!
Hello, I believe your web site could possibly be having browser compatibility issues.
When I look at your website in Safari, it looks fine however, if opening in I.E., it has some overlapping
issues. I simply wanted to provide you with a quick heads up!
Besides that, great blog!
Thank you for observations and submitting issue. I will see the same and fix it.