Use cases / Marketplaces and platforms
Pay sellers and drivers as the work gets done.
Create payouts from your own software with the API, and hear about every result by webhook, without paying anyone by hand.
Sound familiar?
When thousands of people earn on your platform, paying them by hand does not scale, and support gets flooded with "where is my money?".
Payouts become a full-time job
Every week someone exports earnings, builds a list and sends payments. As you grow, that person cannot keep up, and the list is never quite right.
"Where is my money?"
When a seller is not paid, they message support. Support asks finance. Finance searches through transfers. Nobody has one place with the answer.
Retries cause double payments
A timeout in your own system, a retry, and a driver is paid twice. Or a batch that failed halfway is run again from the top.
You cannot test safely
Building payouts against real money is risky, so the integration is rushed, and the first real failure happens in front of customers.
How it looks in practice
An example weekly payout run
This is an illustration of how a delivery platform might pay its riders each week with the API. It is not a real customer.
- 1Your developer
Build it in test mode first
Create test credentials, add fake money, and run the whole flow against a separate test database. Nothing in test mode can touch real money or real people.
- 2Your server
Sign in with OAuth
Your server trades a client ID and secret for a token that lasts an hour. The credentials carry only the scopes you gave them, and can be revoked at once.
- 3Your server
Send the week's earnings as one batch
Each rider is a person with a verified account. Your system creates a batch with an Idempotency-Key, so a retry returns the same batch instead of creating a second one.
- 4Finance
Approvals follow your rules
A batch made through the API follows the same rules as one made on the website: someone other than the credentials' owner approves it, by the amounts and steps you have set.
- 5Your server
Hear about every result
Signed webhooks tell you when each payment succeeds or fails, with the reason. Your app updates the rider's earnings screen, so support is not asked.
The people, figures and screens in this walkthrough are illustrations built from demo data. They are not real customers.
Before and after
What changes when payouts stop being a chore.
Who does what
Everyone has a clear part, and no one holds all the keys.
Roles decide who can prepare, who can approve and who can only look. You choose who has which.
Developer
Creates credentials, builds and tests the integration, and watches the webhook delivery log.
Finance
Funds the balance and approves batches under the rules you set.
Support
Answers sellers from the payment status and reason, instead of asking finance.
Operations lead
Holds the admin role: manages team access, credentials and approval rules.
Built in, not bolted on
The protections that matter most for this.
These are part of how every payout works, not extras you switch on.
Idempotency on every create call
Sending the same key and the same request returns the first answer, marked as a replay. A different request on the same key is refused.
Scopes and instant revoking
Credentials can be limited to reading balances, or to creating batches. Revoking them stops every token already issued.
Limits per credentials
Calls are limited for each set of credentials, so one busy integration never slows another.
Signed webhooks with retries
Every event is signed. If your server is down, we retry with longer waits, and you can resend any delivery from the log.
Practical questions
What people ask before they start.
Something not covered here? Ask us, and we will answer plainly.
Is there a sandbox?
Yes. Test mode has its own database and a pretend bank. Add fake money with one call, and choose the outcome of a payment by the last digits of the account number.
Can we pay many thousands of people?
A batch holds up to 1,000 payments. Create as many batches as you need, each with its own key.
How do we know a payment failed, and why?
You get a payout.item.failed webhook with a failure code and reason, and you can fetch the batch at any time to see every payment's status.
Does a batch created by the API still need approval?
Yes. It follows your approval rules, exactly like a batch made on the website. That is deliberate: software should not be able to move money with no one watching.
Which languages are supported?
It is a plain HTTPS API with JSON, so any language works. The docs show curl, JavaScript, C# and Python.
Also on Tranzaq
The same flow, for other kinds of payout.
Payroll
Pay your whole team on the day, without a queue at the bank.
Learn moreSchools and institutions
Refunds, stipends and supplier payments with a paper trail.
Learn moreNGOs and programmes
Get support to beneficiaries quickly, and prove it reached them.
Learn moreAgents and commissions
Pay your agents every week, accurately.
Learn moreGet started
Stop paying your platform's people by hand.
Create test credentials and make your first payout against fake money this afternoon.
