Designing a stablecoin checkout that does not break order state
When teams add USDT or other stablecoin payments to a store, the first implementation usually looks simple: show a wallet address, wait for a transaction, then mark the order as paid. That works for a demo. It. . .
When teams add USDT or other stablecoin payments to a store, the first implementation usually looks simple: show a wallet address, wait for a transaction, then mark the order as paid. That works for a demo. It breaks down in production. The hard part is not generating a payment request. The hard part is keeping order state honest when real customers behave like real customers:they choose the wrong networkthey send a partial amountthey pay after the order expiresthey send two transactions instead of onethey close the checkout page and come back lateryour webhook is delayed or retriedyour store needs a clean answer: pending, paid, expired, underpaid, or overpaidA practical stablecoin checkout needs a small state machine, not just a QR code. The pattern I preferFor each checkout session, create one payment intent with:the requested amount and settlement currencythe chain/network expected for the transferthe receiving addressan expiry timestampthe merchant order referencea server-side status fieldThen treat blockchain detection as an input to the state machine, not as the state machine itself. For example:The customer opens checkout and the order is pending. A matching transaction arrives before expiry and the order becomes paid. A smaller matching transaction arrives and the order becomes underpaid. A transaction arrives after expiry and the order needs manual review or refund handling. The webhook retries the same transaction and the system ignores the duplicate. That last point matters. Payment systems should be idempotent by default. A retry should never create a second successful order. Where merchants usually get stuckMost small merchants and SaaS founders do not want to run chain monitors, maintain wallet address logic, write webhook retry handling, or explain network mismatches to customers. They want a checkout link and a clean payment result. That is the gap I am trying to solve with ChainPay. ChainPay is a lightweight stablecoin checkout for stores, SaaS products, WooCommerce sites, Telegram businesses, and AI agents. The goal is simple: let a merchant accept USDT payments without building payment infrastructure from scratch. Current focus:simple checkout linksUSDT payment collectionmerchant dashboardWooCommerce use casesAPI-friendly checkout for AI agents and SaaS appsI am currently collecting early feedback before launch. Product Hunt pre-launch page:https://www. producthunt. com/products/chainpay?launch=chainpayWebsite:https://chainpay. to/If you have built crypto checkout, stablecoin billing, WooCommerce payments, or agent payments, I would be interested in what failure cases you think every checkout should handle from day one.