Card Clearing, Interchange, Settlement and Merchant Funding. A practitioner deep dive into post-authorization card financial processing across capture, presentment, clearing, interchange qualification, network fees, issuer and acquirer settlement, Regulation II debit economics, merchant funding, reconciliation, accounting and operational repair.
A card payment does not become financially complete when the terminal says Approved. Authorization is only the real-time permission stage. Chapter 29 begins after that decision and follows the transaction through the back-office financial lifecycle: capture, presentment, clearing, interchange qualification, network fee assessment, issuer and acquirer settlement, merchant funding, reconciliation, accounting, reporting and operational repair.
Chapter 27 established the participants. Chapter 28 followed the real-time authorization lifecycle. Chapter 29 now explains how those participants turn an approved commercial transaction into settled interbank obligations and a funded merchant position. Chapter 30 will separate the product behavior of credit, debit, prepaid, EBT and closed-loop value. Branch 7 will later go deeper into acceptance channels, stored credentials, disputes, refunds and fraud. This chapter therefore owns the financial processing spine after authorization without stealing those later topics.
The central learning principle is simple but critical:
Authorized amount, cleared amount, settlement amount and merchant-funded amount are related, but they are not the same financial truth.
A restaurant may authorize $120 and clear $145 after the tip. A hotel may authorize an estimated amount and later clear the final folio. A merchant may submit a batch after midnight even though the customer purchased hours earlier. The network may calculate interchange and other fees during clearing. Issuer and acquirer obligations may settle net rather than transaction by transaction. The acquirer may then fund the merchant net of merchant discount, adjustments, reserves, refunds or chargebacks according to the merchant agreement. A bank-grade system must be able to explain every one of those differences.
For a roughly 60-minute core session, spend about 35 minutes on Sections 2–4, Sections 5–8 and Sections 10–15. For the next 10 minutes, use the chapter’s three diagrams to keep clearing amounts, settlement positions and merchant funding separate. Use 10 minutes to work through one clearing or funding failure scenario in Section 15, then spend the final 5 minutes explaining: How could network settlement balance while a merchant still receives the wrong funding amount? Treat these timings as a study guide. The remaining sections, additional cases and extended reference material are follow-up study; completing the whole chapter takes longer.
Chapter navigator
- Why authorization is not the end of a card payment
- The end-to-end post-authorization financial chain
- Capture and presentment: turning a sale into a financial record
- Clearing records, matching and lifecycle correlation
- Interchange: what it is and how qualification works
- Network fees, merchant discount and the economics stack
- Visa clearing and settlement model
- Mastercard clearing and net settlement model
- American Express, Discover and alternative network operating models
- US debit interchange and Regulation II
- Issuer settlement, posting and cardholder financial truth
- Acquirer settlement and merchant funding
- Refunds, reversals, adjustments and dispute-boundary events
- Reconciliation, accounting and reporting
- Exceptions, operational controls and real-bank failure scenarios
- Architecture, testing, role checklist and authoritative references
1. Why authorization is not the end of a card payment
Authorization answers whether a transaction should be allowed to proceed at a particular moment. It gives the merchant a decision and usually causes the issuer to create an authorization record or hold. It does not by itself create the final financial obligation that the issuer and acquirer will settle. That financial obligation is formed through clearing and presentment under the applicable card-network rules.
This distinction is one of the first things a card operations analyst must understand. A customer sees an approved purchase immediately. The issuer may show it as pending. The merchant has a successful order. Yet the acquiring processor may not have submitted the financial transaction to the network. Until the financial record is captured and cleared, the network does not have the final transaction data needed to calculate settlement obligations.
A transaction can therefore exist in several states at once. The merchant can consider the sale complete. The issuer can hold funds. The network can have an authorization record but no clearing record. The acquirer can wait for the merchant’s batch close. A finance system can have no final posting yet. These are not contradictions; they are different lifecycle truths.
The financial lifecycle also explains why cleared amount can differ from authorized amount. Certain industries use estimated or incremental authorization. Restaurants may add gratuity under applicable rules. Fuel dispensers can authorize a provisional amount before the final purchase is known. Hotels and car-rental merchants may obtain an initial authorization and then submit a final transaction later. The clearing record must carry the final financial amount and the data required by the network to evaluate whether the transaction was processed correctly.
A bank that merges authorization and clearing into a single status such as SUCCESS creates operational risk. Customer service cannot tell whether the transaction is merely approved or fully posted. Reconciliation cannot identify an authorization with no presentment. Fraud teams cannot distinguish an authorization reversal from a financial refund. Finance cannot explain why the settled position differs from the day’s approval volume. Chapter 29 therefore uses a state model where authorization, clearing, settlement and funding are explicitly separate.
2. The end-to-end post-authorization financial chain
A simplified post-authorization purchase lifecycle looks like this:
merchant capture → acquiring processor → network clearing → issuer presentment → interchange and fee calculation → issuer/acquirer settlement obligation → interbank settlement → issuer posting → acquirer merchant ledger → merchant funding.
The exact technical sequence varies by network, processor, geography, message platform and merchant setup, but the business logic is durable. The merchant first converts the approved transaction into a captured financial transaction. That transaction is submitted to the acquiring side, often in a batch or clearing file even when authorization happened in real time. The acquirer or processor validates the financial record and forwards it through the network’s clearing process.
The network then applies transaction-processing rules. It associates the financial record with the authorization where required, validates message content, identifies product and merchant attributes, evaluates qualification criteria, applies interchange or other network-defined economics, and produces clearing outputs for the issuer and acquirer. Those outputs drive net financial positions and reporting.
The issuer receives clearing detail and posts the transaction to the cardholder account according to the issuer’s product model. A pending authorization hold may be matched and released or replaced by the posted transaction. The issuer’s network settlement obligation becomes part of the institution’s treasury and accounting position.
On the acquiring side, settlement received from the network does not automatically equal the amount paid to the merchant. Merchant funding is governed by the merchant agreement and acquiring model. The acquirer may deduct merchant discount, processing charges, prior refunds, chargebacks, reserves or other permitted adjustments. It may fund gross and collect fees separately, or fund net, depending on the arrangement.
For operations, the most useful habit is to preserve a common transaction identity across the chain: merchant transaction ID, authorization code, acquirer reference, network reference, clearing record ID, issuer posting ID, settlement cycle/date and merchant funding batch. Without those links, a simple question such as “why was the merchant funded $97.10 for a $100 sale?” can require manual searches across half a dozen systems.
3. Capture and presentment: turning a sale into a financial record
Capture is the merchant-side act of confirming that an authorized transaction should be submitted for financial processing. In some environments authorization and capture are closely coupled. In others the merchant first authorizes and later captures after fulfilment. E-commerce merchants often separate authorization from capture so goods are not financially presented until shipment or service delivery. Hotels, travel merchants and restaurants commonly have workflows where the final amount is known only after the initial authorization.
The merchant or payment platform typically sends captured transactions to the gateway, payment facilitator, acquiring processor or acquirer. The acquiring platform validates merchant status, amount, currency, transaction type, authorization references, timestamps, merchant identifiers, point-of-sale data and any product-specific fields. It may also perform duplicate checks and batch balancing before network submission.
Presentment is the financial submission of the transaction into clearing. The network terminology and exact record formats differ, but the business meaning is that the acquiring side is presenting the transaction to the issuer side for financial settlement. The presentment contains the data used to establish the final transaction amount and the financial obligations between members.
Timeliness matters. Card networks define processing and presentment expectations because delayed clearing weakens the relationship between the original authorization decision and the final financial event. A delayed transaction can also affect interchange qualification, customer experience, authorization-hold management and dispute evidence. Mastercard publicly notes that interchange qualification can depend on the time between authorization and clearing. Visa rules likewise impose transaction-processing and clearing obligations on participants.
A mature acquiring platform therefore records at least four times: customer transaction time, authorization time, merchant capture time and network clearing-submission time. Those timestamps answer different questions. If a merchant says “we captured immediately” but the acquiring processor submitted the batch six hours later, the defect is not at the merchant. If clearing rejects the record after the merchant batch balanced, the acquiring platform needs a repair queue rather than simply marking the purchase failed.
Batch control is still important even in a world of real-time checkout. Financial presentment often contains batched or cycle-based processing. Operations needs expected count, expected amount, accepted count, rejected count and financial total at each boundary. A batch can be technically delivered but financially incomplete if records were dropped, duplicated or rejected.
4. Clearing records, matching and lifecycle correlation
Clearing turns transaction records into recognized financial obligations. The network receives transaction detail from the acquiring side, validates it and makes corresponding information available to the issuer. The transaction is evaluated against network processing rules, product type, merchant category, geography, channel and authorization data.
The first major control is authorization-to-clearing matching. The clearing transaction should normally be linked to the correct prior authorization when an authorization was required. Matching can use authorization code, network reference values, PAN or token-derived identifiers, amount, merchant, date/time and other network-specific data. Exact matching logic belongs to network specifications, but the operational principle is universal: the bank must know which authorization became which financial presentment.
Several legitimate patterns complicate matching. A clearing amount may differ from the original authorization. One authorization may support incremental activity. A merchant may submit a completion after an estimated authorization. A reversal may release an unused authorization before the final clearing record arrives. Some transaction types follow different single-message or dual-message processing models. The matching engine therefore cannot rely on amount alone.
The second major control is duplicate presentment detection. Duplicate clearing is financially more dangerous than duplicate authorization because financial presentment can drive posting and settlement. A bank must distinguish a retransmitted technical file from a legitimately repeated customer purchase. File-level idempotency, record-level identifiers and business correlation all matter.
The third control is clearing reject management. A record can fail network or processor validation for malformed data, invalid references, timing issues, merchant configuration, unsupported values or other rule violations. The correct response is not to silently discard it. The acquiring side should create an exception with the original merchant transaction, rejection reason, financial amount and resubmission eligibility. If a corrected transaction is submitted, the audit trail must link original and replacement records.
The issuer also needs a clearing intake control. Network totals should reconcile to received detail. Detail should map to accounts. Posting exceptions should be visible separately from network settlement. A settlement amount can be correct at network level while an issuer account posting fails internally; that is an issuer posting break, not a network settlement break.
5. Interchange: what it is and how qualification works
Interchange is frequently misunderstood as “the merchant fee.” It is not. In the standard four-party purchase model, interchange is an amount transferred between the acquiring and issuing sides under the network’s rules. Visa describes interchange reimbursement fees as transfer fees between acquiring banks and issuing banks for Visa transactions. Mastercard states that interchange rates are generally paid by acquirers to issuers on purchase transactions.
The merchant normally pays a merchant discount rate or other acquiring price to its acquirer, processor or payment facilitator. That merchant price can include interchange as one cost component, but it can also include network fees, processor costs, risk cost, service charges and the acquirer’s commercial margin. Therefore interchange ≠ merchant discount.
Interchange qualification is also not a single static percentage. Networks publish categories and criteria. Mastercard publicly states that qualification can depend on merchant category, time between authorization and clearing, presence or absence of particular transaction data, enhanced data and merchant volume, among other criteria. Visa publishes U.S. interchange reimbursement information and detailed processing rules. The exact rate tables change, so a bank-grade educational product should teach the qualification model, not hard-code every current percentage into durable content.
A simplified qualification engine may consider:
- card product and funding type;
- merchant category code;
- domestic versus cross-border relationship;
- card-present versus card-not-present indicators;
- credential and security data;
- authorization and clearing timeliness;
- regulated versus exempt U.S. debit treatment where applicable;
- enhanced commercial-card data;
- transaction type, amount and other network criteria.
The output of qualification is more than a fee amount. Operations should retain the interchange category or qualification result, rate/rule version, calculation basis and amount. That evidence allows finance and merchant-pricing teams to answer why two $100 transactions produced different economics.
Downgrade or non-qualification analysis is especially important for acquirers. Missing data, late presentment or incorrect merchant configuration can increase processing cost. A strong bank therefore treats interchange optimization as a data-quality and operational-control problem, not merely a pricing problem.
6. Network fees, merchant discount and the economics stack
A merchant’s acceptance cost is made of multiple layers. Interchange is one layer. Networks may assess network or processing fees. Processors and gateways charge technology fees. Acquirers price merchant services, operational risk, fraud exposure, chargeback handling, support and commercial margin. Payment facilitators may bundle these components into simplified pricing.
The accounting stack must keep these components separate even if the merchant receives one consolidated statement. Otherwise finance cannot reconcile network invoices, merchant billing and processor charges independently.
Consider a simplified $100 purchase. The issuer and acquirer may settle the transaction according to the network clearing result. An interchange amount may be due from acquirer to issuer. Network fees may be separately assessed. The merchant’s contract may say that the merchant receives the sale amount less a blended discount and any other adjustments. The acquirer’s merchant-funding engine therefore needs both network economics and merchant-contract economics; they are related but not identical.
This becomes more complex when an acquirer uses interchange-plus pricing. The merchant statement may expose interchange, assessment/network charges and acquirer markup separately. Under blended pricing, those components may be hidden behind one contractual rate. Tiered pricing introduces yet another commercial mapping. Chapter 29 does not prescribe a pricing model; it teaches the accounting separation required to support any model safely.
Fee timing matters as well. Some amounts are calculated per transaction, some per batch or period, and some appear on separate network invoices. Merchant funding can occur before all periodic fees are known. The acquirer therefore needs accrual logic and later true-up controls.
A useful reconciliation equation is:
merchant gross sales − refunds − chargebacks/adjustments − merchant fees ± reserves/other contractual items = merchant net funding.
A different equation is needed for network settlement. Conflating these two equations is a common source of unexplained breaks.
7. Visa clearing and settlement model
Visa’s public rules define settlement as the reporting and funds transfer of settlement amounts owed by one member to another, or to Visa, as a result of clearing. The rules define a settlement amount as the daily net amount in a member’s settlement currency resulting from clearing, including transaction and fee-collection totals. That definition is extremely useful because it separates individual customer purchases from the participant’s daily net settlement position.
When an acquiring participant submits a clearing record, the transaction becomes part of Visa’s clearing process. Visa rules require members to be ready to settle within the applicable settlement timeframe. Visa’s processing environment creates settlement obligations from the cleared activity rather than transferring $100 from issuer to acquirer independently for every $100 sale.
For a bank, the practical architecture therefore has at least three Visa-facing data sets: clearing detail, settlement position and network fee/financial reporting. The bank must be able to reconcile them. A clearing file can contain thousands or millions of transaction records, while the settlement instruction may represent a net amount.
The issuer side should reconcile Visa clearing to cardholder posting and to its Visa settlement obligation. The acquirer side should reconcile merchant clearing submissions to Visa acceptance and then to settlement receivable/payable positions. Treasury must know the settlement currency, expected value date and funding mechanism. Finance must post network receivables/payables and fees to the correct GL accounts.
Visa also distinguishes settlement banks and settlement currencies in its public rules. That matters when the network member uses another bank for settlement or processes multiple currencies. The operational team should not assume that the entity processing transactions is necessarily the same entity at which settlement cash moves.
The key learning point is not a specific proprietary file name. It is the financial architecture: clearing creates the member-level obligation; settlement moves the resulting net funds; internal systems then allocate that financial truth to cardholder and merchant books.
8. Mastercard clearing and net settlement model
Mastercard’s public rules explicitly state that a customer using the Interchange System for authorization and clearing is required to net settle in accordance with Mastercard settlement standards, subject to defined bilateral arrangements. Mastercard also defines interchange fee as an amount paid by the acquirer to the issuer with respect to the interchange of a transaction.
This gives learners a clear conceptual model. The acquiring side submits the transaction into Mastercard clearing. Mastercard processing applies the relevant rules and interchange qualification. Cleared transactions contribute to the issuer/acquirer financial positions. Net settlement then resolves the participant’s aggregated obligations under Mastercard settlement standards.
For reconciliation, Mastercard operations should maintain a chain from acquiring presentment → network clearing result → interchange/fee detail → net settlement report → settlement cash movement. The issuer needs the mirror view from incoming clearing → cardholder posting → interchange revenue/expense → settlement position.
Mastercard also notes that the acquirer must submit a transaction in the currency in which it occurred, while the network can convert transactions into the applicable settlement currency under its rules. Cross-currency settlement therefore introduces FX and currency-position considerations that are separate from the cardholder’s transaction currency and the merchant’s funding currency.
Interchange qualification deserves operational ownership. If a transaction is submitted with missing or late data, the resulting rate may differ. The acquiring bank should record enough rule/result detail to analyze cost movement instead of treating interchange as a black-box network amount.
A production control should also compare expected and actual net settlement. Expected positions can be derived from accepted clearing activity and network fee information. Differences should be explained by timing, adjustments, late records, currency conversion, network fees or other recognized items. An unexplained settlement delta should create a financial-control incident, not be carried indefinitely in suspense.
9. American Express, Discover and alternative network operating models
Not every card ecosystem looks identical to the Visa/Mastercard four-party model. American Express historically combines network, issuing and merchant-acquiring capabilities in parts of its business while also supporting partner issuing and acquiring relationships. Discover operates Discover Network and PULSE and works with issuers, acquirers, processors and merchants. The financial lifecycle remains clearing-and-settlement driven, but the contractual path and party relationships can differ.
American Express merchant support material provides a useful merchant-side financial view. It describes submissions as transaction amounts submitted by the merchant, and settlements as amounts paid to the merchant after deducting discount, fees and other adjustments such as chargebacks. That is a concrete demonstration of the difference between transaction submission and merchant funding.
A merchant can therefore have $50,000 of submitted transactions but receive a lower settlement/funding amount because discount, fees, refunds or adjustments are applied. The merchant’s reconciliation process should be able to trace from submission batch to settlement to bank-account credit.
Discover similarly operates through acquirers and processors and publishes participant/compliance material. Discover documentation for network products refers to settlement timing governed by applicable operating regulations and to sales-data and acquirer-reporting interfaces. The durable lesson is that network-specific reporting and settlement artifacts must be respected; a common card hub should normalize them into a bank canonical model without pretending the underlying network processes are identical.
A multi-network acquirer should therefore maintain a common internal vocabulary—captured, submitted, cleared, settled, merchant-funded—while storing each network’s native identifiers, cycle dates, fee categories and exception codes. This allows one operations dashboard without losing network-specific evidence.
10. US debit interchange and Regulation II
U.S. debit adds an important regulatory layer. Regulation II implements statutory requirements around debit-card interchange fees and routing. For covered issuers, the current Federal Reserve standard generally limits the debit interchange fee to $0.21 plus 0.05% of the transaction value, with an additional $0.01 fraud-prevention adjustment for eligible issuers. Certain small issuers, qualifying government-program cards and certain reloadable general-use prepaid cards are exempt from the fee limitation under the rule.
The small-issuer exemption is based on consolidated assets below $10 billion under the regulatory framework. The Federal Reserve publishes annual exempt and non-exempt lists based on available year-end institution data. A card economics engine therefore cannot simply apply “regulated debit” based on card brand; it needs current issuer-regulatory classification and product eligibility data.
Regulation II also addresses network exclusivity and merchant routing choice. Debit cards must generally be enabled on at least two unaffiliated networks, and issuers/networks may not inhibit a merchant’s ability to route over an enabled network. Chapter 27 introduced that ecosystem requirement. Chapter 29 adds the financial consequence: routing choice can change interchange economics, network fees, settlement reports and reconciliation sources.
A debit transaction routed over one network can therefore have a different fee and settlement path from a similar transaction routed over another enabled network. Acquiring systems should preserve the actual routed network rather than only the card brand printed on the card.
For testing, covered-issuer status, exempt issuer, prepaid exemption, government-program exemption and routing scenarios should be explicit. Hard-coding the statutory cap into application logic without effective dating is poor design because regulatory values can change. The safer pattern is effective-dated reference data with legal/compliance ownership.
11. Issuer settlement, posting and cardholder financial truth
The issuer receives clearing records representing financial transactions. Those records must be matched to the correct cardholder account and posted according to the product’s accounting model. For credit cards, posting affects the cardholder balance and statement. For debit cards, it affects the linked deposit-account position. Chapter 30 will explore those product differences; Chapter 29 focuses on the common reconciliation logic.
A pending authorization hold should be correlated to the clearing transaction. When the final transaction posts, the issuer should release or consume the correct hold. If the clearing amount differs legitimately, the issuer should follow the product and network rules rather than mechanically rejecting the record. If no clearing arrives, the authorization hold should expire or be reversed according to configured rules.
The issuer must also post interchange and network-related accounting separately from cardholder principal. A $100 purchase posted to the customer is not economically identical to the issuer’s net network settlement position. Interchange income, network fees, FX and other items can sit in different GL accounts.
Settlement timing and posting timing can differ. The issuer can receive transaction detail before or after certain settlement events depending on the processing model. The bank should therefore maintain explicit states such as CLEARING_RECEIVED, POSTED_TO_CARDHOLDER, IN_SETTLEMENT_POSITION, SETTLED, rather than one generic posted flag.
Issuer reconciliation typically includes network clearing totals to account postings, account postings to GL, clearing to settlement reports, and settlement reports to actual cash movement. Breaks should identify which layer failed. If the network settled correctly but customer posting failed, treasury should not attempt to “fix settlement.” The repair belongs in the issuer posting layer.
12. Acquirer settlement and merchant funding
The acquiring side receives its network settlement position after clearing. That position represents the member-level financial outcome, not the final merchant payment. The acquirer must allocate the network financial result back to merchants and determine each merchant’s contractual funding amount.
Merchant funding begins with merchant gross financial activity: purchases, credits/refunds and other financial items. The acquiring platform applies merchant pricing and adjustments. Depending on the agreement, it may deduct discount, transaction fees, chargebacks, reserves or other amounts. The net amount is then sent to the merchant’s nominated bank account or otherwise credited under the merchant arrangement.
Funding timing is a product promise. Some merchants receive next-day funding; some receive same-day or accelerated funding products; others have longer contractual schedules. Weekends, bank holidays, risk reserves, negative balances and processor cutoffs can affect availability. The acquiring bank should distinguish network settlement date from merchant funding date.
A merchant funding batch should have a unique ID and clear composition. Operations should be able to show total sales, refunds, fees, chargebacks, reserves, adjustments and final net amount. The bank-account payment should reconcile to that batch. If a payment fails because the merchant bank account is closed, the merchant should remain financially owed even though network settlement already completed.
Negative merchant positions require controlled handling. If refunds and chargebacks exceed new sales, the merchant funding amount can become negative. The merchant agreement may allow debit collection, reserve use or offset against future settlements. Those actions must be represented as separate financial events with an audit trail.
Merchant funding is therefore a mini payment system inside acquiring. It needs beneficiary validation, payment generation, rejection handling, reconciliation and customer communication just like other bank disbursement processes.
13. Refunds, reversals, adjustments and dispute-boundary events
A reversal and a refund are not the same event. Authorization reversal belongs primarily to Chapter 28 because it releases or corrects an authorization before final financial presentment. A refund is a new financial credit from merchant to cardholder after a purchase has been financially processed or captured under the applicable model.
Refunds enter clearing and settlement as financial events. They affect issuer/cardholder posting, acquirer settlement and merchant funding. The merchant’s funding ledger must link refunds to the merchant and ideally to the original purchase. The issuer should post the credit to the cardholder and reconcile it to network clearing.
Clearing adjustments can arise from processing corrections, fee corrections or other network-defined events. Operations should not treat every adjustment as a dispute. The correct classification matters because the evidence, SLA, financial account and owning team differ.
Chargebacks and disputes are covered deeply in Chapter 34. Chapter 29 only establishes the financial boundary: a chargeback or related adjustment can create a new debit/credit in network settlement and merchant funding. The original purchase remains part of history; the dispute lifecycle adds linked financial events rather than erasing the original transaction.
The same principle applies to representment and later dispute stages. Each event should have its own financial amount, date, reason and settlement impact while maintaining a relationship to the original transaction.
A good canonical model therefore stores original_transaction_id, financial_event_id, event_type, network_reference, amount, currency, clearing_cycle, settlement_date, merchant_ledger_effect and cardholder_ledger_effect. That model makes disputes and refunds reconcilable without rewriting history.
14. Reconciliation, accounting and reporting
Card reconciliation is not one comparison. It is a chain of controls across several financial truths.
On the acquiring side, a mature control framework reconciles:
merchant capture → processor accepted detail → network clearing → network settlement → acquirer GL → merchant ledger → merchant funding payment.
On the issuer side, it reconciles:
network clearing → cardholder posting → authorization-hold release → issuer GL → network settlement → settlement cash movement.
Each boundary should reconcile both count and amount where meaningful. Currency must be explicit. Differences should be categorized, aged and owned. A one-cent unexplained financial difference is still a control break; materiality affects escalation, not whether the books should reconcile.
Settlement accounting requires separate accounts for principal, interchange, network fees, receivables/payables, suspense and merchant liabilities. Exact chart-of-account design varies by bank, but combining all card cash movement into one clearing account makes root-cause analysis extremely difficult.
Reporting serves different audiences. Merchants need sales, refunds, adjustments, fees and funding details. Issuer finance needs cardholder postings, interchange economics and network settlement. Treasury needs expected settlement cash and currency positions. Operations needs rejected clearing records, unreconciled items and delayed merchant funding. Product teams need volume, approval-to-clearing conversion, cost and revenue metrics.
A critical control metric is authorization-to-clearing conversion. Not every authorization should clear, but unexpected changes in the ratio can indicate dropped capture files, merchant outages, duplicate reversals or data problems. Another useful metric is clearing-to-funding latency by merchant segment and funding product.
15. Exceptions, operational controls and real-bank failure scenarios
Post-authorization card processing is full of failure modes that do not exist at checkout. A merchant can capture but the gateway can fail to deliver the batch. The acquiring processor can accept a file but reject individual records. A network can clear a transaction but the issuer can fail to post it. Settlement cash can move correctly while the acquirer’s merchant-allocation process fails. Merchant funding can be calculated correctly but the ACH or bank-transfer payout can reject.
A real operations model should therefore maintain separate queues for at least: clearing rejects, unmatched authorization/presentment, duplicate suspicion, issuer posting failure, settlement mismatch, fee mismatch, merchant allocation failure and funding-payment failure.
Case 1 — authorization approved, no clearing. The issuer sees a hold but no financial presentment. The correct action is not to post a purchase manually merely because authorization exists. The hold follows expiry/reversal rules unless valid clearing arrives.
Case 2 — clearing received, authorization not found. The issuer investigates whether the transaction is a valid no-authorization transaction type, a late presentment, an identifier mismatch or a true exception. It should not automatically reject financial data merely because the internal authorization search failed.
Case 3 — acquirer network settlement correct, merchant funding wrong. Network operations should not alter the network settlement. The break belongs in merchant pricing/allocation/funding.
Case 4 — merchant funding payment rejected. The merchant ledger should remain payable. Operations corrects bank details or payout routing and issues a new funding event with links to the original funding batch.
Case 5 — clearing duplicate. The bank must establish whether the duplicate is technical or commercial before reversing customer/merchant positions. Duplicate detection should use network and business identifiers, not amount/date alone.
Controls should include batch completeness, effective-dated rate tables, maker-checker for manual financial adjustments, reconciliation aging, suspense limits, settlement funding forecasts, network file acknowledgements, merchant funding totals and immutable audit evidence.
16. Architecture, testing, role checklist and authoritative references
A bank-grade Chapter 29 architecture normally contains a capture intake, clearing adapter, network-specific transformation layer, lifecycle correlation service, interchange/fee engine or network-fee ingestion, settlement-position engine, issuer/acquirer posting services, merchant ledger, merchant funding engine, reconciliation service, GL integration, reporting store and operational case management.
The canonical transaction model should preserve rather than overwrite lifecycle amounts. Recommended fields include authorized_amount, captured_amount, cleared_amount, settlement_amount, cardholder_posted_amount, merchant_gross_amount, merchant_fee_amount, merchant_net_funding_amount, plus currencies and effective dates for each. Storing only one amount field is insufficient for serious card processing.
A Business Analyst should define state ownership, amount semantics, fee/settlement boundaries, exception handling and reconciliation evidence. An Architect should separate network-specific adapters from the canonical financial model and prevent settlement truth from being hidden inside processor black boxes. A Developer should implement idempotent file/record processing, precise decimal/currency handling and replay-safe financial posting. A Tester should validate amount changes, late presentment, duplicates, network rejects, settlement deltas, fee qualification, negative merchant batches, payout rejection and recovery. Operations should own clearing and funding queues. Finance should own accounting rules and reconciliation sign-off. Treasury should own settlement liquidity and cash readiness. Merchant servicing should be able to explain settlement and funding using the same evidence as finance.
Practical test scenarios must include: approved purchase captured normally; authorization amount different from final clearing amount; capture never submitted; duplicate capture; late presentment; invalid clearing data; regulated debit; exempt debit; different debit routing network; interchange qualification change caused by missing data; cross-currency clearing; settlement report missing; issuer posting failure; acquirer merchant-allocation failure; negative merchant funding; merchant payout reject; refund after settlement; chargeback financial event; weekend funding timing; processor failover and file replay.
The final learning principle is:
A card payment is financially complete only when the bank can reconcile the commercial transaction, network clearing, settlement cash, account posting and merchant funding as one connected evidence chain.
Authoritative references
This application uses JavaScript for the full interactive experience. This text summary is served for accessibility and search indexing.