Card issuing, acquiring, authorisation, clearing, settlement, and chargeback architecture

Cardholder and acceptance channel

Captures card or token credentials, amount, merchant, device, and authentication context.

Kind

channel

Owner

Merchant or wallet acceptance owner

Responsibilities

• Collect only necessary payment data
• Bind the transaction to the merchant and amount

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Secure capture
• No sensitive authentication data in logs
• Device and merchant context

Failure modes

• Compromised terminal or checkout
• Duplicate customer submission

Recovery

• Stop capture and rotate affected credentials
• Reuse the merchant transaction reference

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Merchant commerce and order service

Owns the order, creates one payment attempt, and separates order state from card-scheme state.

Kind

application

Owner

Merchant commerce team

Responsibilities

• Create a stable merchant reference
• Fulfil only under an explicit payment policy

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Amount and currency integrity
• Idempotent payment attempt
• No PAN in general application logs

Failure modes

• Order captured twice
• Goods released on an ambiguous authorisation

Recovery

• Query the payment attempt before retry
• Place fulfilment on hold while payment state is uncertain

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Acquirer gateway and merchant processor

Validates the merchant, routes authorisation and presentment, and maintains acquiring records.

Kind

gateway

Owner

Acquirer processing

Responsibilities

• Authenticate merchant and terminal
• Route under acceptance and scheme rules

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Merchant status
• Message integrity
• Duplicate and velocity checks

Failure modes

• Invalid merchant
• Network timeout
• Duplicate presentment

Recovery

• Return a precise decline or uncertain state
• Reconcile before any resubmission

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Card network and switch

Routes authorisation and clearing records between acquirer and issuer and calculates scheme positions.

Kind

external-network

Owner

Card scheme or domestic switch

Responsibilities

• Route using network and product rules
• Carry correlated authorisation, clearing, and dispute data

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Participant eligibility
• Message and reason-code validation
• Network duplicate control

Failure modes

• Unavailable route
• Late presentment
• Invalid clearing record

Recovery

• Apply network retry or stand-in rules
• Reject or defer with a reason

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Issuer authorisation and card-control service

Checks account, credential, available funds, fraud, limits, and card controls before approving or declining.

Kind

control

Owner

Issuer cards and fraud operations

Responsibilities

• Make one explainable authorisation decision
• Place or release a hold under product rules

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Credential validation
• Available funds
• Fraud and velocity
• Card and merchant controls

Failure modes

• False decline
• Approval without funds hold
• Duplicate hold

Recovery

• Use reversal or expiry rules
• Investigate with original authorisation evidence

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Issuer, acquirer, and merchant books

Records holds, clearing postings, scheme settlement, fees, and merchant funding without treating authorisation as final settlement.

Kind

ledger

Owner

Issuer, acquirer, and finance teams

Responsibilities

• Separate hold from booked transaction
• Reconcile scheme settlement to merchant funding

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Balanced posting
• Presentment-to-authorisation match
• Fee transparency

Failure modes

• Hold never released
• Presentment amount mismatch
• Merchant funding break

Recovery

• Release under documented expiry or reversal
• Open a financial break before correcting books

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Clearing, settlement, and merchant funding

Matches presentments, calculates participant positions, settles, and funds the merchant according to the network and acquiring agreement.

Kind

service

Owner

Scheme settlement and acquirer treasury

Responsibilities

• Validate and aggregate clearing records
• Fund merchants only from confirmed and reconciled obligations

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• File completeness
• Net-position balance
• Settlement evidence
• Reserve and fee rules

Failure modes

• Settlement failure
• Unbalanced batch
• Duplicate merchant funding

Recovery

• Stop the affected cycle
• Recalculate from immutable presentments
• Resume funding by stable batch key

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Dispute and chargeback case management

Tracks retrieval, representment, arbitration, evidence, reason codes, deadlines, and financial adjustments.

Kind

operations

Owner

Issuer and acquirer dispute operations

Responsibilities

• Apply the correct dispute stage and deadline
• Keep evidence and financial postings linked

Inputs

• Authorised business instruction and correlated state

Outputs

• Versioned result, status, and audit evidence

Controls

• Case eligibility
• Reason-code validation
• Evidence completeness
• Maker-checker adjustment

Failure modes

• Missed deadline
• Wrong reason code
• Financial adjustment without case evidence

Recovery

• Escalate before expiry
• Correct with a traceable case and journal

Non-functional requirements

• Durable correlation through stable business and technical identifiers
• Capacity and availability matched to the service-level objective
• Auditable state changes, configuration, and operator actions

Checkout payment attempt

card-holder-channel → card-merchant

Bind credentials or token, amount, merchant, and customer intent.

Contract

api · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Do not create a second attempt when the first response is uncertain.

Authorisation request

card-merchant → card-acquirer

Request an issuer decision through the acquiring route.

Contract

message · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Return approved, declined, or uncertain distinctly.

Network authorisation

card-acquirer → card-network

Route the authorisation with network correlation data.

Contract

message · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Use only permitted retry or stand-in treatment.

Issuer authorisation

card-network → card-issuer

Obtain the issuer's decision and response reason.

Contract

message · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Preserve timeout and late-response evidence.

Authorisation hold

card-issuer → card-ledgers

Reserve available funds without recording final settlement.

Contract

posting · synchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Release or reverse the hold under explicit rules.

Presentment and clearing batch

card-acquirer → card-clearing

Submit captured transactions for clearing.

Contract

file · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Reject duplicates or invalid records without silently dropping the batch.

Network positions

card-network → card-clearing

Provide balanced issuer and acquirer obligations.

Contract

settlement · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Stop settlement when the position set does not balance.

Settlement and merchant funding

card-clearing → card-ledgers

Post scheme settlement and merchant payable or funding.

Contract

posting · batch

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Reconcile settlement before replaying a funding batch.

Dispute financial state

card-ledgers → card-disputes

Link the case to the original authorisation, presentment, and posting.

Contract

operator · operator

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Keep the financial adjustment pending when evidence or eligibility is incomplete.

Chargeback and response

card-disputes → card-network

Exchange reason-coded dispute actions and evidence.

Contract

message · asynchronous

Controls

• Authentication and authorisation
• Integrity and replay protection
• Correlation and audit evidence

Failure treatment

Do not resubmit after a deadline or under an invented reason.

Purchase to merchant funding

Follow one card purchase through authorisation, presentment, settlement, and merchant funding.

1. Capture the payment — Customer intent captured. The channel protects the credential and binds it to amount and merchant.
2. Create one attempt — Order awaiting authorisation. The merchant records one stable payment attempt.
3. Route through the acquirer — Authorisation routed. The acquirer validates the merchant and selects the network route.
4. Reach the issuer — Issuer decision requested. The network carries the request and correlation references.
5. Approve and hold — Approved, not settled. The issuer approves and places a hold; this is not final settlement.
6. Clear and settle — Presentment settled. The captured purchase enters clearing and participant positions settle.
7. Fund and reconcile — Merchant funding recorded. Issuer, acquirer, scheme, and merchant books are reconciled.

Authorisation times out

The acquirer receives no final issuer response.

Last confirmed state

The request was routed; approval state is uncertain.

Settlement

No clearing or settlement has occurred.

Funds and entries

An issuer hold may or may not exist.

Next owner

Acquirer payment operations

Safe action

Return an uncertain outcome and query or reverse under network rules; do not create a fresh customer charge blindly.

Evidence required

• Merchant reference
• Network reference
• Issuer response or reversal evidence

Recovery

• Resolve the original attempt
• Release any orphan hold
• Reconcile late responses

Late or mismatched presentment

Clearing arrives after the permitted window or for a different amount.

Last confirmed state

Authorisation existed; clearing does not match it cleanly.

Settlement

Settlement depends on scheme treatment.

Funds and entries

The hold and booked transaction may differ.

Next owner

Issuer clearing operations

Safe action

Apply the current scheme rule; do not force-match unlike records.

Evidence required

• Authorisation
• Presentment
• Reason and timing data

Recovery

• Classify unmatched presentment
• Post under approved product rules
• Release or adjust the original hold

Chargeback evidence is incomplete

A dispute deadline approaches without required evidence.

Last confirmed state

The original transaction settled.

Settlement

Settlement is not undone merely by opening a dispute.

Funds and entries

Any provisional credit must remain linked to the case.

Next owner

Dispute operations

Safe action

Escalate the case and make only rule-supported provisional or final adjustments.

Evidence required

• Reason code
• Eligibility date
• Customer claim
• Merchant evidence

Recovery

• Complete or withdraw the case
• Post the supported adjustment
• Reconcile scheme and customer books

May the merchant treat authorisation as settlement?

• Treat as approval only — Keeps fulfilment policy honest about later clearing and settlement.
• Treat as final cash — Creates avoidable breaks when presentment, reversal, or settlement differs.

Model authorisation, capture, presentment, settlement, merchant funding, and dispute as separate states.

Where should cardholder data be allowed?

• Constrained cardholder-data environment — Reduces exposure but requires clear token and service boundaries.
• Broad application access — Simplifies some integrations but expands security and assessment scope.

Minimise storage and transmission of cardholder data; prove boundaries rather than assuming token use removes scope.