Payments Academy
More parties than a transfer PAYMENT OPERATIONS STARTED LIVE 01 More parties than a transfer - card payment involves more parties than ACTIVE 02 Debit credit and charge cards - draw directly on the customer current account QUEUED 03 Failures and chargebacks - Card payments create specific operational QUEUED 04 End-to-end purchase - Follow one purchase end to end. QUEUED 05 Four stages four parties - customer sees one charge on their statement QUEUED 06 BA requirements - business analyst writes requirements QUEUED A card payment involves more parties than a simple transfer, and understanding the flow is essential for anyone working in retail payments. Step 1 of 6 More parties than a transfer STARTED More parties than a transfer card payment involves more parties than ACTIVE Debit credit and charge cards draw directly on the customer current QUEUED Failures and chargebacks Card payments create specific operational QUEUED End-to-end purchase Follow one purchase end to end. QUEUED Four stages four parties customer sees one charge on their statement QUEUED BA requirements business analyst writes requirements QUEUED A card payment involves more parties than a simple transfer, and understanding the flow is essential for anyone working in retail payments.
Debit, credit and charge cards PAYMENT OPERATIONS IN PROGRESS LIVE 01 More parties than a transfer - card payment involves more parties than DONE 02 Debit credit and charge cards - draw directly on the customer current account ACTIVE 03 Failures and chargebacks - Card payments create specific operational QUEUED 04 End-to-end purchase - Follow one purchase end to end. QUEUED 05 Four stages four parties - customer sees one charge on their statement QUEUED 06 BA requirements - business analyst writes requirements QUEUED Debit cards draw directly on the customer current account, while credit cards draw on a credit line provided by the issuer, with the customer repaying the issuer later. Step 2 of 6 Debit, credit and charge cards IN PROGRESS More parties than a transfer card payment involves more parties than DONE Debit credit and charge cards draw directly on the customer current ACTIVE Failures and chargebacks Card payments create specific operational QUEUED End-to-end purchase Follow one purchase end to end. QUEUED Four stages four parties customer sees one charge on their statement QUEUED BA requirements business analyst writes requirements QUEUED Debit cards draw directly on the customer current account, while credit cards draw on a credit line provided by the issuer, with the customer repaying the issuer later.
Failures and chargebacks PAYMENT OPERATIONS IN PROGRESS LIVE 01 More parties than a transfer - card payment involves more parties than DONE 02 Debit credit and charge cards - draw directly on the customer current account DONE 03 Failures and chargebacks - Card payments create specific operational ACTIVE 04 End-to-end purchase - Follow one purchase end to end. QUEUED 05 Four stages four parties - customer sees one charge on their statement QUEUED 06 BA requirements - business analyst writes requirements QUEUED Card payments create specific operational and analytical challenges. Step 3 of 6 Failures and chargebacks IN PROGRESS More parties than a transfer card payment involves more parties than DONE Debit credit and charge cards draw directly on the customer current DONE Failures and chargebacks Card payments create specific operational ACTIVE End-to-end purchase Follow one purchase end to end. QUEUED Four stages four parties customer sees one charge on their statement QUEUED BA requirements business analyst writes requirements QUEUED Card payments create specific operational and analytical challenges.
End-to-end purchase PAYMENT OPERATIONS IN PROGRESS LIVE 01 More parties than a transfer - card payment involves more parties than DONE 02 Debit credit and charge cards - draw directly on the customer current account DONE 03 Failures and chargebacks - Card payments create specific operational DONE 04 End-to-end purchase - Follow one purchase end to end. ACTIVE 05 Four stages four parties - customer sees one charge on their statement QUEUED 06 BA requirements - business analyst writes requirements QUEUED Follow one purchase end to end. Step 4 of 6 End-to-end purchase IN PROGRESS More parties than a transfer card payment involves more parties than DONE Debit credit and charge cards draw directly on the customer current DONE Failures and chargebacks Card payments create specific operational DONE End-to-end purchase Follow one purchase end to end. ACTIVE Four stages four parties customer sees one charge on their statement QUEUED BA requirements business analyst writes requirements QUEUED Follow one purchase end to end.
Four stages, four parties PAYMENT OPERATIONS IN PROGRESS LIVE 01 More parties than a transfer - card payment involves more parties than DONE 02 Debit credit and charge cards - draw directly on the customer current account DONE 03 Failures and chargebacks - Card payments create specific operational DONE 04 End-to-end purchase - Follow one purchase end to end. DONE 05 Four stages four parties - customer sees one charge on their statement ACTIVE 06 BA requirements - business analyst writes requirements QUEUED The customer sees one charge on their statement, but behind it there were four stages and at least four parties. Step 5 of 6 Four stages, four parties IN PROGRESS More parties than a transfer card payment involves more parties than DONE Debit credit and charge cards draw directly on the customer current DONE Failures and chargebacks Card payments create specific operational DONE End-to-end purchase Follow one purchase end to end. DONE Four stages four parties customer sees one charge on their statement ACTIVE BA requirements business analyst writes requirements QUEUED The customer sees one charge on their statement, but behind it there were four stages and at least four parties.
BA requirements PAYMENT OPERATIONS COMPLETE LIVE 01 More parties than a transfer - card payment involves more parties than DONE 02 Debit credit and charge cards - draw directly on the customer current account DONE 03 Failures and chargebacks - Card payments create specific operational DONE 04 End-to-end purchase - Follow one purchase end to end. DONE 05 Four stages four parties - customer sees one charge on their statement DONE 06 BA requirements - business analyst writes requirements ACTIVE A business analyst writes requirements that cover each of these moments separately. Step 6 of 6 BA requirements COMPLETE More parties than a transfer card payment involves more parties than DONE Debit credit and charge cards draw directly on the customer current DONE Failures and chargebacks Card payments create specific operational DONE End-to-end purchase Follow one purchase end to end. DONE Four stages four parties customer sees one charge on their statement DONE BA requirements business analyst writes requirements ACTIVE A business analyst writes requirements that cover each of these moments separately.

Key points of this lesson, in order.

0:00 / 3:42 Step 1 of 6

Cards, how a card payment really works

Payment Instruments and Types, Lesson 3 of 7, Narration 3:42, D01 Foundations of money and payments

AuthorisationSettlementChargeback

What you will learn

Your objective. By the end of this lesson, you will be able to explain cards, how a card payment really works. A card payment involves more parties than a simple transfer, and understanding the flow is essential for anyone working in retail payments.

Why it matters. A business analyst must distinguish between authorisation, clearing, settlement, and dispute, and must know which system holds the truth at each stage.

Chapter objective: Learner compares cash, cheques, cards, direct debits, credit transfers, and digital wallets, and selects the right instrument for a given business need based on speed, cost, risk, and reversibility. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.

Key learning points

  • More parties than a transfer
  • Debit, credit and charge cards
  • Failures and chargebacks
  • End-to-end purchase
  • Four stages, four parties
  • BA requirements

Key terms

Authorisation: Approval by the issuer for a card transaction to proceed, confirming the card is valid and funds or credit are available.

Settlement: The final movement of funds between banks to discharge obligations created by cleared payments. Settlement is usually made in central bank money or through correspondent accounts.

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.

Payment flow diagram showing Cards, how a card payment really works.

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

A subscription business wants to collect a fixed monthly fee from thousands of customers without chasing each one. Which instrument fits, and what must it hold first?

Takeaway and next step

What to remember

A payment can be authorised but never cleared, cleared but disputed through a chargeback, or declined for reasons that have nothing to do with funds, such as a fraud rule or a scheme limit.

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

Open the Payment Lifecycle Simulator →

Builds on "Direct debits and pull collections".

Transcript and full text

Show transcript

A card payment involves more parties than a simple transfer, and understanding the flow is essential for anyone working in retail payments. When a customer pays by card, the merchant acquirer sends an authorisation request through the card scheme to the issuing bank, which checks the account, the available balance or credit limit, and fraud rules, and then approves or declines the transaction in seconds. The authorisation reserves the funds but does not yet move them. Later, the merchant batches its authorised transactions for clearing, and the scheme calculates net positions between issuers and acquirers for settlement. Debit cards draw directly on the customer current account, while credit cards draw on a credit line provided by the issuer, with the customer repaying the issuer later. Charge cards, prepaid cards, and commercial cards follow the same basic authorisation, clearing, and settlement pattern, but with different funding and repayment rules. Card payments can be made in person, online, or through a mobile wallet, and each channel has its own authentication requirements, such as a PIN, a one time passcode, or biometric approval. The growth of contactless and tokenised payments has made the customer experience faster, but the underlying flow is unchanged. Card payments create specific operational and analytical challenges. A payment can be authorised but never cleared, cleared but disputed through a chargeback, or declined for reasons that have nothing to do with funds, such as a fraud rule or a scheme limit. A business analyst must distinguish between authorisation, clearing, settlement, and dispute, and must know which system holds the truth at each stage. When you write requirements for card products, always state the expected behaviour for declines, for partial authorisations, for refunds, and for chargebacks, because those are the moments when customers need the clearest communication. Follow one purchase end to end. A customer in Bengaluru buys a laptop online for Rs 84,999 with a credit card. The merchant sends an authorisation request, the issuer checks the credit limit and the fraud rules, and approves it within seconds. The Rs 84,999 is now held against the card limit, but no money has moved. That evening the merchant batches the day's authorised transactions, 1,240 of them worth Rs 1.8 crore in total, and sends the batch for clearing. The card scheme works out the net positions between the issuer and the acquirer, and settlement happens the next morning, when the acquirer receives the funds and pays the merchant, less the merchant service charge. The customer sees one charge on their statement, but behind it there were four stages and at least four parties. Now change one fact and watch what breaks. The customer cancels the order before the merchant captures it, so the merchant never submits the transaction for clearing. The authorisation hold still sits on the card, and the customer cannot use that Rs 84,999 until the hold expires, usually after seven days, or until the merchant releases it. Or the authorisation succeeds but the clearing file is rejected because one amount does not match its authorisation, and the merchant is not paid until the file is corrected and resubmitted. A business analyst writes requirements that cover each of these moments separately. What the system does when authorisation succeeds, when capture is delayed, when clearing fails, and when a refund or chargeback arrives. The test cases should name the system that holds the truth at each stage, because the authorisation log, the clearing file, and the settlement account will not always agree.

A card payment involves more parties than a simple transfer, and understanding the flow is essential for anyone working in retail payments. When a customer pays by card, the merchant acquirer sends an authorisation request through the card scheme to the issuing bank, which checks the account, the available balance or credit limit, and fraud rules, and then approves or declines the transaction in seconds. The authorisation reserves the funds but does not yet move them. Later, the merchant batches its authorised transactions for clearing, and the scheme calculates net positions between issuers and acquirers for settlement.

Debit cards draw directly on the customer current account, while credit cards draw on a credit line provided by the issuer, with the customer repaying the issuer later. Charge cards, prepaid cards, and commercial cards follow the same basic authorisation, clearing, and settlement pattern, but with different funding and repayment rules. Card payments can be made in person, online, or through a mobile wallet, and each channel has its own authentication requirements, such as a PIN, a one time passcode, or biometric approval. The growth of contactless and tokenised payments has made the customer experience faster, but the underlying flow is unchanged.

Card payments create specific operational and analytical challenges. A payment can be authorised but never cleared, cleared but disputed through a chargeback, or declined for reasons that have nothing to do with funds, such as a fraud rule or a scheme limit. A business analyst must distinguish between authorisation, clearing, settlement, and dispute, and must know which system holds the truth at each stage. When you write requirements for card products, always state the expected behaviour for declines, for partial authorisations, for refunds, and for chargebacks, because those are the moments when customers need the clearest communication.

Follow one purchase end to end. A customer in Bengaluru buys a laptop online for Rs 84,999 with a credit card. The merchant sends an authorisation request, the issuer checks the credit limit and the fraud rules, and approves it within seconds. The Rs 84,999 is now held against the card limit, but no money has moved. That evening the merchant batches the day's authorised transactions, 1,240 of them worth Rs 1.8 crore in total, and sends the batch for clearing. The card scheme works out the net positions between the issuer and the acquirer, and settlement happens the next morning, when the acquirer receives the funds and pays the merchant, less the merchant service charge. The customer sees one charge on their statement, but behind it there were four stages and at least four parties.

Now change one fact and watch what breaks. The customer cancels the order before the merchant captures it, so the merchant never submits the transaction for clearing. The authorisation hold still sits on the card, and the customer cannot use that Rs 84,999 until the hold expires, usually after seven days, or until the merchant releases it. Or the authorisation succeeds but the clearing file is rejected because one amount does not match its authorisation, and the merchant is not paid until the file is corrected and resubmitted. A business analyst writes requirements that cover each of these moments separately. What the system does when authorisation succeeds, when capture is delayed, when clearing fails, and when a refund or chargeback arrives. The test cases should name the system that holds the truth at each stage, because the authorisation log, the clearing file, and the settlement account will not always agree.

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.