Card fundamentals checkpoint
Check that you can walk a card payment end to end: who the four parties are, what authorisation does and does not do, how clearing and settlement actually move the money, and how chargebacks run — plus one check each on 3-D Secure and network tokens.
QUESTIONS AS TEXT
Q1. In the four-party model, which party decides whether a card payment is approved?
Answer: A: The issuer — the cardholder's bank checks the card's status, the available funds or credit, and its own fraud rules, then answers yes or no.
Approval is the issuer's call: it holds the account, so only it can check status, available funds or credit, and its own fraud picture. The acquirer and the network exist to carry the question to the right issuer in seconds — and the answer back.
Q2. What distinguishes a three-party card scheme from the four-party model?
Answer: A: One company acts as issuer, acquirer, and network at once, holding both the cardholder and the merchant relationship.
In a three-party scheme one company issues the cards, acquires the merchants, and runs the network between them — cardholder and merchant both contract with the same firm, and there is no interchange flowing between separate banks because there are no separate banks.
Q3. A card authorisation was approved. What has actually happened to the money?
Answer: A: Nothing has moved yet: the issuer has placed a hold reducing the cardholder's available balance, and funds move later, at clearing and settlement.
An approval means the issuer accepts the transaction and has reserved the amount with an authorisation hold. The actual movement of money waits for the acquirer's clearing record and the settlement cycle — often the next business day or later, depending on the scheme's calendar.
Q4. In ISO 8583 terms, which message pair carries a card authorisation and its outcome?
Answer: A: The 0100 authorization request and the 0110 authorization response.
The 0100 authorization request carries the card, amount, and merchant data to the issuer; the 0110 response returns the decision and, on approval, the authorisation code. The type codes come from the widely deployed 1987 version of the standard, and each network speaks its own dialect of it.
Q5. The issuer's authorisation system is down. What does stand-in processing mean for the payment?
Answer: A: The card network answers on the issuer's behalf, applying limits and rules the issuer configured in advance, and advises the issuer afterwards.
Stand-in processing keeps cards usable through issuer outages: the network approves or declines within parameters the issuer pre-set, then sends advice messages so the issuer can post the holds after the fact. The scheme rules place the resulting risk on the issuer.
Q6. Where in the card lifecycle is the interchange fee applied?
Answer: A: During the network's clearing cycle: as each clearing record is processed, the fee is calculated into the amounts settled between acquirer and issuer.
Interchange is applied in clearing: as the network processes each clearing record it computes the fee from its interchange tables, and settlement between acquirer and issuer happens net of it. Merchants feel it inside the merchant discount rate their acquirer charges.
Q7. How does money actually move between banks in card settlement?
Answer: A: The network calculates each participant's multilateral net position for the cycle, and the settlement bank moves those net amounts.
Card schemes settle on a deferred, multilateral net basis: obligations from the cycle's cleared records are netted per participant, and the net amounts move at the settlement bank. Whether merchant funding lands the next day or later depends on the scheme's calendar and the acquirer's payout terms.
Q8. Why is the amount an acquirer pays out to a merchant slightly less than what the customer paid by card?
Answer: A: The acquirer deducts the merchant discount — covering the interchange it pays the issuer, the scheme fees it pays the network, and its own margin.
The gap is the merchant discount rate: the acquirer's all-in price for card acceptance. Inside it sit the interchange the acquirer pays the issuer, the scheme fees the network charges, and the acquirer's own margin — visible as separate lines when pricing is unblended.
Q9. A cardholder disputes a charge and the issuer raises a chargeback. What is the merchant's formal way to fight it?
Answer: A: Representment: the acquirer presents the transaction a second time, with evidence that the charge was valid.
The chargeback lifecycle is structured: a chargeback with a reason code, then representment with evidence matched to that code (Mastercard's rulebook says second presentment; Visa's process calls it a dispute response), then pre-arbitration and finally network arbitration if nobody yields.
Q10. What does a chargeback reason code actually control?
Answer: A: The procedure for the case: which evidence counts, what can be argued, and the time limits each side has under the scheme's rules.
Reason codes select the playbook. Each network publishes its own set — Visa groups disputes into four categories, Mastercard uses message reason codes — and the code chosen determines the evidence a merchant must produce in representment and the clocks both sides run against.
Q11. In EMV 3-D Secure, what is the difference between the frictionless flow and the challenge flow?
Answer: A: Frictionless: the issuer authenticates silently from the risk data. Challenge: the shopper must actively verify, for example with a one-time code or an approval in their banking app.
The issuer's access control server scores the data sent with each 3-D Secure request. Low risk passes frictionless — the shopper notices nothing. Higher risk triggers a challenge the shopper must complete. Either way the result feeds into authorisation, and successful authentication generally shifts fraud liability to the issuer under scheme rules.
Q12. When a card has been added to a mobile wallet, what does the merchant's terminal receive at payment time?
Answer: A: A device token — a DPAN standing in for the real card number — plus a cryptogram; the network maps it back to the real PAN for the issuer.
Adding a card to a wallet triggers tokenisation under the EMV Payment Tokenisation framework: a token requestor (the wallet) asks the token service for a device token, and thereafter the phone presents that DPAN with a per-transaction cryptogram. The merchant's systems handle only the token — one reason tokenisation shrinks PCI DSS scope.