One integration, every Tanzanian payment rail.
Mobile money and bank payments behind a single set of objects, with signed webhooks and idempotent requests. There's no sandbox — every request, from your first test key, reaches a real payment rail.
Approval (KYB) required before your first key works.
- id
- pi_01J9X4M3K2J7Y2Q8R6T1V5W3Z
- merchant_id
- 3fa85f64-5717-4562-b3fc…
- amount
- 25000.00
- currency
- TZS
- method
- mobile_money
- state
- Succeeded
- received
- 29 Apr 2026, 13:30
Illustrative event shape. The published reference is the source of truth.
Built for how you'd build it
Payment intents
One object follows a payment from created to succeeded, on whichever rail the customer chooses.
Webhooks
Signed events for every state change, retried on a fixed schedule (about three days) rather than forever.
Idempotency keys
Retry a request safely: the same key returns the same result, never a second charge.
Versioning
One current version. Send the version header to confirm it, or omit it and you get it anyway.
Test keys, real rails
Test keys (sk_test_) are accepted by the same live API and reach real payment rails — a sandbox environment does not exist yet. Treat every request as a real payment.
API reference
Authentication, payments, refunds, payouts, balance, checkout sessions and webhooks, with request and response shapes.