Status verification

Webhooks are the fastest way to learn about status changes. You can also read the current status at any time, and ask us to re-check an open payment with the provider.

How we verify payments

1. The provider sends a callback to our server. We check its signature and, for Cryptomus, its source IP. Callbacks that fail these checks are logged and ignored.
2. We then confirm the status with an authenticated server-to-server query to the provider before applying it.
3. Only after that do we update the payment, post the ledger entries and send your webhook.

Customer redirects, browser responses and checkout page visits never change a payment's status.

Read a payment

GET /payments/{id} · scope payments:read. Returns the payment as we currently know it. This makes no call to the provider.

curl https://gatway.hunario.com/api/v1/payments/pay_01j9x4... \
  -H "Authorization: Bearer $GATEWAY_SECRET_KEY"

Re-verify with the provider

POST /payments/{id}/verify · scope payments:write

For a live payment that is still open (created, pending, processing, confirming or on_hold) or refund_pending, this queries the provider and applies any verified change. For final or test-mode payments, it returns the stored payment unchanged.

• Limited to 6 calls per minute per payment. More return 429 rate_limited.
• Use it to recover from a missed webhook, not to poll. We already sync open payments in the background every few minutes.

Read a payout

GET /payouts/{id} · scope payouts:read. Processing payouts are synced with the provider in the background, and you receive a webhook when they reach a final state.

List and filter

GET /payments and GET /payouts accept these query parameters:

Results are newest first. To find a payment by your order ID, use GET /payments?reference=order-1001.

Isolation

A key can only read its own merchant's records in its own mode. Asking for another merchant's ID, or for a live ID with a test key, returns 404 resource_not_found, exactly as if the record did not exist.