Global losses to online payment fraud in the ecommerce sector were estimated to be about $44 billion in 2024. But who pays when a transaction turns out to be fraudulent? That depends on how the payment was processed, what security tools were used, and what rules apply behind the scenes. That handoff of responsibility is called a liability shift, and it’s an important piece of the payment system. Unfortunately, many businesses don’t think about this until they’re on the wrong side of it.
Below, we’ll explain exactly how the liability shift works, when it occurs, and how to use it to your advantage.
What’s in this article?
- What is a liability shift in the context of card payments?
- When does a liability shift occur and who becomes responsible?
- How does liability shift affect your fraud prevention strategy?
What is a liability shift in the context of card payments?
A liability shift defines who’s responsible when a payment is identified as fraudulent. That responsibility can shift depending on who in the payment chain used the right security tools. It comes down to which party failed to secure the transaction.
If a business uses up-to-date security protocols, such as EMV (Europay, Mastercard, and Visa) chip readers and 3D Secure (3DS), and fraud still happens, the liability typically shifts to the card issuer. If the business skips those protections, the issuer is no longer responsible. The business (or its acquiring bank) becomes financially liable for the chargeback.
That change in responsibility is intentional. Card networks use it to drive adoption of better security. The message is clear: implement stronger authentication and you won’t be the one covering fraud losses.
Card network rules follow a strict logic for assessing liability:
Did the business implement the available authentication method?
Was the transaction processed through the proper channel?
If the answers to both are “yes,” the business is protected. If not, it’s exposed.
When does a liability shift occur and who becomes responsible?
Liability shift doesn’t apply to every transaction. It happens only when certain technologies or protocols are (or aren’t) used to detect and prevent fraud. If those conditions are met, the risk of fraud transfers from the business to the issuer. If they’re not, the business is responsible.
Here’s a closer look at when and why liability shift occurs for different types of transactions.
EMV chip card transactions
If a customer presents an EMV chip card for payment but the business doesn’t process it using a chip reader, the business becomes liable for any fraud tied to that transaction. This means:
If the business doesn’t support EMV but the card has a chip, the business (or its acquirer) takes the loss
If the business uses an EMV reader on the chip card, the issuer is likely liable
This doesn’t affect disputes unrelated to card fraud such as “damaged product” claims. The business is still responsible for those.
Online transactions
Liability shift for online or mobile payments usually depends on whether 3DS was used and whether the authentication succeeded:
If a transaction is authenticated via 3DS, liability shifts to the cardholder’s bank.
If 3DS isn’t used, fails, or is unavailable, the business is liable.
If the cardholder later claims they didn’t authorize the charge, the issuer is responsible only if authentication was completed. Even if the transaction wasn’t authenticated because the issuer doesn’t participate in 3DS or an error happens, liability usually won’t shift to the issuer.
Contactless and digital wallet transactions
Many digital wallets (e.g., Apple Pay, Google Pay) qualify for liability shift because of how they’re tokenized and authenticated. These transactions often include cryptographic proof that the cardholder was verified using biometrics or device-based credentials. When that proof is present, liability typically shifts to the issuer.
Transactions without authentication options
Not every channel enables authentication, including mail order/telephone order (MOTO) payments. In these cases, liability generally stays with the business because the transaction can’t be verified in real time.
How does liability shift affect your fraud prevention strategy?
Liability shift is a decision-making tool. It shapes how you handle risk, what security steps you take at checkout, and how you balance fraud prevention with customer experience.
It helps you decide when to add authentication
3DS gives you something most fraud tools can’t: protection from financial liability. That makes it a powerful fallback—especially for transactions that trigger risk signals, such as high-value orders, international cards, and first-time customers.
Some businesses use 3DS selectively. For example, they’ll use 3DS on risky transactions to shift liability away from themselves but skip it on low-risk transactions to minimize checkout friction and preserve conversion rates. They’re not treating every customer like a threat but using liability shift where it matters most.
But in some regions, regulatory compliance requires using 3DS on all online transactions.
It changes how you interpret risk scores
When you know a transaction has liability shift (because 3DS succeeded or the chip was used), you might decide to approve it even if fraud indicators are present. Conversely, if a transaction doesn’t qualify for liability shift, you might want to increase scrutiny. That might mean requiring more verification, sending it to manual review, or blocking it.
It reframes the cost of fraud
A successful liability shift means the issuer, not your business, absorbs the loss. That reduces your direct financial exposure, but fraud still has indirect costs such as:
Losing inventory
Handling dispute escalations
Getting flagged by networks for high fraud rates
While liability shift decreases the impact of fraud, it doesn’t eliminate the damage. You still want to prevent it when you can.
Your overall strategy depends on your business model, risk profile, and geography. The EU, for example, requires Strong Customer Authentication (SCA) for all online payments, and up-to-date 3DS authentication fulfills that requirement. In the US and other regions, 3DS is optional. That gives you more flexibility but also more decisions to make. If you operate globally, you’ll likely end up using a hybrid strategy: 3DS everywhere it’s required and a risk-based approach elsewhere.
The content in this article is for general information and education purposes only and should not be construed as legal or tax advice. Stripe does not warrant or guarantee the accurateness, completeness, adequacy, or currency of the information in the article. You should seek the advice of a competent attorney or accountant licensed to practice in your jurisdiction for advice on your particular situation.