Handle underpayment and overpayment
On-chain, a buyer can send slightly less or slightly more than the invoice. The webhook surfaces this as underpaid or overpaid instead of settled, with the actual amount, so you can resolve the difference deterministically rather than guessing.
- A verified payment webhook endpoint
- An open invoice id (in_..) to reconcile against
1Branch on the webhook status
After verifying the HMAC, switch on status. underpaid and overpaid both carry the amount_usd actually received so you can compute the delta against the invoice price.
> { "invoice": "in_8fK2", "status": "underpaid", "amount_usd": 41 }2Resolve an underpayment
For underpaid, keep the invoice open and ask the buyer to send the remaining balance to the same pay-to address. The next inbound transfer settles the invoice and flips status to settled.
3Resolve an overpayment
For overpaid, fulfil the order and return the excess with a partial refund against the invoice. A C2 write records the refund against the invoice id.
curl https://api.1st-node.com/v1/payments/invoices/in_8fK2/refund \
-H "Authorization: Bearer sk_live_..." \
-d '{"amount_usd":8}'4Stay idempotent on retries
Webhook delivery is idempotent, so the same underpaid or overpaid event can arrive twice. Key your handler on the invoice id and status so a redelivery never issues a second refund or double-credits the order.
常见问题
Does an underpaid invoice ever settle on its own?
Yes. The invoice stays open at the same pay-to address; once the cumulative received amount reaches the price, the status flips to settled and you receive a fresh webhook.
Can a redelivered overpaid event trigger two refunds?
Not if you dedupe. Deliveries are idempotent — key on the invoice id so a repeated event is recognised and skipped.
继续阅读
充值、拿密钥、上线。
自助开通。支持加密货币或银行卡。按额度计费——重型原语更贵,简单调用很便宜。
获取 API 密钥