Meet us at conferences around the world
SiGMA Europe
How to integrate a payout API for PSPs and platforms without the surprises. The go-live sequence, single vs mass payout API calls, the status and reconciliation traps, and why paying money out is a different job from taking it in.
By Daniel Karpilovsky, Head of Success, Payneteasy
The question I get on every withdrawal kickoff is the same: «we already take card payments, how different can sending money out be?» Here is the honest answer. Different enough that it has its own failure modes, and the teams that ship payouts smoothly are the ones who plan for those before go-live, not during it. Going live is a sequence, not a switch.
If you build marketplaces, platforms, or anything that pays people, this is your guide. Not a specification dump, a practical walk-through: what a payout API does, where integrations actually stumble, and the order to do things in so your first real payout is boring, which is exactly what you want.
A payout API lets PSPs and platforms send mass payouts to sellers, merchants and contractors automatically. This guide covers the go-live order and the traps to plan for.
Talk to a payment expertA payout API is how your software sends money out, to sellers on your marketplace, contractors, winners, refunds, automatically and at volume, instead of someone approving each transfer by hand. If a pay-in API is the till at the front of the shop, a payout API is how you pay everyone at the back. Same business, opposite direction, and the direction matters more than people expect.
This is the mistake I correct most often. Teams assume paying out is just taking a payment with the sign flipped. It is not. When you collect, a decline is the bank's problem and the customer tries again. When you pay out, the money is leaving your account, so a mistake is your problem, and often irreversible. Status finality, retries, and reconciliation all behave differently. Respect that, and the rest is straightforward.
Do these in order. The order is the whole trick.
Skip step 3 or 4 and you will feel it in production, usually on a Friday.
Most platforms need both. The design difference is how you read the result.
| Single payout | Mass (batch) payout | |
|---|---|---|
| Use case | One transfer on demand | Many recipients in one call |
| What you submit | One recipient | A batch of recipients |
| What you must handle | One status | Per-recipient status, partial success |
| Common trap | Assuming submitted means settled | Treating a batch as all-or-nothing |
| Reconciliation | One line to match | A file to match, per recipient |
Here is the unglamorous middle, the part that decides whether go-live is calm or not. A recipient's details are slightly wrong and the payout bounces days later, not instantly. A batch half-succeeds and a system that expected all-or-nothing loses track of who got paid. A retry without an idempotency key pays someone twice. None of these are exotic; they are the ordinary failure modes of paying money out, and every one of them is cheap to handle before launch and expensive to handle after. Plan the sequence, and the failure modes stop being surprises.
If you are a PSP, or a platform that pays out on behalf of merchants, the payout API stops being a single integration and becomes infrastructure. A mass payout API has to accept thousands of recipients in one call, return a status for every one of them, and survive a partial failure without anyone being paid twice.
Three things separate a payout API for PSPs from a one-off integration: per-recipient status and reconciliation across the whole batch, idempotency on every request so a retry is always safe, and routing across banks and corridors so one slow rail does not hold up the rest. For the wider picture of moving money to third parties across borders, read how to pay third parties globally with ease, and for the terminology see what a payout is.
Payneteasy's payout API is built for the messy reality, not the happy-path demo: per-recipient status, idempotency, mass payouts with partial-success handling, and reconciliation you can actually trust. And because it sits inside an orchestration platform, payouts can route across banks and corridors the same way card payments do. We get you live, then we get you winning, in that order. Start in the sandbox; the goal of your first real payout is to be completely uneventful.
Practical next step: read the platform overview and request a sandbox key, then run a single test payout end to end before you design the batch. Boring first, scale second.
Building payouts for a PSP or a marketplace? Talk to a Payneteasy payment expert for a demo of the mass payout API and sandbox access.
A way for your software to send money out to people, sellers, contractors, winners, refunds at scale, automatically, instead of approving each transfer by hand. It is the paying-out side of payments, separate from collecting card payments in.
A first sandbox payout can take hours. A production-ready integration, with status webhooks, idempotency and reconciliation handled, usually takes days, not months, when the docs and a sandbox are in front of you.
An idempotency key lets you safely retry a request without sending the same payout twice. For paying money out, that safety is not optional, networks fail mid-request, and a double payout is real money gone.
Yes. A mass payout lets you submit a batch in one call. The thing to design for is partial success: some succeed, some need a retry, and your system must read per-recipient status, not a single batch result.
Through status webhooks, not by assuming. A payout moves through states, and you reconcile against the final settled status, not the moment you submitted it.
Yes. Payneteasy's mass payout API lets a PSP or platform submit a batch of recipients in one call and read per-recipient status, with idempotency keys so a retry never pays twice. Talk to our team for a demo and sandbox access.
Thank you for reaching us. Your request has been sent successfully. We will get back to you as soon as possible.
Message was not sent
