Payins
Take payment on the local rail. Every arrival is matched to the order that was waiting for it, and whatever cannot be matched automatically goes to an operator instead of being guessed at.
Payin & payout infrastructure
One integration for collecting payments and paying people back — on local rails, in local currency, with the routing, reconciliation and monitoring that keeps it running.
Live markets on request · new rails added on demand
Collecting and disbursing are the same problem seen from two ends, so they live behind one integration, one balance and one ledger.
Take payment on the local rail. Every arrival is matched to the order that was waiting for it, and whatever cannot be matched automatically goes to an operator instead of being guessed at.
Pay out to a local account, one at a time or by the thousand. A transfer too large for a single account is split across several and re-assembled into one settled deal.
Balances are kept per currency and backed by an append-only ledger, so the number on screen is always the sum of its history — and can be rebuilt from it at any time.
Every deal, transfer and adjustment is queryable by date, market and counterparty, and exportable straight from the filter you are already looking at.
Payin8 connects to local rails rather than pushing everything across one border. A market is three things, and adding one is a matter of putting them in place — not of changing how you integrate.
The way money actually moves where your customers are — the local transfer everyone already uses, not a wire that takes three days and an explanation.
Real accounts on that rail, with their own limits and working hours. Deals are placed across them automatically, and one that is unwell steps out of rotation on its own.
Whoever operates the accounts. The integration layer is pluggable, so a new one is a module on our side and nothing at all on yours.
Tell us the market and the rail, and we will tell you what it takes to open it.
A REST API and a webhook. You create a deal and get told when it moves — the routing, retries and provider quirks stay on our side.
// ask for a payout
POST https://api.payin8.io/deals
{
"direction": "out",
"currency": "<code>",
"amount": "<amount>",
"destination": { "account": "…", "name": "…" },
"reference": "<your order id>"
}
// and it tells you when it lands
{
"id": "…",
"status": "completed",
"receipt": "https://…"
}
Your order id is the key. Retrying a request never pays twice.
Signed, retried until acknowledged, and never out of order.
A deal is only completed once the money has actually moved and the proof is attached to it.
Everything the API does is visible — and fixable — in the admin, by the people running the desk.
Payments fail in ways ordinary software does not: half-sent, sent twice, sent and unrecorded. These are the parts that exist because of that.
Before a retry, the provider's own history is searched for a transfer of that amount to that account. A crash between the send and the record cannot turn into a second payment.
A deploy refuses new sends and waits for the ones in flight, so a restart never lands in the middle of a transfer.
Balances are recomputed from the ledger on demand and every difference is reported. Silent drift is not a thing that can happen quietly here.
Roles are limited by permission and by currency, so a desk running one market sees exactly that market — through the same screens everybody else uses.
Which direction, which market, what volume, and by when.
Keys, docs and a test market, usually the same week.
One endpoint and one webhook. Most teams are done in days.
Real accounts, real limits, and a desk watching them.
Tell us what you need to move and where. We answer with specifics.