Keep detection and fulfillment separate
Circle Wallets distinguishes transaction initiation, confirmation and completion. Its documentation warns that a transfer visible in a block explorer may not yet have reached the confirmation threshold needed for COMPLETE.[3] These are Circle Wallets states, not universal labels for every gateway. The operational lesson is to map your chosen provider's states to explicit business actions. Showing a customer that a transfer was detected and shipping an irreversible order should not be the same transition.
Specify an asset and a network together
PayIn’s order guidance asks merchants to define accepted chains and tokens before launch.[8] Displaying only a ticker is therefore an incomplete instruction. Our recommendation is to show the network name, token identity as supplied by the provider, destination and amount together. Maintain the supported combinations as reviewed configuration rather than a hand-written list copied into several screens. Stripe’s page lists its own supported currencies and networks; those combinations do not establish what PayIn or another provider accepts.[1]
Do not promise one universal confirmation time
Circle explains that confirmation requirements vary by blockchain and that insufficient confirmations expose transactions to reorganizations.[3] Avoid turning a current vendor table into a timeless delivery promise. Define the threshold using the network, provider and type of goods you actually support, and review it when documentation changes. Customer copy should distinguish waiting for a transfer to appear, waiting for sufficient confirmation and an internal processing delay. A timer may inform a customer, but it should not itself authorize fulfillment.
Handle a stuck payment without guessing
Our suggested support sequence is to collect the order reference, network, asset and transaction hash through an appropriate support channel. Check that the transaction corresponds to the expected destination and asset, then compare the provider's state with your internal record. Never request a seed phrase or private key. If the transaction is on an unsupported network, do not promise recovery or tell the customer to send again until the first transfer has been investigated. An explorer screenshot is an aid, not an authorization to manually credit an account.
Write and rehearse the release rule
A useful policy states which authoritative record is checked, what finality state permits release, who may override it and what evidence an override preserves. Test a detected-but-unconfirmed payment, a provider outage and a notification received after an order expires. The expected result is a visible pending or review state, not a silent success. These are proposed operating controls rather than claims of a live implementation. Keep the review date alongside the policy so a future operator knows which network and provider assumptions were used.
Sources & currency
Continue reading
Two webhook deliveries must not become two fulfillments →
All field guides →