Payments Academy
Card payments face a basic problem PAYMENT OPERATIONS STARTED LIVE 01 Card payments face a basic problem - Card payments face a basic problem. ACTIVE 02 Password to remember and every code - extra step at checkout QUEUED 03 Confirming that the person paying - Three D Secure provides authentication QUEUED 04 Authentication that backfires - If it adds a clumsy authentication step QUEUED 05 Liability - authentication, the liability generally QUEUED 06 Chargeback process - owner and a response time QUEUED Card payments face a basic problem. Step 1 of 6 Card payments face a basic problem STARTED Card payments face a basic problem Card payments face a basic problem. ACTIVE Password to remember and every code extra step at checkout QUEUED Confirming that the person paying Three D Secure provides authentication QUEUED Authentication that backfires If it adds a clumsy authentication step QUEUED Liability authentication, the liability generally QUEUED Chargeback process owner and a response time QUEUED Card payments face a basic problem.
Password to remember and every code PAYMENT OPERATIONS IN PROGRESS LIVE 01 Card payments face a basic problem - Card payments face a basic problem. DONE 02 Password to remember and every code - extra step at checkout ACTIVE 03 Confirming that the person paying - Three D Secure provides authentication QUEUED 04 Authentication that backfires - If it adds a clumsy authentication step QUEUED 05 Liability - authentication, the liability generally QUEUED 06 Chargeback process - owner and a response time QUEUED Every extra step at checkout, every password to remember and every code to type, increases the chance that a genuine customer will abandon their purchase. Step 2 of 6 Password to remember and every code IN PROGRESS Card payments face a basic problem Card payments face a basic problem. DONE Password to remember and every code extra step at checkout ACTIVE Confirming that the person paying Three D Secure provides authentication QUEUED Authentication that backfires If it adds a clumsy authentication step QUEUED Liability authentication, the liability generally QUEUED Chargeback process owner and a response time QUEUED Every extra step at checkout, every password to remember and every code to type, increases the chance that a genuine customer will abandon their purchase.
Confirming that the person paying PAYMENT OPERATIONS IN PROGRESS LIVE 01 Card payments face a basic problem - Card payments face a basic problem. DONE 02 Password to remember and every code - extra step at checkout DONE 03 Confirming that the person paying - Three D Secure provides authentication ACTIVE 04 Authentication that backfires - If it adds a clumsy authentication step QUEUED 05 Liability - authentication, the liability generally QUEUED 06 Chargeback process - owner and a response time QUEUED Three D Secure provides authentication, confirming that the person paying is the genuine cardholder. Step 3 of 6 Confirming that the person paying IN PROGRESS Card payments face a basic problem Card payments face a basic problem. DONE Password to remember and every code extra step at checkout DONE Confirming that the person paying Three D Secure provides authentication ACTIVE Authentication that backfires If it adds a clumsy authentication step QUEUED Liability authentication, the liability generally QUEUED Chargeback process owner and a response time QUEUED Three D Secure provides authentication, confirming that the person paying is the genuine cardholder.
Authentication that backfires PAYMENT OPERATIONS IN PROGRESS LIVE 01 Card payments face a basic problem - Card payments face a basic problem. DONE 02 Password to remember and every code - extra step at checkout DONE 03 Confirming that the person paying - Three D Secure provides authentication DONE 04 Authentication that backfires - If it adds a clumsy authentication step ACTIVE 05 Liability - authentication, the liability generally QUEUED 06 Chargeback process - owner and a response time QUEUED If it adds a clumsy authentication step that stops the fraud but causes 5 percent of genuine customers to abandon their baskets Step 4 of 6 Authentication that backfires IN PROGRESS Card payments face a basic problem Card payments face a basic problem. DONE Password to remember and every code extra step at checkout DONE Confirming that the person paying Three D Secure provides authentication DONE Authentication that backfires If it adds a clumsy authentication step ACTIVE Liability authentication, the liability generally QUEUED Chargeback process owner and a response time QUEUED If it adds a clumsy authentication step that stops the fraud but causes 5 percent of genuine customers to abandon their baskets
Liability generally shifts PAYMENT OPERATIONS IN PROGRESS LIVE 01 Card payments face a basic problem - Card payments face a basic problem. DONE 02 Password to remember and every code - extra step at checkout DONE 03 Confirming that the person paying - Three D Secure provides authentication DONE 04 Authentication that backfires - If it adds a clumsy authentication step DONE 05 Liability - authentication, the liability generally ACTIVE 06 Chargeback process - owner and a response time QUEUED With authentication, the liability generally shifts to the issuer, because the issuer confirmed the cardholder. Step 5 of 6 Liability generally shifts IN PROGRESS Card payments face a basic problem Card payments face a basic problem. DONE Password to remember and every code extra step at checkout DONE Confirming that the person paying Three D Secure provides authentication DONE Authentication that backfires If it adds a clumsy authentication step DONE Liability authentication, the liability generally ACTIVE Chargeback process owner and a response time QUEUED With authentication, the liability generally shifts to the issuer, because the issuer confirmed the cardholder.
Chargeback process should map every reason code PAYMENT OPERATIONS COMPLETE LIVE 01 Card payments face a basic problem - Card payments face a basic problem. DONE 02 Password to remember and every code - extra step at checkout DONE 03 Confirming that the person paying - Three D Secure provides authentication DONE 04 Authentication that backfires - If it adds a clumsy authentication step DONE 05 Liability - authentication, the liability generally DONE 06 Chargeback process - owner and a response time ACTIVE The chargeback process should map every reason code to an owner and a response time, because a chargeback answered late is a chargeback lost. Step 6 of 6 Chargeback process should map every reason code COMPLETE Card payments face a basic problem Card payments face a basic problem. DONE Password to remember and every code extra step at checkout DONE Confirming that the person paying Three D Secure provides authentication DONE Authentication that backfires If it adds a clumsy authentication step DONE Liability authentication, the liability generally DONE Chargeback process owner and a response time ACTIVE The chargeback process should map every reason code to an owner and a response time, because a chargeback answered late is a chargeback lost.

Key points of this lesson, in order.

0:00 / 3:25 Step 1 of 6

Why Card Payments Need Extra Protection

3D Secure, Tokenization and Chargebacks, Lesson 1 of 7, Narration 3:25, D08 Cards and alternative payments

ChargebackIssuer

What you will learn

Your objective. By the end of this lesson, you will be able to explain card payments need extra protection. Card payments face a basic problem.

Why it matters. Every extra step at checkout, every password to remember and every code to type, increases the chance that a genuine customer will abandon their purchase.

Chapter objective: Learner explains 3D Secure authentication, tokenization, chargeback reason codes, and dispute handling, and decides the correct chargeback response for a given dispute scenario. Learner applies this skill in realistic banking scenarios, with clear examples and correct terminology throughout.

Key learning points

  • Card payments face a basic problem
  • Password to remember and every code
  • Confirming that the person paying
  • Authentication that backfires
  • Liability generally shifts
  • Chargeback process should map every reason code

Key terms

Chargeback: A dispute raised by a cardholder through the issuer to reverse a card payment, for example for fraud, non delivery or a duplicate charge.

Issuer: A bank or licensed institution that issues payment cards to customers and holds their accounts. It authorises transactions, debits cardholder accounts, and manages credit limits and fraud controls.

Payment flow diagram showing Why Card Payments Need Extra Protection.

Practise this lesson

Exercise

Trace the card payment in this lesson through authorisation, clearing and settlement.

Use the four-party model and the stage timings in this lesson.

  1. What to do. State what happens at each stage, who pays whom, and when the merchant is actually credited.

Correct result. Authorisation holds the funds and returns a response code. Clearing sends the transaction in a batch file. Settlement moves the net amount between banks, and the acquirer credits the merchant after deducting interchange, scheme fees and its margin.

Why. A card payment is not one event. The customer sees it on Monday, the merchant gets it on Wednesday, and the difference is the clearing and settlement cycle.

Check your understanding

Practice question

What does 3D Secure add to an online card payment?

Takeaway and next step

What to remember

Every extra step at checkout, every password to remember and every code to type, increases the chance that a genuine customer will abandon their purchase.

Follow Rs 10 through every stage, from instruction to beneficiary credit, and note where it can stop.

Open the Payment Lifecycle Simulator →

Builds on "System design deep dive: card authorization at scale".

Transcript and full text

Show transcript

Card payments face a basic problem. The card itself is not present in an online transaction, and the merchant cannot see the person paying or check their signature. A fraudster who has obtained a card number, expiry date and security code can use them to buy goods online, and the genuine cardholder may only discover the fraud when they check their statement. This card not present fraud has been the fastest growing type of card fraud for many years, and it is the reason the industry has invested heavily in authentication, tokenization and dispute processes. The challenge is to add security without destroying the customer experience. Every extra step at checkout, every password to remember and every code to type, increases the chance that a genuine customer will abandon their purchase. Merchants measure this abandonment carefully, because a checkout that is too strict loses sales. Issuers face the same trade off, because a card that is declined too often will be replaced by a competitor's card in the customer's wallet. The best security solutions are therefore those that are invisible to most customers and only challenge the small minority of transactions that look risky. This chapter covers three technologies and processes that work together to solve this problem. Three D Secure provides authentication, confirming that the person paying is the genuine cardholder. Tokenization replaces the real card number with a surrogate value, so that the real number is never exposed. And the chargeback process provides a remedy when fraud or an error still occurs, giving the cardholder a way to recover their money and giving the merchant a fair chance to defend the transaction. Together they form the trust framework that makes card payments work at scale. Put numbers on both sides of the trade off. A merchant doing Rs 10 crore of online sales a month with fraud running at 0.1 percent of value loses Rs 1 lakh a month to fraud. If it adds a clumsy authentication step that stops the fraud but causes 5 percent of genuine customers to abandon their baskets, it loses Rs 50 lakh of sales to save Rs 1 lakh, which is a bad bargain. The right answer is risk based. Challenge only the transactions that look risky, and let the rest through silently. A fraudster who has bought a stolen card number, expiry date, and security code can place an order for Rs 25,000 in minutes, and the genuine cardholder may not notice until the statement arrives. Without authentication, that Rs 25,000 becomes a chargeback the merchant must absorb. With authentication, the liability generally shifts to the issuer, because the issuer confirmed the cardholder. That shift is worth more to the merchant than the fraud loss itself, because it turns an unpredictable cost into a predictable one. An analyst writes the security requirements as rules with thresholds, not as vague intentions. The risk engine should score each transaction on device, history, amount, and delivery address, and challenge only above an agreed score. The monitoring should track two numbers every day. The fraud rate and the abandonment rate, because improving one at the expense of the other is not an improvement. The chargeback process should map every reason code to an owner and a response time, because a chargeback answered late is a chargeback lost. And the requirements should state what happens when the authentication service itself is down, because a security control that blocks all payments when it fails is worse than the fraud it prevents.

Card payments face a basic problem. The card itself is not present in an online transaction, and the merchant cannot see the person paying or check their signature. A fraudster who has obtained a card number, expiry date and security code can use them to buy goods online, and the genuine cardholder may only discover the fraud when they check their statement. This card not present fraud has been the fastest growing type of card fraud for many years, and it is the reason the industry has invested heavily in authentication, tokenization and dispute processes.

The challenge is to add security without destroying the customer experience. Every extra step at checkout, every password to remember and every code to type, increases the chance that a genuine customer will abandon their purchase. Merchants measure this abandonment carefully, because a checkout that is too strict loses sales. Issuers face the same trade off, because a card that is declined too often will be replaced by a competitor's card in the customer's wallet. The best security solutions are therefore those that are invisible to most customers and only challenge the small minority of transactions that look risky.

This chapter covers three technologies and processes that work together to solve this problem. Three D Secure provides authentication, confirming that the person paying is the genuine cardholder. Tokenization replaces the real card number with a surrogate value, so that the real number is never exposed. And the chargeback process provides a remedy when fraud or an error still occurs, giving the cardholder a way to recover their money and giving the merchant a fair chance to defend the transaction. Together they form the trust framework that makes card payments work at scale.

Put numbers on both sides of the trade off. A merchant doing Rs 10 crore of online sales a month with fraud running at 0.1 percent of value loses Rs 1 lakh a month to fraud. If it adds a clumsy authentication step that stops the fraud but causes 5 percent of genuine customers to abandon their baskets, it loses Rs 50 lakh of sales to save Rs 1 lakh, which is a bad bargain. The right answer is risk based. Challenge only the transactions that look risky, and let the rest through silently. A fraudster who has bought a stolen card number, expiry date, and security code can place an order for Rs 25,000 in minutes, and the genuine cardholder may not notice until the statement arrives. Without authentication, that Rs 25,000 becomes a chargeback the merchant must absorb. With authentication, the liability generally shifts to the issuer, because the issuer confirmed the cardholder. That shift is worth more to the merchant than the fraud loss itself, because it turns an unpredictable cost into a predictable one.

An analyst writes the security requirements as rules with thresholds, not as vague intentions. The risk engine should score each transaction on device, history, amount, and delivery address, and challenge only above an agreed score. The monitoring should track two numbers every day. The fraud rate and the abandonment rate, because improving one at the expense of the other is not an improvement. The chargeback process should map every reason code to an owner and a response time, because a chargeback answered late is a chargeback lost. And the requirements should state what happens when the authentication service itself is down, because a security control that blocks all payments when it fails is worse than the fraud it prevents.

Full lesson text (all scenes)

Completing a lesson updates your progress dashboard on the homepage.

Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.