Bizum Spain: instant transfers

1) Bizum context and positioning

Bizum is a Spanish interbank instant transfer and payment scheme built into the applications of local banks. Works 24/7, covers P2P (per phone number), P2M (e-commerce/offline payment), as well as donations/donations and invoices. Confirmation is performed in the banking application (SCA/PSD2), funds move along bank rails with immediate authorization and quick crediting.

• Telephone addressing (alias), no IBAN in UX.
• Instantaneous and final credit transfer (chargeback is absent in cards).
• P2M: payment on the site, in the application, offline (QR/Bizum code).
• Request-to-Pay: "request money" to contacts or customers.

2) Members and roles

Bizum scheme/interbank switch - rules, routing, participant catalogs.
Issuing banks - mobile applications, SCA, anti-fraud and limits.
PSP/acquirers - merchant connection to Bizum P2M, API/SDK, reporting and calculations.
Merchant - initiates a payment/request, processes statuses, maintains returns and reconciliation.
Payer/Recipient - confirms transactions in the bank application.

3) Modes and user scenarios

3. 1 P2P "per phone"

The sender selects a contact (phone number) → enters the amount → confirms in his banking application → the recipient sees an instant credit on the account.
For new recipients, reduced thresholds/add. checks.

3. 2 P2M (payment to merchant)

E-commerce: at the checkout, enter the Bizum phone number, or open the deeplink banking application; confirmation - push/SCA.
Offline/QR: dynamic QR per-order (amount + orderId), scanning in the banking application → confirmation → online status to merchant.
Bizum code: the merchant can show a short code/alias for payment at the point of sale.

3. 3 Request-to-Pay

The merchant forms a request for payment (amount/purpose/validity period) → the client confirms in his banking application → the funds are credited as a regular Bizum transfer.

3. 4 Deposits and accounts payable

Supported short codes/alias for charity and utility/small payments.

4) Statuses

'initiated '→' pending '→' success '/' failed '/' cancelled '/' expired '.
For requests - additional states' requested '/' expired '.

5) Limits and risk policies

There is no single "super-circuit" ceiling: banks and/or PSP set limits, often depending on the KYC level, history and channel.

Per-transaction, per-day/24h, sometimes weekly/monthly.
New recipient/merchant - reduced thresholds, shutter speed or confirmation.
Channel/script: separate limits for P2P, P2M (web/app/QR), Request-to-Pay.
Velocity/device/geo-rules on the bank side.

6) Economics and commissions

For merchant Bizum is usually cheaper than card MDR, but the conditions depend on the PSP/bank.
Plan costs for integration/SDK, processing 'pending/expired', support/ODR and recon.

7) Returns and disputes

Chargeback (as in cards) is missing for A2A. Return - a new credit transaction from merchant to payer (partial refunds are supported).
Terms - bank (often T + 0/T + 1).
Disputes/complaints - through PSP and bank procedures; Prepare order logs, confirmations, and customer communications.

8) Safety and compliance

PSD2/SCA in the banking application: PIN/biometrics, device binding, risk-based authentication with the bank.
PII minimization: store only the necessary attributes (phone/refs), encrypt PII, restrict access.
Webhooks: HMAC/nonce, replay protection, audit and retray log.

9) Merchant integration

Options

1. Hosted/Embedded by PSP - fast start: Bizum forms, statuses, errors out of the box.
2. Server-to-Server + App2App/QR - native UX, dynamic QR per-order, deep error handling.
3. Pay-by-Link/Request-to-Pay - account by link (email/SMS/messenger), confirmation at the bank.

• API: `createPayment`, `requestToPay`, `refund`, `webhook`, `reconcile`.
• Idempotence ('orderId' + key), exponential retrays, event dedup.
• Recon: daily auto-recon + periodic full-recon; storage of UTR/fin references.
• SLA dashboards: conversion, 'pending→success/expired', latency before enrollment.

10) Reconciliation and Reporting

Log: 'paymentId/transactionId', 'orderId', channel (P2P/P2M/QR/App2App/Request), payer's bank, status, amount/currency, timestamp, UTR/bank link.
From PSP: registers for enrollments/returns/corrections, late status updates.

11) UX patterns

Mobile-first: for mobile - App2App; for desktop - dynamic QR.
Transparent errors: limit, timeout, SCA failure; safe repeat + alternative (card/SEPA/other A2A).
Receipt: amount, time, 'transactionId', channel, UTR, support contacts.
Request validity period/QR: Show timer and recovery script.

12) Recurrence and mandates

Basic Bizum - one-off with SCA. For subscriptions, a bundle is used: the first payment of Bizum → e-mandate/SEPA DD/Open-Banking for subsequent write-offs (limit/frequency/notifications, mandate management screen).

13) High-risk verticals (including iGaming)

Availability/limits depend on bank/PSP policy and local law.
Expect lowered thresholds, enhanced KYC, possible holds.
Plan alternative rails (maps, SEPA, other PIS) and smart-routing by risk.

14) Bizum Gateway architecture

API layer (REST/GraphQL) for cash register and backhoe.
Event queues: status events → billing/CRM/analytics.
Security: vault for secrets, IP-allowlist PSP, strict redirect-URI validation, anti-replay tokens.
Observability: metrics by channel (App2App/QR/Request), 'pending→success/expired', time to settlement.

15) Output checklist

1. Subscribe Bizum channel from PSP/Bank; select channels (App2App/QR/Request).
2. Implement 'createPayment '/' requestToPay', dynamic QR, error/limit screens.
3. Connect webhooks, idempotency, retrai and event dedup.
4. Set up recon (daily + full), UTR/fin references storage.
5. Support partial/full refunds and ODR procedures.
6. Run SLA dashboards and conversion/latency alerts.
7. Conduct e2e tests with the main banks/devices.

Limit Reference Card

Per-txn/24h/7d: store in config, check before starting.
New recipients/merchants: lowered thresholds/shutter speed.
Channels: separate limits for P2P, P2M (web/app/QR), Request-to-Pay.
Velocity/risk: Bank antifraud can gently deflect/slow down operations.

Summary

For online - App2App + dynamic QR, for offline - QR/Bizum code, for transfers - P2P by number.
Separate online confirmation and final credit in logic; build around webhooks + recon and partial refunds.
Do not fix amounts: maintain limit configs by bank/channel and update regularly.
For subscriptions, the first Bizum bundle → a ticket with transparent management and notifications.