Instant merchant settlement with stablecoins: a PSP playbook

Card acquiring settles merchants on a delay. T+1 to T+3 business days is typical, with weekends and public holidays adding to it, and rolling reserves on top for higher risk merchants. The delay is not a technical limit. It is the shape of a system in which authorisation, clearing and settlement are separate events run by separate parties. Stablecoin settlement collapses those events into one transfer that is final in seconds to minutes and available every day. The economics of that shift for a PSP are set out in where the margin actually comes from. This article is about how to run it.

What changes when settlement is on-chain

Dimension	Card settlement, fiat	Stablecoin settlement
Timing	T+1 to T+3 business days	Seconds on Base or Solana; around 13 minutes to finality on Ethereum mainnet
Calendar	Business days only	Every day, every hour
Reversibility	Chargebacks for months	None. Refunds are new payments
Who holds float	Acquirer and scheme, between events	The PSP, briefly, or nobody
Failure mode	Delayed batch, reserve hold	Wrong address, unfunded wallet, screening block
Merchant sees	Bank credit, days later	Bank credit, same day, or a stablecoin balance if they opt in

The right hand column is attractive. The failure modes in it are new, and each of the seven controls below exists to close one of them.

Control 1: allowlisted settlement addresses

A card payout goes to a bank account the PSP verified at onboarding. A stablecoin payout goes to an address. If the address is wrong, the funds are gone. The first control is therefore an allowlist: each merchant that opts to receive stablecoin registers one or more settlement addresses, the PSP verifies ownership with a signed message or a small test transfer, and the payout engine refuses to send anywhere else. Changes to the allowlist follow the same dual approval a bank detail change would. Most merchants will never register an address, because they will take fiat. The allowlist still governs the PSP's own treasury and off-ramp addresses.

Control 2: a contracted off-ramp

Merchants who take fiat need someone to turn the PSP's stablecoin into bank money. That is the off-ramp: a licensed provider that accepts USDC or EURC and sends a local currency credit to the merchant's bank, or to the PSP's bank for onward payout. The contract matters more than the technology. It should fix the conversion spread, the settlement cut-offs into each banking system, daily and per transaction limits, and what happens when a payment is blocked by screening. In the European Union the off-ramp will be an e-money institution or payment institution; in the United States a money transmitter or a bank. The licensing questions on the European side are covered in MiCA and PSD2 for stablecoin payments.

Control 3: netting pay-ins against payouts

A PSP that accepts stablecoin pay-ins and settles merchants in stablecoin has two flows that partly cancel. Netting them reduces the amount that must be converted, which reduces spread paid, and reduces the balance that sits idle. The mechanism is a daily, or intraday, netting window in which inbound stablecoin is applied to outbound obligations first, and only the residual is converted or funded. This is ordinary treasury practice. It is worth stating because many first implementations convert every pay-in to fiat and then buy stablecoin to fund every payout, paying the spread twice for no reason.

Control 4: a liquidity policy

Instant settlement needs funded wallets. The PSP must decide whether to prefund a stablecoin float sized to expected payouts, or to fund just in time from fiat via the issuer or a liquidity provider. Prefunding is simpler and faster but ties up capital and creates an asset to safeguard. Just in time funding is capital efficient but depends on the issuer's minting hours and the PSP's banking rails, which do not run on weekends. Most PSPs land on a hybrid: a float sized to cover weekends and holidays, replenished on business days. The policy should state the float size, who may change it, and the trigger for topping up.

Control 5: screening that satisfies the Travel Rule

Stablecoin transfers between regulated firms carry information obligations. The Financial Action Task Force's Recommendation 16, known as the Travel Rule, requires originator and beneficiary information to travel with the transfer. In the European Union the Transfer of Funds Regulation has applied to crypto asset transfers since 30 December 2024, with no minimum threshold for transfers between service providers. In practice this means the PSP must screen counterparties and addresses before sending, attach the required information through a Travel Rule messaging solution when the counterparty is another regulated firm, and have a documented process for blocked or returned transfers. The screening step is where instant settlement can stop being instant. Design it to run before the payout window, not inside it.

Control 6: reconciliation on unique references

A bank transfer carries a reference field. A stablecoin transfer does not, in any way a merchant's finance system can rely on. The reconciliation model therefore has to create uniqueness some other way: a distinct receiving address per merchant or per invoice, a memo field on chains that support one, or an internal ledger that records every outbound transfer against the obligation it settles before the transfer is sent. The last of these is the robust option, because it does not depend on chain features. The PSP's ledger is the record. The chain is the proof. The reporting that reaches the merchant looks like a card settlement report, with the transaction hash available on request for audit.

Control 7: a merchant experience that hides all of it

The merchant should see a faster settlement schedule and nothing else. Same onboarding, same bank account, same payout report, with a new option to be paid daily including weekends. The opt in to receive stablecoin should be a separate, deliberate step with its own terms, because it changes the merchant's accounting. The test of a good implementation is that a merchant's controller cannot tell, from the report, which rail the money took. That is also the test regulators and auditors will apply.

Sequence and timing

1. Contract the off-ramp and agree the conversion terms. Everything else depends on this.
2. Build the ledger and the reconciliation model. Do not send a single transfer before the ledger can explain it.
3. Stand up screening and the Travel Rule connection with the off-ramp and any settlement counterparties.
4. Set the liquidity policy and fund the float.
5. Run the allowlist and payout engine against internal accounts for a full month, including two weekends.
6. Offer daily fiat settlement to a small merchant cohort. Add the stablecoin opt in last.

A PSP with an existing payout engine and a willing off-ramp can run the first merchant cohort in one to two quarters. The long pole is rarely the chain integration. It is the off-ramp contract and the compliance sign off on screening. Scoping those two before any engineering starts is where independent advice saves the most time, because the provider selling the rail has no incentive to slow you down at the point where slowing down is correct.

North Settlements provides business advisory services, not legal or regulatory advice. Licensing, safeguarding and Travel Rule obligations differ by jurisdiction and by the entity's regulatory status. Confirm requirements with qualified counsel before designing settlement flows or holding stablecoin balances on behalf of merchants.