How Card Payments Actually Work

A card payment looks like the shortest possible banking interaction. A customer taps a card in Lisbon, the terminal beeps, and the merchant prints a receipt. The customer sees a notification before leaving the counter. The merchant sees "approved". Both sides assume the money moved.

That is only the front edge of the process.

A card payment is a conversation between a merchant terminal, acquirer, card scheme network, issuer processor, issuing bank, clearing system, settlement process, and merchant funding engine. The tap is only the customer-visible start. Behind it are authorisation messages, risk checks, holds, clearing files, interchange calculations, dispute rights, offline acceptance rules, stand-in processing, settlement accounts, and reconciliation.

This article explains how card payments actually work. The focus is on the common four-party model used by schemes such as Visa and Mastercard, with European examples and euro amounts. We will cover issuer and acquirer roles, the authorisation path, ISO 8583-style messages, holds, clearing, interchange, merchant settlement, offline approvals, stand-in processing, reversals, chargebacks, and why card payments are not instant money movement even when they feel instant.

The Four-Party Model Separates Customer, Merchant, Issuer, and Acquirer

Most everyday card payments use a four-party model:

• cardholder
• merchant
• issuer
• acquirer

The cardholder is the person using the card. The issuer is the bank or financial institution that issued the card and owns the relationship with the cardholder. The merchant is the shop, hotel, restaurant, or online seller accepting the card. The acquirer is the institution that provides card acceptance to the merchant and connects the merchant into the card network.

The card scheme sits between issuer and acquirer. It defines rules, message formats, dispute processes, interchange categories, settlement mechanics, and network connectivity.

A €42 purchase at a pharmacy in Athens therefore involves several relationships:

cardholder -> issuer: account, card, credit or debit product
merchant -> acquirer: acceptance contract and merchant settlement
issuer <-> scheme <-> acquirer: authorisation, clearing, settlement

The cardholder does not have a direct banking relationship with the acquirer. The merchant does not usually have a direct relationship with every possible issuer. The scheme network provides the common routing, rules, and settlement structure.

This separation explains many card behaviours that look strange from the outside. The merchant can receive an approval before it is paid. The issuer can place a hold before it receives final clearing. The acquirer can fund a merchant before every dispute window is closed. The scheme can route messages and calculate obligations without being the merchant's bank or the customer's bank.

Authorisation Is Permission, Not Final Settlement

The first real-time step is authorisation.

The merchant terminal asks whether the transaction should be allowed. The issuer, or a delegated stand-in system, replies with approval or decline.

For a card-present purchase, the path usually looks like:

POS terminal
  -> merchant acquirer host
  -> card scheme network
  -> issuer processor
  -> issuer decision engine
  -> issuer processor
  -> scheme
  -> acquirer
  -> POS terminal

The issuer evaluates:

• card status
• account status
• available funds or credit limit
• card-present authentication data
• merchant category
• terminal country
• transaction amount
• fraud velocity
• offline or online PIN result
• contactless counters
• product restrictions

If the issuer approves, it usually places a hold or reduces available credit. The customer sees a pending transaction. The merchant receives an approval code. But final clearing and merchant settlement have not happened yet.

This distinction matters. Authorisation says:

Under current information, the issuer permits this transaction.

It does not say:

The merchant has received funds and every settlement process is complete.

Many card support issues come from confusing those two statements.

The Authorisation Message Carries Operational Detail

Card authorisation messages are structured. They are not vague "please pay" requests.

Many card networks historically use ISO 8583-style message structures. The exact fields and private extensions differ by network, processor, and product, but the issuer may receive data such as:

message type: authorisation request
primary account number or token reference
processing code: purchase
amount: €42.00
merchant category code: pharmacy
merchant id
terminal id
acquirer id
point-of-service entry mode: contactless EMV
cardholder verification method result
transaction currency: EUR
local date and time
system trace audit number
retrieval reference number
EMV cryptogram data

That data lets the issuer make a narrow decision quickly. A pharmacy purchase in Athens using contactless EMV has a different risk profile from a keyed e-commerce transaction, a cash withdrawal, or a magnetic-stripe fallback in a country where chip cards are normal.

The issuer response may include:

approved or declined
response code
authorisation code
issuer authentication data
issuer scripts for EMV card update
advice or referral indicators

The response code is not only customer messaging. It drives terminal behaviour, merchant receipts, retry handling, and sometimes issuer case management.

The Acquirer Is the Merchant's Gateway Into Card Rails

The acquirer provides acceptance infrastructure to the merchant.

It may provide:

• terminal estate or gateway connectivity
• merchant onboarding and underwriting
• transaction routing
• fraud tools
• settlement reporting
• merchant funding
• chargeback handling
• PCI compliance support

The acquirer has to trust the merchant enough to fund it later. That is a credit and fraud risk. If a merchant sells expensive goods, receives card payments, and then disappears before chargebacks arrive, the acquirer may be left with losses. That is why merchant onboarding, reserves, rolling holds, and risk monitoring exist.

From the POS terminal's point of view, the acquirer is the first remote system. From the card network's point of view, the acquirer is the participant responsible for bringing the merchant's transaction into the scheme. From the merchant's point of view, the acquirer is the entity that eventually pays out funds, net of fees and reserves.

This role is different from the issuer. The issuer protects the cardholder account. The acquirer protects the merchant acceptance side.

The Issuer Owns the Cardholder Risk Decision

The issuer decides whether to approve.

For a debit card, the issuer cares about available account funds, holds, overdraft rules, fraud signals, and card status. For a credit card, it cares about available credit, delinquency status, fraud signals, product controls, and regulatory rules.

The issuer may decline because:

• insufficient funds or credit
• card blocked or expired
• suspected fraud
• wrong PIN
• merchant category blocked
• transaction exceeds limit
• contactless counter requires online verification
• card product does not support that transaction type

Approval is not only about money. A customer may have €5,000 in the account and still be declined because the card is blocked, the merchant category is prohibited, or fraud signals are strong.

Issuers therefore run specialised authorisation engines. They often sit next to, but not identical with, the core banking ledger. The authorisation engine needs low latency. The core ledger needs durable accounting. The two must agree on funds, but they are tuned for different jobs.

Available Balance Falls Before Ledger Balance Changes

When an issuer approves a debit card purchase, it may place an authorisation hold.

Suppose Elena has:

ledger balance:    €1,200
available balance: €1,200

She buys groceries in Vienna for €64. The issuer approves and creates a hold:

ledger balance:    €1,200
available balance: €1,136
active hold:       €64

The official posted account history may not yet contain the debit. The customer still has less spendable money. This is correct because the issuer has promised the merchant side that the transaction is approved under scheme rules.

When clearing arrives later, the issuer posts:

Debit:  Customer deposit liability        €64
Credit: Card settlement clearing          €64

The hold is consumed or released. Now:

ledger balance:    €1,136
available balance: €1,136
active hold:       €0

The customer saw one card purchase. The issuer modelled permission, reservation, and final posting as separate states.

Dual-Message Card Payments Split Authorisation and Clearing

Many card purchases are dual-message transactions.

The first message is authorisation. The second financial presentment arrives later through clearing.

This design supports cases where the final amount is not known at authorisation time:

• hotels
• car rentals
• fuel terminals
• restaurants with tip adjustment
• e-commerce partial shipment
• delayed merchant capture

A restaurant in Milan may authorise €70, then clear €83 after service is added. A hotel may authorise €300, then clear €248. An online shop may authorise €180, then capture only €110 because one item is out of stock.

The issuer must match clearing to authorisation and apply scheme rules:

authorised amount: €300
clearing amount:   €248
release unused:    €52

or:

authorised amount: €70
clearing amount:   €83
uplift allowed?    depends on merchant type and scheme rules

The matching logic needs references, merchant data, amount tolerance, date windows, and product rules. If it fails, customers see stale holds, duplicate-looking entries, or unexplained amount changes.

Clearing Files Turn Approvals Into Financial Presentment

Clearing is the process where the merchant side presents the approved transaction for financial processing.

The merchant or acquirer submits transactions into clearing, often in batches. The scheme processes those records and delivers clearing data to issuers. The issuer posts customer debits and settlement clearing entries. The scheme also uses clearing data to calculate settlement obligations between participants.

A clearing record may include:

• original authorisation reference
• clearing amount
• transaction currency
• settlement currency
• merchant id
• acquirer id
• interchange qualification data
• terminal and POS data
• transaction date
• processing date
• fee indicators

The issuer uses this data to:

• match the original hold
• post the customer debit
• release unused hold amounts
• detect duplicates
• calculate or verify fees and interchange
• feed reconciliation

Clearing can arrive hours or days after authorisation. If it never arrives, the issuer eventually releases the hold. If it arrives late after hold expiry, the issuer may still need to post under scheme rules, which can create customer confusion.

Settlement Moves Net Obligations Between Participants

Settlement is not the same as clearing.

Clearing provides transaction details and financial presentment. Settlement resolves net obligations between participants.

At a simplified level:

issuer owes acquirer side for purchases
acquirer side owes issuer side for refunds and chargebacks
scheme calculates net positions
settlement accounts move according to scheme cycle

The merchant does not usually receive money transaction by transaction directly from every issuer. The acquirer funds the merchant according to the merchant agreement, often net of fees, reserves, and prior adjustments.

The issuer may settle through scheme settlement accounts, correspondent accounts, central bank arrangements, or other participant structures depending on region and product.

The important point is that the customer posting, scheme settlement, and merchant funding are related but not identical timelines.

A customer may see a posted debit today. The merchant may receive payout tomorrow. The acquirer may manage settlement cycles and reserves separately. The scheme may net obligations across many transactions. Reconciliation proves those layers agree.

Merchant Funding Is Not the Authorisation Amount

The merchant rarely receives the full ticket amount untouched.

For a €100 card sale, merchant funding may be affected by:

• interchange
• scheme fees
• acquirer markup
• terminal or gateway fees
• rolling reserve
• chargeback debit
• refund offsets
• settlement timing

A simplified merchant statement might show:

gross card sales:       €10,000
refunds:                €400
interchange:            €180
scheme fees:            €30
acquirer fee:           €70
rolling reserve:        €200
net merchant payout:    €9,120

The customer sees one €100 purchase. The merchant sees batch settlement and fee deductions. The acquirer sees risk exposure and funding obligations. The issuer sees customer debits and scheme settlement positions.

This is why merchant settlement is its own article-worthy system. Authorisation approval is only the beginning of the merchant's cash lifecycle.

Interchange Is an Economic Rule Layer

Interchange is a fee generally paid from the acquirer side to the issuer side, governed by scheme rules and regulation. In Europe, consumer card interchange is capped in many contexts, but the details vary by product, transaction type, domestic rules, and commercial card treatment.

Interchange depends on factors such as:

• debit or credit
• consumer or commercial card
• domestic or cross-border
• card-present or card-not-present
• authentication method
• merchant category
• transaction amount
• regulatory region

Interchange is not computed by the POS terminal. It is determined through clearing and scheme fee logic. It affects merchant economics and issuer revenue.

Engineers working on card systems need to treat interchange as rule-driven financial data, not a constant percentage. A missing POS data element can change qualification. A transaction routed as e-commerce rather than card-present can change fee treatment. A failure to submit required authentication data can affect liability and economics.

Stand-In Processing Keeps Commerce Running During Issuer Outages

Sometimes the issuer is unavailable.

The scheme or processor may provide stand-in processing, where a delegated system approves or declines according to predefined rules. Stand-in exists because commerce cannot stop every time an issuer has a temporary outage.

Stand-in rules may consider:

• card status files
• risk limits
• transaction amount
• merchant category
• historical behaviour
• country
• velocity data available to the network

Stand-in is useful, but it creates risk. The issuer may not have made the live decision. The issuer later receives clearing or advice and must reconcile the transaction against its own account state.

If a customer had low funds during issuer outage, stand-in approval may create an overdraft or exception. If a fraudster exploits an issuer outage, stand-in limits determine loss exposure.

Issuers therefore configure stand-in carefully:

allow low-value grocery and transport
decline high-risk merchant categories
cap total stand-in exposure per card
block cards in negative status file

The right rules balance acceptance continuity against fraud and credit risk.

Offline Approvals Are Different From Stand-In

Offline approval happens at the card and terminal level, not at the scheme standing in for an unavailable issuer.

EMV cards and terminals can sometimes approve transactions offline under configured limits and risk rules. This is more common in environments where connectivity is unreliable, transaction values are low, or transit speed matters.

The terminal and card evaluate:

• terminal floor limit
• card offline counters
• card risk parameters
• terminal risk management
• cardholder verification result
• application cryptogram type

If the transaction is approved offline, the issuer may only learn later through clearing or advice. That means there was no live funds check at the moment of purchase.

Offline approval is therefore controlled tightly. A card may allow a few low-value offline transactions before requiring online authorisation. A terminal may force online for higher risk transactions. Issuers tune card parameters to limit exposure.

Offline does not mean insecure by default. It means risk was accepted locally under cryptographic and rule constraints. The issuer still needs later clearing, posting, and reconciliation.

Contactless Transit Shows Why Card Systems Optimise for Throughput

Transit systems in cities such as London or Amsterdam cannot wait several seconds for every gate tap. They need fast customer movement. Many transit card flows therefore use special acceptance logic, risk lists, aggregation, and delayed authorisation.

A gate may accept a tap quickly, then the back office calculates fares later:

• entry tap
• exit tap
• daily cap
• journey aggregation
• later authorisation or debt recovery

This is not the same as a simple retail purchase. The card system is adapted to the physical throughput requirement.

The tradeoff is delayed risk. If a card later fails payment, the transit operator may add it to a deny list, attempt debt recovery, or block future travel until the outstanding fare is paid.

This example shows why card systems are not one universal transaction lifecycle. They are rule systems shaped by merchant context.

Reversals Handle Failed or Aborted Authorisations

Card systems use reversals when an approved authorisation should be undone.

Common cases:

• terminal crash after approval
• merchant cancels before completion
• timeout after issuer approval
• duplicate authorisation detected
• partial ATM dispense failure

If the issuer receives a reversal before posting, it can release the hold. If posting already happened, a compensating entry may be needed.

The issuer should not silently erase the original event. It should preserve:

• original authorisation
• reversal message
• reason
• timestamp
• references
• hold release or accounting repair

This matters during disputes. A customer may claim the terminal failed but their available balance was reduced. The issuer needs to show whether approval happened, whether reversal arrived, and whether the hold was released.

Refunds Are New Transactions

A refund is normally a new transaction, not a deletion of the purchase.

If a customer returns a jacket in Barcelona, the merchant sends a refund through the acquiring side. The refund travels through the network to the issuer. The issuer posts a credit to the cardholder. Settlement and merchant accounting follow.

The original purchase remains in history:

purchase: €120 debit
refund:   €120 credit

This explains why refunds can feel slower than purchases. The purchase authorisation was a real-time permission decision. The refund may depend on merchant processing, acquirer submission, clearing, issuer posting, and settlement timing.

The merchant employee saying "refund processed" may mean the merchant system created the refund instruction. It does not always mean the issuer has already posted the credit.

Chargebacks Are Scheme Dispute Workflows

Chargebacks are not ordinary refunds.

A chargeback is a formal dispute under scheme rules. The issuer challenges a transaction because of fraud, goods not received, processing error, duplicate billing, cancelled service, or another reason code.

The workflow may involve:

• customer dispute intake
• provisional credit decision
• issuer chargeback submission
• acquirer response
• merchant evidence
• representment
• pre-arbitration
• arbitration
• final financial outcome

Every stage has time limits and evidence requirements.

Chargebacks affect accounting and settlement. The merchant may lose funds. The acquirer may debit the merchant. The issuer may give the cardholder provisional or final credit. The scheme may apply fees.

From a systems perspective, chargebacks require strong linkage to the original transaction:

original authorisation reference
clearing reference
merchant data
receipt or proof
cardholder claim
reason code
case state
financial adjustments

Treating chargebacks as simple transaction edits destroys the evidence chain.

Card-Not-Present Adds Authentication and Fraud Complexity

Online card payments have different risk from card-present EMV transactions.

In e-commerce, the merchant does not read a chip in person. The issuer may rely on:

• card number or token
• expiry date
• CVV or CVC
• billing information
• device fingerprinting
• 3-D Secure
• merchant risk data
• prior customer behaviour

In Europe, strong customer authentication rules influence many e-commerce flows. 3-D Secure can route a transaction through frictionless approval or a challenge flow. Liability may shift depending on authentication, exemptions, and scheme rules.

The authorisation message therefore carries e-commerce indicators. An issuer may treat a €200 card-not-present transaction very differently from a €200 contact chip transaction with offline PIN.

Card systems must preserve channel semantics. "Purchase for €200" is not enough.

Tokenisation Changes the Identifier, Not the Business Flow

Mobile wallets and network tokens replace the primary account number exposed to the merchant with a token. This reduces the value of stolen merchant-side card data.

In a mobile wallet transaction, the issuer and network may see:

• device token
• token requestor id
• cryptogram
• wallet assurance data
• device cardholder verification method result

The business flow remains recognisably card-based:

merchant -> acquirer -> network -> issuer -> response

But the risk decision changes because the issuer can evaluate token and device signals. A wallet transaction with biometric device verification may be lower risk than a manually keyed card number.

Tokenisation also adds lifecycle operations:

• token provisioning
• token suspension
• token deletion
• device binding
• token assurance scoring

These token states influence authorisation decisions.

Reconciliation Connects Authorisation, Clearing, and Settlement

Card reconciliation asks whether the pieces agree.

The issuer may reconcile:

• approved authorisations
• active holds
• clearing records
• posted transactions
• scheme settlement reports
• chargeback records
• fee reports

Common breaks include:

• authorised but not cleared
• cleared but no matching authorisation
• clearing amount differs from hold
• duplicate clearing
• reversal after clearing
• settlement total differs from clearing detail
• fee record missing from accounting

The acquirer reconciles merchant batches, scheme clearing, merchant funding, reserves, chargebacks, and fees.

Reconciliation is where the illusion of a single tap becomes a controlled financial process. If authorisation, clearing, posting, settlement, and merchant funding do not align, someone has to investigate and repair.

Idempotency Exists at Every Layer

Retries happen constantly.

The POS may retry after a communication error. The acquirer may retry to the network. The issuer processor may receive duplicate messages. Clearing files may be resent. Merchant funding jobs may rerun after failure.

Card systems need duplicate controls based on references such as:

• system trace audit number
• retrieval reference number
• authorisation code
• merchant id
• terminal id
• transaction timestamp
• clearing sequence
• acquirer reference

The exact duplicate logic depends on message type. A duplicate authorisation request should not create two holds. A duplicate clearing record should not post two debits. A duplicate merchant funding file should not pay the merchant twice.

The core pattern is:

if business reference already processed:
    return or ignore according to message type
else:
    process once and store the result

This is simple to state and difficult to implement across old processors, scheme retries, file batches, and partial failures.

A Full Card Payment Walkthrough

Take a €56 card-present purchase at a bookshop in Prague.

Initial customer state:

ledger balance:    €900
available balance: €900

The customer taps a card. The terminal and card perform EMV contactless processing and decide online authorisation is required. The terminal sends the transaction to the acquirer.

The acquirer validates merchant and terminal data, then forwards the request through the scheme. The scheme routes by card range or token mapping to the issuer processor.

The issuer checks:

• card active
• account active
• available funds
• merchant category
• transaction velocity
• EMV cryptogram data
• contactless risk counters

The issuer approves and places a hold:

ledger balance:    €900
available balance: €844
hold:              €56

The response returns through scheme and acquirer to the terminal. The terminal prints approved.

Later, the merchant's transaction is captured and included in acquirer clearing. The scheme sends clearing to the issuer. The issuer matches it to the authorisation, posts the debit, and consumes the hold:

Debit:  Customer deposit liability      €56
Credit: Card settlement clearing        €56

Scheme settlement later includes the transaction in net obligations. The acquirer funds the merchant according to settlement schedule and merchant agreement, net of fees and adjustments.

The customer experienced one tap. The system executed several linked but distinct processes.

A Failure Walkthrough: Approval Response Lost

Now consider a €210 purchase in Copenhagen.

The issuer approves, but the response is lost between acquirer and terminal. The terminal times out and tells the cashier the transaction failed.

Possible states:

• issuer approved and placed hold
• merchant did not complete sale
• reversal may or may not arrive
• customer may retry with same or different card

If the customer retries and the second attempt succeeds, the issuer must avoid leaving the first hold active forever. It needs reversal handling, duplicate detection, hold expiry, and support visibility.

If clearing later arrives for the first attempt, operations needs to know whether the merchant actually completed the sale or whether the clearing is invalid. The logs, reversal messages, and acquirer evidence matter.

This failure case explains why card systems have more states than approved and declined.

Testing Card Payment Systems Requires Non-Happy Paths

Useful tests include:

• authorisation approval with clearing match
• authorisation decline
• timeout after issuer approval
• reversal before clearing
• clearing without authorisation
• duplicate authorisation retry
• duplicate clearing file
• partial capture
• amount uplift
• stale hold expiry
• stand-in approval
• offline approval later cleared
• refund after purchase
• chargeback after clearing
• merchant funding rerun

Each test should verify customer state, settlement state, and reconciliation state.

For example:

case: duplicate clearing record
expected customer ledger: one posted debit
expected recon: duplicate clearing closed without second posting
expected audit: duplicate reference stored

Card payment correctness is mostly about these edges.

Acquirer Risk Starts Before the First Transaction

The acquirer does not only route messages. It underwrites the merchant.

Before a merchant can accept cards, the acquirer or payment facilitator usually evaluates:

• business identity
• beneficial owners
• merchant category
• expected transaction volume
• average ticket size
• refund pattern
• delivery model
• chargeback risk
• financial history
• prohibited goods or services

This matters because acquirers often fund merchants before all dispute risk has expired. If a travel merchant sells €800,000 of holiday packages and collapses before customers travel, chargebacks may arrive after the merchant has already received funding. The acquirer can be exposed if it cannot recover from the merchant.

Acquirers manage this risk through:

• rolling reserves
• delayed settlement
• volume caps
• transaction monitoring
• merchant category restrictions
• fraud rules
• termination rights

The payment approval at the terminal is therefore downstream of a prior risk decision: the acquirer agreed to let this merchant submit card transactions under defined conditions.

For engineers, merchant risk appears in systems as configuration:

merchant_status = active
allowed_mcc = 5812
max_ticket = €2,000
daily_volume_limit = €80,000
settlement_delay = 2 business days
rolling_reserve = 5 percent

If those controls are wrong, the acquirer can approve transactions for a merchant it should have blocked or fund money it should have held.

Merchant Category Codes Influence More Than Reporting

Merchant category code, or MCC, classifies the merchant's business type. It is not just analytics metadata.

MCC can affect:

• interchange
• issuer fraud scoring
• cardholder rewards
• spending controls
• cash-like transaction treatment
• regulatory restrictions
• corporate card policy
• chargeback rules

A €300 transaction at a hotel, a jewellery shop, a gambling merchant, a grocery store, and a government office can produce different issuer behaviour even if the amount is identical.

Corporate card programmes often use MCC controls. A company may allow hotels and airlines but block gambling, cash-like merchants, or luxury goods. Consumer issuers may apply extra risk controls for high-fraud MCCs. Some transaction types may be treated as cash advances rather than purchases.

This means acquirer merchant setup must be accurate. If a merchant is miscoded, the transaction may qualify for wrong fees, bypass issuer controls, or trigger unexpected declines.

MCC quality is therefore a control issue:

merchant sells electronics
configured MCC: grocery
effect: issuer risk model and interchange qualification may be wrong

Card rails depend on accurate merchant data because the issuer never sees the physical shop. It sees fields.

Merchant Descriptors Are a Customer Support System

The descriptor is the text customers see on their statement. It often determines whether they recognise the transaction.

A poor descriptor creates disputes:

customer shopped at: Athens Bike Repair
statement shows: ABR HOLDINGS LTD
customer opens dispute: "I do not recognise this"

Descriptors may include:

• legal name
• trading name
• city
• country
• phone number
• payment facilitator sub-merchant data

Payment facilitators and marketplaces make this harder. The merchant of record may be a platform, while the customer remembers a sub-merchant. Scheme rules often require meaningful sub-merchant descriptors to reduce confusion and chargebacks.

Engineering consequence: descriptor data must flow from merchant onboarding to authorisation, clearing, customer statement enrichment, and dispute tooling. It is not a cosmetic string added at the end.

If descriptor enrichment fails in the mobile app but the ledger posting is correct, support still suffers. If descriptor data is wrong in clearing, issuer statement history may become confusing for years.

Payment Facilitators Add a Layer Between Acquirer and Merchant

Payment facilitators, or payfacs, aggregate many sub-merchants under a master acquiring relationship. They make onboarding easier for small merchants and platforms.

The flow becomes:

sub-merchant
  -> platform or payment facilitator
  -> acquirer
  -> scheme
  -> issuer

This adds operational requirements:

• sub-merchant onboarding
• sub-merchant descriptor data
• split settlement
• platform risk monitoring
• reserve management
• chargeback routing
• fraud controls across many sellers

The issuer may see a transaction that needs both platform and sub-merchant information. The acquirer must know which sub-merchant created the transaction. The facilitator may need to fund multiple sellers from one acquirer settlement.

For example, a marketplace in Berlin may process a €48 purchase from a small seller in Porto. The card transaction may settle to the facilitator, while the facilitator later pays out the seller after fees, reserves, and platform rules.

This is still a card payment, but the merchant funding path has another ledger layer.

Tips, Pre-Authorisations, and Incrementals Need Special Handling

Some merchants do not know the final amount when authorisation happens.

Hospitality and travel are the classic cases:

• restaurant tip added after initial authorisation
• hotel incidentals pre-authorised at check-in
• car rental deposit held before return
• fuel pump pre-authorisation before final litres are known

These flows can use incremental authorisations, completion messages, or clearing amount tolerances depending on region, scheme, and merchant type.

A hotel example:

check-in pre-authorisation: €500
extra minibar authorisation: €60
final clearing: €438
unused hold release: €122

If the issuer cannot link those events, the customer may see multiple holds. If the merchant fails to complete or reverse correctly, available funds may remain tied up. If clearing exceeds authorised tolerance, the issuer may create an exception or dispute.

The acquirer must provide merchant systems that handle these scenarios correctly. A normal retail capture model is not enough for hotels, car rental, or fuel.

Partial Approval Is Useful but Operationally Awkward

Some systems support partial approval. If a customer has only €35 available for a €50 purchase, the issuer may approve €35 and the merchant can request another tender for the remaining €15.

Partial approval is common in some prepaid and gift-card contexts. It requires terminal and merchant POS support.

The merchant system must:

• recognise partial approval
• reduce remaining balance due
• ask for another payment method
• avoid treating the transaction as full approval
• print accurate receipt

The issuer response must clearly indicate approved amount. The clearing record must match the approved partial amount.

If the POS ignores partial approval, it may release goods while only part of the amount is covered. If the terminal treats partial approval as decline, the customer experience suffers.

Partial approval shows that even "approved" can require additional detail. Approval is not always binary.

Dynamic Currency Conversion Changes the Customer Decision

Dynamic currency conversion, DCC, lets a merchant offer to charge a customer in the card's home currency rather than the merchant's local currency.

For a euro-denominated card used in Zurich, the terminal may offer:

pay CHF 92.00
or pay approximately €96.40 with merchant-provided conversion

DCC is controversial because the offered conversion may be less favourable than issuer conversion. Regulations and scheme rules require disclosure and customer choice.

Technically, DCC changes transaction data:

• transaction currency
• cardholder billing amount shown
• conversion rate
• markup disclosure
• customer acceptance evidence

The issuer receives a transaction in the chosen currency. If the customer later disputes the conversion, the merchant and acquirer need evidence that the choice was offered clearly.

Terminal UI and receipt data matter here. A hidden or confusing DCC prompt is not only bad UX. It can become a compliance and dispute issue.

Card Present and Card Not Present Have Different Liability Logic

Liability rules determine which party bears fraud losses under scheme rules.

EMV chip liability shifts made counterfeit card-present fraud more likely to fall on the party that did not support secure chip processing. E-commerce liability may depend on 3-D Secure authentication, exemptions, and issuer or merchant decisions.

This means the transaction path affects economics after fraud happens.

For a card-present chip transaction:

• Was chip read?
• Was fallback used?
• Was PIN or CDCVM performed?
• Did terminal support EMV correctly?
• Was issuer online?

For e-commerce:

• Was 3-D Secure attempted?
• Was it frictionless or challenged?
• Was an exemption used?
• Did issuer authenticate?
• Was merchant using secure credential-on-file logic?

The authorisation approval alone does not settle liability. The surrounding evidence and rule framework matter. Systems must preserve that evidence in clearing, dispute, and case management.

Card Fees Are a Stack, Not One Fee

Merchants often call the cost "card fees", but the economics are layered.

Costs may include:

• interchange
• scheme assessment fees
• acquirer processing fee
• gateway fee
• terminal rental
• PCI or compliance fee
• chargeback fee
• cross-border fee
• authorisation fee
• refund fee

Pricing models vary:

• blended rate
• interchange plus
• tiered pricing
• flat fee per transaction
• monthly minimum

From a systems view, fee calculation depends on transaction data quality. A transaction may qualify differently based on:

• card product
• region
• merchant category
• authorisation and clearing timing
• authentication data
• entry mode
• refund or reversal status

Merchant statements therefore need detailed fee lines and reconciliation back to transactions. A merchant should be able to understand why a €100 transaction did not produce €100 payout.

Settlement Timing Is a Product Feature

Acquirers compete on settlement speed.

Merchant funding may be:

• same day
• next business day
• two business days
• weekly
• delayed for risk review
• split by merchant account

Fast funding is valuable to merchants, but it increases acquirer risk. Chargebacks and refunds may arrive after funding. The acquirer may protect itself through reserves or rolling holds.

For example:

restaurant card sales today: €3,800
next-day funding: €3,690 after fees
rolling reserve: €110
chargeback debit from prior week: €75
net deposit: €3,615

The merchant's bank account deposit is not a direct mirror of today's approved sales. It is the result of funding rules.

Settlement timing also depends on weekends, holidays, currency, and scheme cycles. A Friday evening batch may fund differently from a Monday morning batch.

Scheme Rules Define the Operating System of Cards

Card schemes are not only networks. They publish operating rules.

Rules cover:

• authorisation timing
• clearing presentment windows
• chargeback reason codes
• evidence requirements
• merchant category definitions
• fallback handling
• contactless limits
• tokenisation
• data quality
• dispute timeframes
• settlement obligations

Participants build systems around those rules. A merchant refund window, issuer chargeback deadline, or acquirer evidence requirement is not arbitrary product behaviour. It usually traces back to scheme rules, regulation, or merchant agreement.

This is why card software often contains rule tables and calendar logic. A presentment may be valid within one timeframe and late after another. A dispute may be representable with one reason code but not another. A fallback transaction may shift liability only under specific conditions.

The network message path is the visible part. The rulebook is the operating system behind it.

Monitoring Card Rails Requires Business Metrics and Technical Metrics

A card processing platform needs normal infrastructure monitoring, but that is not enough.

Technical metrics:

• authorisation latency
• timeout rate
• host availability
• queue depth
• file ingestion success
• duplicate rate
• HSM latency

Business metrics:

• approval rate
• decline reason distribution
• fallback rate
• stand-in volume
• clearing match rate
• stale hold count
• chargeback rate
• merchant funding exceptions

A server can be healthy while approval rate collapses because a risk rule was misconfigured. A network can be reachable while clearing files are late. A terminal estate can process transactions while fallback rate rises due to chip reader failure.

Card operations therefore need dashboards that combine protocol, accounting, and business indicators.

Data Retention Makes Later Disputes Possible

A chargeback may arrive weeks or months after the original purchase. The issuer, acquirer, and merchant need evidence.

Useful retained data includes:

• authorisation request and response
• EMV tags
• entry mode
• CVM result
• terminal id
• merchant id
• acquirer reference
• clearing record
• receipt
• settlement batch
• refund or reversal linkage
• 3-D Secure data for e-commerce

Retention must balance privacy, PCI requirements, data minimisation, and dispute needs. Sensitive card data must be protected or tokenised. Full PAN storage is restricted. CVV must not be stored after authorisation.

The engineering challenge is preserving enough evidence without retaining prohibited sensitive data.

Incident Recovery Is Reconciliation Heavy

When a card incident occurs, the public symptom may be simple:

some card payments failed between 14:05 and 14:22

The recovery work is not simple.

Operations needs to identify:

• requests declined incorrectly
• approvals where terminal never received response
• duplicate retries
• holds that should be released
• clearing records that may arrive later
• stand-in approvals during outage
• merchant batches affected
• customer notifications needed

Logs alone are not enough. The bank needs to join authorisation, holds, clearing, reversal, and settlement evidence. Incident recovery is therefore a reconciliation exercise.

Good systems preserve enough identifiers to answer:

Was this customer charged?
Did this merchant receive approval?
Did clearing arrive?
Was settlement included?
Was a reversal processed?

Without that traceability, restoring service is only the beginning of the incident.

Cross-Border Card Payments Add Currency and Scheme Complexity

A customer with a euro account may use a card in Zurich, Copenhagen, or Prague. The card purchase may involve a merchant currency, scheme settlement currency, issuer billing currency, and sometimes dynamic currency conversion.

The issuer needs to preserve:

• original merchant amount
• merchant currency
• scheme conversion amount
• issuer billing amount
• exchange rate date
• foreign exchange markup
• settlement amount

For example:

merchant amount: CHF 88.00
scheme converted amount: €91.40
issuer markup: €1.83
customer posted amount: €93.23

The customer may only remember the local shelf price. The issuer statement shows euros. The scheme clearing file carries conversion evidence. The merchant settlement may remain in Swiss francs or another settlement currency depending on acquirer setup.

This adds reconciliation and support complexity. A customer may dispute the exchange rate. The issuer needs to show the rate source, date, markup, and whether the customer chose DCC. The acquirer needs to show what the merchant submitted. The scheme records determine part of the answer.

Cross-border card payments are therefore multi-currency ledger events, not merely domestic card purchases with translated labels.

Authorisation Advice and Completion Messages Fill Gaps

Card systems include more than simple request and response messages.

Some flows use advice messages, completion messages, or notifications to report that something happened after an earlier decision. An ATM may send completion or reversal details. A pre-authorised transaction may later send completion. A merchant environment may send advice when online response timing was abnormal.

These messages matter because they repair uncertainty.

Example:

issuer approved ATM withdrawal
ATM attempted dispense
cash dispensed successfully
completion advice confirms physical outcome

or:

issuer approved
terminal failed before completion
reversal advice requests hold release

The issuer should process these messages idempotently and link them to the original authorisation. If advice is lost or duplicated, operations may need journal evidence from the acquirer or ATM operator.

This is why card message processing looks larger than the simple purchase path. The ecosystem has to represent physical-world outcomes that happen after the issuer's initial approval.

Card Networks Are Also Rule Enforcement Points

The scheme network does more than route packets.

It may enforce:

• participant connectivity rules
• message format validation
• stand-in logic
• token mapping
• fraud monitoring services
• dispute timeframes
• clearing file validation
• settlement calculation
• data quality programmes

If an acquirer sends malformed data, the network may reject it or pass it with penalties depending on severity and rule. If an issuer is unavailable, the network may stand in. If a transaction uses a network token, the network may map token to underlying account credentials before routing.

The scheme is therefore an operational control plane. Issuers and acquirers connect to it, but they also comply with its data, timing, security, and dispute rules.

This explains why card projects often involve certification with schemes. A bank cannot simply invent its own message interpretation and expect the network to accept it.

Merchant Presentment Timing Can Affect Issuer Risk

Merchants do not always clear immediately. Delayed presentment creates issuer and customer effects.

If a merchant clears late:

• the original hold may have expired
• customer available balance may have recovered
• the customer may believe the transaction disappeared
• issuer may need to post a debit later
• support calls may increase

Schemes set presentment timeframes. Late presentment may still be valid in some cases or may create dispute rights. The issuer's hold-expiry policy must balance customer availability against likely clearing arrival.

Example:

day 0: authorisation €74
day 5: issuer hold expires
day 8: merchant clearing arrives
day 8: customer sees posted debit

The customer may ask why a transaction from last week appeared today. The answer is merchant presentment timing. The issuer cannot explain that if it discarded the original authorisation context.

The Smallest Useful Mental Model

A card payment is not one instant transfer from customer to merchant. It is a controlled lifecycle across authorisation, reservation, clearing, settlement, merchant funding, and possible dispute.

The key ideas are:

1. the issuer protects the cardholder side
2. the acquirer protects and funds the merchant side
3. the scheme routes messages and defines rules
4. authorisation is permission, not final settlement
5. clearing turns approvals into financial presentment
6. settlement resolves obligations between participants
7. offline and stand-in approvals trade availability for controlled risk
8. reconciliation proves the layers agree

The terminal beep is real, but it is not the whole payment. It is the customer-visible result of a distributed financial workflow designed to make card acceptance fast, auditable, reversible where rules allow, and economically settleable later.

That is how card payments actually work.