The gateway API
A payments API whose documentation is generated from the same table that serves the requests, so the reference can never describe an endpoint the platform does not have.
Developers integrating payments into a shop, a billing system, a marketplace, a school platform or an institution’s own software.
Part of the platform itself: it is present wherever BitriPay runs.
The problem
Integrating payments usually means reading documentation that was true last quarter, discovering the real behaviour from error messages, and building retry logic because the provider’s idea of idempotency is a suggestion.
How it works
- Create a payment intent with an amount, a currency and your reference.
- Send the customer to its checkout URL, or render its QR payload.
- Act on the signed webhook when the payment succeeds or settles.
- Reconcile against the statement; every object carries the reference you gave it.
What you can check
Facts about the running platform rather than adjectives. Each one is visible in the product, the API reference or the ledger.
- The OpenAPI document and the human reference are generated from one operation table, so they cannot disagree.
- Every money-moving POST requires an Idempotency-Key: a replay returns the original object, and the same key with a different body is refused.
- Webhooks are signed twice — HMAC-SHA256 over the timestamped body, and an Ed25519 platform signature — and retried on a published schedule across 24 hours.
- Errors carry a descriptive code and a stable numeric family, so software can branch on the family without parsing English.
- A sandbox with documented magic numbers drives the real state machine, including the failures, without touching an operator.
What it costs
The API costs nothing to use. You pay for the payments it moves, at the rate on your account.
Questions
How do I test a failure?
The sandbox publishes magic numbers that drive specific outcomes — success, insufficient funds, a timeout that later succeeds — through the same attempt machine production uses. You test the unhappy paths without an operator and without pretending.
What happens if my server retries a payment?
Send the same Idempotency-Key and you get the original object back rather than a second payment. The same key with a different body is refused outright, which turns a dangerous bug into a readable error.
How do I know a webhook is really from you?
Each delivery carries a timestamped HMAC over the exact body using your endpoint secret, plus an Ed25519 signature from the platform key you can fetch from the key registry. Verify either or both, and reject anything older than five minutes.
Read next
Signed webhooks
Deliveries you can verify two independent ways, replay yourself from the dashboard, and receive on a built-in inbox if you have nowhere to host an endpoint yet.
Connected accounts
Create your customers’ merchant accounts by API, take payments for them with your own key, keep your fee — and hand the account over whenever they are ready, keys and history intact.
Hosted checkout
A checkout that offers the payer only the rails that can actually complete their payment, decided at the moment they arrive rather than listed hopefully on a page.