Instant Payments
Instant Payments is a retail, @alias-addressed transfer layer that rides on top of the
platform's existing CBDC settlement rails. It's a different product from mint/burn/transfer/
bridging (all still described in Token Operations): those move
value between the institution's own accounts, while Instant Payments moves value between
retail customers of participant banks, instantly and across banks. A companion consumer
PWA ("Billetera") is the app a retail customer installs; this page covers the surfaces exposed
in the Portal (apps/dashboard).
Every payment is either:
INTERNAL— sender and recipient are customers of the same bank.CROSS_ORGANIZATION— sender and recipient are at different banks. These settle wholesale on-chain between the two banks' settlement accounts.
The Billetera consumer wallet
Billetera (billetera.blockchain.hn) is the phone-first PWA a retail customer installs. It
re-themes itself around the customer's bank and is Spanish-first (Lempira, symbol L). A customer
picks a bank and name, lands on a balance-and-movements home, then activates instant payments by
registering a globally-unique @alias — the identifier others use to pay them. Until an alias
is activated, the home Enviar / Recibir actions route into the activation flow.
Left: the Payments tab before activation — the value props and the Activar CTA. Right:
@alias registration, with a live availability check (green ¡Disponible! when free, or "ya está
en uso" when taken).
Left: the home screen — the bank-themed balance card with Enviar / Recibir and the movements
feed. Right: the Enviar dinero sheet — amount, recipient @alias (with a QR-scan shortcut), and
an optional reference message.
The screenshots above are from the current demo/self-service build (see Current status): a customer self-registers a wallet and alias, and the wallet opens with a fixed demo balance.
The settlement account
Each Commercial organization has one Instant Payments settlement ("ops") account, used to
settle cross-bank payments. It is auto-provisioned when the organization is activated (not a
step the admin performs) and is deliberately not a multisig — it's a single custody key the
platform generates and controls, distinct from the account/group model in
Accounts. Banks top up its liquidity from their exchange address via
the wholesale Send flow; GET /organizations/:id/instant-payments/account (and .../balance)
expose its address and balance, gated on read · InstantPayment and organization ownership.
Portal surfaces
Both organization types see an Instant Payments sidebar item (/instant-payments), but the
page renders differently depending on the viewer's organization type:
| Viewer | What they see |
|---|---|
| Commercial (Participant) | Their own retail surface: Dashboard (settlement-account card, volume/payment/avg-payment KPIs split cross-bank vs. internal, day/hour distribution), Transactions, and Users (their registered retail clients) tabs, plus CSV export. |
| Central (Issuer) | A read-only, aggregate-only oversight view: system-wide or per-bank KPIs (settled volume, payment count, avg payment, users), a sortable/searchable per-bank rollup table (each bank's settlement-account address, volume, payments, users), day/hour distribution charts, and CSV/JSON export. No transaction- or client-level detail is exposed here. |
The Issuer oversight view requires read · InstantPaymentOversight, which only Administrators and
Auditors carry — Issuer Members don't see the Instant Payments sidebar item at all. Participant
staff (any role) see their own bank's surface via read · InstantPayment.
Permissions
| Subject | Administrator | Member | Auditor |
|---|---|---|---|
InstantPayment | manage | read, create | read |
InstantPaymentOversight | manage | — | read |
InstantPayment covers a bank's own clients/accounts/payments; InstantPaymentOversight is the
Issuer-only, cross-bank aggregate surface above. See Roles & Permissions
for how these fit the rest of the ability matrix.
Current status: demo mode
The alias-registration path wired into the PWA today is a public, throttled demo/self-service
flow (POST /instant-payments/demo/clients, .../demo/clients/:id/alias) — demo wallets get a
fixed, server-side starting balance so the sandbox stays honest. A production-oriented, org-scoped
path also exists for a bank's staff to register real retail clients directly
(POST /instant-payments/clients, requires create · InstantPayment), but it isn't yet the flow
the PWA uses end-to-end.