Roadmap
Every capability in the Wallet API is documented — but not all of them run in production today. This page draws the line clearly so you can plan your integration against reality.
For 🚧 capabilities the API contract is complete and stable — field names, the status machine and error codes are designed not to change. What is missing is not code, but the connected provider at the end of that integration (a bank, a biller, a cash network, a card issuer).
Running in production today
These work end to end inside the closed loop, and you can build your integration on them right now.
| Capability | Page |
|---|---|
| Program, branding, currency and policy management | Panel — Programs |
| End-user lifecycle, wallet and account creation | Core Concepts |
| Card top-up (3D Secure included) | Top-up |
| Cash top-up through an agent | Top-up |
| Wallet-to-wallet transfer | Transfers |
| Wallet payments — individual → business, with commission | Wallet Payments |
| Refund a card payment into the wallet | Refund to Wallet |
| QR generation, parsing and collection (closed loop) | QR |
| Cashback campaigns, points, tiers, badges | Loyalty & Cashback |
| Limit buckets and KYC-tiered entitlements | Limits · KYC Levels |
| Fee schedules and quotes | Fees |
| Operation listing, receipts, export | Operations |
| Webhook delivery | Webhooks |
| White-label end-user portal | Portal |
Waiting on a connected provider
| Capability | What it needs | Page |
|---|---|---|
| 🚧 Bank transfer top-up | A bank integration — per-user deposit references and inbound matching run on it | Top-up |
| 🚧 Bank withdrawal (to the user's own IBAN) | The same bank integration | Withdrawals |
| 🚧 IBAN transfer (to a third party) | The same bank integration | Transfers |
| 🚧 Bulk payouts | The same bank integration (except wallet-internal targets) | Bulk Payouts |
| 🚧 Bill pay | A biller integration — inquiry and settlement depend on the provider | Invoices & Bill Pay |
| 🚧 ATM / QR cash-out | A cash withdrawal network connection | Withdrawals |
| 🚧 Card issuing | An issuer-processor and a BIN allocation | Panel — Cards |
On your program the 🚧 integrations are closed by program configuration — calling a closed integration is rejected. The dominant gate is the program's loopMode: it defaults to CLOSED, and in that state IBAN withdrawals, bank withdrawals and IBAN-targeted bulk payout items are refused unconditionally. Card issuing additionally requires a card issuer integration bound to your program; without one the whole card flow is rejected.
Until your provider contract is in place you can bind the Test integrations from the panel (Test Bank, Test ATM Network, Test Biller, Test Card Issuer, Test Exchange) — deterministic simulators whose scenarios are all on, bound exactly like a real integration. That lets you exercise the failure paths without a real institution behind them. Scenario tables: Testing.
Model the same distinction in your product: a closed integration does not mean "the capability does not exist", it means "it has not been opened for this program". Do not hide closed paths in your UI — show them locked, so users can see what is coming and when.
QR and interoperability
QR runs closed loop today: the code you generate is read and paid inside your own ecosystem — your app, your businesses, your terminals.
A common-standard QR format readable by banks and other payment apps is not being produced yet. The blocker is regulatory rather than technical: emitting a format before the applicable technical guideline and field structure are settled produces a code that is believed to be compliant but that no reader understands. Until that is settled, no standard compliance is claimed.
Details: QR.
How to plan your integration
- Start with the closed loop. User creation, card top-up, transfers, payments and loyalty all work today — build your product core on them.
- Write against the 🚧 contracts. Field names and the status machine are stable; when an integration connects, your code does not need to change.
- Make your UI conditional. Show the "withdraw to bank" button based on program capability; never expose a path that cannot complete.
- Wire webhooks from day one. When an integration connects, the new event types start flowing to the same endpoint.
How this page changes
When a provider connects, the 🚧 box on that page is removed and the capability moves into the "running today" table above. See the Changelog for releases.