Developers
Create with a POST and an idempotency key, read by id, list with cursor pagination, and receive state changes by signed webhook. Learn the pattern once and it holds across every resource.
Resources
Every resource follows the same conventions: create with a POST and an idempotency key, read by id, list with cursor pagination, and receive state changes by signed webhook.
Create a payment, let routing pick the acquirer or method, and receive the outcome by webhook. Retries and cascades happen behind the same payment id.
| Method | Path | What it does |
|---|---|---|
| POST | /v1/payments | create and authorise |
| POST | /v1/payments/{id}/capture | capture an authorisation |
| POST | /v1/payments/{id}/refund | full or partial refund |
| GET | /v1/payments/{id} | current state and route |
Conventions
Every create accepts an idempotency key, so a retried request after a timeout cannot double-charge or double-pay.
Events are signed and timestamped. Verify before you trust, and expect at-least-once delivery with safe replays.
Lists page by cursor rather than offset, so reporting jobs stay consistent while new records arrive.
Errors carry a machine-readable code, a human-readable message and, where relevant, the decline reason and route.
Breaking changes arrive under a new version. Your integration keeps working while you plan the upgrade.
Sandbox mirrors production behaviour, including declines, holds and webhook sequences you need to handle.
Next step
Tell us what you are building and who is building it. We will provision sandbox credentials, share the reference and put an engineer on the thread.