Payments

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-ключ