Payments Training Hub
Authorisation: real time check 1 Authorisation NOW 2 Terminal 3 Cardholder controls 4 Approval 5 Merchant never 6 Path Authorisation is the real time check that happens while the customer is still at the till or on the checkout page. Step 1 of 6 Authorisation: real time check 1 NOW Authorisation 2 Terminal 3 Cardholder controls 4 Approval 5 Merchant never 6 Path Authorisation is the real time check that happens while the customer is still at the till or on the checkout page. Step 1 of 6
Terminal sends the request 1 Authorisation 2 Terminal NOW 3 Cardholder controls 4 Approval 5 Merchant never 6 Path The terminal sends the request to the acquirer, the acquirer forwards it to the card scheme, and the scheme routes it to the issuer using the card number. Step 2 of 6 Terminal sends the request 1 Authorisation 2 NOW Terminal 3 Cardholder controls 4 Approval 5 Merchant never 6 Path The terminal sends the request to the acquirer, the acquirer forwards it to the card scheme, and the scheme routes it to the issuer using the card number. Step 2 of 6
Cardholder controls 1 Authorisation 2 Terminal 3 Cardholder controls NOW 4 Approval 5 Merchant never 6 Path It checks cardholder controls, such as a daily limit or a block on online spending. Step 3 of 6 Cardholder controls 1 Authorisation 2 Terminal 3 NOW Cardholder controls 4 Approval 5 Merchant never 6 Path It checks cardholder controls, such as a daily limit or a block on online spending. Step 3 of 6
Approval travels back as an authorisation response 1 Authorisation 2 Terminal 3 Cardholder controls 4 Approval NOW 5 Merchant never 6 Path The approval travels back as an authorisation response, message type 0110, from issuer to scheme to acquirer to merchant. Step 4 of 6 Approval travels back as an authorisation response 1 Authorisation 2 Terminal 3 Cardholder controls 4 NOW Approval 5 Merchant never 6 Path The approval travels back as an authorisation response, message type 0110, from issuer to scheme to acquirer to merchant. Step 4 of 6
Merchant never clears it 1 Authorisation 2 Terminal 3 Cardholder controls 4 Approval 5 Merchant never NOW 6 Path If the merchant never clears it, the hold expires and the funds are released. Step 5 of 6 Merchant never clears it 1 Authorisation 2 Terminal 3 Cardholder controls 4 Approval 5 NOW Merchant never 6 Path If the merchant never clears it, the hold expires and the funds are released. Step 5 of 6
Path needs its own message 1 Authorisation 2 Terminal 3 Cardholder controls 4 Approval 5 Merchant never 6 Path NOW Each path needs its own message, its own log entry and its own reconciliation treatment. Step 6 of 6 Path needs its own message 1 Authorisation 2 Terminal 3 Cardholder controls 4 Approval 5 Merchant never 6 NOW Path Each path needs its own message, its own log entry and its own reconciliation treatment. Step 6 of 6

Steps of this lesson, in order.

0:00 / 4:19 Step 1 of 6

Authorization in Real Time

Card Authorization, Clearing and Settlement, Lesson 2 of 8, Narration 4:19, D08 Cards and alternative payments

ReconciliationAuthorisationFraud scoring

What you will learn

Your objective. By the end of this lesson, you will be able to explain authorization in real time. Authorisation is the real time check that happens while the customer is still at the till or on the checkout page.

Why it matters. Step four is the hold, and the analyst must understand how long it lasts.

Chapter objective: Learner explains card authorization, clearing, and settlement, including the roles of issuer, acquirer, network, and merchant, and traces a card transaction from swipe to settlement. Learner practises this skill on realistic banking cases, explaining the reasoning clearly and using correct terminology throughout the work.

Key learning points

  • Authorisation: real time check
  • Terminal sends the request
  • Cardholder controls
  • Approval travels back as an authorisation response
  • Merchant never clears it
  • Path needs its own message

Key terms

Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.

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

Fraud scoring: A risk score assigned to a payment based on factors such as amount, location, device, velocity and customer history.

Payment flow diagram showing Authorization in Real Time.

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 customer pays by card at a shop. The terminal shows approved, but the shop owner asks when the money will actually reach the shop account. What is the correct explanation?

Takeaway and next step

What to remember

If the merchant never clears it, the hold expires and the funds are released.

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

Open the Payment Lifecycle Simulator →

Builds on "The Four Parties and the Card Transaction".

Transcript and full text

Show transcript

Authorisation is the real time check that happens while the customer is still at the till or on the checkout page. It answers one question before the sale completes: will the issuer honour this transaction for this amount, on this card, at this moment? The merchant terminal or website builds an authorisation request with the card number, the amount, the currency, the merchant name and location, the transaction type, and data about how the card was presented, for example chip, contactless, online or wallet. That request is the first message in the card flow, and every later step depends on it being complete and correct. Step one is the request travelling from merchant to issuer through the acquirer and the scheme. The terminal sends the request to the acquirer, the acquirer forwards it to the card scheme, and the scheme routes it to the issuer using the card number. In card messaging this is the authorisation request, sent in the ISO 8583 format as message type 0100. The scheme may add checks of its own, such as whether the card is reported lost, and it may act as a stand in when the issuer system is briefly unavailable, using rules the issuer set in advance. The whole journey normally takes one to two seconds. Step two is the issuer checks, and they run in a fraction of a second. The issuer verifies that the card is active and not blocked, lost or stolen, that the account exists, and that the available funds or credit cover the amount. It checks cardholder controls, such as a daily limit or a block on online spending. It runs fraud scoring on the amount, the merchant, the location and the device, and it checks the card verification value for online transactions and the PIN or biometric for card present ones. Any one of these checks can stop the transaction, and the order matters: a blocked card is declined before a funds check is needed. Step three is the response, and it carries the status the merchant must act on. If all checks pass, the issuer approves, returns an approval code, and places a hold on the funds. The available balance falls immediately, but the money has not left the account and the transaction is not yet a posted charge. The approval travels back as an authorisation response, message type 0110, from issuer to scheme to acquirer to merchant. If a check fails, the issuer declines and returns a response code. Common codes are 05 for do not honour, 51 for insufficient funds, 54 for an expired card, 14 for an invalid card number, and 91 for issuer unavailable. Step four is the hold, and the analyst must understand how long it lasts. An authorisation hold reserves the funds for a limited period, typically about seven days for a standard purchase, and longer for hotels, car hire and other travel merchants where the final amount is not known at check in. If the merchant clears the transaction within that window, the hold converts into a posted charge. If the merchant never clears it, the hold expires and the funds are released. Exceptions are where authorisation design is tested, and there are four the analyst must handle. A decline is a firm no from the issuer, and the merchant must not retry it as a new request without a change. A timeout means no response arrived, so the status is unknown, and the merchant must reverse the authorisation or run a status check before retrying, or the customer can be charged twice. A partial approval means the issuer approves only part of the amount, and the merchant must collect the balance another way. A referral means the issuer wants a voice authorisation, usually a call to the issuer, before the sale can proceed. Each path needs its own message, its own log entry and its own reconciliation treatment. Reversals close the loop when a sale does not complete. If the customer cancels, the terminal fails, or the merchant voids the sale, the merchant sends an authorisation reversal, which asks the issuer to release the hold. A reversal is not a refund, because no money moved. A refund is a separate transaction that follows a cleared charge. Mixing the two up creates reconciliation breaks and customer complaints, so systems must keep authorisation, reversal, clearing and refund as four distinct transaction types with their own identifiers and statuses.

Authorisation is the real time check that happens while the customer is still at the till or on the checkout page. It answers one question before the sale completes: will the issuer honour this transaction for this amount, on this card, at this moment? The merchant terminal or website builds an authorisation request with the card number, the amount, the currency, the merchant name and location, the transaction type, and data about how the card was presented, for example chip, contactless, online or wallet. That request is the first message in the card flow, and every later step depends on it being complete and correct.

Step one is the request travelling from merchant to issuer through the acquirer and the scheme. The terminal sends the request to the acquirer, the acquirer forwards it to the card scheme, and the scheme routes it to the issuer using the card number. In card messaging this is the authorisation request, sent in the ISO 8583 format as message type 0100. The scheme may add checks of its own, such as whether the card is reported lost, and it may act as a stand in when the issuer system is briefly unavailable, using rules the issuer set in advance. The whole journey normally takes one to two seconds.

Step two is the issuer checks, and they run in a fraction of a second. The issuer verifies that the card is active and not blocked, lost or stolen, that the account exists, and that the available funds or credit cover the amount. It checks cardholder controls, such as a daily limit or a block on online spending. It runs fraud scoring on the amount, the merchant, the location and the device, and it checks the card verification value for online transactions and the PIN or biometric for card present ones. Any one of these checks can stop the transaction, and the order matters: a blocked card is declined before a funds check is needed.

Step three is the response, and it carries the status the merchant must act on. If all checks pass, the issuer approves, returns an approval code, and places a hold on the funds. The available balance falls immediately, but the money has not left the account and the transaction is not yet a posted charge. The approval travels back as an authorisation response, message type 0110, from issuer to scheme to acquirer to merchant. If a check fails, the issuer declines and returns a response code. Common codes are 05 for do not honour, 51 for insufficient funds, 54 for an expired card, 14 for an invalid card number, and 91 for issuer unavailable.

Step four is the hold, and the analyst must understand how long it lasts. An authorisation hold reserves the funds for a limited period, typically about seven days for a standard purchase, and longer for hotels, car hire and other travel merchants where the final amount is not known at check in. If the merchant clears the transaction within that window, the hold converts into a posted charge. If the merchant never clears it, the hold expires and the funds are released.

Exceptions are where authorisation design is tested, and there are four the analyst must handle. A decline is a firm no from the issuer, and the merchant must not retry it as a new request without a change. A timeout means no response arrived, so the status is unknown, and the merchant must reverse the authorisation or run a status check before retrying, or the customer can be charged twice. A partial approval means the issuer approves only part of the amount, and the merchant must collect the balance another way. A referral means the issuer wants a voice authorisation, usually a call to the issuer, before the sale can proceed. Each path needs its own message, its own log entry and its own reconciliation treatment.

Reversals close the loop when a sale does not complete. If the customer cancels, the terminal fails, or the merchant voids the sale, the merchant sends an authorisation reversal, which asks the issuer to release the hold. A reversal is not a refund, because no money moved. A refund is a separate transaction that follows a cleared charge. Mixing the two up creates reconciliation breaks and customer complaints, so systems must keep authorisation, reversal, clearing and refund as four distinct transaction types with their own identifiers and statuses.

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.