The Payments
Lifecycle

From swipe to settlement — the full authorization, clearing, and settlement sequence, and the four-party model every acquirer controller must own cold.

Every card transaction moves through a defined sequence of phases, each with distinct timing, counterparties, and accounting triggers. As an acquirer controller, your P&L, your settlement liability, and your reconciliation exposure are all governed by where a transaction sits in this lifecycle at month-end. Misunderstanding phase boundaries is the single most common source of controller-level reconciliation errors in payments finance.

The Four-Party Model

The dominant structure in card-based payments is the four-party (open-loop) model, in which the card network sits between the issuing and acquiring sides of the transaction without directly holding funds. This is the Visa and Mastercard architecture. The three-party model (Amex, Discover pre-network deals) collapses the issuer and acquirer roles, producing different economics entirely.

Phase 1: Authorization (T+0)

Authorization is a real-time approval request routed from the merchant's terminal or gateway, through the acquirer, across the card network, to the issuer's authorization system. The issuer verifies funds/credit availability, fraud rules, and account status, returning an approval or decline code — typically within 1–3 seconds.

• 1
  Cardholder Initiates — Swipe, tap (NFC/contactless), dip (EMV chip), or card-not-present (CNP/e-commerce).
• 2
  Terminal/Gateway Formats — ISO 8583 message constructed with PAN, amount, merchant category code (MCC), acquirer BIN, and transaction type.
• 3
  Acquirer Routes to Network — The acquirer receives the auth request and routes to Visa/MC VisaNet or Banknet via host-to-host connection.
• 4
  Network Routes to Issuer — Visa/MC identifies the card BIN and routes to the correct issuer authorization host.
• 5
  Issuer Decision — Approve (with auth code), decline, or referral. Response traverses the same path in reverse.

Phase 2: Clearing (T+1)

Clearing is the process by which the merchant submits its final batch of transaction data to the network for financial settlement. In card-present environments, clearing may occur same-day or next-day as part of end-of-day batch capture. In CNP/e-commerce, clearing typically occurs at shipment or service delivery. Clearing is the event that triggers interchange qualification.

The clearing message includes the final transaction amount (which may differ from the authorized amount — notably in lodging, restaurant, and car rental environments where tips and final charges are added post-auth), merchant category code, and acquirer processing information. The network uses this data to calculate interchange and net settle between issuers and acquirers.

Phase 3: Settlement (T+1 / T+2)

Settlement is the actual movement of funds between the issuer and acquirer, netted by the card network. Visa and Mastercard operate settlement through Visa Settlement Service (VSS) and Single Message System/Dual Message System respectively. Net settlement positions are calculated across all transactions cleared on a given business day, with the network acting as a central counterparty.

Timing Summary

Controller Checklist — Payments Lifecycle

Journal Entries — Payments Lifecycle

Alternative Rails — Real-Time Payments (FedNow / RTP)

Not all payments run on card rails. The FedNow Service (launched July 2023) and The Clearing House RTP network operate instant payment rails that settle in seconds — not days. For controllers at acquirers or merchants accepting bank-to-bank payments, these rails have fundamentally different timing, cost, and accounting profiles than Visa/MC.

Account Flows &
Money Movement

The fee waterfall from gross transaction value to merchant net — and how every basis point flows through the acquirer P&L.

Money movement mechanics sit underneath every revenue recognition call, reconciliation procedure, and margin analysis a payments controller runs. The economics of a single transaction involve four distinct fee layers, multiple counterparties, and netting arrangements that can obscure gross-to-net relationships if not carefully mapped. This section traces funds from the cardholder's bank to the merchant's DDA and maps every deduction.

The Fee Waterfall

Acquirer Economics Decomposed

The acquirer's net revenue — sometimes called the "acquirer take rate" — is the MDR charged to the merchant minus interchange passed to the issuer and scheme fees paid to the network. This spread is the core economic unit of merchant acquiring. A healthy acquirer maintains gross margins after pass-throughs in the 15–40 bps range for large retail merchants and 60–120 bps for SMB and specialty merchant segments.

Funding Chain: From Issuer Bank to Merchant DDA

The mechanics of the actual cash movement are important for GL mapping. The card network acts as the settlement agent, maintaining net positions across all members. Each business day, the network calculates multilateral net settlement positions across all acquirers and issuers on the system. The net settlement amount is then moved via the settlement bank (typically a Fed member institution) to each participant's settlement account.

• 1
  Network Settlement Credit — The acquirer's settlement account (held at a Fed bank or directly with Visa/MC settlement) receives net credits for all transactions cleared by merchants in the acquirer's portfolio.
• 2
  Internal Funding Journal — The acquirer's internal processing system posts entries: Debit Settlement Receivable / Credit Merchant Payable (net of MDR, fees, reserves).
• 3
  Reserve Holdback — If the merchant is subject to rolling reserve, a portion of the funded amount is transferred to a reserve account rather than released to the merchant DDA.
• 4
  Merchant DDA Funding — Remaining net amount is credited to the merchant's DDA account, either at the acquirer's bank or via ACH to an external bank.

Full Journal Entry Lifecycle — $100M Monthly Portfolio

The following walkthrough traces a single month's $100M portfolio through every accounting event from authorization to funded merchant DDA. This is the journal entry sequence a controller must own cold. All figures use the consistent portfolio model used throughout this guide: $100M GTV, 1.75% blended MDR, 1.65% blended interchange, 0.14% scheme fees, 0.51% acquirer net margin.

GL Mapping Framework

Controller Checklist — Account Flows & Money Movement

Revenue Recognition
(Controller View)

ASC 606 applied to merchant acquiring: gross vs. net, principal vs. agent, performance obligations, and the transaction-level judgments that matter at month-end.

ASC 606 reorganized how acquirer controllers think about revenue. The five-step model is familiar, but its application to payments — where the acquirer is simultaneously a processor, a lender (via float), a risk-taker, and a distributor of scheme economics — creates layered judgment calls that the standard itself leaves only partially resolved. The following covers each step as it applies to acquiring.

The ASC 606 Five-Step Model Applied to Acquiring

The Core Judgment: Gross vs. Net (Principal vs. Agent)

This is the highest-stakes revenue recognition question in acquiring. The principal vs. agent determination drives whether revenue is reported as gross MDR billed to the merchant or net of interchange and scheme fees. The difference is material — on a typical IC++ acquirer earning 22bps net on 175bps gross MDR, a gross presentation reports roughly 8x more revenue than a net presentation with identical economics. This is a critical disclosure issue for public acquirers and the most consequential accounting judgment call in the business.

Acquiring Revenue: The Gross vs. Net Analysis

The industry practice is not uniform. The key question is whether the acquirer controls the "payment processing service" that is being delivered to the merchant, or whether the acquirer is merely an agent connecting the merchant to the card network and issuer. Most large acquirers with direct network membership, proprietary processing infrastructure, and assumption of credit risk will support a gross revenue presentation.

Performance Obligations and Contract Modifications

One of the more operationally challenging areas in acquirer revenue recognition is identifying whether a merchant contract re-pricing, volume tier reset, or product bundle change constitutes a contract modification under ASC 606-10-25-10. A modification that adds distinct services at a standalone selling price is accounted for as a separate contract. A modification that changes the scope or price for existing services requires judgment on whether to account for it prospectively or via a cumulative catch-up.

Contract Costs (ASC 340-40)

Incremental costs of obtaining a merchant contract — primarily sales commissions, signing bonuses, and onboarding costs that are incremental and would not have been incurred absent the contract — must be capitalized as contract assets and amortized over the expected contract period (including renewals if reasonably certain) when they are expected to be recovered. This creates a significant asset on acquirer balance sheets and a corresponding amortization expense that must be separated from ongoing operating costs for margin analysis.

Journal Entries — Revenue Recognition Applied

Controller Checklist — Revenue Recognition

Surcharge Accounting

Surcharging — charging cardholders an additional fee (typically 1–3%) to offset MDR cost — creates a specific revenue recognition question. The treatment depends on who sets the surcharge and who collects it.

Refund & Reversal Accounting

Refunds and reversals are not the same thing. A reversal cancels a transaction before settlement. A refund returns funds to a cardholder after settlement. Each has a different accounting treatment.

Interchange &
Scheme Economics

Visa and Mastercard interchange categories, assessment fees, network fees, basis points arithmetic, and how every fee tier flows through the acquirer P&L.

Interchange is the largest single cost driver in card payments, representing 70–85% of total payment processing costs on a gross basis. A controller who cannot read an interchange table, explain qualification criteria, and reconcile interchange billed by the network to the underlying transaction detail is operating blind in the most material line item on the P&L. This section demystifies interchange categories and establishes the analytical framework for scheme economics.

What Is Interchange?

Interchange is a fee paid by the acquirer to the issuer for each card transaction. It compensates the issuer for credit risk, funding cost, fraud losses, and reward program costs. Interchange rates are set by the card networks (Visa, Mastercard) and published in their interchange rate tables — but individual issuers receive the interchange income, not the network itself. The network charges separate scheme/assessment fees for network access and processing services.

Interchange Rate Determinants

Visa Interchange Categories — Key Tiers

Scheme/Assessment Fees — Visa

Separate from interchange, Visa charges assessment fees to acquirers for network access, processing, and authorization services. These fees are typically billed monthly on a complex schedule and are a frequent source of reconciliation complexity.

Basis Points Arithmetic

All interchange and scheme fee economics are expressed in basis points (bps) for comparability. One basis point = 0.01% = $0.10 per $1,000 of transaction volume. When analyzing acquirer margins, the controller must convert per-item fees to an effective basis-point equivalent based on average ticket size.

Mastercard Interchange Categories — Key Tiers

Mastercard's interchange structure parallels Visa's but uses different tier names and rate levels. Controllers managing mixed Visa/MC portfolios must maintain separate rate models — blending them produces inaccurate cost forecasts.

MDR Pricing Models — How Acquirers Structure Merchant Pricing

Acquirers charge merchants under one of three primary MDR structures. Understanding the pricing model is prerequisite to revenue recognition, margin analysis, and interchange cost allocation. Each model has distinct controller implications.

Bundled MDR — From Statement to Sub-Ledger

The MDR shown on a merchant statement is a single number. The accounting it produces is not. A 2.30% blended rate looks atomic to the merchant — one percentage applied to gross volume — but on the acquirer's books it splits into three economically distinct components, governed by three different parts of ASC 606, posted across multiple GL accounts, and reconciled across at least three independent data sources. This section walks the dollar from the merchant statement through to the variance accounts that surface margin compression — the architecture every controller needs to understand before they can defend the revenue line.

1. The Anatomy of a Bundled MDR

Every bundled MDR contains three components: interchange paid to the issuing bank, network assessments paid to Visa and Mastercard (or the equivalent on closed-loop networks), and the acquirer's residual spread. The proportions vary by card type and merchant category, but the structure is constant. For a representative $100 retail credit transaction at 2.30% blended pricing, the decomposition looks like this:

Two of the three components — interchange and assessments — are agent positions under ASC 606-10-55-37. The acquirer has no pricing discretion (network IRDs and assessments are set unilaterally by the schemes), no inventory or credit risk on those amounts (they pass straight through to the issuer or network), and no control over the underlying service (the issuer extends credit; the network operates the rails). Only the residual spread satisfies the principal indicators: the acquirer controls the processing service, bears the credit risk on the merchant relationship, and exercises pricing discretion. This is the foundational judgment that drives every downstream accounting decision in the rest of this section.

2. Three Defensible P&L Presentations

The principal/agent conclusion above produces a clean economic answer — $0.52 of acquirer net revenue per $100 transaction — but three different P&L presentations exist for displaying that answer, and the choice has material implications for reported gross revenue, gross margin, and disclosure treatment.

The Cost-of-Revenue presentation, which this handbook treats as primary for principal acquirers, presents gross MDR as the top revenue line and interchange and assessments as separate cost-of-revenue lines above the gross profit line. This treats interchange the way it economically behaves: as a true period cost incurred to deliver the processing service, not as a deduction from revenue. It is the dominant approach for bank acquirers and large full-stack processors who can document strong principal indicators.

Pure net presentation reports only the $0.52 spread as revenue, with interchange and assessments routed entirely through balance sheet payables and never touching the income statement. This is increasingly common post-606 for processors with weaker principal arguments, and is the default for ISO and aggregator models where the acquirer's role is closer to facilitation than principal delivery.

Contra-revenue presentation, while historically common, has fallen out of favor under 606. It presents gross MDR as revenue and interchange/assessments as contra-revenue accounts that net down to the same $0.52 — implying that interchange somehow reduces revenue rather than treating it as a cost of generating revenue. The contra-revenue view persists in management reporting and internal sub-ledgers (where seeing gross-to-net dynamics is useful for FP&A and pricing analytics) but has largely disappeared from external financial statements.

3. IC+ vs Tiered — Mix Risk Mechanics

The four pricing structures introduced in MDR Pricing Models above deliver the same ASC 606 conclusion — principal/agent decomposition produces a net spread that is the acquirer's true revenue. But they distribute economic risk very differently across the merchant relationship, and the difference shows up not in revenue recognition but in margin volatility.

Under interchange-plus, the merchant absorbs interchange volatility; the acquirer earns its fixed plus regardless of card mix. Under tiered, the acquirer absorbs that volatility: the spread expands when low-cost cards run at high tier rates (the "downgrade benefit") and compresses when high-cost cards run at low tier rates. The chart below shows how dramatically this can swing for the same merchant under the same headline rates, depending on which card types actually transact.

The arithmetic is mechanical but the consequences are not. A regulated debit card on a tiered qualified rate produces 152 bps of acquirer spread — nearly five times the IC+ benchmark of 35 bps — because the merchant pays the qualified tier rate (1.79%) while the underlying interchange is just 27 bps. That 152 bps is real revenue, fully booked, fully recognized, but exists only because tiered pricing decoupled the merchant's billed rate from the underlying interchange cost. A standard credit card on the same qualified tier produces only 18 bps of spread because the underlying interchange is 161 bps — nearly the entire qualified tier rate is consumed by interchange, leaving the acquirer with only the difference between 1.79% and 1.61% to work with.

This is why tiered pricing portfolios show wider margin distributions than IC+ portfolios at the same average MDR, and why FP&A teams at tiered acquirers track card mix as obsessively as they track volume. A 100-bps shift in card mix from regulated debit to rewards credit can compress margins by 30+ bps even as revenue (gross MDR) stays constant — a margin compression that has no analog in IC+ pricing.

4. Bundled Monthly Recognition — When Pricing Becomes Subscription

Subscription pricing models — common in modern merchant services platforms (Helcim, Stax, Payment Depot) and growing in mid-market acquiring — introduce a recognition wrinkle that per-transaction models do not. The merchant pays a flat monthly fee covering all processing at interchange cost, plus a pass-through of the interchange itself. The bundled monthly fee is not earned at any single transaction event; it is earned over the service period.

Under ASC 606-10-25-27(a), this is a stand-ready performance obligation: the acquirer is contractually obligated to be ready to process transactions throughout the month, regardless of whether the merchant actually generates volume. Revenue is recognized ratably across the service period — typically straight-line daily — while interchange and assessments continue to accrue per-transaction as actual volume runs. The two recognition patterns interact across the cycle as follows:

Three accounting consequences flow from this structure. First, the recognition pattern is over-time rather than point-in-time, requiring a daily ratable accrual against the eventual cash receipt. Second, the spread becomes variable consideration under ASC 606-10-32-11: the acquirer bears the interchange volatility risk that the merchant would bear under IC+, and the residual spread is therefore an estimate that must be constrained to the amount not at risk of significant reversal. Third, a month-end true-up is required to reconcile the estimated bundled spread to the actual interchange and assessments paid off the network settlement file. The true-up posts to revenue (favorable variance) or to a contra-revenue reserve (unfavorable variance), and is a recurring control point in the close calendar.

For practical purposes, most subscription acquirers maintain a daily revenue accrual based on the bundled fee divided by days in the period, with the variance posting on the last business day of the month. The constraint analysis is documented at the contract level (most subscription contracts have IC volatility clauses that protect the acquirer from extreme mix shifts, narrowing the constraint) and refreshed quarterly.

5. The Sub-Ledger Reconciliation Engine

The decompositions, presentations, and recognition patterns above only work if a daily reconciliation engine sits between the acquirer's three primary data sources — the network settlement files, the merchant billing system, and the treasury cash position — and produces a single source of truth that posts to the GL. This engine is the sub-ledger, and its variance accounts are the diagnostic surface where margin compression, downgrade leakage, and tier mis-assignments become visible before they reach the financial statements.

The architecture is mechanically simple: three input streams flow into a daily sub-ledger that computes the per-merchant decomposition, posts the four core balances to the GL (net discount revenue, interchange payable, assessment payable, settlement payable), and routes any variances to three dedicated variance accounts. Interchange variance captures the difference between what the merchant was billed (under IC+ pass-through) and what was actually paid to the issuer — the downgrade leakage that consumes margin under data-quality failures. Scheme variance captures the timing differences between estimated daily assessments and actual monthly billing receipts from Visa and Mastercard. Tier reclass reserve, used only under tiered pricing, captures post-period qualification adjustments that re-tier transactions after the original recognition.

The control story is the three-way tie-out: every business day, the sub-ledger must reconcile to the network settlement files (interchange and assessment side), to the merchant billing engine (gross MDR side), and to the treasury cash position (settlement side). Any of the three breaks open is a SOX-relevant exception that must be aged, escalated, and resolved before the books close. Most acquirers automate the first two and maintain a manual review on the third.

The sub-ledger is also where the principal/agent decision lives operationally. Under net presentation, the sub-ledger never posts interchange to revenue accounts — it posts directly from the cash receipt to the issuer payable, with only the spread routing through revenue. Under COGS-style presentation, the sub-ledger posts gross MDR to revenue and interchange to a separate cost-of-revenue line. Whichever view is documented in the ASC 606 memo dictates the sub-ledger configuration; changing the configuration without updating the memo is a material weakness waiting to happen.

PCI DSS — Controller Cost Awareness

Payment Card Industry Data Security Standard (PCI DSS) compliance is a non-negotiable requirement for all entities that store, process, or transmit cardholder data. For the acquiring controller, PCI DSS creates two direct financial exposures: (1) compliance costs — QSA assessments, penetration testing, infrastructure upgrades, and tokenization investments, which are recurring operating expenses; and (2) non-compliance fines — Visa and Mastercard can levy monthly fines on acquirers for merchants in their portfolio who are non-compliant or who suffer a breach. These fines ($5,000–$100,000/month per scheme) flow directly through the acquirer P&L and must be tracked in the scheme fee reconciliation. Non-compliance liability clauses in the MPA determine whether the fine can be passed to the merchant.

Journal Entries — Interchange Cost Accounting

Controller Checklist — Interchange & Scheme Fees

3-Party vs 4-Party Networks — The Accounting Difference

Visa and Mastercard operate 4-party networks — issuer and acquirer are separate entities, interchange flows between them. American Express and Discover operate 3-party (closed-loop) networks — Amex is simultaneously the network, the issuer, AND often the acquirer. This structural difference creates fundamentally different accounting for the acquirer.

Reserves
& Risk

Rolling, capped, and upfront reserve structures; calculation methodology; and the ASC 450 framework for controller booking, release, and contingent liability governance.

Reserves are the primary financial control mechanism acquirers use to protect against merchant credit exposure. When a merchant fails — through insolvency, fraud, or operational disruption — and there are outstanding chargebacks or refund obligations, the acquirer is the liable party under network rules. The reserve is the buffer between that exposure and the acquirer's P&L. For the controller, reserves touch three distinct accounting domains: the liability assessment (ASC 450), the funding mechanics (settlement), and the disclosure framework (ASC 275).

Reserve Types

Reserve Calculation Methodology

The "exposure window" is the critical variable. It represents the maximum period during which chargebacks or returns could be presented after a merchant ceases processing. For most card types, this is 120 days from transaction date (Visa) or from statement date (Mastercard). For high-risk sectors (travel, subscription, software), the window may extend to 540 days for dispute-based chargebacks. The reserve target should be sized against the maximum chargeback liability window, not just the current rolling period.

ASC 450: Contingency Accounting for Reserves

ASC 450-20 governs the accounting for loss contingencies. For acquirer reserves, the relevant question is: does the acquirer have a probable and estimable loss exposure from a specific merchant's chargeback or insolvency risk?

For a healthy, operating merchant with no abnormal chargeback history, the standard reserve hold (rolling or capped) is typically not a loss contingency — it is a refundable customer deposit held as a liability (Merchant Reserve Liability). The reserve is released to the merchant per the agreement terms, and no loss accrual is required absent evidence of impairment.

However, when a specific merchant exhibits loss indicators — elevated chargebacks, fraud alerts, bankruptcy filing, cessation of processing — the controller must evaluate whether an incremental loss accrual is required above and beyond the existing reserve balance. The accrual represents the estimated net loss exposure: gross chargeback exposure minus recoverable reserve balance minus estimated recovery.

Proactive Reserve Methodology for Systemic Events

A more complex scenario arises when a network rule change, regulatory event, or industry-wide disruption creates expected losses across a portfolio of merchants — not a single identified counterparty. In this case, a proactive reserve methodology may be appropriate under ASC 450's collective-basis provisions.

Controller Booking & Release Framework

Journal Entries — Reserve Lifecycle

Controller Checklist — Reserves

Reserve Types — Decision Framework

Dynamic Reserve Triggers — What Forces Action

FX &
Cross-Border

Cross-border transaction mechanics, FX exposure types, DCC economics, hedging vs. pass-through decisions, and the controller's framework under ASC 815 and ASC 830.

Cross-border transactions — those where the card is issued in a different country than the merchant location — introduce FX exposure on multiple dimensions: the settlement currency, the currency of the merchant's DDA, and the currencies in which the acquirer operates. For a globally active acquirer with multi-currency merchant portfolios, FX exposure in payments is material and requires a deliberate accounting and risk management framework.

Cross-Border Transaction Mechanics

When a UK cardholder uses a Visa card at a US merchant, the transaction is denominated in USD but originates from a GBP-issued card. The issuer settles in USD (the transaction currency) with the network. The acquirer receives USD settlement. If the merchant's DDA is USD-denominated, there is no FX transaction at the acquirer. The FX conversion happens on the issuer side (GBP cardholder pays USD to their bank, which absorbs the FX risk and charges an ISA/foreign transaction fee).

The picture changes materially when the acquirer operates across currencies — processing merchants in EUR, GBP, JPY — or offers Dynamic Currency Conversion (DCC).

ASC 830 — Foreign Currency Translation

ASC 830 (Foreign Currency Matters) governs two distinct situations: remeasurement (when a transaction is denominated in a currency other than the entity's functional currency) and translation (when a foreign subsidiary's financial statements are converted to the parent's reporting currency).

ASC 815 — Hedging Framework

Acquirers with material FX exposures may elect to hedge using forward contracts, FX swaps, or options. ASC 815 governs whether hedge accounting is available and how to document, assess, and report hedges. The decision to hedge (vs. accept FX P&L volatility vs. pass through to merchants) is a joint risk management and accounting decision with significant P&L implications.

DCC Revenue Recognition and FX Margin Accounting

DCC revenue — the margin earned by the acquirer on the spread between the wholesale FX rate used to convert the transaction and the rate quoted to the cardholder — is recognized at the time of transaction settlement, when the acquirer has provided the currency conversion service and the margin is fixed. It is gross revenue (the acquirer is the principal in the currency conversion), presented separately from interchange and MDR revenue in management reporting for margin transparency.

Journal Entries — FX Remeasurement

FX Controls Framework

Controller Checklist — FX & Cross-Border

Reconciliation
& Close

Settlement file vs. GL reconciliation, scheme billing rec, chargeback reserve rec, and a practical monthly close calendar for the acquiring controller.

Reconciliation in payments is a multi-layered matching exercise: settlement data flowing from the network must tie to internal processing records, which must tie to the GL, which must tie to the bank statement. Each layer introduces potential breaks that, if unresolved, compound across periods. A disciplined close process in acquiring requires dedicated settlement reconciliation tooling — whether a purpose-built system or a well-structured Excel framework built specifically around the daily settlement file format — and a controller who understands the source data well enough to know whether a break is a timing difference, a booking error, or a genuine exposure.

The Four Layers of Acquiring Reconciliation

Settlement File Reconciliation

The daily settlement reconciliation starts with the network's settlement file — for Visa this is the TC46 (settlement) file; for Mastercard the IPM (Interchange Processing Message) file. These files contain the gross transaction amounts, interchange calculations, scheme fees, and net settlement position for each day's clearing cycle. The controller's team must reconcile this data against:

• 1
  Transaction Count & Amount Match — Total transaction count and gross volume in network file vs. internal processing system. Breaks typically indicate timing differences or unprocessed file segments.
• 2
  Interchange Validation — Interchange amounts per the network file must be validated against expected rates per the interchange rate tables and actual card mix. Unexpected downgrade rates generate variance requiring root cause analysis.
• 3
  Scheme Fee Validation — Monthly scheme billing statements (Visa Consolidated Billing Statement / MCBS) must be reconciled against expected fees based on volume data. This is often a delayed reconciliation given scheme billing cycles.
• 4
  Net Settlement Tie-Out — Net settlement position per network file must match the cash received in the settlement bank account (same-day or T+1). Unresolved net position breaks are a material reconciling item that escalates to treasury and network relations teams.

Monthly Close Calendar

Journal Entries — Close Process Entries

Controller Checklist — Reconciliation & Close

Four-Layer Reconciliation — Break Escalation Framework

Every settlement break lives at one of four layers. The controller's job is to identify which layer the break is at before doing anything else. Fixing the wrong layer wastes hours and leaves the real break open.

Open Item Aging — Hard Rules

What a Real Break Looks Like — Three Scenarios

Chargebacks
& Disputes

Full chargeback lifecycle, representment mechanics, reason code taxonomy, P&L flow-through, and reserve implications for the acquiring controller.

Chargebacks are the mechanism by which cardholders dispute transactions and reverse funds previously settled to merchants. For the acquirer, chargebacks create an immediate financial obligation — the acquirer is required by network rules to return funds to the issuer upon receipt of a valid chargeback, with subsequent recovery from the merchant or from reserves. Chargeback management is simultaneously a risk management, operational, and accounting function, and the controller must understand all three dimensions.

The Chargeback Lifecycle

Visa Chargeback Reason Code Framework

P&L Flow-Through and Reserve Implications

The P&L impact of chargebacks depends on whether the chargeback can be recovered from the merchant. For financially sound merchants with sufficient reserve or DDA balance, chargebacks are typically a pass-through — the acquirer debits the merchant, the net P&L impact is zero (offset by reserve draw-down or direct merchant debit). The P&L exposure materializes when:

Concessions vs. Errors vs. Disputes — Critical Distinction

These three categories look similar operationally but have completely different accounting treatments. Conflating them is a recurring audit finding in payments finance.

Controller Checklist — Chargebacks & Disputes

Breaking Into
Payments Finance

The 30/60/90 day career roadmap, credential strategy, 10-K case study framework, and how controllers build durable industry credibility — from first day in payments to recognized domain authority.

You've read the guide. You understand the four-party model, the fee waterfall, ASC 606's principal vs. agent framework, reserve methodology under ASC 450, and how network quarterly billing creates close risk. That knowledge alone puts you ahead of most people who carry a "payments finance" title. Now the question is how to operationalize it into a career trajectory. This section gives you the concrete playbook.

The 30 / 60 / 90 Day Roadmap

Whether you're new to acquiring or transitioning from Big 4 / FP&A into a controller role, the first 90 days are the highest-leverage window of your career in this domain. What you build in that window determines whether you're seen as someone who processes closes or someone who owns the business. The difference is intentional infrastructure-building.

Year 1–4 Career Arc

The ETA Certified Payments Professional (CPP)

The CPP is the most recognized credential in the payments industry, administered by the Electronic Transactions Association (ETA). It covers payments technology, security (PCI DSS, EMV), business development, and operational mechanics across the acquiring value chain. For a finance professional, the CPP signals domain commitment and operational breadth — that you understand the business you're accounting for, not just the accounting.

Reading Public Acquirer 10-Ks as Case Studies

The most underutilized free resource in payments finance education is the public 10-K. Annual reports of publicly traded acquirers contain their actual revenue recognition policies, reserve methodologies, segment structures, and risk disclosures — the output of exactly the accounting judgments you're building expertise on. One hour per quarter reading a competitor 10-K compounds faster than almost any other learning investment.

ASC Mastery Sequence — Priority Order

Building Credibility Through Documentation

In payments finance, credibility is built through documented intellectual work — not tenure. The controller who has written and defended a principal-vs.-agent analysis memo, built a reserve methodology framework from scratch, and published an internal training guide on interchange economics has built something no number of years of transaction processing can replicate: a portfolio of demonstrated accounting judgment applied to domain complexity.

Credentials & Certifications — Full Framework

The payments controller career has three parallel credential tracks: accounting/finance depth, payments domain, and technology fluency. The most valuable professionals in this space carry at least one from each track. Below is every credential worth considering, mapped by career stage, time investment, and the specific value it creates in a payments finance context.

Track 1 — Accounting & Finance Foundation

Track 2 — Payments Domain Credentials

Track 3 — Technology & Data Intelligence

Track 4 — Project Management & Leadership

Credential Priority Matrix — By Career Stage

AI & Agentic
Payments

How autonomous AI agents are reshaping payment initiation, authorization models, and the control frameworks controllers must build to manage machine-initiated spend at scale.

The next structural shift in payments is not a new card network or a faster settlement rail — it is the elimination of the human in the loop. AI agents capable of making purchasing decisions, initiating transactions, and managing multi-vendor spend autonomously are moving from research projects to production deployments. For the acquiring controller, this represents the most significant operational and accounting challenge since the transition to CNP e-commerce. This section maps the implications.

Traditional vs. Agentic Payment Flow

How AI Agents Initiate Payments

Current generation AI agents — including those built on Claude, GPT-4o, and Gemini — can be provisioned with payment credentials (virtual card numbers, API keys linked to payment accounts, or direct network API access) and authorized by their human principals to initiate purchases within defined parameters. The architecture typically involves:

• 1
  Policy-Bound Authorization — The human principal sets spending policies (merchant categories, amounts, time windows) that constrain agent behavior. The agent acts within these bounds autonomously. This is conceptually similar to corporate card controls — but AI agents can evaluate and initiate in milliseconds at scale.
• 2
  Tokenized Agent Identity — Rather than using the principal's personal card credentials, agents are increasingly provisioned with unique virtual card numbers or API tokens that can be individually traced, suspended, and audited. Visa's "Intelligent Commerce" and Mastercard's "Agent Pay" initiatives are building this infrastructure into the network level.
• 3
  Agentic Commerce APIs — Stripe's agent toolkit, Adyen's AI commerce APIs, and major bank commercial payments infrastructure are building explicit API surfaces for AI-initiated payment flows, with programmable approval workflows and real-time controls.
• 4
  Multi-Agent Orchestration — In enterprise contexts, a purchasing agent may be directed by a workflow orchestrator (itself an AI model), which received its goal from yet another system. The payment may be 4 levels of AI delegation removed from the human's original intent. This breaks every existing fraud model assumption about transaction intent.

Accounting & Control Implications for Controllers

The implications for acquiring controllers are not theoretical — they will arrive in your portfolio before your accounting policy frameworks are ready. The following are the specific areas where existing frameworks are inadequate and where new policy work is needed.

Revenue Recognition Timing

ASC 606's five-step model assumes a contract with a customer, performance obligations, and a transaction price. In agentic commerce, the "customer" may be an AI model acting on behalf of an enterprise. When is the performance obligation satisfied — at delivery of the digital good or service to the agent, or when the agent's principal benefits from it? For instantaneous digital deliveries (API calls, data, SaaS access), the timing question is narrow. For physical goods delivered to a location selected by an AI agent on behalf of a human, the question is more complex and the dispute window is potentially different.

Dispute and Chargeback Liability with No Human in the Loop

The existing chargeback reason code framework — grounded in human-intent disputes — does not adequately address AI-initiated transactions. If an AI agent purchases a service based on a misunderstanding of its principal's goal, is that "not as described" (13.3) or something else? If the agent is compromised by a prompt injection attack and makes unauthorized purchases, is that fraud (10.4)? Current network rules have not fully resolved agent-level liability, and this creates material uncertainty in acquirer reserve models.

Model Governance and Audit Trails

For SOX-compliant finance organizations, the introduction of AI agents into payment workflows requires a new class of IT general controls: model governance controls. These include documentation of model authorization scope, audit trail requirements for AI-initiated transaction decisions, periodic validation of model behavior against authorization policies, and change management procedures for model updates that could affect payment behavior. The audit trail question is particularly acute: in a dispute, can you produce an immutable log of why the AI agent made the purchase decision? Without this, the acquirer and merchant face an evidentiary gap in dispute proceedings.

How Networks Are Responding

What Controllers Must Build Now

The controllers who will lead this transition are those who engage with the technical architecture before it reaches production scale in their portfolios. The following is the priority work queue:

Agentic Commerce — The Controller's Accounting Framework

When an AI agent initiates a payment on behalf of a user — booking travel, purchasing supplies, executing a subscription — several accounting questions emerge that traditional acquiring frameworks don't address. The agent holds a mandate (permission to spend), uses stored credentials or network tokens, and may transact across multiple merchants. Who bears the chargeback risk when the agent makes an error? How is the mandate liability recognised? When does revenue recognise?

Agentic Payments — Five Controller Questions

Sources &
Attestation

Every statement, framework, and example in this handbook is derived from publicly available accounting standards, regulatory filings, industry publications, and controller-style analysis. No proprietary, confidential, or employer-specific material is included.

Public Sources Used

This handbook is built on information drawn exclusively from the following categories of public sources. Every accounting treatment, technical framework, journal entry illustration, and operational description traces back to one or more of these.

1. US GAAP & Accounting Standards

2. Card Network Rules & Published Materials

3. Regulatory & Government Sources

4. Industry Publications & Research

5. Author’s Independent Analysis

What This Handbook Does NOT Contain

Verification

Auditors, compliance reviewers, or curious readers can verify that this handbook's content derives only from public sources by following these steps:

1. Any GAAP-related claim can be verified against the FASB Codification at asc.fasb.org.
2. Interchange and scheme fee references can be verified against Visa and Mastercard public rate tables.
3. 10-K disclosure examples can be verified against the cited company's most recent SEC filing on EDGAR.
4. All illustrative dollar figures are hypothetical — none represent actual volume, revenue, or results from any real company.
5. Author attestation (above) confirms no proprietary content has been used.

Contact for Audit Support

If you are an auditor, compliance reviewer, or employer representative and require additional sourcing detail or attestation for a specific statement in this handbook, contact the author directly:

Version & Change Control

This attestation and sourcing statement is offered in good faith to document the author’s commitment to content originality and respect for intellectual property and confidentiality obligations. It is provided as supplementary reference material for readers who require transparency about content provenance, including auditors, compliance reviewers, and employers conducting standard due diligence on public authorship.

Payments & Finance
Terminology

110+ essential terms spanning merchant acquiring, payments finance, accounting standards, and emerging AI payments — controller-grade definitions.

The Close
Playbook

Variance analysis against volume and rate drivers, network quarterly billing in arrears, the full month-end close operating model, and the failure scenarios that blow up a clean close.

The acquiring close is not a general ledger exercise — it is a volume and rate reconciliation. Every line on the P&L is the product of a volume driver (GTV, transaction count, card mix) and a rate driver (MDR bps, interchange rate, scheme fee rate). When actual results deviate from plan, the explanation is always one of those two dimensions. The controller who understands this structure can produce a fully explained variance in hours. The one who doesn't spends days chasing unexplained noise.

The second structural reality of the acquiring close is billing in arrears. Visa and Mastercard do not bill scheme fees in real time. The Consolidated Billing Statement (CBS) and Mastercard Consolidated Billing System (MCBS) arrive 15–30 days after month-end. Some network fee categories — particularly FANF, cross-border assessments, and integrity fees — are billed on a quarterly lag. A controller who books only what has been billed is systematically understating costs and overstating margin every single period.

The Volume × Rate Decomposition Framework

Every variance in acquiring revenue or cost can be decomposed into a volume effect and a rate effect. This is the margin bridge. Build it into your close process and you will never present an unexplained variance to leadership again.

Network Billing in Arrears — The Controller's Timing Problem

Scheme fees are not paid in real time. They are billed on a lag that creates a structural accrual requirement every single month. Failing to understand the billing cycle of each fee category is the #1 source of scheme fee accrual variances at close.

The Controller's Daily Operating Rhythm

This is what the job actually looks like. Not theory — the specific tasks a payments controller executes every business day to run a clean acquiring book. If you're not doing all of these, you're flying blind.

Month-End Close Checklist — Acquiring Controller

Building the Acquirer Margin Bridge

The margin bridge is the most important deliverable the acquiring controller produces each month. It explains, in dollar terms, every driver of the change in net margin versus plan and versus prior period. Leadership does not want to hear "volume was up" — they want to know exactly how much each driver contributed and why.

Accrual Principles — Four Rules

• 1
  Estimate from best available data, not from perfection. Final scheme billing never arrives on M+2. Use prior-month actuals adjusted for volume change. Document the method. True-up when billing arrives. A reasonable estimate with documented methodology always beats a late close waiting for perfect data.
• 2
  Never net revenue against costs. Interchange is a cost. MDR is revenue. Separate lines always. Netting them destroys variance explainability and triggers revenue recognition presentation questions under ASC 606.
• 3
  Cutoff is a control, not an estimate. Revenue cutoff (clearing date) is deterministic — pull the exact cleared file for the last day of the month. If your revenue figure differs from that file, one of them is wrong. There is no "estimate" in cutoff.
• 4
  Every balance sheet account needs a sub-ledger. Settlement receivables, merchant payables, reserve liabilities, scheme fee payables — all require supporting detail tied to the GL balance. A GL account without a sub-ledger tie is an audit finding waiting to happen.

Failure Scenarios — What Breaks the Close

Month-End Close Journal Entries — Complete Set

Month-End Close Checklist — M+1 to M+15

Controller KPIs &
POS Terminal Accounting

The metrics dashboard every acquiring controller must own, float economics, and the definitive accounting treatment for POS terminal rental vs. sale — an area where most acquirer finance teams get it wrong.

The Controller's KPI Dashboard

These are the metrics that tell you whether the acquiring business is performing as modeled. A controller who can't speak to all of these at a weekly business review isn't functioning as a strategic finance partner — they're a scorekeeper. Know these cold. Know what drives them. Know what their movement signals before it shows up in the P&L.

Float Economics — The Hidden P&L Line

Float is the time value benefit the acquirer captures between receiving settlement funds from the network and disbursing those funds to the merchant's DDA. In a $100M/month portfolio with a 1.5-day average float, the acquirer holds approximately $5.0M in investable float on any given day ($100M ÷ 30 days × 1.5). At a Fed Funds rate of 4.50%, that float generates approximately $225K/year in interest income — a real, trackable P&L line that most mid-market acquirer controllers never model.

POS Terminal Accounting — Rental vs. Sale

Point-of-sale terminal accounting is one of the most commonly mis-applied areas in acquiring finance. The distinction between a terminal rental (or lease) and a terminal sale is not a billing question — it is a GAAP question with material balance sheet and income statement consequences. Getting this wrong creates overstated or understated assets, misclassified revenue, and potential restatement exposure.

Terminal Sale

When the acquirer sells a terminal to the merchant, title transfers and the merchant owns the hardware. The accounting is straightforward:

Terminal Rental / Operating Lease

When the acquirer retains ownership and rents the terminal to the merchant for a monthly fee, the transaction is a lease under ASC 842. The acquirer is the lessor. The classification — operating lease or sales-type lease — determines the entire accounting treatment.

Controller Checklist — KPIs & POS Accounting

Issuing Side
Accounting

The same transaction, opposite accounting. How interchange, network fees, rewards, interest income, charge-offs, and co-brand economics work from the issuer's perspective — and why every acquirer controller needs to understand both sides.

Every card transaction has two sides of the ledger. The acquiring side earns MDR and pays interchange as a cost. The issuing side receives that interchange as revenue and pays network fees, funds rewards, and bears credit risk. Understanding both sides is directly useful — it affects how you read interchange economics, evaluate partner agreements, interpret co-brand deal terms, and explain pricing decisions to leadership.

Interchange as Issuer Revenue

For the issuer, interchange is the primary revenue driver on card transactions. Under ASC 606, interchange is recognized at the point each transaction clears — it meets the performance obligation (providing the credit/debit authorization service) at that moment. Unlike acquiring MDR, the issuer does not have a direct relationship with the merchant; interchange flows through the network as a fee set by the network and collected by the issuer per cleared transaction.

Issuer P&L Structure

Rewards Expense — The Most Contested Accounting

Rewards are the single most judgment-intensive accounting item in card issuing. The fundamental question under ASC 606 is whether rewards represent a reduction of revenue (contra-revenue) or an operating expense — and the answer depends on whether the rewards are part of the transaction price or a separate customer loyalty program.

Co-brand Economics — Controller Framework

Co-brand agreements (e.g., airline cards, retail cards) create complex revenue sharing arrangements between the card issuer and the brand partner. The dominant co-brand structure today is the issuer paying the brand partner a royalty — typically a per-account fee, a per-spend fee, or a revenue share on net portfolio economics — in exchange for the brand providing its customer base and exclusive card rights. Some legacy structures pass a portion of interchange directly to the brand, but modern co-brand deals are more commonly structured as royalty payments tied to GTV or portfolio profitability, not interchange splits. For the issuer's controller, co-brand payments are typically a cost of revenue — either a contra-revenue against interchange or a customer acquisition/retention cost depending on the specific contractual structure.

CECL & Allowance for Credit Losses — Deep Dive (ASC 326)

CECL (Current Expected Credit Loss) replaced the incurred loss model in 2020 for large public companies and represents the most significant change to credit accounting in decades. For issuers, CECL requires estimating the lifetime expected credit loss on every financial asset at the moment of origination — not when a loss becomes probable. The P&L impact of extending credit is front-loaded under CECL; the income statement sees the provision on Day 1.

CECL Calculation Methodology

ASC 326 does not prescribe a specific method — it requires the estimate to reflect reasonable and supportable forecasts of future economic conditions. In practice, card issuers use one of three approaches, often in combination:

Allowance for Credit Losses — Journal Entry Lifecycle

Key CECL Ratios — Controller Monitoring

Revenue Share &
Partner Economics

ISO residuals, PayFac splits, issuer revenue share, and co-brand deal mechanics — the calculation logic, contract interpretation, system gaps, and audit risks that controllers must own.

Revenue share arrangements are among the most complex accounting and operational challenges in payments finance. The economics flow in multiple directions — acquirers pay ISOs, PayFacs pay sub-merchants, issuers pay co-brand partners, networks pay volume incentives — and each flow has its own recognition timing, classification treatment, and reconciliation requirement. If your revenue share liability is unreconciled, your P&L is wrong.

ISO Residuals

An ISO (Independent Sales Organization) earns a residual — a share of the net revenue generated by the merchants it introduced to the acquirer. Residuals are typically calculated as a percentage of the acquirer's net margin (MDR minus interchange minus scheme fees) on the ISO's portfolio, paid monthly in arrears.

PayFac Sub-Merchant Splits

A Payment Facilitator (PayFac) operates under a master MID and boards sub-merchants under its umbrella. The PayFac charges sub-merchants a blended rate (typically 2.5–3.5% for SMB), pays the acquirer a wholesale rate (interchange + acquirer markup), and retains the spread. This creates a layered P&L that the PayFac controller must model explicitly.

Revenue Share Classification — Contra vs. Expense

The most frequent audit finding in payments revenue share accounting is misclassification between contra-revenue and operating expense. The distinction matters materially for gross revenue presentation under ASC 606.

Network Volume Incentives — Received by Acquirer

Large acquirers often receive volume incentive payments from Visa and Mastercard in exchange for routing volume commitments or achieving volume targets. These are sometimes called "network incentives" or "volume rebates" and are negotiated annually. They are typically structured as: a fixed annual amount payable quarterly, and/or a variable component tied to volume growth above a threshold.

System Gaps — The Controller's Operational Risk

ISO Agreement — Key Controller Checkpoints

Controller Checklist — Revenue Share

Journal Entries — Revenue Share Accounting

PayFac as a Service (PFaaS) — Controller Framework

The payments distribution model has evolved through four distinct stages, each with different accounting implications for platforms. Understanding where your platform sits in this evolution determines how you recognize revenue, classify merchant payments, and assess ASC 606 principal vs. agent status.

PFaaS — The ASC 606 Principal vs. Agent Question

When a platform uses PFaaS (e.g., Stripe Connect, Adyen for Platforms), the revenue recognition question is: is the platform a principal (recognizes gross payment volume as revenue) or an agent (recognizes only its net platform fee)? This is not a theoretical question — it determines whether a $1M/month platform reports $1M or $30K in revenue. The answer has significant implications for gross margin presentation and investor perception.

Volume Definitions
& Mix Risk

Volume is not one number. Auth volume, cleared volume, settled volume, reported volume, and eligible volume are five different figures — and confusing them is the most common source of interchange reconciliation errors in merchant acquiring.

When a business leader says "our volume was $100M last month" they could mean any of five different things, each with a different dollar amount and a different accounting implication. The controller who conflates these numbers produces incorrect interchange accruals, misstated revenue, and unreconciled settlement files. This section defines each precisely and maps them to their accounting triggers.

The Five Volume Definitions

Mix Risk — How Card Mix Destroys Margin

Mix risk is the interchange cost impact of a shift in the composition of cards used to transact at a merchant portfolio, with no change in GTV or MDR pricing. It is the most commonly missed variance component in acquirer margin analysis and a frequent source of unexplained P&L deterioration.

Decomposing the Interchange Variance Bridge

A complete interchange cost variance bridge has three components — volume, rate, and mix. Most controllers only show two. The missing mix component is systematically misattributed to "rate" when it's actually portfolio composition.

Controller Checklist — Volume Definitions

Why Volume Definitions Matter for Contracts

Merchant agreements define pricing based on volume — and the volume definition in the agreement may not match any of the five technical definitions above. A common contract term: "MDR applies to net processed volume." Does "net" mean cleared volume? Settled volume? GTV minus refunds? The controller must map every contract pricing term to a specific technical volume definition and ensure the billing system applies the correct base. A 2% error in the volume base on a $50M merchant is $100K/year in billing variance.

Journal Entry — Why Volume Type Matters for Cutoff

Network Reporting
(Visa / Mastercard)

How Visa and Mastercard calculate, bill, and audit assessment fees — accrual vs. invoice timing, quarterly true-ups, compliance program fees, and what controllers must build to stay ahead of billing surprises.

Visa and Mastercard are not just transaction routers. They are the regulatory and economic infrastructure of card payments — setting rates, enforcing rules, billing fees, and fining non-compliance. For the acquiring controller, the card networks operate on their own billing cycle — the invoice arrives weeks after the economic event, the amount is largely non-negotiable, and reconciling it back to internal volume data is the controller's responsibility. Understanding their billing mechanics is essential to accurate accruals and clean audits.

The Billing Hierarchy

Assessment Fee Calculation Logic

Understanding exactly how networks calculate each fee line is the prerequisite to building an accurate accrual. Networks apply rates to different volume bases — getting the base wrong means your accrual is wrong even if the rate is right.

Accrual vs. Invoice — The Controller's Operating Model

The core challenge: scheme fees are incurred daily (every transaction generates an assessment) but billed monthly or quarterly. The controller must accrue the full amount by period-end and true-up when the invoice arrives. The accrual error compounds if any of these are wrong: the rate, the volume base, the fee category coverage, or the quarterly fee estimate.

True-Up Process When Billing Arrives

• 1
  Download CBS and MCBS (typically M+15 to M+20). Map every line item to your accrual model. Any line item in billing that has no corresponding accrual line is an immediate investigation item.
• 2
  Calculate variance by fee category. Do not net total billing vs. total accrual — that hides offsetting errors. A 10% over-accrual on assessment netted against a 10% under-accrual on FANF looks like zero variance but is two errors.
• 3
  Book true-up journal entry. Dr/Cr Scheme Fee Expense vs. Scheme Fee Payable for the net difference by category. Document the cause of each variance above your materiality threshold.
• 4
  Update accrual model. If the variance is systematic (e.g., FANF consistently over-accrued because MID count model is stale), correct the model input — not just the true-up entry.
• 5
  Investigate new line items. Any fee category in billing that wasn't in the prior month requires immediate research. New network fees are introduced through quarterly network bulletins — if you're not reading the bulletins, you'll always be surprised at billing time.

Controller Checklist — Network Reporting

Compliance Programs — Controller Cost Awareness

FTP &
Balance Sheet Mechanics

How the balance sheet drives payments profitability — settlement receivables, merchant payables, cardholder receivables, float, and Funds Transfer Pricing (FTP) as the hidden P&L lever most controllers ignore.

Most payments P&L discussions focus on the income statement: MDR revenue, interchange cost, scheme fees, net margin. But the balance sheet is where the real economics of payments live. Settlement timing creates float. Float is investable. Cardholder receivables generate interest income. Merchant payables represent short-term funding obligations. FTP (Funds Transfer Pricing) is the internal mechanism banks use to allocate the cost and benefit of this balance sheet activity to the businesses that generate it. At a bank-owned acquirer, FTP-allocated float income and funding costs can represent 20–30% of total acquiring contribution in a normal rate environment — a material component that is invisible to controllers who focus only on fee income and interchange spreads.

The Payments Balance Sheet — Four Key Positions

Float Economics — The Full Model

Float is the investable cash that exists because settlement timing creates temporary balances. For an acquirer, there are two types: receive float (settlement receivable earns interest while in transit from network) and pay float (merchant payable is a temporary source of funds between receipt and disbursement). In a rising rate environment, float becomes a meaningful P&L contributor.

FTP — Funds Transfer Pricing Framework

FTP is the internal rate a bank's treasury charges or credits its business units for the use of balance sheet. For the acquiring business within a bank:

• 1
  Settlement Receivable earns FTP credit — Treasury pays the acquiring business the overnight rate on the settlement receivable balance for each day it holds that asset before cash receipt. This is income to the acquiring P&L.
• 2
  Merchant Payable incurs FTP charge — The acquiring business owes merchants. Treasury funds this liability at the overnight rate, charging the acquiring business for the cost. This is a cost to the acquiring P&L.
• 3
  Net FTP position — If the settlement receivable (asset) is larger than the merchant payable (liability), the acquiring business has a net FTP credit — it earns more from float than it pays for the liability funding. This is structurally always true: net settlement ($98.47M) > merchant payable ($98.25M) by the acquirer margin.
• 4
  Reserve liability earns FTP credit — The reserve balance withheld from merchants is a liability of the acquirer (held for the merchant's account) but the cash is managed by treasury. Treasury pays FTP credit on the reserve balance, creating meaningful income at scale.

Cardholder Receivables — Issuer Balance Sheet

For issuers, the cardholder receivable (outstanding credit card balances) is the primary balance sheet asset and the primary income driver. Understanding how it builds, deteriorates, and is reserved is essential for any finance professional at a bank with card issuing operations.

Journal Entries — Balance Sheet Positions

Controller Checklist — FTP & Balance Sheet

End-to-End
Master Flow

One complete lifecycle — from authorization to closed books. Every GL entry, every timing difference, every system handoff, every accrual. The $100M monthly portfolio model, fully reconciled from T+0 to M+20.

Every section in this handbook covers one piece of the acquiring lifecycle. This section ties them all together in a single, unbroken flow — the way a controller actually experiences the business. Use this as your anchor reference. When something in your close doesn't tie, trace it back to this model and find where the chain breaks.

Phase 1 — Authorization (T+0)

The cardholder taps or swipes. The acquirer sends an authorization request to the card network, which routes to the issuer for approval. Approval comes back in under 200ms. No money moves. No accounting entry.

Phase 2 — Clearing (T+1) — Revenue Recognition Trigger

The merchant closes their daily batch. All captured transactions are submitted to the acquirer's processor, which formats and submits a clearing file (TC46 for Visa, IPM for Mastercard) to the network. This is the accounting event. Revenue is recognized at clearing — the performance obligation (authorizing and facilitating the payment) is complete.

Phase 3 — Settlement (T+1 to T+2) — Cash Receipt

The card network calculates multilateral net settlement positions for all members. It sends net cash to the acquirer (GTV minus interchange minus scheme fees) via the settlement bank (typically Fed or SWIFT). The settlement receivable converts to cash.

Phase 4 — Merchant Funding (T+1 to T+3)

The acquirer funds the merchant's DDA account net of MDR and any reserve holds. This extinguishes the merchant payable. The reserve withheld becomes a liability that will be held for 90 days and then released (or applied to chargebacks).

Phase 5 — Month-End Accruals (M+1 to M+3)

The month closes. Daily clearing entries have been booked throughout. Now the controller runs the accrual layer: cutoff for any cleared-but-not-settled items, full scheme fee accrual, and a reserve roll-forward.

Phase 6 — Chargeback & Reserve (Ongoing, Monthly Assessment)

Phase 7 — Network Billing True-Up (M+10 to M+20)

Phase 8 — Quarterly Fee True-Up (Q+45)

Phase 9 — Variance Bridge (M+7)

Full Balance Sheet Position — End of Month

Where the Flow Breaks — Five Failure Modes

Master Flow Close Checklist

BNPL
Controller Framework

Buy Now Pay Later — the accounting framework for acquirers and issuers processing BNPL transactions. ASC 606 recognition, receivable treatment, contra-revenue decisions, reserve methodology, and the P&L impact of deferred pay at scale.

BNPL volume exceeded $300B globally in 2024 and is the fastest-growing payment method in e-commerce. For controllers, BNPL creates accounting questions that traditional card frameworks don't answer: who recognizes the receivable? When does the merchant get paid? How is the BNPL provider's revenue recognised? What reserve is required? The answer depends entirely on where your organisation sits in the BNPL value chain.

The Three BNPL Models — Accounting Differs by Position

Revenue Recognition — BNPL Provider Perspective

For a BNPL provider (Affirm, Klarna, Afterpay), revenue comes from two sources: the merchant discount rate (MDR charged to the merchant for the BNPL service — typically 2–8%, much higher than card MDR) and consumer fees (late fees, interest on longer-term plans). ASC 606 governs the merchant MDR. ASC 310/835 governs interest income on consumer receivables.

Acquirer Perspective — When BNPL Provider Is Your Merchant

Contra-Revenue in BNPL — The Merchant Incentive Question

Some BNPL arrangements include merchant incentives — the BNPL provider pays the merchant a bonus for driving consumer adoption. Under ASC 606, these payments to merchants may be contra-revenue (if they represent a price concession on the MDR) or marketing expense (if the merchant is providing a distinct advertising/promotional service).

Controller
Scenario Tools

Seven interactive scenario tools for payments controllers — covering net revenue, scheme fee accruals, reserve adequacy, FTP float income, issuing net interchange, and ISO revenue share waterfall. Each tool outputs a quantified result, a CFO narrative, and controller talking points. Tools 2–7 auto-run on load with default inputs. Tool 1 (P&A Classifier) opens on question 1.

How to Use These Tools

Enter your actual or estimated inputs and run the scenario. Outputs are directional — they quantify the gap between economic expectations and what lands in the P&L, and give you the language to explain it. These tools are designed to complement the close checklist in Chapter 07 (Reconciliation & Close).

Fraud Economics
& Accounting

How fraud losses flow through the P&L, how fraud reserves differ from chargeback reserves, and the full accounting framework for network compliance programs — VDMP, VFMP, and EDRM — that most controllers learn only when the first fine arrives.

Fraud and chargebacks are operationally related but financially distinct. A chargeback is a dispute mechanism — the cardholder asserts a claim and the funds reverse through a defined network process. A fraud loss is a direct financial loss incurred when fraudulent transactions settle and cannot be recovered. Controllers who conflate these two expose themselves to misstated reserves, wrong P&L line attribution, and reserve inadequacy surprises.

The Fraud Loss Taxonomy

Acquirer fraud losses fall into three categories, each with different accounting treatment:

Network Fraud Monitoring Programs — The Real Cost

Visa and Mastercard operate tiered compliance programs that generate direct financial charges against the acquirer when merchants breach fraud rate thresholds. Understanding these programs is prerequisite to accurate scheme fee accruals.

Fraud Reserve vs. Chargeback Reserve — The Accounting Distinction

Both reserves sit under ASC 450 (loss contingencies), but the estimation methodology differs:

Journal Entries — Fraud Loss Lifecycle

The 3DS Economics: Fraud Liability Shift and Revenue Impact

3D Secure authentication on CNP transactions shifts fraud chargeback liability from the acquirer to the issuer — for authenticated transactions, the acquirer is not liable for fraud-based chargebacks. The controller implication: 3DS adoption rates directly affect your fraud reserve adequacy model.

Merchant Bankruptcy
& Credit Risk

What actually happens when a merchant fails — the reserve draw-down sequence, loss recognition timing, clawback mechanics, proof-of-claim filing, and the accounting treatment for partial recoveries. The highest-stakes event in acquirer finance, and the one least covered in training.

A merchant bankruptcy is simultaneously a risk event, a legal event, a cash event, and an accounting event — and they do not all happen at the same time. The controller's job is to understand the sequence, account for each stage correctly, and ensure that the financial statements reflect reality before and after the insolvency event with appropriate reserve coverage.

The Merchant Default Timeline

Reserve Draw-Down Sequence — Journal Entries

CECL Application to Merchant Receivables (ASC 326)

Under the Current Expected Credit Loss model, the acquirer must estimate lifetime expected credit losses on the settlement receivable portfolio at each reporting date — not just when a specific merchant shows stress. For most T+1/T+2 settlement receivables the holding period is short enough that CECL has limited impact, but for funded receivables, rolling reserves, and any extended funding arrangements, CECL requires forward-looking loss estimates on Day 1.

Clawback Mechanics

A clawback occurs when an acquirer attempts to recover funds already paid to a merchant for transactions that subsequently generated chargebacks. The legal right to claw back is established in the Merchant Processing Agreement — but the practical ability depends entirely on whether the merchant has funds in their DDA or whether a funded reserve is available.

Deferred Revenue
& Contract Liabilities

When payments revenue must be deferred under ASC 606 — setup fees, annual fees, SaaS-bundled payment arrangements, hardware amortization, and the roll-forward mechanics that belong in every payments controller's close package.

In traditional card acquiring, revenue recognition was straightforward: MDR at clearing, done. Modern integrated payments — software-led, subscription-bundled, hardware-embedded — creates multiple performance obligations in a single merchant contract. When obligations are satisfied over time rather than at a point, revenue must be deferred. Getting this wrong creates a restatement risk, not just a timing difference.

Common Deferred Revenue Triggers in Payments

The Standalone Selling Price (SSP) Problem

When a merchant contract bundles multiple services — processing, software, hardware, support — the transaction price must be allocated to each distinct performance obligation based on its standalone selling price. If the company does not sell each component separately, SSP must be estimated using the adjusted market assessment approach, expected cost plus margin, or residual approach.

Deferred Revenue Roll-Forward — The Close Procedure

Deferred Revenue Balance Sheet Management

The deferred revenue liability should be split between current (recognized within 12 months) and non-current (beyond 12 months) on the balance sheet. As the merchant portfolio grows, the deferred revenue balance grows — which creates working capital pressure even though the cash has already been received. This is the opposite of the settlement receivable timing problem and controllers need to communicate both dynamics together.

Stablecoins &
Crypto Payment Acceptance

The controller's framework for digital asset payment acceptance — ASC 350 vs. fair value accounting, stablecoin settlement mechanics, crypto-to-fiat conversion timing, and the emerging regulatory and accounting standard landscape for 2024–2026.

Crypto payment acceptance is no longer theoretical. Major acquirers and payment platforms now process USDC, USDT, and other stablecoins alongside card rails. For controllers, the accounting questions are not theoretical either — they are live close questions with no definitive GAAP standard (yet). This chapter covers the current framework and the emerging guidance.

The Three Models of Crypto Payment Acceptance

Current GAAP Treatment — ASC 350 Intangible Asset Model

Under current US GAAP (before the FASB's December 2023 ASU 2023-08), crypto assets are classified as indefinite-lived intangible assets under ASC 350. This creates a severely conservative accounting model:

ASU 2023-08 — Fair Value Accounting (Effective 2025)

The FASB issued ASU 2023-08 in December 2023, effective for fiscal years beginning after December 15, 2024 (i.e., January 1, 2025 for calendar-year companies). This standard requires fair value measurement for in-scope crypto assets with changes recognized in net income each period.

Stablecoin-Specific Accounting Questions

Stablecoins — USDC, USDT, BUSD, and their successors — introduce specific questions that volatile crypto does not. A stablecoin is designed to maintain a 1:1 peg to USD. Does that make it cash? A cash equivalent? A financial instrument? ASC 350 says no to all three under current GAAP.

Revenue Recognition — Crypto Payment Acceptance

The Controller's Checklist for Crypto/Stablecoin Acceptance

• Determine whether your company holds crypto assets at any point — even briefly during conversion
• If yes: classify under ASC 350 (pre-2025) or ASC 350 as amended by ASU 2023-08 (2025+)
• Establish a crypto asset accounting policy before any significant volume — retroactive application is painful
• For stablecoins: do not assume cash equivalent treatment without a written technical accounting memo
• Revenue recognition: document the rate and timing of USD conversion for each crypto received
• Custody risk disclosure: where are the crypto assets held? Counterparty risk on custodian must be disclosed
• Tax: crypto assets trigger taxable events on disposition — coordinate with tax on timing of conversions
• Internal controls: crypto wallets and private keys are financial assets requiring SOX-level access controls

Escheatment
101

Unclaimed property law applied to payments — which balances escheatable, dormancy period rules by state, remittance mechanics, and the accounting treatment for escheatment liabilities. One of the least-understood compliance obligations in payments finance, and one of the most aggressively audited by state governments.

Escheatment — the legal process by which unclaimed property is transferred to the state after a defined dormancy period — is not optional, not voluntary, and not widely understood in payments finance. States have become increasingly aggressive in auditing financial services companies for unclaimed payment-related balances. The fines and interest on late or missed escheatment filings routinely exceed the underlying unclaimed amounts.

What Is Escheat in Payments?

In a payments context, escheatable property includes any financial obligation to a third party (typically a merchant, cardholder, or former employee) where the holder — the acquirer, issuer, or processor — has lost contact with the owner and cannot remit the funds. The balance does not disappear; it becomes a state government liability after the dormancy period expires.

The Dormancy Period and Due Diligence Requirements

Before property can be remitted to the state, the holder must complete a due diligence process — typically sending written notice to the last known address of the owner within a specified window before the dormancy period expires. If the owner does not respond, the property is then reported and remitted to the state.

Priority Rules — Which State Receives the Funds?

The U.S. Supreme Court established a two-priority rule for unclaimed property:

• First priority: The state of the owner's last known address receives the property. If you have an address for the merchant or cardholder, that state gets the funds.
• Second priority: If you have no address (or the address is in a state with no unclaimed property law), the state of the holder's incorporation receives the property. For a Delaware-incorporated company with an unknown-address merchant, Delaware gets it.

For payments companies with national merchant portfolios, this means filing in potentially 50+ states annually — each with slightly different dormancy periods, due diligence requirements, and filing formats.

Accounting Treatment for Escheatment Liabilities

The Breakage Revenue Intersection

Gift cards and reward points require careful analysis at the intersection of ASC 606 breakage revenue and state escheatment law. Under ASC 606, a company can recognize breakage revenue (unredeemed balances) proportionally as redemptions occur — if it is probable that a significant reversal will not occur. But many states do not allow breakage to extinguish the escheatment obligation. You may recognize breakage as revenue under GAAP while still having an escheatment liability to the state for the same unredeemed balance.

State Audit Risk — What Controllers Must Know

State unclaimed property audits are conducted by third-party contingent fee auditors who earn a percentage of the amounts they identify. This creates aggressive audit behavior. Common audit targets in payments companies:

• Outstanding check register — items that have been outstanding for more than 3 years are almost certainly escheatable
• Reserve release failures — rolling reserve amounts not released on schedule (merchant has moved, no forwarding address)
• Stale credit memos — unapplied credits to merchant accounts older than 3 years
• Intercompany balances — aged intercompany payables are often missed in escheatment analysis
• Unredeemed incentive payments — ISO signing bonuses, promotional credits, incentive checks that were not cashed