A merchant requests 250 USDC on a specified network. The buyer sends 249, sends 260 or sends a token with a similar ticker on another chain. A blockchain transfer may have occurred in each case. Whether the order is paid depends on the merchant's acceptance policy and the payment system's actual ability to identify and use the funds.
These are ordinary checkout exceptions, not edge cases to leave until support receives a complaint. A payment integration needs an explicit relationship between the order, the accepted asset, the network, the amount, the deadline and the settlement condition. Otherwise fulfilment becomes a collection of manual guesses around incoming transactions.
Define the payment instruction precisely
The instruction should identify the network and token contract or equivalent asset identifier, destination, amount and quote expiry. The order currency and payment asset also need separate records. A dollar-denominated sale paid with a dollar-linked token is still an agreement about which asset and quantity discharge the amount due.
Circle's USDC contract directory lists identifiers for USDC on supported chains. Its structure makes an operational point: a ticker is not enough to identify the accepted token. The integration needs the correct network and asset identifier, verified against the provider's supported configuration.
Show those details before the buyer sends funds, in the payment link or wallet request where supported and in the visible checkout instructions. A warning after broadcast cannot prevent a route error. Avoid presenting unsupported networks as equivalent choices merely because their address formats resemble the accepted one.
Keep payment state separate from order state
An order may be awaiting funds, partially funded, funded but unconfirmed, ready for fulfilment or referred for review. A payment can have its own observation and settlement status. Compressing all of this into a paid flag makes it difficult to explain why goods were released or why an exception remains open.
BTCPay Server's invoice documentation, although focused on its own payment methods rather than a universal stablecoin standard, separates base invoice status from partial, excess and late-payment exceptions. It also distinguishes processing from settled. That separation is a useful design pattern: the amount received and the settlement condition answer different questions.
The merchant should define which combination permits fulfilment for each product. A low-value digital service and an irreversible shipment may justify different tolerances. The rule needs a named owner and a recorded version so support staff do not negotiate a new policy for every payment.
Underpayment needs a tolerance with a purpose
A short payment can result from a mistyped amount, withdrawal fees deducted by an intermediary or a buyer misunderstanding which fees it must pay. Measure the received token units against the requested units. Do not infer the missing amount from a wallet screenshot or the buyer's statement that the payment cost the expected total.
A merchant may allow a small shortfall because recovering it costs more than the discrepancy. Define the tolerance in explicit units or a stated formula, with a cap and the applicable asset. Applying a percentage without an absolute cap can create a large concession on a large order.
Where top-ups are accepted, bind additional transfers to the same order and retain the contribution of each one. Check the effect of quote expiry: does the buyer owe a fixed token quantity or a newly calculated balance in the order currency? The checkout must communicate the answer before requesting the second payment.
A hypothetical order paid in two transfers
Hypothetical example: a merchant quotes an order at 250 USDC for a limited payment window. A buyer sends 249.50 USDC because a service deducts a withdrawal fee. The merchant's published tolerance is 0.10 USDC, so the order remains partially funded rather than automatically fulfilled.
The buyer then sends another 1 USDC. The system records two separate transfers totalling 250.50 USDC and flags a 0.50 USDC excess. It does not create two paid orders or discard the first contribution. Fulfilment follows the settlement rule for the accepted payments, while the excess follows the merchant's separate resolution policy.
If the second transfer arrives after expiry, the expired quote remains part of the record. A reviewer may accept it under a defined rule, but the system should retain that decision and its reason. Replacing the original amount or deadline hides what actually happened and makes reconciliation harder.
Overpayment is a separate obligation to resolve
Receiving extra funds should not automatically increase an order quantity or create a credit balance. Those are business actions that require policy. Record the amount attributed to the sale separately from the excess under review, and ensure an automated accounting export does not silently treat the whole receipt as revenue.
The resolution may involve a customer credit or a return of funds, depending on the applicable policy and facts. That later transfer has its own authorisation and destination-verification requirements. The detailed outbound process is addressed in stablecoin payment refunds; checkout's job is to identify the discrepancy and preserve the evidence needed to resolve it.
Support staff need a view that shows all related transfers, fees, applied tolerances and previous decisions. Without it, two staff members can independently resolve the same excess. A case identifier and controlled state changes help keep customer service, finance and the payment provider aligned.
Wrong asset and wrong network are different failures
A transfer of an unaccepted token on the correct network is not an underpayment in the accepted token. It is a different asset. A transfer on a different network is a different route. Either may be visible to an explorer while remaining outside the merchant provider's supported recovery process.
Do not promise recovery simply because the destination has the same textual address on another chain. Control of keys, contract behaviour, custody arrangements and provider policy can differ. Collect the transaction identifier, network, asset identifier and destination, then use the supported investigation path. Keep the order unresolved until the acceptance policy has actually been met or an authorised exception is recorded.
Prevention is cheaper than uncertain recovery. Restrict offered choices to supported routes, test wallet requests and explain whether exchange withdrawals can arrive net of fees. Verify the resulting receipt against the expected asset identity rather than trusting names supplied by a token or a client browser.
Reconcile the order against the funds
Link each accepted transfer to one controlled allocation. Reconcile the order system, provider records and relevant wallet or settlement records, including partial and excess balances. A successful checkout page redirect is not evidence that the funds arrived, and a notification is not a substitute for resolving an inconsistent underlying payment record.
The asset-identity discipline in token identifiers and reference data belongs directly in checkout. The merchant's operating goal is a paid-order decision that can be explained after the event: which funds were accepted, under which terms, and which unresolved balance remains for someone to handle.