PesaBridge

Developer API

Collect & disburse with a few calls.

A clean, Daraja-style API: OAuth2 client-credentials, a sandbox, prompt-to-pay and signed, retried webhooks — integrate collections and payouts in an afternoon.

prompt-to-pay.sh
# Push a charge
POST /partner/stk
{ "msisdn":"2547…",
"amount": 250 }
← 200 charge.pending
→ charge.completed ✓

In depth

The developer API is built for money, not just requests. You exchange client credentials for a short-lived token, then push a charge to a customer; they confirm in their wallet, and you receive a signed webhook the moment it clears. Every call is idempotent, so a retry after a dropped connection never double-charges.

A charge moves through a clear lifecycle — pending, authorised, completed, declined or expired — that you can poll or receive by webhook. Webhooks are signed with HMAC-SHA256 and retried until acknowledged, so your systems can trust every callback, and balance and transaction queries let you reconcile. A sandbox runs the same contract as production, and rails are abstracted behind the API, so you integrate once and switch providers without changing your code.

Why it matters

Built to be trusted.

  • OAuth2 client-credentials with sandbox and production keys.
  • Prompt-to-pay (STK push) with status polling.
  • HMAC-SHA256 signed, retried webhooks your systems can trust.

Outcomes

  • Integrate in an afternoon
  • Reconcile automatically
  • Build on a stable contract
Talk to us

What's inside

Developer API — in detail.

01

OAuth2 tokens

Exchange client credentials for a bearer token.

02

Charge & status

Push a charge and poll its lifecycle.

03

Webhooks

Signed callbacks the moment a charge clears.

04

Balance & history

Query collection balances and transactions.

Real flows

How it works in practice.

Switch between the journeys this capability handles. Each one checks balance and limits, then waits for PIN or biometric authorisation before posting balanced entries to the ledger.

Merchant push (STK)

The merchant pushes a charge through its lifecycle; the customer approves a prompt.

Authorised with PIN or biometric — nothing posts to the ledger until the customer confirms.
  • Balance & limit checked first
  • Validation / authorisation gate
  • Balanced debits & credits posted
Customer
System
01
SystemMerchant pushes a charge
02
SystemCreate charge · state = pending
CustomerPrompt appears on the phone
03
04
System · validatesValidate & check balance
Customer · validatesAuthorise — PIN or biometric
05
06
SystemDebit payer, credit merchant
07
SystemState = completed
08
SystemSigned webhook + retry until ack
System · donePaid ✓ · receipt shown
Step Validation / PIN Completed
0+

Countries you can launch in

0

Native apps, one platform

0

Channels — App · USSD · Web · API

0%

Double-entry, always balanced

More of the platform

One core, every capability.

Ready to launch your wallet?

Book a demo and we'll stand up your brand, country and rails — and walk you through the apps, admin and API.