Reconciling Mastercard clearing with on-chain money: where the pennies go missing

A stablecoin card programme keeps two records of the same money: the card scheme's clearing and settlement, and the chain. They never agree on their own. Every difference between them is either a real loss, a timing gap or a bug, and the job of reconciliation is to tell you which, every day, before the differences add up.

More programmes now run on both rails at once; Mastercard and BVNK's platform, launched on 15 October, puts fiat and stablecoin accounts, conversion and stablecoin-linked cards behind one API [8]. We have built crypto-wallet card issuing, including the card ledger and Mastercard clearing reconciliation. The examples below are synthetic.

Three records, not two

It helps to name the stages precisely. Marqeta's European guide defines them as:

Authorisation: approving the cardholder's transaction to the merchant through the network.
Clearing: finalising the hold on funds and posting the transaction to the cardholder's account.
Settlement: moving the funds between the merchant's and the cardholder's banks [1].

On a stablecoin programme there is a fourth record: the on-chain transfer that funded the payment, or returned money to the user. Reconciliation is three joins: authorisation to clearing, clearing to settlement, and each of those to the chain.

How clearing arrives

Clearing is batched. Merchants batch their clearings roughly once a day and submit them to the acquirer; the network splits them by issuer and passes them on [2]. Marqeta says Mastercard clearings arrive in several cycles a day, and recommends reconciling by settlement date and clearing cycle against the scheme's settlement report, net of the scheme's fees [1].

Two consequences follow. A purchase on Monday evening may clear on Tuesday or Wednesday. And "today's" clearing depends on which cut-off you use, so pick one definition of the business day and use it everywhere.

The breaks

Break	What you see	Examples
Authorisation, no clearing	A hold that never posts	Cancelled sale, or a merchant that never cleared
Clearing, no authorisation	A posting with nothing to match	Force post, offline or stand-in approval
Amount differs	Clearing above or below the hold	Final amount differs from the estimate, currency conversion
Several clearings	One authorisation, many postings	Split shipments, hotel or car hire extras
Reversal	A hold released, sometimes after a pull	Merchant reversal, or expiry
Late clearing	A posting after the hold expired	Merchant cleared late
Chain disagrees	Ledger entry with no transfer, or the reverse	Failed, dropped or late transaction

Authorisations with no clearing

Holds expire. Marqeta's European guide gives a default hold of eight days before reversal, with longer and shorter periods for some merchant types [2]. Lithic lists periods of 1 to 30 days depending on the scheme and transaction type, and warns that expiry does not stop a clearing arriving later [3]. If your programme pulled stablecoins at authorisation and returns them at expiry, a late clearing leaves you unfunded.

Clearing with no authorisation

When Marqeta cannot link a clearing to an earlier authorisation, it still posts it, as a force capture [2]. It also says all clearings must be processed whatever the earlier authorisation status, because settlement is already in progress [2], and Enfuce's documentation likewise says clearing can arrive with no matching authorisation and is still processed under scheme rules [9]. Marqeta recommends reconciling force-post and offline transactions in particular [4]. Stand-in approvals land here too: Mastercard can approve on the issuer's behalf when it cannot reach the processor, and the issuer learns of it afterwards [5]. None of these had an on-chain pull at the time. Each one is a collection your system must start, and a loss if it fails.

Amount differences and currency conversion

Marqeta notes that clearings can come in higher than the authorised amount in some cases, and that a merchant can clear for a lower amount or clear more than once [2]. For a cross-currency purchase, the conversion used at clearing need not match the one used at authorisation, so even a "same amount" purchase can clear at a different billing amount. Treat the clearing amount as the truth, and the difference as an adjustment with its own ledger entry and, where needed, its own on-chain transfer.

Several clearings and reversals

One authorisation can produce several clearings: Enfuce gives an online order shipped in parts, and extra charges from hotels, fuel stations or car hire, as examples, and marks each clearing as partial or final [9]. Lithic notes that a clearing not marked final may leave the rest of the hold in place until a later event releases it or it expires [3]. Your ledger needs the remaining hold per authorisation, not a yes/no "cleared" flag. Reversals and expiries show up in Marqeta's event list as temporary events that restore the balance; refunds as final ones [4].

The chain disagrees

A ledger entry says "pulled 40 USDC"; the chain has no such transfer. Or the chain has a transfer you have no record of. Solana gives three commitment levels: processed can still be rolled back, confirmed has a supermajority of stake behind it, and finalized has reached maximum lockout [7]. Solana's guide adds that roughly 5% of blocks are never finalized, and that a transaction may be dropped and should be resent until its blockhash expires, which takes roughly 60 to 90 seconds [6].

So a ledger entry written at processed can describe a transfer that never happened. Reconcile ledger entries against finalized data, even if you answered the authorisation at confirmed.

Matching keys

Design the keys before the first payment. A workable set:

Authorisation to clearing: the scheme's transaction reference, carried through by your processor, plus the card. When the processor has linked them, use its link. When it has not, fall back to card, merchant, amount within a tolerance and a date window, and send every fallback match to review.
Clearing to settlement: the settlement date and cycle, summed and compared with the scheme's settlement report [1].
Ledger to chain: your own payment id, written to the ledger before you send the transaction, with the signature stored against it once sent. Never key on amount and wallet alone: two 40 USDC purchases in a minute look identical on chain.

Every key is many-to-one in at least one direction. An authorisation can have several clearings, a refund may match nothing, and one on-chain transfer may fund an incremental hold. Model the links as a table, not a column.

Exception queues

A break you can't explain goes in a queue, not a suspense account nobody reads. Keep separate queues because they have different owners and deadlines:

Unfunded postings: force posts, stand-in approvals and late clearings with no pull. Collect, or write off.
Unmatched clearings: no authorisation found by any key.
Amount breaks: over a set tolerance, per currency.
Stale holds: past expiry with no clearing.
Chain breaks: ledger and chain disagree at finalized.

Each item needs an age, an amount, and a rule for when it escalates. Report the queue totals daily. A queue that only grows means a key is wrong.

Where to start

Count your breaks before you fix them. A week of clearing matched against your ledger and the chain, with every break put in one of the queues above, tells you where your pennies go.

What we do: our card-programme diagnostic covers ledger and reconciliation design. See https://centrob.co/#payments.