Beyond the Click: Authentication, Authorisation & Capture

What Really Happens After You Tap ‘Pay’?

You tap your card. Maybe click "Pay Now" on your favourite app. It takes a second or two, and voilà — payment successful. But beneath that moment of magic, a complex ballet is playing out between multiple players and invisible checks.

Authentication, authorisation, and capture are the three pillars that silently decide if your payment will succeed, fail, or even happen at all. They sound technical (and maybe a little boring?), but understanding these steps unlocks a hidden world — one that explains why you need an OTP sometimes and not others, why merchants pre-auth your money but don’t always charge you, and how fraud is prevented without getting in your way.

If you've ever wondered:

• Why most international card payments don’t ask for OTPs? (yes! some do.)

• What merchants do when a product is returned after a payment?

• How UPI Autopay deducts money monthly without asking you?

• Or how a payment gets approved in 300 milliseconds?

Then this is the article for you.

Who's Who in the Payment Flow: A Cast of Essential Players

Every time a card transaction occurs, a complex yet highly coordinated process unfolds, involving several key entities. Understanding their individual roles and how they interact is fundamental to grasping the mechanics of payment processing. Let's introduce the core players:

1. The Cardholder

• Who they are: This is the individual initiating the payment, typically using a credit or debit card.

• Their role: The cardholder provides their payment details (e.g., card number, expiry date, CVV) to the merchant to authorize a purchase. Their primary concern is a secure, seamless, and convenient checkout experience.

2. The Merchant

• Who they are: This is the business (online or physical) selling goods or services that accepts card payments.

• Their role: The merchant captures the cardholder's payment details and initiates the payment request through their chosen payment infrastructure. Their goal is to efficiently process transactions, receive funds, manage fraud, and provide a positive customer experience.

3. The Payment Aggregator

• Who they are: A Payment Aggregator (PA) is a service provider that allows merchants to accept online payments without needing to establish their own direct merchant account with an acquiring bank. They "aggregate" transactions from many small to medium-sized businesses under one large merchant account. Examples include Stripe, PayPal (for their merchant services), and Square.

• Their role: PAs simplify payment processing for merchants by handling much of the complexity, including compliance, technical integration, and reconciliation. They collect funds from customers on behalf of multiple merchants and then pay out the merchants. For many smaller merchants, the PA is their primary connection to the payment ecosystem.

4. The Acquiring Bank (and its use of the Payment Gateway)

• Who they are: This is the financial institution (eg. HDFC, ICICI) that provides banking services to the merchant and processes their credit and debit card transactions. They have a direct relationship with the Card Networks.

• The Payment Gateway is a critical technology component often provided by or closely integrated with the acquiring bank (or a third-party vendor the acquiring bank partners with).

• Their role: The Acquiring Bank is responsible for receiving authorised funds from the Issuing Bank (via the Card Networks) and depositing them into the merchant's bank account. They also manage the merchant's payment processing relationship, handle chargebacks, and provide fraud monitoring services.

Connecting to Payment Gateways:

1. When a merchant wants to accept card payments, they apply to an acquiring bank (or a Payment Aggregator, which itself works with an acquiring bank).

2. Once approved, the acquiring bank (or its partner Payment Gateway provider) provides the merchant (or Payment Aggregator) with the necessary API credentials (like API keys, secret keys, merchant IDs, terminal IDs).

3. These credentials are vital for the merchant's e-commerce platform or POS system to securely connect to the Payment Gateway. (eg. Cybersource, PayU)

4. The Payment Gateway then acts as the secure conduit, encrypting the transaction data and routing it from the merchant to the acquiring bank and onward through the Card Networks. Essentially, the Payment Gateway acts as the secure connection that the Acquiring Bank uses to send transaction requests to the Card Networks (like Visa or Mastercard) for approval.

5. Card Networks

• Who they are: These are the global operational networks, such as Visa, Mastercard, American Express, and Discover.

• Their role: Card Networks serve as the central nervous system of the payment ecosystem. They establish the rules and standards for all transactions, facilitate the routing of authorization requests and settlement data between acquiring and issuing banks, and manage the interchange fees that banks pay each other. They ensure the seamless interoperability of billions of cards and terminals worldwide.

Acting as a guarantor: Imagine you swipe your card in Tokyo, issued by a bank in Brazil. How does the Tokyo merchant's bank trust a bank they've never met?

That's the magic of Card Networks (Visa, Mastercard, etc.).

They are the ultimate trust brokers. Banks don't trust each other directly for every payment. Instead, they trust the network.

Here's how:

• The Network Guarantees: When your card payment is approved, the network essentially tells the merchant's bank: "Don't worry, we'll make sure you get your money, even if the issuing bank fails."

• Backed by Collateral: This guarantee isn't empty. All banks participating in the network contribute to a common pool of funds (collateral and default funds). If one bank defaults, the network uses these reserves to cover the payment.

• The Global Reconciler: The network operates sophisticated "clearing houses" that reconcile billions of transactions daily, calculating who owes whom, and then facilitating the actual fund transfers between banks.

So, while banks are strangers, the Card Network is the trusted intermediary that guarantees every transaction, making global commerce frictionless and reliable.

The Role of the Settlement Guarantee Fund (SGF):

To ensure the integrity and stability of the payment system, especially in scenarios where a participating bank might default on its obligations, Card Networks (or the central clearing entities they operate) often establish a Settlement Guarantee Fund (SGF).

• What it is: The SGF is a pool of funds, often contributed by all participating banks (Issuing and Acquiring Banks) within the network, or backed by collateral and lines of credit. Think of it as a shared insurance policy for the entire payment system.

• How it works: If a bank, say an Issuing Bank, authorizes a transaction and then faces severe financial distress or even fails before the actual funds are settled to the Acquiring Bank, the SGF steps in. Instead of the Acquiring Bank (and by extension, the merchant) losing the money, the SGF would cover the shortfall to ensure that the settlement completes as promised.

• Why it matters (The "Bank Closes" Scenario): This mechanism is critical. Without an SGF (or similar robust risk-mitigation measures), the failure of a single bank could trigger a domino effect, undermining confidence and potentially paralyzing the payment system. The SGF acts as a last resort, guaranteeing the completion of valid transactions even if an individual participant bank cannot meet its obligations. It ensures that the "promise to pay" established during authorization is ultimately fulfilled, maintaining the trust that is foundational to cashless commerce. This systematic safeguarding prevents individual bank failures from disrupting the entire payment chain and protects all participants from unexpected lossesThis explanation clarifies what an SGF is, its purpose, and how it acts as a critical safety net, specifically addressing the "bank closes next day" scenario. It should resonate well with your target audience of payment professionals, compliance specialists, and product managers.

6. The Issuing Bank

• Who they are: This is the financial institution that issued the credit or debit card directly to the cardholder.

• Their role: The Issuing Bank is responsible for authenticating and authorising or declining transactions based on the cardholder's available funds or credit limit, card status (e.g., active, expired, reported stolen), and their own internal fraud detection rules. If approved, they temporarily "hold" the funds for a credit card or debit the account for a debit card. They also manage the cardholder's account, statement generation, and customer service for card-related inquiries.

Authentication: Hey, does this card belongs to you?

Ever wondered what really happens behind the scenes when you enter your OTP for an online payment? You’re probably focused on completing the transaction—but there’s a whole cast of digital players working in the background to ensure your card hasn’t been compromised.

Let’s peek behind the curtain.

The Flow Begins: Cardholder to Issuer

When you, the cardholder, initiate a payment on a merchant's site—say you're buying sneakers from an online store—your payment journey starts simple:

1. You enter your card details (PAN, expiry, CVV).

2. Tokenisation Flow/Guest Checkout Flow (covered in my last article).

3. This information travels through the Payment Gateway → Payment Aggregator → Acquiring Bank → Card Network.

4. It reaches your Issuing Bank (e.g., Axis Bank) for authentication.

This is the step where the issuing bank must verify that it’s really you making the transaction.

But Wait, the Bank Doesn't Always Authenticate Directly...

Most banks don’t handle authentication in-house anymore.

Instead, they rely on a specialized actor: the Access Control Server (ACS). (eg. Wibmo, M2P)

The ACS is a third-party system that performs the authentication step on behalf of the issuing bank.

Enter: EMVCo's 3-D Secure Protocol (3DS)

To standardise this, 3DS — 3 Domain Secure was introduced:

The “3 domains” are:

1. Issuer Domain – your bank

2. Acquirer Domain – the merchant’s bank

3. Interoperability Domain – the card networks (Visa, Mastercard, etc.)

To orchestrate this digital handshake between the cardholder and the issuer during online payments, the payments industry relies on 3-D Secure (3DS) — a protocol developed by EMVCo, the same global body behind EMV chip standards.

But here’s the kicker: 3DS isn’t static — it’s evolving. Constantly.

Let’s walk through its journey:

3DS 1.0: The OTP Era

This was your classic “redirect” experience.

• The customer clicks Pay Now and gets thrown to a clunky bank page.

• An OTP is sent via SMS or email.

• You enter it and, boom — authenticated.

Drawbacks:

• Slow, bad UX (remember typing OTPs while switching apps?).

• Higher cart abandonment.

• No support for mobile-first experiences.

3DS 2.0+: The Contextual, Risk-Aware Era

3DS 2.0 changed the game by allowing frictionless authentication.

Key changes:

• Merchants and Payment Gateways can now share ~100+ data points (like device type, location, history) with the issuer before prompting the user.

• If the issuer deems it low risk, the customer won’t see any challenge — payment just goes through.

• If the issuer wants extra confirmation, it can still challenge via OTP, fingerprint, or face ID.

In India, RBI still requires a challenge (like OTP), but globally, frictionless flows are growing — and that’s still authentication, just risk-based and silent.

What About Biometrics?

3DS 2.x supports biometric authentication too — using your phone’s face ID or fingerprint, especially on apps or browser-native flows. This is increasingly seen in tokenised device-based payments.

3DS Keeps Evolving

EMVCo and global networks are working toward:

• Better UX across devices.

• Stronger cryptography for cardholder identity.

• Seamless embedded authentication inside merchant apps (no redirect).

You may never see 3DS at work — but behind that one-click checkout, it’s humming in the background, risk-scoring every transaction.

When you click "Pay," your merchant's system asks the card network where to send you for authentication. The card network (like Visa or Mastercard) knows which ACS (Access Control Server) your specific bank uses and provides that ACS URL to the merchant's system. Then, the merchant's system simply redirects your browser to that ACS URL, presenting you with the challenge.

We'll unravel the intricate details on 3DS in the upcoming article!

Real-World Example: Ever Seen “Powered by” on the OTP Page?

That’s your Access Control Server (ACS) in action.

Imagine this:

• You're using your Axis Bank debit card on an e-commerce site.

• The OTP page loads, and at the bottom, you notice the words: “ACS powered by Wibmo, M2P"

that’s Axis Bank delegating authentication to Wibmo, an ACS provider.

They handle:

• Serving the authentication page

• Risk evaluation

• OTP validation

• Communicating the result back to the issuing bank

When a 3D Secure (3DS) authentication is successful, the Access Control Server (ACS) doesn't just send a simple "yes." It provides specific cryptographic values that are crucial for the next steps in the payment flow and for determining liability in case of fraud. These two key values are the ECI and the CAVV.

Let's break down what the ACS responds with:

1. Electronic Commerce Indicator (ECI)

The ECI is a numerical value that indicates the outcome of the 3D Secure authentication. It's a critical piece of information that travels with the transaction through the payment network to the acquiring bank and ultimately to the issuing bank during the authorization request.

• What it tells you: The ECI signifies the level of authentication performed and is a major factor in determining liability shift.

Common ECI values (may vary slightly by network):

Successful Authentication (05):

• Meaning: The cardholder was successfully authenticated by the issuer (e.g., via OTP, password, or seamless frictionless flow). This is the best outcome for merchants, as it usually means liability shifts to the issuing bankfor fraud-related chargebacks.

Attempted Authentication- Frictionless or Issuer/Cardholder Not Participating (03):

• Meaning: Authentication was attempted, but either the cardholder or issuer was not fully enrolled/participating, or the transaction was deemed low-risk enough for a "frictionless" authentication where no user interaction was required. In many cases, liability still shifts to the issuing bank because the merchant attempted 3DS authentication. In other cases, it remains with the acquirer bank.

Authentication Failed/Not Performed/Unable to Authenticate (07)

• Meaning: Authentication either failed (e.g., incorrect OTP entered), was not performed (e.g., card or issuer not 3DS-enabled), or could not be completed due to technical issues. In these cases, liability generally remains with the merchant.

2. Cardholder Authentication Verification Value (CAVV)

The CAVV (for Visa) or AAV (Accountholder Authentication Value for Mastercard), or AEVV (American Express Verification Value) is a unique cryptographic value or "cryptogram" generated by the Issuing Bank's ACS during the authentication process.

• What it tells you: This is the actual proof of authentication. It's like a digital fingerprint of the successful authentication event.

• How it works:The ACS creates the CAVV based on various data points from the transaction (like PAN, ECI, seed values, authentication result code, etc.).This CAVV is sent back to the merchant's payment gateway/processor along with the ECI. When the merchant then sends the authorisation request to their acquiring bank, the CAVV (and ECI) is included in that authorisation message.

• The Issuing Bank (or the card network on its behalf) then verifies the CAVV during the authorization process. This verification ensures that:

1. The authentication actually took place.

2. The transaction details (amount, currency, etc.) match what was authenticated.

3. The cryptogram hasn't been tampered with.

• Purpose: The CAVV acts as irrefutable evidence that the cardholder was authenticated. If the CAVV is present and successfully verified, it strongly supports the liability shift from the merchant to the issuing bank in case of a fraudulent chargeback.

The Full Picture

So, when your Axis Bank card (or its Wibmo-powered ACS) successfully authenticates you, it's not just sending a "transaction approved" signal. It's packaging up crucial data:

1. An ECI value (e.g., "05" for Visa, "02" for Mastercard) indicating that successful authentication occurred.

2. A CAVV (or AAV/AEVV) – a unique, cryptographically secured value that is the tangible proof of your successful authentication.

These two pieces of information then travel with the authorisation request, informing all parties that Strong Customer Authentication (SCA) was performed, providing security, and critically, assigning liability in the complex world of online payments.

Payment Service Providers (PSPs) are constantly innovating here, employing techniques like auto-read OTPs (where your phone automatically fills the OTP) and other smart UI/UX methods to streamline the process and keep those authentication success rates high.

Beyond the OTP: Diverse Authentication Methods

Most of us are used to receiving an OTP (One-Time Password) via SMS or email and typing it in to complete a payment. But authentication in payments is evolving fast, and OTP is just one form of Two-Factor Authentication (2FA).

Under global security frameworks like 3DS2 (EMVCo) and RBI's 2FA guidelines, the “factors” used in authentication are categorized into:

Something You Know

• A password, PIN, or static code

Something You Have

• Your phone (to receive OTP or generate a dynamic code), a token device, or a card chip

Something You Are

• Biometrics: fingerprint, face scan, voice

Real-World Examples of Non-OTP Authentication:

1. UPI Autopay with biometric/FIDO – No OTP, but your biometric scan on the phone is enough.

2. Apple Pay / Google Pay – Authenticate using Face ID or Fingerprint.

3. Tokenised card transactions on NFC – Your phone is the “something you have”, and device binding acts as authentication.

4. RBA (Risk-Based Authentication) – In some countries, if a transaction is deemed low-risk (based on amount, location, device fingerprint), no second factor is prompted at all.

Global vs India Contrast

In India, 2FA is mandated even for ₹1 payments, typically through OTP.

But in Europe, UK, and the US, 2FA is risk-based, and if your transaction passes the test (like a $20 Amazon order from your usual IP and device), the payment goes through without OTP or biometric.

So when people say “why don’t international payments ask for OTP?”, it’s not because there’s no authentication—it’s just more intelligent, contextual, and silent.

What About In-Store Payments? Chip, PIN & Tap

Online isn’t the only place authentication happens. Card-present transactions — like when you pay at a store — have their own flavour of verification.

Let’s break it down:

EMV Chip & PIN Authentication

When you insert your card at a terminal and enter your PIN, you're completing what's called Cardholder Verification. Here's what’s going on:

• The EMV chip on your card generates a unique cryptogram for the transaction.

• You’re asked to enter your PIN — this verifies you are the cardholder.

• The terminal sends the cryptogram + PIN validation request to your issuing bank via the acquirer and card network.

If the PIN matches the bank’s records, the transaction is authenticated.

This is common in India, the UK, and most of Europe.

Tap-to-Pay (Contactless EMV)

For low-value transactions (e.g., under ₹5,000 in India), no PIN is needed.

Instead, device + card proximity + transaction pattern is used as a lightweight authentication signal. But:

• If you cross a value threshold or do too many taps in a day...

• You'll be asked to dip the card and enter your PIN — a fallback to strong authentication.

International Chip Payments

Ever noticed no OTP or PIN while shopping abroad? It’s not “less secure” — just different:

• Your chip creates a unique dynamic cryptogram.

• The terminal + network + issuer apply Risk-Based Authentication.

• If the risk is low (e.g., same card, known merchant, chip read successful), no PIN is needed.

In India, though, RBI mandates PIN for most card-present transactions — so you’ll typically always be prompted here.

So, Is Authentication Always Needed?

Yes — in some form:

• Online: via 3DS, ACS, OTP, or biometrics.

• In-store: via EMV PIN, contactless + device, or fallback swipe + signature.

• Autopay: device-bound checks or one-time setup with subsequent silent risk-based re-auth.

The form of authentication may differ, but the goal is always the same — to confirm that you are initiating the payment.

Authorisation: Why Your Bank Judges More Than Just Your Balance?

Okay, you have been authenticated, the cardholder, and verified that you're truly the person making the purchase online. But even if you're the legitimate cardholder, your bank isn't just going to hand over the money without a final, crucial check. This is where Authorization steps in, a rapid-fire risk assessment of both you and the merchant.

Understanding Authorisation:

Imagine you're at a grand store, about to buy something significant. You've just shown your ID (that was authentication!). But before the cashier finalizes the sale, they make a quick call to your bank. They're not asking, "Is this person who they say they are?" (that's done). They're asking: "Does this transaction, given everything we know about the cardholder and the merchant, seem safe to proceed right now?"

This quick check is what we call Authorisation. It's the "permission to spend" request that happens in milliseconds when you click "Pay" or swipe your card.

1. The "Permission to Spend" Request: Your merchant's system, through their acquiring bank and the card network, sends an Authorisation Request to your Issuing Bank (the bank that gave you your card). This request is packed with data: the amount, the merchant, your card details, and – crucially, if it was an online purchase – the ECI and CAVV (the proof of authentication).

2. Your Bank's Lightning-Fast Risk Calculation: This is where it gets truly fascinating. Your Issuing Bank doesn't just check your balance. In milliseconds, it performs a sophisticated, multi-layered risk assessment that evaluates both sides of the transaction:

Validating the Cardholder (You):

• Funds/Credit Check: "Does this cardholder have enough money in their debit account or enough available credit limit on their credit card for this specific purchase?"

• Spending Patterns: "Is this transaction consistent with the cardholder's usual spending habits? Is it an unusually large amount, a purchase from a brand new merchant, or in a different country than usual?"

• Past Behavior: "Have there been any recent suspicious activities on this account, regardless of authentication?"

• 3DS Data: The ECI and CAVV from 3D Secure play a massive role here, significantly reducing the cardholder risk for online transactions.

Validating the Merchant:

• Merchant Category: "Is this merchant type (e.g., gambling, electronics, travel) typically associated with higher fraud risks?"

• Merchant History: "Does this merchant have a history of high chargebacks or suspicious activity? Are they adhering to network rules?"

• Transaction Context: "Does the transaction amount make sense for this merchant? Is this merchant location unusual for a customer from this region?"

• Fraud Scores: Both banks and payment networks often use sophisticated risk scoring models (powered by AI and machine learning) that assign a numerical score to each transaction. This score incorporates hundreds of data points about the cardholder, the merchant, the device, and the transaction itself, helping to predict the likelihood of fraud.

3. The "Yes" or "No" (and Why):

• Approval: If all checks pass, and the combined risk is deemed acceptable, your Issuing Bank sends an "Approval" message back through the network to the merchant. This typically includes an authorization code – a unique number confirming that the funds are "held" or the credit is reserved for this specific transaction. Crucially, no money has actually moved yet! It's just a promise, a temporary hold on your funds or credit.

• Decline: If any check fails – whether it's insufficient funds, an expired card, a technical error, or a high-risk score flagged by the fraud models for either the cardholder or the merchant – your Issuing Bank sends a "Decline" message, often with a specific reason code. This is why your payment sometimes fails even if you know you have money or were authenticated – the bank's sophisticated risk engine decided the transaction itself carried too much risk.

Why is this separate from authentication?

• Authentication is about Identity: "Are you who you say you are?"

• Authorisation is about Risk & Funds: "Do you have the means, and does this specific transaction (involving both you and this merchant) pass all our safety checks right now?"

You can be perfectly authenticated, but still get declined if you don't have enough money, or if your bank's fraud detection system identifies a suspicious pattern related to the merchant or the nature of the transaction itself.

So, the next time your card sails through a purchase, remember that swift, silent conversation that just happened. It wasn't just your bank confirming your identity; it was a rapid, data-driven assessment of your financial readiness and the overall risk of the transaction, giving the merchant the crucial "go-ahead" to secure your funds for later collection. It's the moment your spending promise becomes official, secured by layers of intelligence.

Advanced Concept of Decoupled Flow:

When Authentication and Authorisation Are Handled Separately

In traditional payment flows, the same entity often handles both authentication and authorisation. However, modern payment ecosystems sometimes use a decoupled flow, where:

• Authentication is performed by one entity (e.g., a Payment Aggregator or a specialized Authentication Service Provider).

• Authorisation is performed by another entity (e.g., a different Acquiring Bank or Payment Gateway).

How Does This Work?

1. Authentication Step: The customer authenticates (e.g., via OTP, biometrics, UPI PIN) through the first service. Upon success, this service generates secure credentials as discussed above.

2. Passing the credentials: These are passed securely to the second entity that handles authorisation.

3. Authorisation Step: The authorisation entity uses the credentials to validate that the customer has been properly authenticated and proceeds with risk checks and fund holds.

Why Use Decoupled Flows?

• Flexibility: Allows merchants to integrate with multiple providers specializing in different parts of the flow.

• Scalability: Can optimize for better user experience by offloading authentication to a trusted provider.

Capture: The Final Act before Settlement:

We've seen how your issuing bank authenticates you, and then, in a blink, performs a swift risk assessment – an Authorisation – of both you and the merchant. This puts a "hold" on your funds or credit. But here's the final, and perhaps most strategically intriguing, piece of the payment puzzle: Capture.

The Invisible Bridge to Your Bank Account: Understanding Capture

Think of Authorization as getting a green light at a busy intersection. The path is clear, but the car hasn't moved yet. Capture is the moment the light actually turns green and the car starts moving towards its destination – your merchant's bank account.

Capture is the instruction from the merchant to their acquiring bank to actually collect the authorized funds.

1. From "Hold" to "Collect": After a successful authorization, the merchant typically sends a "capture" request to their acquiring bank. This might happen automatically right after authorization (especially for in-store purchases) or manually at a later stage.

2. The Funds are "Pulled": The acquiring bank then forwards this capture request through the card network to your Issuing Bank. Your Issuing Bank then officially debits your account (for debit cards) or posts the charge to your credit card statement (for credit cards). The "pending" status on your statement changes to a completed transaction.

3. The Journey to the Merchant: The funds then travel from your Issuing Bank, through the card network, to the acquiring bank, and finally into the merchant's business account. This entire process, from authorization to the funds landing in the merchant's account, is called settlement and typically takes 1-3 business days.

The Curious Strategy: How Merchants Save on MDR by Delaying Capture

This is where the timing of "Capture" becomes a crucial strategic decision for merchants, often tied to something called the Merchant Discount Rate (MDR).

MDR is the fee merchants pay for accepting card payments. It's a percentage of each transaction, plus sometimes a small fixed fee. This MDR covers various costs: interchange fees (paid to your Issuing Bank), network fees (to Visa/Mastercard), and the acquiring bank's processing fees.

Here's the intriguing part: merchants usually incur the full MDR fee only when the payment is captured and settled.

Imagine a scenario: You buy a custom-made piece of furniture online, with a 30-day return policy.

• Immediate Capture: If the merchant captures the funds immediately after your purchase, they get paid right away. But if you decide to return the furniture within the 30-day window, the merchant faces a refund process. This isn't just an inconvenience; they might have to pay additional fees to process the refund, and they definitely won't get their original MDR back (or only a portion of it, depending on their agreement). They've paid the MDR for a sale that ultimately didn't stick.

• Delayed Capture (The Smart Play): Savvy merchants might choose to delay the capture request until after the return period has expired, or until the goods are actually shipped/delivered.

How it works: They authorise your card at the time of purchase, placing a "hold" on your funds. This hold (authorization) typically lasts for a certain period (e.g., 7-30 days, depending on the card network and issuer).

The Benefit: If you return the item during the return period, the merchant simply voids the authorisation. No money ever moved, and therefore, no MDR was paid for that transaction. The "hold" on your funds is simply released, and your available balance goes back to normal.

Savings on MDR: By avoiding capturing payments for orders that are likely to be returned or cancelled, merchants significantly reduce the instances where they pay MDR on "non-sales." This is particularly common for:

• Custom or Made-to-Order Goods: Where production takes time.

• Pre-orders: For items not yet released.

• High-Value Items: Where returns are more common or costly.

• Services with a Trial Period: Where final billing occurs after a trial.

• Hotels/Car Rentals: Where a pre-authorisation is taken at check-in, and the final capture happens at checkout.

This strategic delay allows merchants to optimize their cash flow, reduce their operating costs, and ensure they only pay the MDR on transactions that are truly finalized. It's a fascinating example of how the intricate steps of payment processing offer hidden efficiencies for businesses.

Recurring Payments: Authorisation Without Authentication?

You've signed up for a streaming service, a gym membership, or an online magazine. Every month, like clockwork, the payment goes through. But have you ever noticed that after the very first time, you rarely (if ever) have to enter an OTP or password again for these recurring charges?

This isn't an oversight; it's a deliberate design to balance security with convenience, especially for payments you've authorized to happen repeatedly.

Here's why and how this is possible for your subscriptions and automated bills:

• The Key: You typically undergo full 3D Secure authentication (e.g., OTP) when you first set up that recurring payment or standing instruction with a merchant. This initial authentication serves as your explicit consent for future charges. Think of it as a one-time, highly secure handshake.

• The Automation: Once this initial authentication and mandate registration are securely complete, subsequent recurring payments of a fixed amount are often processed without requiring an OTP every single time. Your bank already has your initial, explicit consent and the secure e-mandate on file. This prevents endless OTPs for your monthly streaming service!

• India's Specific Rules (RBI e-mandate framework): Since October 2021, the RBI's framework specifies that for recurring payments up to ₹15,000 (and up to ₹1,00,000 for specific categories like mutual funds, insurance, credit card bills), only the first transaction (to set up the e-mandate) needs AFA (Additional Factor of Authentication, like OTP). For amounts exceeding these thresholds, AFA is required each time. Banks also send helpful pre-debit notifications (SMS/email) at least 24 hours in advance, allowing you to easily manage or opt out of upcoming payments.

So, while strong authentication is paramount for online security, the system is smart enough to know when you've already given your explicit consent for a recurring charge. This allows your subscriptions to run smoothly, avoiding repetitive OTPs, while still ensuring security through that critical first-time verification.

This seamless automation is undeniably convenient, but it raises an interesting technical question for the curious minds among you: If there's no new OTP and no fresh authentication challenge for these subsequent recurring payments, what specific value or reference is transmitted as the CAVV (Cardholder Authentication Verification Value) in the authorisation request to signify that the transaction is legitimate and linked to a previously authenticated mandate?

We've explored the hidden steps of your online card payments. Now, put on your detective hat and pay attention next time you hit "buy":

1. Who's Really Checking Your OTP?

When that page pops up asking for your OTP, have you ever noticed the small print like "Powered by Wibmo" or "Secured by M2P"? Why isn't it just your bank's usual page? Next time, try to spot which company (the ACS) is acting as your bank's security guard, making sure it's really you.

2. Why Did My Payment Get Rejected (Even with the Correct OTP and Enough Money)?

It's frustrating when you type in the right OTP and know you have plenty of cash, but your payment still fails. If it's not a money issue, what else could it be? Could your bank's hidden fraud system be flagging the store, the item, or even your usual spending habits as suspicious, just to keep your money safe?

3. Why Is My Money "Pending" Forever?

You made a purchase, but your bank app shows the transaction as "pending" for days or weeks. Why isn't the money officially gone yet? Could the store be holding onto your funds for a reason, perhaps waiting for a return period to end, to save on their own fees?

Until next time!