Introduction

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:

1. Authenticate with the key required by the endpoint.
2. Create a resource using your own unique reference or idempotency key where supported.
3. Store the Tsara identifier and your business reference together.
4. Present any returned payment instructions to the customer.
5. Process signed webhooks as the primary asynchronous notification channel.
6. 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_token returned 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

1. Authentication
2. Response Format
3. Errors and Status Codes
4. Quickstart
5. The product-specific section you intend to integrate
6. Webhooks and API Keys