A business can accept a customer’s USDC without keeping USDC in its treasury, but the conversion does not happen merely because a wallet address exists. The payment system needs a deposit destination configured to liquidate the stablecoin, a customer account where the resulting dollars land, and a separate transfer into the business-owned treasury.
Coinbase documents one version of this pattern in its current Settle customer stablecoins as USD integration guide. The example is specific to Coinbase Developer Platform Custodial Wallets. It shows the accounting boundaries that any comparable design needs to make explicit: who owns each account, when USDC becomes USD, how the deposit is matched to a customer, and when the business can treat funds as collected.
This article reflects the Coinbase documentation inspected on 31 October 2026. It explains the flow; it does not report a live integration or transaction test.
The flow has three balances, not one
The Coinbase recipe separates the payment into three stages:
- A customer sends USDC onchain to a deposit address.
- The deposit address is configured to convert that USDC to USD in the customer-owned account.
- The platform transfers USD from the customer-owned account to an entity-owned treasury account.
The distinction between the second and third stages is easy to miss. The liquidation address credits the same account to which it belongs. It does not sweep converted dollars directly into a different treasury account. The platform therefore needs a second transfer after it confirms the customer’s USD balance.
| Stage | Asset shown | Account owner | What has happened |
|---|---|---|---|
| Customer sends | USDC | Customer’s external wallet | Onchain transfer has been initiated |
| Liquidation completes | USD | Customer | USDC has been converted and credited |
| Treasury collection | USD | Business entity | Converted funds have moved to the platform treasury |
A status label such as “deposit received” is incomplete unless it names the stage and account.
A liquidation address is a rule, not just a wallet address
In the Coinbase example, the platform creates a crypto deposit destination on the customer’s account. It sets the target asset to USD and points the target account to the same customer account. Coinbase says USDC sent to that address is then converted to USD and credited to the account.
If the target is omitted, deposited USDC remains USDC. That makes configuration part of the payment’s economic meaning. Two addresses can receive the same token but produce different ledger outcomes.
The deposit address also belongs to a named network. Coinbase’s example uses Base. A merchant should not treat “send USDC” as complete payment instructions. The order needs the supported network, asset, destination address and reference. Sending a token on the wrong network can create a recovery problem even when the token symbol looks correct.
Our stablecoin payment guide covers the buyer-facing choice between an invoice address, payment link and checkout. The liquidation-address pattern concerns what the platform does after choosing a custodial settlement route.
Account ownership controls the next transfer
Coinbase’s recipe creates two accounts with different owners:
- the customer-owned account receives the converted USD
- the entity-owned treasury account collects the USD after a transfer
The platform passes the customer’s ID when creating the first account. It leaves the treasury account entity-owned. Coinbase warns that a treasury accidentally created as customer-owned can cause an “Invalid source and target pair” response when the platform tries to move funds.
That error is not simply a malformed amount. It means the ownership model is different from the intended flow. An operations team needs to record account ownership at creation time and verify it before processing money.
The current recipe also requires the entity to be onboarded with Custodial Wallets enabled and the customer to be onboarded and KYC-verified with the relevant custody and transfer capabilities. Those are product requirements in Coinbase’s implementation, not a universal rule for every self-custody payment.
When should an order be marked paid?
An onchain transaction, a converted customer balance and a treasury transfer answer different questions.
- Onchain deposit seen: has the stablecoin transfer reached the specified address?
- Conversion credited: does the customer account now show the expected USD?
- Treasury collected: has the USD transfer into the business-owned account succeeded?
- Bank payout available: can the business withdraw or wire the treasury balance through its configured payment method?
The Coinbase recipe tells production applications to react to the deposit webhook. It then checks the customer’s USD balance before transferring funds to the treasury. A merchant should choose the stage that controls fulfilment and name it in its order-state model.
For a digital product with low reversal risk, the business may decide that confirmed conversion is enough. A regulated platform or a seller of high-value goods may require treasury collection and additional compliance checks. The documentation does not set that business policy.
Webhooks should trigger a read of the authoritative payment or balance state. They should not be treated as the ledger themselves. Store the provider event ID, customer reference, asset, network, amount, destination and resulting transfer ID so that a repeated webhook does not create a second treasury movement.
Reconciliation needs both blockchain and platform records
The onchain transfer hash proves that a transaction was included on a network. It does not by itself show the business’s final USD balance. The custodial platform maintains the conversion and account-transfer records that connect the deposit to the treasury.
Coinbase recommends attaching metadata, such as a reference or customer ID, to transfers and querying transfer history for reconciliation. A practical ledger row should keep:
| Field | Reconciliation use |
|---|---|
| Customer or order reference | Links the deposit to the commercial obligation |
| Deposit address and network | Identifies the onchain destination |
| Transaction hash | Locates the stablecoin transfer |
| USDC amount received | Records the incoming asset |
| USD amount credited | Records the conversion result |
| Customer account ID | Shows where converted funds first landed |
| Treasury transfer ID and status | Shows whether the business collected the USD |
| Timestamps for each stage | Separates blockchain, conversion and transfer delays |
Fees and conversion terms need their own fields. The Coinbase recipe demonstrates the flow but does not supply one universal exchange rate or fee for every customer, account or production arrangement.
What “no stablecoin on the balance sheet” means here
Coinbase describes the outcome as incoming USDC being automatically converted to USD, with no stablecoin held on the entity’s balance sheet. That statement depends on the documented account structure: the customer-owned account receives the converted USD, then the platform moves USD into the entity-owned treasury.
It does not mean the business can ignore the stablecoin leg. The deposit network, token contract, transaction hash and conversion record still matter for payment operations, disputes and reconciliation. Accounting treatment also depends on the legal arrangement and jurisdiction. A product description does not replace professional accounting analysis.
For a different route, a business may deliberately hold USDC in a wallet and convert later. That creates a different custody, pricing and treasury-risk model. Our stablecoin reserve explainer looks at issuer and redemption mechanics, while gross versus net settlement explains why the timing of final obligations matters.
Source
- Coinbase Developer Platform: Settle customer stablecoins as USD, inspected 31 October 2026
