Built against QR+ Master Specification v1.2.0, Registry API v1.2.0, Payer Service Provider API v1.2.0, and Payee Service Provider API v1.2.0. Published 22 July 2026.
Network
PrSP
Your Bank App
Payer side
PeSP
Mzansi Payment Systems
Payee side
system: not provisioned
REG
Registry
cache source
Registry cache loaded for Mzansi Payment Systems · pep-general, pep-shortcode
Registry Administration
Provisioning Mzansi Payment Systems as a Service Provider. Before any Paylink can be resolved, the Service Provider has to register itself, set up signing keys, and let every other participant's local cache discover it. This is /profile/* (write, self-only) and the read-only Registry discovery endpoints.
Other Registry endpoints (17)
These aren't part of the core provisioning story, but they're real endpoints — listing, browsing, and cleanup operations. Callable anytime; they use whatever service/authority you've already provisioned above, or a fallback example.
Step 1 · Generate Paylink
Choose who presents, and which encoding. This is created locally — nothing is sent to any API yet.
Step 2 · Scan & Resolve
The scanning party's Service Provider resolves the Paylink against the presenting party's Service Provider.
Step 3 · Request Payment
The PeSP now knows what to charge, and asks the PrSP to collect it — offering whichever rails it accepts.
Step 4 · Payment Reply
This is the PrSP's actual callback to /reply-payment. Pick any outcome — the Payer approving via an offered rail, or the PrSP declining or failing the request.
Step 5 · Conclude
Close out the payment, then the whole flow session.
Draws live as you act — one arrow per request or response.
Every request and response, in order.
WHAT JUST HAPPENED
ASK ABOUT QR+
What do you want to know?
Built-in answers from the QR+ spec — no live AI, just a knowledge base covering encodings, flow types, the Registry, and the payment flow.