Today we're launching the UPI Inter-Institutional Transfer API — a single endpoint that enables secure, real-time KES transfers between Banks, Fintechs, and Saccos in Kenya. No more siloed money movement. No more manual EFTs. Just one POST request.

How it works

Each participating institution is assigned a numeric channel code. Banks start at 101, Fintechs at 201, and Saccos at 301. Your integration specifies the sender account, recipient account, their respective channel codes, the currency, and the amount — and we handle the routing.

Who is this for?

• SACCOs that need to disburse loans to member bank accounts
• Fintechs collecting from bank customers and settling to their own wallets
• Enterprises running payroll across mixed account types
• Aggregators building multi-rail payment infrastructure

Getting started

The endpoint is available immediately on both sandbox and production. Add your institution codes to the request and you're live. See the API reference for the full payload spec and response format.

The B2B Paybill API is now live on POST /billing/v3/b2b/create. It supports the BusinessPayBill channel and enables businesses to settle invoices, pay suppliers, and make inter-business transfers directly from their ProTax merchant wallet.

Use cases

• Supplier invoice settlement to their MPESA paybill
• Automated recurring payments for business subscriptions
• Payroll disbursement to staff SACCO paybills
• Tax payments to KRA paybill numbers

Signature

The B2B signature concatenation order is: MerchantID + channel + shortCode + identifier + amount. This is different from the Mobile Payout signature — make sure you update your signing logic.

When downstream networks are unreachable — whether that's a Telco maintenance window, a bank's nightly batch cut-off, or a brief internet blip — transactions submitted to the ProTax API should not simply fail. With Offline Mode, they don't.

The problem with synchronous-only APIs

Most payment APIs are purely synchronous: you POST a request, the server forwards it downstream, and you get a response. If the downstream system is unreachable, you get an error. Your customer doesn't get their airtime. Your application has to decide whether to retry, when, and how many times — and you have to build all of that yourself.

Our queue architecture

When "offline_mode": true is included in a request body, the ProTax API accepts the transaction immediately and returns a 200 with status QUEUED. The transaction is durably stored and joins our internal retry queue.

The queue uses an exponential backoff schedule: first retry at 1 minute, then 5, 15, 60, and 360 minutes. If all five retries fail, a payment.failed webhook is dispatched and the transaction is marked terminal.

State machine

Every queued transaction moves through a strict state machine: QUEUED → PROCESSING → SUCCESS | FAILED | PENDING_RETRY. State transitions are atomic — a transaction can only be in one state at any time, preventing double-processing even under concurrent retry workers.

How to use it

Simply add "offline_mode": true to any request payload. No other changes to your integration are required. You'll receive an IPN callback when the transaction reaches a terminal state — subscribe to the payment.success and payment.failed webhook events for clean handling.

When we designed v1 of the ProTax API, MD5-based signatures were a pragmatic choice for simplicity. By 2024 they were a liability. v2.0 removes them entirely and raises the baseline across three security dimensions.

1. HMAC-SHA256 signatures

All request signatures must now use HMAC-SHA256. MD5 signatures are rejected with error 1104 Signature Mismatch. The migration is a one-line change in most languages — see the Migration Guide for per-language examples.

2. TLS 1.2+ enforcement

Production endpoints no longer accept TLS 1.0 or 1.1 connections. Most modern HTTP clients default to TLS 1.2+ already. If you're using an older OpenSSL build or a legacy HTTP client, you'll need to update your TLS configuration.

3. Zero-downtime API key rotation

Dashboard API key rotation now generates a new key while the old one remains valid for 24 hours. This gives your team time to deploy the new key to all environments before the old one expires — no service interruption required.

The ProTax Airtime API already supported pinless Faiba airtime via telco: "FAIBA". Today we're adding full data bundle vending via the new FAIBA_B channel — 11 bundle products spanning daily, weekly, monthly, 60-day, and 90-day plans.

Available bundle products

Bundles range from DAILY_DATA_100MB (KES 10) to 90_DAY_DATA_225GB (KES 6,000), with autorenew variants for daily and monthly plans. The new Chui, Kifaru, Ndovu, and Simba combo plans include minutes and SMS alongside data.

How to use it

Use the existing Airtime API endpoint with telco: "FAIBA_B" and the productCode field set to your desired bundle code. For combo plans, set telco: "FAIBA_B" and use the combo product codes like SIMBA_DATA_20GB.

The ProTax Biometrics API is now live — connecting physical biometric devices (fingerprint scanners, face recognition units) to your digital systems via a simple REST interface.

Two endpoints

Use GET /api-biometric to pull all attendance records for your merchant partner ID. Use GET /api-single with a UID to fetch the attendance record for a specific student or employee.

Who is it for?

• Schools — automate student attendance from biometric registers into school management systems
• Enterprises — connect HR payroll systems to real biometric clock-in data
• Security companies — log access control events programmatically

Records include check time, employee/student name, status, gender, SN, and SMS notification status — everything needed to drive downstream workflows.

OTP latency is one of those things that feels invisible until it breaks. A login flow that takes 12 seconds to deliver a code feels slow. One that takes 3 seconds feels instant. We spent Q2 2024 driving that number down.

What we changed

The old routing layer used a single primary aggregator with a secondary fallback. If the primary was slow, every message waited for a timeout before falling over. The new layer is parallel-first: we submit to multiple aggregators simultaneously and accept whichever responds first, cancelling the others.

Results across networks

• Safaricom: 12s avg → 3.2s avg
• Airtel: 18s avg → 4.1s avg
• Telkom: 22s avg → 4.8s avg

No changes to the API are required on your side. All SMS and OTP requests automatically use the new routing layer.

Nairobi City Water & Sewerage Company (NCWSC) bill payments are now supported in the ProTax Pay Bill API via the NAIROBI_WTR channel code.

This means your platform can now vend all major household utility payments in Kenya — electricity, water, and TV subscriptions — through a single unified API. No separate integrations, no separate contracts.

How to use it

Use the Pay Bill endpoint (POST /billing/v1/bill/create) with "telco": "NAIROBI_WTR" and the customer's NCWSC account number in the account field. The signature concatenation is the same as all other Pay Bill channels: amount + account + telco + initiatorPhone + MerchantID.