Tsara gives businesses one API for collecting payments, moving NGN, working with stablecoins, paying bills, and embedding customer-facing payment experiences.
Instead of integrating separate systems for every payment rail, your application can create a Tsara resource, present the returned instructions to the customer, and follow the resource until it reaches a final status.
What you can build
- hosted checkout experiences with bank-transfer and crypto payment options
- reusable payment links with custom customer fields
- reserved accounts for long-lived customer or business collections
- temporary virtual accounts for transaction-specific collections
- fiat transfers, scheduled payouts, and transaction refunds
- stablecoin onramp, offramp, wallet, address, and transfer flows
- airtime, data, cable TV, and electricity payments
- embeddable ramp widgets for onramp, offramp, and crypto-funded bills
Choose the right product
| Requirement | Recommended surface |
|---|---|
| Collect a payment for an order | Checkout |
| Share a reusable payment page | Payment Links |
| Give a customer a persistent NGN account | Fiat - Reserved Accounts |
| Collect one exact payment into a temporary account | Fiat - Virtual Accounts |
| Send NGN to one bank account | Fiat - Transfers |
| Send one or many asynchronous disbursements | Fiat - Payouts |
| Convert NGN to stablecoin | Stablecoin - Onramp |
| Convert stablecoin to NGN | Stablecoin - Offramp |
| Sell airtime, data, cable, or electricity | Bills |
| Add a configurable ramp interface to your product | Ramp Widget |
How integrations work
Most Tsara flows follow the same pattern:
- Authenticate with the key required by the endpoint.
- Create a resource using your own unique reference or idempotency key where supported.
- Store the Tsara identifier and your business reference together.
- Present any returned payment instructions to the customer.
- Process signed webhooks as the primary asynchronous notification channel.
- Use the relevant status or fetch endpoint as a reconciliation fallback.
Payment and payout operations may begin in a non-final state. Do not treat a successful create response as proof that money movement has completed; always inspect the resource status.
Authentication at a glance
- business server-to-server endpoints use a business secret key
- the documented checkout-create flow uses the business public key; all protected checkout reads and updates use the business secret key
- ramp widget bootstrap uses a widget public key
- ramp runtime requests use the short-lived
session_tokenreturned during session creation - incoming webhooks use a separate signing secret for signature verification
Never expose a business secret key or webhook secret in browser or mobile application code. Continue with Authentication before making your first request.
Recommended reading order
- Authentication
- Response Format
- Errors and Status Codes
- Quickstart
- The product-specific section you intend to integrate
- Webhooks and API Keys