Corporate Cards Funded by Stablecoins: How Authorisation and Settlement Work

How a stablecoin-funded corporate card works

A corporate card funded from a stablecoin treasury combines two separate payment layers. USDC or USDT is the company’s source of funds, while the purchase itself runs through the established card system involving the merchant, acquirer, card network and issuing programme.

At checkout, the merchant does not normally receive stablecoins or interact with a blockchain. It submits a conventional card authorisation request and is ultimately paid through its acquiring bank. Behind the card, the company may allocate stablecoins to a card balance, convert them into the card’s billing currency or use another funding structure offered by the programme.

This distinction determines what treasury teams must control and reconcile. A complete record may include an on-chain stablecoin movement, a stablecoin-to-fiat conversion, a card authorisation, a hold, a posted card transaction and an expense record. These events can occur at different times and have different reference numbers.

Where stablecoin conversion can occur

The term stablecoin-funded card does not identify a single conversion model. Finance teams should establish exactly when the company stops holding USDC or USDT and starts holding, spending or owing fiat currency.

The programme terms should explain the supported stablecoins, billing currencies, conversion point, exchange-rate source, fees and treatment of unused balances. Finance should also determine whether card availability depends on jurisdiction, company industry, employee location or onboarding eligibility.

From card tap to final settlement

1. Authorisation

When an employee presents a physical or virtual card, the merchant sends an authorisation request. The card programme evaluates the request against available funding and controls. Checks can include the per-transaction or periodic limit, merchant category code, card status, transaction channel and whether international or cash-withdrawal use is permitted.

An approval confirms that the transaction can proceed at that moment. It does not establish the final accounting amount. Finance systems should label an authorisation as pending rather than posting it immediately as an immutable expense.

2. Holds and available balance

An approved authorisation normally creates a hold. Three balances may therefore differ:

• Ledger balance: the balance after completed entries.
• Pending spend: authorised transactions that have not yet posted.
• Available balance: the amount left after relevant holds and other reservations.

Estimated authorisations are common when the final charge is not yet known. Hotels may include an allowance for incidentals, fuel stations may request a preset amount, and car-rental companies may reserve more than the expected rental charge. In markets where tips are added after the initial request, a restaurant’s final amount can also differ.

Limits must accommodate legitimate holds. If an employee’s remaining capacity is below a hotel’s room-plus-incidentals request, the authorisation can be declined even when the expected room charge fits within the budget.

If the merchant cancels or never completes the purchase, it may send an authorisation reversal or allow the hold to expire under the applicable card rules. The released amount increases available capacity. This is not a refund because no settled purchase is being returned.

3. Clearing and settlement

During clearing, the merchant submits the completed transaction. The cleared amount can equal, replace or adjust the original authorisation. The transaction becomes posted once it has completed the programme’s settlement process.

Purchase date, authorisation date and posted date may be different. Merchant submission practices, weekends, transaction type and card-network rules all affect timing. A stablecoin funding source does not eliminate these conventional stages or make the card transaction settle on-chain to the merchant.

Foreign-currency purchases can involve two conversions

A cross-border purchase can create both card-network foreign exchange and stablecoin funding conversion. For example, the merchant may charge in one currency, the card may bill in another, and the programme may convert USDC or USDT into the billing or settlement currency.

The final company cost can therefore reflect:

• the merchant transaction amount and local currency;
• the card-network or programme conversion into the billing currency;
• any foreign-exchange markup or transaction fee disclosed in the terms;
• the rate and fee used to convert stablecoins into fiat; and
• the timing difference between authorisation, clearing and conversion.

Dynamic currency conversion is a separate merchant-side choice. It allows the merchant or its payment provider to convert the purchase into the card’s home currency. Choosing local currency generally leaves the conversion to the card programme, but treasury should compare the actual programme and merchant terms rather than applying a universal rule.

For accounting, use the final posted card amount and the completed funding conversion. An authorisation notification is operational evidence, not necessarily the amount that should be booked.

Reversals, refunds and disputes are different events

A reversal cancels an authorisation before settlement and releases reserved capacity. A refund is a separate credit initiated after a purchase has posted. For foreign-currency spend, the refund can differ from the original billing amount because it is processed later or under different conversion conditions.

A dispute formally challenges a posted transaction, such as an unauthorised purchase or goods not received. Deadlines and evidence requirements depend on the card programme and network. Cardholders should report issues promptly and retain receipts, order confirmations, cancellation evidence and merchant correspondence.

Controls that matter before approval

Pre-spend controls are most effective when they are evaluated during authorisation. Useful controls include per-transaction and periodic limits, merchant category restrictions, separate cards by employee or purpose, and the ability to freeze a card without disabling the company’s wider treasury.

Stablerail supports virtual and physical corporate cards funded from a company’s own treasury, alongside card limits, merchant category controls, fiat conversion and exportable audit evidence. Availability and terms still depend on the relevant company, jurisdiction and programme.

Virtual cards can also separate recurring vendors or subscriptions. This makes it easier to identify the source of a charge, limit a vendor’s spending capacity and replace one credential without interrupting unrelated company expenses.

A practical reconciliation checklist

1. Record the stablecoin asset, amount, wallet or treasury reference and time of the funding movement.
2. Capture the conversion rate, fiat proceeds and separately disclosed fees when conversion occurs.
3. Track pending authorisations separately from posted expenses and general-ledger entries.
4. Match the final posted amount to the cardholder, merchant, receipt and business purpose.
5. Investigate differences between authorised, cleared and posted amounts instead of forcing an exact match.
6. Reconcile reversals and refunds as separate events linked to the original transaction.
7. Export evidence showing approvals, card controls, funding activity and completed transactions for period close.

Questions to resolve before issuing cards

Finance and treasury teams should document the operating model rather than relying on the phrase stablecoin card. Confirm which USDC or USDT networks are accepted, when conversion occurs, how pending holds affect limits, which rate and fees apply, and how refunds are credited.

Also verify supported billing currencies, employee locations, merchant categories, transaction channels and dispute procedures. The applicable programme terms—not the initial authorisation screen—should be the source of truth for pricing, eligibility and settlement treatment.

The central control principle is simple: do not treat the stablecoin transfer, card authorisation and merchant settlement as one event. Link them, but preserve each stage as a distinct treasury and accounting record. That produces a clearer available-balance view, more reliable expense reporting and stronger evidence at close.