Build with the wallet API.
Holding and moving money is the part of your roadmap that never shrinks. This is the part you do not have to write. Your system calls the wallet, and the balances, the ledger and the withdrawal review sit on our side of the line.
The shape of an integration
Most of what your users will do in the wallet is done for them. What you build is the join between your product and six endpoints, in the order below.
Your application key is exchanged for a session token. Every call after that carries the token, so a key is never sent from a browser.
POST /api/authenticate
One call opens a wallet for a person in your product. You get a wallet ID back and keep it against your own user record.
POST /api/wallet/create
Your system asks for the amount. The person approves it in their wallet, and the amount can be divided between the parties as it is made. The parts must add up to the amount paid.
POST /api/transaction
The money goes back to the wallet it came from, where it can be spent again inside your product.
POST /api/transaction/refund
What a wallet holds, and the movements behind it for any period. The same records can be exported into a spreadsheet.
GET /api/wallet · GET /api/transaction
What it looks like on the wire
A wallet is opened once. After that, a payment is one call and an approval by the person who holds the money.
{
"reference": "your-user-4471",
"currency": "ZAR",
"type": "personal"
}
// the wallet is open and ready to hold money
{
"walletID": "PW_example123456",
"status": "active"
}{
"debitWalletID": "PW_example123456",
"amount": 200.00,
"description": "Order 4471",
"splits": [
{ "walletID": "MW_example123456", "amount": 160.00 },
{ "walletID": "HW_example123456", "amount": 40.00 }
]
}
// the wallet asks the customer to approve it
{
"status": "authentication-required",
"authentication": { "status": "pending" }
}What you get when we scope your integration
There is no public sandbox to sign up for. We scope the integration with you first, then hand over what you need to build against.
- Integration documentation. The endpoints above, their fields and their responses, written for the calls your product will actually make.
- A test-mode connected application. Your own application to build against, with wallets you can open, fund and empty without moving real money.
- A named person to work with. One person on our side who knows your integration, from the first call to the day it goes live.
What people ask before they build.
Is there a public sandbox?
No. There is no sandbox to sign up for. We scope the integration with you first, then set up a test-mode connected application and hand over what you need to build against.
How do we connect?
Three ways, and most products use all three. Open the wallet from your own system, let your system ask for a payment, and take the records out.
How long does an integration take?
We scope the timeline with you. It depends on which services you turn on and how your own system is built, so we would rather tell you after we have seen it than put a number here.
What do we store on our side?
The wallet ID, against your own user. Every later call names the wallet by that ID, so your system never has to hold a balance of its own.
Tell us what you want to build.
Describe what the wallet should do for your users and we will scope the integration with you.