orchura.
Cross-border payment infrastructure for African B2B

Collections and payables,
composedon one rail.

PayShap, RTC, mobile money, cards, Pay-by-Bank, USDC — routed, settled, and reconciled through the same ledger. Both directions, first-class.

PAYMENTINTENTOne primitiveCollections · PayablesROUTING ENGINERetry-and-routep99 · <200msPayShapZA · secondsRTCZA · 10s clearingM-PESAKE · secondsCardsp99 · 184msPay-by-BankOpen bankingUSDCTreasury · cross-borderZARPZA · stablecoinLEDGERDouble-entryReconciledONE PRIMITIVE · ONE ROUTING DECISION · SEVEN PEERS · ONE LEDGER
PayShapRTCMobile moneyCardsPay-by-BankUSDCZARP
THE INFRASTRUCTURE LAYER

Every rail, a peer. Every primitive, wired the same.

PayShap
RTC
M-PESA
Pay-by-Bank
USDC

Rails as peers in the routing engine

PayShap, RTC, mobile money, cards, Pay-by-Bank, stablecoin — each evaluated per request, routed to the path most likely to succeed at the lowest defensible cost.

ROUTED · 7D
R 482.4k
↑ 12.4%

A double-entry ledger that survives audit

Every primitive — collections, payables, retries, reversals — writes to the same ledger. Reconciled back to the rail of record without human intervention.

PAYABLE · SETTLEDSent
R 124,820.00
To FNB · ••0421
RAIL · RTCFEE · R 18P99 · 184MS

Payables, first-class with collections

Both directions move through the same primitives. The PaymentIntent treats payouts and collections identically — same routing, same ledger, same reconciliation.

FOR ENGINEERS · OPERATORS · FINANCE LEADS

Built for the operator, not the spectator.

The founder reads the API docs. The head of finance lives in the dashboard. Both signed up without a sales call — the product is the same for everyone, and the leverage is in the architecture.

Join the waitlist
01FOUNDER
Reads the API docs. Ships the first integration in an afternoon.
API · SDK · sandbox
02OPERATOR
Lives in the dashboard. Approves payouts, watches every rail in real time.
Dashboard · approvals · alerts
03FINANCE
Reconciles in the ledger. Closes the books on Friday, not Monday.
Double-entry ledger · exports
HOW IT WORKS

Three steps. One afternoon. No re-platforming.

01

Sign up · self-service

No sales call. No bespoke build. Verify when you're ready to go live — usually same day.

02

Wire the PaymentIntent

One primitive for collections, payables, retries and reversals. Three lines on the server, three on the client, or call the hosted handoff.

03

Route, settle, reconcile

Every transaction is routed to the rail most likely to succeed, settled into the double-entry ledger, and reconciled back to the rail of record.

BY THE NUMBERS

Built to scale, quietly.

99.9%
Routing decisions resolved across the rail matrix — retry-and-re-route, not retry-and-fail.
200ms
p99 routing decision — every rail evaluated, lowest defensible path picked.
MADZTNEGSNMLCIGHNGETUGRWKETZZMZWMZNABWZANINETEEN MARKETS · ONE ROUTING ENGINE
COVERAGE · 19 MARKETS

Wired across the continent. Rail by rail.

PayShap and RTC in ZA. M-PESA across KE, TZ, UG, RW. NGN, GHS, EGP and XOF bank rails. ZARP and USDC for cross-border. Each market is a peer in the routing engine — same primitive, same ledger, same reconciliation.

ZAPayShap · RTC · Cards · ZARP · USDC
BWCards · USDC
CIXOF · Cards
DZCards · USDC
EGEGP · Cards · USDC
ETCards · USDC
GHGHS · M-PESA · USDC
KEM-PESA · Cards · USDC
MACards · USDC
MLXOF · USDC
+ 9 more markets
SECURITY · POSTURE

Compatible with sponsor banks, regulators, and developers.

In that order of restraint. Architectural choices that map to the standards a SARB examiner or a sponsor-bank risk team would expect — named, dated, and externally auditable.

ARCHITECTURE

Sponsor-bank model, not a bank

Orchura is an FSP under FAIS, sitting on a sponsor-bank rail. We are not a bank, not a card scheme, and not a crypto exchange — and the codebase reflects that boundary.

FAISSARB · NPS
VAULT

PCI DSS Level 1 architecture

Card data is tokenized at the edge. No PAN persisted in our systems. The vault is held by an HSM-backed sub-processor; merchants reference tokens, never raw numbers.

PCI DSS L1HSM · TLS 1.3 mTLS
LEDGER

Audit-safe double-entry ledger

Every primitive — collections, payables, retries, reversals — writes append-only to a double-entry ledger that survives audit. Time-bounded WORM retention per regulator class.

ISO 27001 controlsWORM · append-only
DATA

POPIA-grade data handling

Personal data is processed under explicit lawful basis. Data subject rights are wired into the API — access, deletion, portability return through the same primitive. Information Officer registered with the Regulator.

POPIAGDPR · adequacy
STATUS · BUILD & LAUNCH STATES — WHAT'S SHOWN, WHAT'S LABELLED, WHAT WAITSUPDATED · 2026-Q2
READY WHEN YOU ARE

Wire the rails once. Scale the rest.

Self-service onboarding. One API. The same product everyone gets — the leverage is in the architecture.

Join the waitlist