Technology is changing the way people pay for things. To keep your business safe from fraud and chargebacks, you need to know the most recent rules and security measures.  One important part of payment security is knowing about liability shift, which lets you, as a merchant, pass on the expense of a fake payment to the issuer.  Using tools like 3D Secure (3DS) liability shift, retailers may lower chargebacks and move the responsibility for fraudulent transactions on the issuer. This helps them deal with the costs of fraud. 

We will go into great detail on payment liability shifts in this article, looking at how they work in different areas, payment schemes, acquirers, payment methods, and transaction types, such as Cardholder Initiated Transaction (CIT) or Merchant Initiated Transaction (MIT).  We will go over the many kinds of responsibility shift situations, such EMV liability shift, 3D Secure, SCA (Strong Customer Authentication) exclusions, and out-of-scope transactions. We will also talk about the rules that each market has to follow.  By the conclusion, you'll know how these steps help reduce fraud responsibility shift and keep you and your customers safe from fraud.

What does it mean to transfer payment liability?

If a payment turns out to be fraudulent, a payment liability transfer means that someone else is now accountable for paying for the chargeback.  This term usually means that the merchant is giving up their obligation to the payment card provider.

The responsibility changes according on the payment situation, such as the payment method, the location, the kind of transaction (such CIT or MIT), and whether or not authentication is used in the payment flow.  Chargebacks cost money, so it's crucial to find the proper balance between protecting yourself against fraud and making sure your consumers have a good checkout experience.

Liability shift for EMV

In the past, the card issuer (the bank that issued the card) was responsible for any fraudulent transactions that happened when the card was present.  With the addition of EMV chip technology, which makes payment cards safer, the merchant is responsible for transactions that don't fulfill scheme security standards.

If you, the merchant, don't implement EMV chip technology and someone uses an EMV-enabled card to make a fake purchase, you are now responsible for the loss.  If you do support EMV chip but the card issuer doesn't issue EMV-enabled cards, the card issuer is still responsible.

The payment responsibility shift is meant to encourage your firm to use safer ways to process payments and cut down on fraud.

3D secure and chargeback responsibility transfers

Chargeback responsibility shifting can also happen with online transactions where the card is not present.  3D Secure (3DS) has been around for a long time and is a popular way to stop fraud.  3DS was also required as part of the SCA rules to cut down on payment fraud in the UK and EU.  Merchants can move the responsibility for fraudulent transactions to the card issuer by adding an extra layer of authentication. This helps them cut down on the expenses of fraud. 

If a client tells their issuer that a payment was fraudulent and asks for their money back (a chargeback), the person who has to pay for it depends on whether 3DS was used to verify the cardholder's identity.  Under SCA, 3DS is required for many online payments in the EU and UK. In markets like the US and MENA, however, it is still being adopted and is not yet a statutory necessity. 

The SCA requirements made the 3D Secure protocol a lot more popular in Europe.  However, 3DS is also used in other parts of the world, where systems give comparable responsibility transfer alternatives for transactions where the card is not present, even if SCA is not required by law.

3D Secure is a security system that makes online payments more secure by adding an extra step to the process.  If your business allows this and a fraudulent transaction happens, the card issuer is usually responsible for the transaction.

When is the merchant responsible?

If you accept a type of payment that isn't protected by responsibility shift (such a non-EMV card) or if you don't use an EMV-compliant payment terminal, you are accountable for any fraud losses that happen.

If you take an online payment that is later reported as fraudulent and you can't offer 3DS authentication data, you are also responsible for the expense of refunding the consumer. 

When is the issuer responsible?

If the card issuer has sent out a payment card with a known security flaw, such a weak magnetic stripe or a PIN that is easy to guess, they are likely responsible for any fraudulent transactions that happen in stores.

If a payment card issuer approves a fraudulent transaction that was processed using 3D Secure, on the other hand, the issuer may be responsible for the transaction if they didn't adequately check the cardholder's ID or didn't notice anything strange happening.  

Payment Method: Normal amount of liability

• Contactless (card present) The company that gave you the card
• Magnetic stripe (card is present) Merchant/Acquirer
• Chip and PIN (card present) The company that gives you the card
• CNP online not utilizing 3D Secure Merchant/Buyer
• CNP (card not present) online  utilizing 3D Secure Card issuer
• Phone, mail, and other CNP that don't use the internet Merchant/Acquirer
• Using SCA exemptions and transactions that are not covered by SCA is a requirement for payment service providers (PSPs) to use 2FA like 3DS for most electronic payments. 

But there are several SCA exemptions and transactions that are not covered by SCA that let PSPs skip SCA rules for particular sorts of transactions. These include the amount, risk level, or payment channel utilized.  Out-of-scope transactions are ones that existing rules say don't have to follow SCA rules.  Also, the requirements may be different for CIT (Cardholder Initiated Transaction) and MIT (Merchant Initiated Transaction), so firms should check how exemptions apply to payments that happen on a regular basis or are part of a subscription. 

The most popular SCA exclusions

• Transactions with a value of less than a particular amount (30 euros or the equivalent)
  
• Trusted beneficiaries—transactions to beneficiaries who have already been approved are not subject to SCA restrictions.
  
• Secure corporate payments are transactions between firms that have been checked for risk and meet particular security criteria.

Changing liability with APMs

There are several alternative payment mechanisms (APMs), such as Apple Pay and Google Pay, that can help lower chargebacks and move liability for fraud to a 3DS or other sort of fraud liability transfer.  Using biometric identification, device-based cryptograms, and tokenized card data, these solutions let retailers move the risk of fraud from the merchant to the card issuer.

Pay with Apple

In most places, Apple Pay already fulfills SCA criteria since it lets users use Touch ID or Face ID to confirm transactions.  Because of this, Apple Pay transactions typically get a responsibility transfer without having to go through a second 3DS challenge.  If the issuer sends back an Electronic Commerce Indicator (ECI) that confirms successful verification, the card issuer is usually still responsible for any fraudulent transactions.  Apple Pay also follows the SCA rules in the MENA area, which lets responsibility transfer in many local marketplaces. 

Pay using Google

Google Pay can also transfer responsibility through its CRYPTOGRAM_3DS mode, which links payment information to the user's Android device.  In these situations, the issuer agrees that the cardholder was fully verified and normally takes on the risk of fraud.  But if Google Pay utilizes PAN_ONLY, you may still need to employ 3DS to fully shift fraud culpability.  Keep in mind that variances in card schemes and regions might also affect liability.

Other APMs

Platforms like Transfi, a global & cross-border payment system, can also be helpful for liability shifts in payments.  There are numerous more APMs than Apple Pay and Google Pay that provide strong authentication capabilities or short dispute periods. These might assist you in decreasing the likelihood of chargebacks.  These strategies can make payments smoother and help prevent fraud losses.

Conclusion

Any organization that uses digital payments today needs to know how payment responsibility transfers work.  Merchants have significant methods to cut down on fraud and shift risk back to the issuer, such as EMV chips, 3D Secure, and biometric APMs (Apple Pay, Google Pay).  But the trick is to do it right.  Fraud might be the responsibility of either the merchant or the issuer, depending on the type of transaction, the area, and the security protocol.  Merchants may give customers a good experience while lowering the risk of chargebacks and financial exposure to fraud by following security standards like SCA and using solutions like 3DS.

FAQs 

1. What does it mean to transfer a payment liability?

When certain security technologies are used, such EMV or 3DS, the card issuer takes on the financial risk for a fraudulent transaction instead of the retailer.

2. When is a business responsible for a fake transaction?

Merchants are responsible if they don't utilize EMV-compliant terminals or omit 3D Secure for online payments.  The merchant has to pay for chargebacks if the authentication data is absent.

3. What role does 3D Secure (3DS) play in the transfer of liability?

3DS adds an extra step to internet payments to make sure they are safe.  If 3DS is utilized and fraud still happens, the card issuer is normally responsible, not the merchant.

4. What kinds of transactions are not covered by the SCA?

These include payments to trustworthy beneficiaries, payments to businesses, or payments of less than 30 euros.  They might not always insulate you from responsibility, but they might not demand 2FA.

5. Do Apple Pay and Google Pay defend against responsibility shift?

Yes, both usually qualify for responsibility shift since they use biometrics or cryptograms to fulfill SCA.  But protection may be different depending on the mode (for example, PAN_ONLY in Google Pay) and the area.