Test Three-Balance Reconciliation Before Production
Pair your ledger prototype with Formance Reconciliation to test the three-balance reconciliation from Step 5 against normalized on-chain data before any production integration.
Your engineering team just shipped stablecoin acceptance for ACME, the platform's largest merchant. A $50,000 payment lands, the system marks it received, releases the order, and the customer walks away with the product. Hours later, the blockchain reorganizes, and the payment disappears. The treasury team is short $50,000, and the engineering team can't reverse ACME's balance because the deposit landed in a shared wallet with fifty other payments.
Crypto acceptance is a ledger problem, not a checkout problem, and engineering teams make the decisions that determine whether it works at design time. Roughly 50% of companies earning over $500 million in annual revenue accept crypto payments, and 23% of North American CFOs at companies over $1 billion in revenue expect their treasury to use crypto (also known as digital assets) within two years.
That means the design decisions are landing on engineering teams that have never had to reconcile a reorg against a customer balance before. The cost of getting them wrong scales with the size of the merchants being onboarded.
This guide covers the five infrastructure decisions behind the checkout (custody, confirmation, ledger attribution, conversion timing, and reconciliation), the regulatory controls that cut across them, and a Numscript pattern you can run locally to test the account model.
Accepting crypto payments requires five infrastructure decisions: a custody model, a confirmation policy, a ledger design that attributes funds per customer, a conversion timing rule, and reconciliation ownership. Regulatory controls apply across all five as a design input.
A gateway for crypto acceptance sits in front of these five decisions but does not replace them. It generates deposit addresses, quotes exchange rates at checkout, and emits payment events. Building a crypto gateway is a distinct engineering project, but operational risks in custody, confirmation, attribution, conversion, and reconciliation still arise regardless of the gateway you choose.
Formance Ledger, an open-source, programmable core ledger that unifies fiat and crypto with regulatory-grade traceability, is the reference implementation used throughout this guide to make each of the five decisions concrete. The design patterns apply to any double-entry ledger with per-asset precision and hierarchical account paths.
Pick one of three crypto custody models: self-custody, third-party custodial, or MPC/threshold. The choice depends on which counterparty risk and key-management burden your team can carry.
The crypto payment infrastructure, which can include a payment processor, integrated point-of-sale, or direct wallet acceptance through business-controlled addresses, determines the custody model. In turn, the custody model determines whether your ledger can prove which customer owns which funds.
Self-custody, full key control and full operational burden
Self-custody gives you full control of signing keys and full responsibility for key ceremonies, shard backup, rotation, and recovery drills. In practice, this means HSMs or equivalent hardware, key ceremonies run on a fixed cadence, and dedicated security headcount to own the runbook and pass audits.
A regulated entity that cannot delegate key control needs to budget for an ongoing security engineering program.
A third-party custodian takes key management off your operational surface and hands you counterparty risk you cannot patch. Your ability to move funds depends on their solvency and their willingness to release balances on demand. If the custodian fails or freezes withdrawals, your customers' balances become claims in an external proceeding rather than assets you can settle against.
A standard vendor security review will not tell you whether a custodian can actually recover funds if a key is lost, so ask them when they last ran a recovery drill, what happened, and how they keep customer funds separate from their own before signing. Keep per-customer balances on your own ledger too, so if the custodian goes down you can still tell whose money is stuck.
MPC splits signing authority across key shares so no single machine holds a complete key, and it requires rehearsed recovery in case one share becomes unavailable.
In MPC, that rehearsal covers rotating shares when staff or infrastructure changes, adjusting the signing threshold as the team grows, and confirming you can migrate off the vendor without losing access to the keys they helped generate.
Pick MPC when you want to avoid single-custodian counterparty risk but do not have the headcount to run a full self-custody security program.
Whichever model you choose, any business running an omnibus structure has to keep per-customer fund attribution in the ledger.
A crypto payment confirmation policy has three states for every incoming payment: detected, confirmed, and available.
Fulfilling an order at first confirmation is a design bug, because a chain reorganization can move or invalidate a transaction already marked paid.
Confirmation depth requirements differ by asset and by each chain's finality mechanics, so set thresholds per asset and revisit them as chain conditions change. The distinction between confirmation and settlement finality is what determines when funds are yours to move. Weight thresholds by order value, and hold the release posting until you meet depth.
The policy is enforced at the ledger boundary, which Step 3 covers.
Every confirmed deposit has to be recorded as a double-entry posting in a core ledger that names the customer or merchant sub-account at credit time, because a wallet balance only records total holdings and cannot prove who owns what.
Below are attribution mechanics, an account path design that maps confirmation states onto ledger paths, and a Numscript example you can run locally.
Attribution has four moving parts: double-entry, attribution at credit time, idempotency, and per-asset precision.
When you detect a deposit, record it in the ledger against a sub-account named for the merchant it belongs to, and use the confirmation states from Step 2 (pending and available) as separate sub-accounts under that merchant. Checking how much a merchant has in either state is a simple lookup on one account instead of stitching together balances from multiple wallets.
If you accept deposits across multiple chains, add a per-chain boundary path (for example, @external:bitcoin:gateway alongside @external:ethereum:gateway) so provenance stays queryable per chain. When identical assets arrive from sources with different risk profiles, tag units (also known as the "color of money pattern") with distinct provenance without creating a new asset type, and transaction metadata attaches counterparty identifiers or invoice numbers.
Numscript is Formance's domain-specific language for expressing money movements as transactions that both engineers and finance teams can read.
The pattern for a $250,000 invoice uses @external:ethereum:gateway as the blockchain boundary, @merchants:acme:pending for detected funds, and @merchants:acme:available for funds released after confirmation.
Detection moves $250,000 from the boundary to pending, and then confirmation moves the same amount from pending to available. The transfer_id metadata is the idempotency key, so the ledger rejects a duplicate submission with the same transfer_id without a second credit.
// DIGITAL_ASSET_DEPOSIT_DETECTED
// Event: detect Acme's 250,000 USDC deposit and credit its pending balance
send [USDC/6 250000000000] (
source = @external:ethereum:gateway allowing unbounded overdraft
destination = @merchants:acme:pending
)
set_tx_meta("event_type", "digital_asset_deposit_detected")
set_tx_meta("transfer_id", "trf001")
// DIGITAL_ASSET_DEPOSIT_CONFIRMED
// Event: release Acme's 250,000 USDC deposit after confirmation depth is met
send [USDC/6 250000000000] (
source = @merchants:acme:pending
destination = @merchants:acme:available
)
set_tx_meta("event_type", "digital_asset_deposit_confirmed")
set_tx_meta("transfer_id", "trf001")
If a chain monitor detects a reorg before it reaches the required depth, submit a compensating posting against pending without crediting available. Keeping the rollback in pending prevents it from cascading into balances you have already spent against.
Convert crypto payments to fiat as soon as they arrive. Only hold crypto if your treasury team has a specific reason, and if you do, track each stablecoin issuer as its own line on the ledger.
Options include BTC, ETH, and USD-pegged stablecoins like USDC and Tether (USDT). Asset choice is a liquidity and volatility question, and for stablecoins specifically, it is also a question about whose balance sheet you are holding. Stablecoins are now the default settlement rail (monthly on-chain volume reached $7.5 trillion in March 2026, passing ACH), which makes issuer choice a real balance-sheet exposure rather than a technical preference.
If you hold the crypto, your ledger has to track issuer exposure as its own balance class so that a USDC balance and a USDT balance are never netted into a single "stablecoins" line. Conversion itself is a treasury pattern with its own reconciliation legs across fiat and on-chain accounts. This is known as the stablecoin sandwich.
Reconcile the three balance sources (bank, blockchain, and internal ledger) as independent pairwise comparisons. Total balances can match across all three sources while individual customer balances are still wrong, and if no one acknowledges the uneven balances, they sit unresolved until an audit surfaces them.
Run reconciliation per posting class, each against a designated counterparty: on-chain postings against custodian or wallet balances, conversion postings against exchange settlement reports, and fiat settlement postings against bank statements.
Compare bank and blockchain records independently against the internal ledger, because attribution can break even when the totals tie out. Operations teams may then be unable to identify which customer's funds are stuck in which leg, so each posting class needs a named owner for exceptions, or the break sits in a queue no one is watching.
Track deposit status and treasury sweep status separately in the ledger. Credit a customer's deposit when the deposit meets your confirmation policy, and treat sweeping funds from a deposit address to a treasury wallet as a separate internal operation between accounts you control.
If a sweep fails, retry it without touching the customer's credit. If the ledger treats deposit and sweep as the same thing, a failed sweep will wrongly reverse a credit the customer already earned.
Regulatory controls apply across the five infrastructure decisions and dictate what data your acceptance flow has to capture at design time. Adding a know your customer (KYC) vendor onto a finished pipeline forces re-architecture of the acceptance pipeline.
In the European Union, MiCA applied its stablecoin titles from 30 June 2024 and the full crypto service provider regime from 30 December 2024. Structure the accounts chosen in Steps 1 and 3 to support applicable fund-segregation and traceability obligations.
In the United States, the GENIUS Act was signed on July 18, 2025, and takes effect at the earlier of 18 months after enactment or 120 days after final implementing regulations. Payment stablecoin issuer rules are arriving on a fixed statutory timeline.
At the state level, the Conference of State Bank Supervisors (CSBS) money transmission framework makes it clear that qualifying virtual currencies fit within the definition of money transmission, so state-level licensing analysis belongs in the pre-integration design phase.
The foundation of any crypto payment flow is the ledger. It proves who owns which funds, tracks the pending-to-available transition, enforces per-asset precision, and gives reconciliation something to check against.
Prove it in your organization first. Clone the open-source Formance Ledger on GitHub, run the Numscript postings from Step 3 locally, and extend the @merchants and @external account model to your own asset mix and confirmation thresholds.