Blog / Payments & payment fraud, Ravelin University

Card payment liability shift – everything you need to know to reduce chargeback burden

The knowledge you need to make the most of liability shifts and reap the benefits for your company – including saving money on chargebacks.

13 July 2026

Card payment liability shift – everything you need to know to reduce chargeback burden

Liability shift for chargebacks is a complex, often misunderstood area. But there are plenty of reasons for payments professionals to spend time understanding and maximizing it where possible.

Card payment liability shift is also a key incentive for merchants to adopt a 3D Secure server, in locales where Secure Customer Authentication is not mandated by law – and a welcome bonus where it is.

This guide will arm you with all the knowledge and detail you need to make the most of liability shifts and reap the benefits for your company, including saving money on chargebacks.

Please note that our advice below applies specifically to card-not-present (CNP) transactions. Different sets of rules apply for in-person transactions, which tend to not be of relevance for ecommerce.

What is liability shift?

Liability shift is when the financial responsibility for a fraud-related dispute shifts from the merchant to the issuing bank that the cardholder raised the dispute with. There are strict requirements for liability to shift, which we will look at in more detail below.

Normally, the financial burden of disputes sits with the acquiring bank – and therefore their merchants. Liability shift is a way for that financial burden to be passed on to the issuers, away from merchants.

It is generally achieved through the use of any of the 3D Secure (3DS) protocols.

Liability shift is only available for disputes with reason codes related to fraud.

The benefits of successful liability shift

Why would a merchant take the time to understand complex liability shift rules? The main reason is to prevent potential financial loss from chargebacks and their related costs.

Specifically, we could break down the benefits as follows:

  1. Less money lost to chargebacks: When a cardholder files a dispute for a transaction for which the liability has shifted, it is no longer the merchant’s money that is returned to them. This means the merchant can reduce the cost of chargebacks.

  2. Reduction in operational costs: Operational costs are lower for the merchant, as no staff need to investigate and potentially challenge disputes, freeing up their time.

  3. Potential reduction in software costs: By fully leveraging all the opportunities presented by liability shift mechanics, merchants avoid spending money on chargeback guarantee software.

  4. Avoiding monitoring program fees: A high number of disputes will land you in one of the card schemes’ monitoring programs, such as Visa’s VAMP, where companies with a high dispute ratio pay extra fees for each transaction. Although transactions where liability has shifted still count towards the dispute ratios much of the time, sensible application involves leveraging 3DS, and thus indirectly minimizes disputes, ultimately reducing those key metrics and keeping merchants in card schemes’ good books.

  5. Accepting more payments: When applied comprehensively and strategically, shift gives merchants the confidence to accept more payments, which ultimately means more conversions. This way, payments and fraud teams can significantly contribute to the company’s overall profits.

  6. Accepting more card options: There is also a benefit related to the strategic acceptance of attempted transactions. In certain cases, if a merchant attempts to run a 3DS authentication but the customer’s card issuer does not support the protocol, the liability still shifts to the card issuer. This way, merchants may feel more confident accepting cards that they otherwise might not, such as international or older banks.

Ravelin Logo

A 3D Secure solution you can trust

Optimize your conversions and minimize friction with Ravelin's 3DS & SDKs.

When does liability shift to the issuer?

For all their benefits, liability shifts are a complex matter. Generally speaking:

  • The use of exemptions or delegated authentication will mean that liability sits with the acquirer/merchant.

  • Frictionless 3D Secure authentication* (without an exemption applied) often means liability sits with the issuer.

  • For trusted beneficiaries, if the issuer accepts the trusted listing, the liability falls with the issuer.

  • For secure corporate payments, the liability falls with the issuer.

However, each card scheme has different rules on whether liability shifts to the acquirer/merchant or issuer when an exemption is accepted, or delegated authentication is used.

This can often be influenced by whether it is the acquirer or the issuer who applies the exemption.

*For the avoidance of doubt, frictionless 3D Secure refers to flows where the issuer approves the transaction without challenging the customer with a password or text code.

How do you gain liability shift?

In general, a merchant can gain liability shift by successfully authenticating a cardholder via 3D Secure. However, it can also occur in some cases where 3DS is requested, but the issuer isn't enrolled.

The precise circumstances under which liability shift can occur are complicated and vary according to the country, the card scheme, and other factors.

In unauthenticated payments, the liability for fraud generally sits with the merchant. So if stolen credit card details are used on your website and the cardholder files a chargeback request, then you bear the cost of that fraud.

However, when the payment is authenticated (through 3DS or through FaceID on ApplePay, for example) then the liability shifts to the card issuer.

There are cases where 3DS is performed correctly, but liability shift benefits are still not granted.

  • This can happen if the merchant is on certain card scheme fraud or chargeback monitoring programs or uses a restricted merchant category code (MCC). Restricted MCCs include wire transfer merchants and certain gambling companies.
  • There is no liability shift for subsequent recurring transactions that are merchant-initiated.
  • Frictionless 3D Secure authentication without an exemption applied often means liability is with the issuer.

As a general rule, however, an authenticated transaction benefits from liability shift.

Because of the complexity of liability shift rules, we have prepared a comprehensive scenario table for your reference. Below are some scenarios for Visa and Mastercard, which show if liability shift occurred depending on the authentication outcome, 3DS version, whether an authentication value was provided or not, and the ECI value.

Visa card transaction scenarios & liability shift outcomes

Card schemeScenarioAuthentication outcomeAuthentication value provided?ECI valueLiability shift?
VisaIssuer/cardholder not enrolled in 3DS (3DS2)AttemptedYes06YES ✅
VisaIssuer/cardholder not enrolled in 3DS, but special exception applies: non-reloadable prepaid card (globally); OR merchant in fraud monitoring program (globally); OR merchant with restricted MCC (US); OR transaction does not meet customer payment system requirements.AttemptedYes06NO ❌
VisaVisa Attempts Service stands in on behalf of the issuer – ACS unavailableAttemptedYes06YES ✅
VisaVisa Attempts Service stands in on behalf of the issuer – ACS unavailableAttemptedNo06NO ❌
VisaVisa Attempts Service stands in on behalf of the issuer – ACS unavailable, but special exception applies: non-reloadable prepaid card (globally); OR merchant in fraud monitoring program (globally); OR transaction does not meet customer payment system requirements.AttemptedYes06NO ❌
VisaACS unavailableAttemptedNo07NO ❌
VisaAuthentication successfulFully authenticatedYes05YES ✅
VisaAuthentication successful, but no authentication value providedFully authenticatedNo05NO ❌
VisaAuthentication successful, but special exception applies: merchant in fraud monitoring program (globally); OR merchant with restricted MCC (US).Fully authenticatedYes05NO ❌
VisaData onlyFully authenticated (TransStatus I)Yes07NO ❌

Mastercard transaction scenarios & liability shift outcomes

Card schemeScenarioAuthentication outcomeAuthentication value provided?ECI valueLiability shift?
MastercardIssuer/cardholder not enrolled in 3DSAttemptedNo00NO ❌
MastercardIssuer/cardholder not enrolled in 3DS and the transaction is customer "non-low risk"AttemptedYes01YES ✅
MastercardIssuer/cardholder not enrolled in 3DS and the customer is considered low riskAttemptedYes02YES ✅
MastercardAuthentication successfulFully authenticatedYes02YES ✅
MastercardAuthentication successful, but no authentication value provided by the issuerFully authenticatedNo02NO ❌
MastercardData onlyFully authenticated (TransStatus I)Yes06NO ❌
MastercardIdentity Check InsightsFully authenticated (TransStatus I)Yes06NO ❌

Does the use of exemptions or delegated authentication impact liability shift?

In general, when a merchant uses SCA exemptions or delegated authentication, the standard liability shift to the issuer does not take place. Instead, the financial liability remains with the acquirer/merchant.

Here, too, card schemes have different rules on whether liability shifts to the acquirer/merchant or issuer when an exemption is accepted or delegated authentication used. You can find out more information for the card schemes and scenarios in the table above.

How do you know if a transaction has gained liability shift?

In order to tell whether a transaction has gained liability shift, check the Electronic Commerce Indicator (ECI) field. This is a payment system-specific value that is provided by the issuer or card scheme in the 3D Secure flow, that indicates the results of the attempt to authenticate the cardholder.

Some 3DS providers today do not provide ECI values to merchants, and may simply return a yes/no response on whether there is liability shift for the merchant.

On the Ravelin 3DS platform, you can see liability shift indicators both as a handy label at the top of a transaction, as well as in the 3DS authentication log – see image above.

In terms of understanding the specific ECI values per card scheme, we’ve prepared a handy reference table.

Example ECI values for major schemes & liability

Card schemeECI valueLiability sits with...
Visa05Issuer
Visa01, 04 or 07Acquirer / merchant
Mastercard01, 02 or 07Issuer
Mastercard00, 04 or 06Acquirer / merchant
American Express05 or 06Acquirer / merchant
Discover05, Transaction Status Y or AIssuer
Discover07, Transaction Status UAcquirer / merchant
eftpos05 or 06Issuer
eftpos07Acquirer/ merchant

Leveraging liability shifts to reduce chargeback burden

We hope the above guide and tables have helped you develop a better understanding of the complex topic of liability shifts.

A trustworthy and proactive 3D Secure solution provider will work with you to minimize your exposure to potential chargebacks by making the most of liability shifts.

Ravelin’s industry-leading support allows our merchants and PSPs to make the most of liability shifts despite their complexity.

Ravelin Logo

A 3D Secure solution you can trust

Optimize your conversions and minimize friction with Ravelin's 3DS & SDKs.

Frequently Asked Questions

Who is liable for chargebacks?

Liability shift rules define which party is liable for chargebacks, and hence who pays the customer in case of a dispute. 

Generally speaking, the issuer is liable for transactions successfully authenticated via 3D Secure, while the merchant is liable for those that are not – but there are particular exceptions and special conditions.

When does liability not shift in card payments?

Examples of when liability remains with the merchant include unauthenticated payments, merchant-initiated recurring payments, merchants in monitoring programs e.g. VAMP, and merchants in high-risk industries (with restricted MCCs).

Even in other cases, liability shift rules are not as clear-cut as one might hope. Please refer to our detailed tables in the above guide for specifics.

Can you lose liability shift protection even with successful 3DS?

Yes, there are cases when although 3D Secure is performed correctly, the liability does not shift to the issuer.

A merchant may not be granted liability shift when they are in breach of a fraud or dispute monitoring requirement set by the card scheme.

Merchants that use restricted merchant category codes (MCCs) cannot benefit from liability shifts either. These typically include industries deemed to be high-risk, such as wire transfers, inbound teleservices, iGaming/online gambling, and cryptocurrency.

Also, when there is no authentication value provided, liability does not shift.

When the transaction does not meet customer payment system requirements, authentication typically does not shift.

When does liability shift for digital wallets?

The rules around digital wallets are more complex, primarily because of particularities with Google Pay authorization flows.

We have prepared a detailed article about this. Please see our guide to liability shift for Google Pay and Apple Pay for specifics.

Does liability shift for gift cards?

When authentication has been attempted, liability does not shift for non-reloadable prepaid Visa cards.

Please see the tables in the main article for specifics.

What are the restricted MCCs for liability shift?

In the US, liability does not shift when the merchant is linked to one of the restricted merchant category codes.

These are:

  • 4829
  • 5967
  • 6051
  • 7995
  • 6540
  • 7801
  • 7802

Author