How a USDC Invoice Actually Settles Onchain

A USDC invoice represents a request for onchain payment, but the steps from invoice creation to final stablecoin settlement are often misunderstood. Many teams expect familiar card-like flows. Onchain payment mechanics differ at every stage: initiation, signature, settlement, and reconciliation. Here, I’ll break down what actually happens when a customer pays a USDC invoice, with a worked example and failure modes you should expect.

What Does an Onchain USDC Invoice Do?

An onchain invoice is a structured request for payment in USDC, usually containing the requested amount, recipient settlement address, due date, and a unique invoice ID. The key difference from fiat invoicing is that the payer must actively sign a blockchain transaction from their wallet to transfer USDC. Nothing moves until this cryptographic approval is given and mined.

A typical USDC invoice might look like:

• Amount: 250 USDC
• To: 0xMerchantAddress
• Due: 2024-07-10
• Chain: Base
• Invoice ID: inv-2024-07-001

The payment request is offchain. The settlement is onchain.

Customer Payment Flow: Step by Step

1. The Invoice is Presented

The merchant presents the invoice, often as a web-based checkout, a payment link, or within a customer portal. There is no onchain record until the payer interacts. The invoice includes the recipient address and the amount in USDC.

2. Customer Signs a USDC Transfer

When the customer chooses to pay, their wallet prompts them to sign a transaction. This transaction is a call to the USDC contract’s transfer method, moving funds from the customer’s address to the merchant’s.

Example: - Customer: 0xCustomerWallet - Merchant: 0xMerchantAddress - Amount: 250 USDC - Chain: Base

The transaction submitted:

// ABI encoded call to USDC token
transfer(0xMerchantAddress, 250000000) // USDC uses 6 decimals

The customer’s wallet signs and broadcasts this transaction. No private key ever leaves the wallet. The merchant does not see or handle any sensitive key material.

3. Blockchain Settlement

Once the transaction is mined, USDC moves from the customer’s address to the merchant’s. The USDC contract on Base emits a Transfer event. This is final. The merchant’s balance increases, the payer’s decreases.

There is no escrow, no third-party custody, and no chargeback. The only participants are the customer’s wallet, the USDC contract, and the merchant’s address. If the transaction fails (for example, due to insufficient funds or gas), nothing settles. The invoice remains unpaid.

4. Merchant Reconciliation

The merchant monitors the blockchain for settlement. This can be by polling for the Transfer event or using a webhook provider. Once the required amount is received at the settlement address and matches the invoice ID or reference, the invoice is marked as paid in the merchant’s system.

A Worked Example: Paying a USDC Invoice on Base

Let’s follow Alice, who needs to pay a 250 USDC invoice to Acme SaaS on Base. The invoice details:

• Amount: 250 USDC
• Settlement address: 0xAcmeSaaS
• Invoice ID: SaaS-2024-07-10-42

1. Alice visits the payment link.

She connects her wallet (0xAlice) and reviews the request.

2. Alice’s wallet prompts for a USDC transfer:

• Recipient: 0xAcmeSaaS
• Amount: 250 USDC (250,000,000 in smallest units)
• Gas: 0.0005 ETH (for the transaction fee on Base)

3. Alice signs and sends the transaction.

Onchain, the transaction is:

transfer(0xAcmeSaaS, 250000000)

4. The transaction is included in block 12,345,678.

• Alice’s USDC balance decreases by 250 USDC.
• Acme’s USDC balance increases by 250 USDC.
• A Transfer event is emitted:

{
  "from": "0xAlice",
  "to": "0xAcmeSaaS",
  "value": "250000000"
}

• Alice pays the gas fee, settled in ETH (or the native token for the chain).

5. Acme’s backend detects the payment.

• The system matches the incoming transfer against SaaS-2024-07-10-42.
• The invoice is marked paid.
• Acme can now provision service or deliver goods.

Failure and Edge Cases

Insufficient Funds

If Alice tries to pay but has only 100 USDC, the transaction will revert. Nothing moves. The invoice remains open.

Gas Fee Issues

If Alice has USDC but lacks ETH for gas, her wallet cannot submit the transaction. The invoice stays unpaid. This is a common source of support requests.

Wrong Recipient Address

If Alice manually enters the wrong address, USDC will settle there. The transaction is final once confirmed. No recall, no chargeback. The merchant cannot reverse this.

Partial Payments

If Alice sends only 200 USDC, the merchant receives funds, but reconciliation will show an underpayment. The invoice remains open or partially paid, depending on the merchant’s policy.

Onchain Settlement is Atomic and Final

The core difference from card rails is atomic settlement. When the USDC transfer is confirmed, the merchant has funds, and the customer cannot reverse the payment. There are no pending authorizations or delayed settlements. The only exception is a blockchain reorg, which is rare on stable, high-liquidity chains like Base, Ethereum, or Polygon. Most merchants wait for a few confirmations before delivering service.

How We Handle This at Reclack

At Reclack, we build billing automation for USDC payments that follows this exact flow. We never touch customer or merchant funds. Each invoice is presented with the amount and recipient address, and the customer signs a transfer from their own wallet. Once the payment settles onchain, it is final. We monitor for the transfer event and mark invoices paid in real time. No one is ever asked for a seed phrase. Our platform is live for Base, Ethereum, and Polygon. Learn more about our approach at reclack.com.