A payments API that is boring in the right ways.
Predictable REST resources, idempotency on every mutating call, signed and retried webhooks, a normalised error model and a sandbox where you can reproduce the cases that matter before you go live.
The qualities that matter in a payments API are unglamorous
Payment integrations fail on the edges: a timeout that might have charged the customer, a webhook that arrived twice, an error you cannot classify, a decline you cannot reproduce in testing. The API is designed around those cases first, because they are what actually costs engineering time once you are live.
From request to reconciled
Authenticate
Scoped API keys per environment. Keys are server-side only, and test and live are separate credentials against separate data.
Create a payment
One POST creates a payment for any method. Method-specific differences are handled behind the same resource shape.
Handle the next action
The response tells you what to do next: redirect, present a challenge, or nothing at all because it is done.
Receive the webhook
The authoritative result arrives as a signed webhook. Your handler verifies the signature and processes idempotently.
Reconcile
Look up any payment, refund or payout by your own reference, and pull the same data that appears in reporting.
What payments api covers
REST API
Predictable resources, standard verbs and JSON. Nothing bespoke to learn beyond the payment model itself.
Payment creation
One endpoint creates a payment for cards, wallets, bank methods and local methods.
Payment status
A single normalised status model across every method, so your state machine does not branch per provider.
Webhooks
Signed, retried server-to-server events with an explicit event type on every message.
Callbacks & redirect flows
Return URL handling for redirect-based methods, with the browser return never treated as proof of payment.
3DS handling
Authentication steps are surfaced as a next action your integration handles consistently.
Tokenization
Exchange card data for a token and charge the token later, so you never store a card number.
Refund API
Full and partial refunds against the original payment, with their own status lifecycle and webhooks.
Payout API
Programmatic payout initiation where payouts are enabled on your account, including batches.
Transaction lookup
Retrieve any payment, refund or payout by Flowa Pay identifier or by your own reference.
Idempotency
Idempotency keys on mutating requests, so a retry after a timeout returns the original result instead of charging twice.
Authentication
Scoped, rotatable server-side API credentials, separated by environment.
Error handling
A normalised error model with stable machine-readable codes, a human-readable message and an explicit retryable flag.
Sandbox
A full test environment with deterministic triggers for approvals, declines, authentication and asynchronous completion.
Why teams choose it
- Safe retries. Idempotency keys mean a network timeout cannot become a double charge.
- One state machine. A normalised status model across every method keeps your integration simple as methods are added.
- Reproducible edge cases. The sandbox can produce the declines and authentication paths you need to handle.
How you connect
- Hosted payment page: a redirect and a webhook handler.
- Embedded checkout: drop-in fields on your own page.
- Server-to-server: full control through the API.
What you can accept
- Every method enabled on your account, through one payment resource
Availability depends on merchant category, jurisdiction, underwriting and the applicable payment or acquiring partner.
How it is controlled
- API credentials are server-side only and scoped per environment.
- Webhook payloads are signed so your server can verify origin.
- Tokenization keeps card data out of your systems on hosted and embedded integrations.
Flowa Pay provides the payment technology and orchestration layer. Acquiring, scheme settlement and regulated payment services are provided by licensed acquiring and payment partners under their own authorisations.
Server-to-server payments
Server-to-server gives you total control of the interface: your form, your validation, your design, with payment details submitted directly from your server through the API. It is the most flexible integration and carries the largest compliance obligation, because card data passes through systems you operate. Choose it when the checkout experience is a core part of your product and you are prepared to carry that scope. Where you want the control without the scope, embedded checkout keeps the fields in an isolated payment surface on your own page.
- Full control of the checkout interface and validation
- Direct API submission from your server
- Largest compliance scope: card data passes through your systems
- Embedded checkout is the middle option: your page, isolated fields
Webhooks
Webhooks are the authoritative channel. A browser redirect can be interrupted, a tab can be closed and a mobile connection can drop, so no integration should treat the customer's return as confirmation. Every webhook carries an event type and a signature. Verify the signature, process idempotently because retries can deliver the same event more than once, and respond quickly: acknowledge first and do your own work asynchronously.
- Signed payloads, verified with your endpoint secret
- Automatic retries with backoff until acknowledged
- At-least-once delivery, so handlers must be idempotent
- Events for payment, refund, payout, settlement and dispute lifecycles
Sandbox
The sandbox is a complete, separate environment with its own credentials and its own data. It is built for reproducing the cases that are hard to produce on purpose in production: a specific decline reason, a 3-D Secure challenge, an asynchronous method that completes minutes later, a webhook retry after a failed delivery. Build against those cases before go-live rather than discovering them in production.
- Separate credentials and data from live
- Deterministic triggers for approval, decline and authentication outcomes
- Asynchronous and redirect method simulation
- Webhook delivery and retry testing
Common questions
Retry it with the same idempotency key. You receive the original result rather than creating a second payment.
Yes. Delivery is at least once, so handlers must be idempotent. Each event carries a stable identifier for de-duplication.
No. Use it for the customer's experience only. The webhook is the authoritative result.
Yes, with separate credentials and data, and deterministic triggers for the outcomes you need to test.
Ready to put payments api to work?
Talk to our team about your corridors, your volumes and the routes that fit your business.