Each USDC payment has a hash and an address, but no invoice. Here is how to tie it to a bill, a client and a bank.
Stablecoin reconciliation is the work of matching each on-chain transfer to the invoice, customer and ledger entry it pays, then to the dollars that reach the bank. The blockchain record shows a transaction hash, a sending and receiving address, a token and a network. It shows no invoice number. A business closes that gap through the deposit structure its provider offers and the status events the provider sends.
What has to match
A finance team usually needs four records to agree before a stablecoin payment is booked as settled:
| Record | Where it comes from | What it proves |
|---|---|---|
| On-chain transfer | Block explorer or provider event | Tokens moved: hash, token, network, amount |
| Deposit or payment object | Provider API (payment, deposit address, drain) | Which customer or invoice the transfer belongs to |
| Conversion and fees | Provider balance or drain record | How many dollars the tokens became |
| Bank credit | Bank statement or payout record | The dollars actually arrived |
The hard step is the second row. A transfer can only be tied to an invoice if the receiving address, an address tag or a provider payment object identifies it.
Three ways providers attribute a payment
Providers document different models, and each one changes the matching work.
Checkout payment objects (Stripe). Stripe’s stablecoin payments start from a payment the merchant creates, so the invoice reference sits on the Stripe object before the customer pays. Customers choose the token, wallet and network. Stripe lists USDC on Tempo, Ethereum, Solana, Polygon and Base, plus USDP and USDG, which it marks as US-only. Completed payments settle in the Stripe balance in the merchant’s local currency, and the presentment currency is USD. From there, matching works from the Stripe balance and payouts; Stripe says payout timing varies by network. Its Checkout guide also says line items must be priced in USD.
Deposit addresses (Circle Mint). Circle’s API generates a deposit address for a given currency and chain, and a deposit to it credits the associated wallet. Circle says it may reuse addresses on chains that support reuse, so a request for USD and ETH deposit addresses on Ethereum can return the same address. The response can also include an addressTag next to the address, and matching logic has to store both. A business that needs one address per customer should confirm how the provider assigns them before building matching rules on addresses alone.
Liquidation addresses (Bridge). Bridge’s liquidation addresses are permanent on-chain addresses tied to one customer and one destination. Incoming tokens are converted and forwarded automatically: instantly on real-time rails such as wires and blockchains, and in a daily batch for ACH. Each deposit creates a drain record that carries the payment through its life.
Drain states as a reconciliation trail
Bridge lists nine drain states. They map cleanly to ledger entries.
| Drain state | Ledger treatment |
|---|---|
in_review | Hold as pending; Bridge says it usually clears, and it contacts the business if unresolved after 24 hours |
funds_received | Tokens received; outbound payment not yet sent |
payment_submitted | Outbound payment sent, not yet confirmed |
payment_processed | Settled; the record may carry a tx_hash, imad or trace_number |
undeliverable | Not delivered, for example an invalid account |
returned | Sent, then rejected by the destination |
refunded | Returned funds re-sent to another destination |
error | System or network issue; may need manual work |
canceled | Stopped before submission, for example after a compliance review or below the minimum |
An IMAD identifies a wire and a trace number identifies an ACH entry, so the bank-credit row of the table gets a direct key. Bridge says drains only move forward, and it sends a webhook for each new drain and state change. Bridge also asks for a return_address so failed or returned funds have somewhere to go.
Refunds and reversals
Stablecoin refunds run in the opposite direction from card refunds. Stripe returns refunds as stablecoins to the customer’s original wallet, and the refund object carries the refund’s transaction hash. Stripe lists no dispute support for stablecoin payments, so there are no chargebacks to reconcile. A returned off-ramp payment at Bridge, by contrast, comes back as a returned drain and then, if re-sent, a refunded one.
A working checklist
- Store the provider’s object ID, the transaction hash and the network on every ledger line.
- Post on-chain receipts as pending until the provider marks them final or processed.
- Keep a separate line for conversion and fees, so token amounts and dollar amounts can both be traced.
- Match the bank credit by wire IMAD or ACH trace number where the provider returns one.
- Treat address reuse and missing address tags as exceptions, with a manual queue.
The deposit and payout calls behind these flows are compared in stablecoin on off ramp api, and the checkout side in accept stablecoin payments b2b.
