Bizum España: traducciones instantáneas

1) Contexto y posicionamiento de Bizum

Bizum es un esquema interbancario español de transferencias y pagos instantáneos integrado en las aplicaciones de los bancos locales. Funciona 24/7, cubre P2P (por número de teléfono), P2M (pago en e-commerce/offline), así como donaciones/donados y facturas a pagar. La confirmación se realiza en la aplicación bancaria (SCA/PSD2), los fondos se mueven a través de los raíles bancarios con autorización inmediata y acreditación rápida.

• Direccionamiento por teléfono (alias), sin IBAN en UX.
• Instantaneidad y finalidad de la transferencia de crédito (no hay chargeback como en las tarjetas).
• P2M: pago en el sitio, en la aplicación, fuera de línea (código QR/Bizum).
• Request-to-Pay: «solicitar dinero» a contactos o clientes.

2) Participantes y roles

Esquema Bizum/Interbancario Sweet - reglas, routing, catálogos de participantes.
Los bancos emisores son aplicaciones móviles, SCA, antifraude y límites.
PSP/Equyers - Conexión de merchant a Bizum P2M, API/SDK, informes y cálculos.
Merchant: inicia el pago/solicitud, procesa los estados, realiza devoluciones y concilia.
Pagador/destinatario: confirma las transacciones en la aplicación del banco.

3) Modos y scripts personalizados

3. 1 P2P «por teléfono»

El remitente selecciona el contacto (número de teléfono) → ingresa el importe → confirma en su aplicación bancaria → el destinatario ve un crédito instantáneo en la cuenta.
Los umbrales reducidos/dopados son posibles para los nuevos destinatarios. inspecciones.

3. 2 P2M (pago al merchant)

E-commerce: en la caja registradora se introduce el número de teléfono Bizum o se abre una aplicación bancaria por deeplink; confirmación - push/SCA.
Offline/QR: QR por pedido dinámico (suma + ordenId), escaneo en la aplicación bancaria → confirmación → estado en línea del merchant.
Código Bizum: el merchant puede mostrar un código breve/alias para pagar en el punto de venta.

3. 3 Solicitudes de pago/Facturas

Merchant forma una solicitud de pago (cantidad/destino/fecha de caducidad) → el cliente confirma en su aplicación bancaria → los fondos se acreditan como una transferencia Bizum normal.

3. 4 Donados y facturas a pagar

Se admiten códigos cortos/alias para caridad y pagos de utilidad pública/pequeños.

4) Estados

'iniciated' → 'pending' (pendiente de confirmación/respuesta bancaria) → 'success'/' failed '/' canceled '/' expired'.
Para consultas, los estados adicionales son 'requested '/' expired'.

5) Límites y políticas de riesgo

No hay un techo único «supershem»: los límites establecen bancos y/o PSP, a menudo dependen del nivel KYC, la historia y el canal.

Per-transaction, per-day/24h, a veces weekly/monthly.
Nuevo receptor/merchant: umbrales reducidos, extracto o confirmación.
Canal/script: límites individuales para P2P, P2M (web/app/QR), Request-to-Pay.
Velocity/device/geo-reglas en el lado del banco.

6) Economía y Comisiones

Para el merchant, Bizum suele ser más barato que el MDR de tarjeta, pero las condiciones dependen del PSP/banco.
Planifique los costos de integración/SDK, procesamiento de 'pending/expired', soporte/ODR y recon.

7) Devoluciones y Dispouts

Chargeback (como en las tarjetas) no está disponible para A2A. Devoluciones - Una nueva operación de crédito del merchant al pagador (se admiten refundiciones parciales).
Los plazos son bancarios (a menudo T + 0/T + 1).
Disputs/quejas - a través de procedimientos PSP y banco; prepare registros de pedidos, confirmaciones y comunicaciones con el cliente.

8) Seguridad y cumplimiento

PSD2/SCA en la aplicación bancaria: PIN/biometría, device binding, autenticación risk-based del banco.
Minimización PII: almacenar sólo los atributos necesarios (teléfono/refs), cifrar PII, restringir el acceso.
Webhooks: HMAC/nonce, protección de respuesta, registro de auditoría y retrés.

9) Integración de merchant

Opciones

1. Hosted/Embedded de PSP - Inicio rápido: formas de Bizum, estados, errores fuera de la caja.
2. Server-to-Server + App2App/QR - UX nativo, QR dinámico por orden, manejo profundo de errores.
3. Pay-by-Link/Request-to-Pay - cuenta por enlace (email/SMS/mensajero), confirmación en el banco.

• API: `createPayment`, `requestToPay`, `refund`, `webhook`, `reconcile`.
• Idempotencia ('orderId' + clave), retraídas exponenciales, dedoup de eventos.
• Recon: daily auto-recon + periódico full-recon; Almacenamiento de referencias UTR/fin.
• SLA-dashboards: conversión, 'pending→success/expired', latencia previa a la inscripción.

10) Conciliación y presentación de informes

Lógica: 'paymentId/transactionId', 'orderId', canal (P2P/P2M/QR/App2App/Request), banco del pagador, estado, cantidad/moneda, timestamp, UTR/enlace bancario

Desde PSP: registros de inscripción/devoluciones/correcciones, actualizaciones de estado tardías.

11) Patrones UX

Mobile-first: para mobile - App2App; para escritorio: QR dinámico.
Errores transparentes: límite, tiempo de espera, fallo SCA; repetición segura + alternativa (mapa/SEPA/otro A2A).
Recibo: cantidad, tiempo, 'transactionId', canal, UTR, contactos de soporte.
Caducidad de la solicitud/QR: muestra el temporizador y el script de recuperación.

12) Reincorporación y mandatos

El Bizum básico es uno-off con SCA. Para las suscripciones se utiliza un paquete: el primer pago Bizum → e-mandate/SEPA DD/Open-Banking para los cargos posteriores (límite/frecuencia/notificaciones, pantalla de gestión de mandatos).

13) Verticales de alto riesgo (incluyendo iGaming)

La disponibilidad/límites dependen de las políticas bancarias/PSP y del derecho local.
Esperar umbrales reducidos, KYC reforzado, posibles hold's.
Planifique raíles alternativos (mapas, SEPA, otros PIS) y una ruta inteligente en función del riesgo.

14) Arquitectura «Bizum Gateway»

Capa API (NAT/GraphQL) para la caja registradora y el backofis.
Colas de eventos: eventos de estado → facturación/CRM/análisis.
Seguridad: vault para secretos, PSP de IP-allowlist, validación estricta de URI de redireccionamiento, tokens anti-replay.
Observabilidad: métricas por canal (App2App/QR/Request), 'pending→success/expired', tiempo hasta settlement.

15) Check-list de la salida en el prod

1. Suscriba el canal Bizum con PSP/banco; seleccione los canales (App2App/QR/Request).
2. Implemente 'createPayment '/' requestToPay', QR dinámico, pantallas de errores/límites.
3. Conecte webhooks, idempotencia, retraídas y dedoup de eventos.
4. Configure recon (daily + full), almacenamiento de referencias UTR/fin.
5. Apoye los refundidos parciales/completos y los procedimientos ODR.
6. Ejecute SLA-dashboards y alertas de conversión/latencia.
7. Realice pruebas e2e con los bancos/dispositivos principales.

Tarjeta de referencia de límites

Per-txn/24h/7d: almacenar en la configuración, comprobar antes del inicio.
Nuevos destinatarios/merchantes: umbrales reducidos/extracto.
Canales: límites individuales para P2P, P2M (web/app/QR), Request-to-Pay.
Velocity/riesgo: el antifraude del banco puede desviar/ralentizar suavemente las operaciones.

Resumen

Para online - App2App + QR dinámico, para offline - código QR/Bizum, para traducciones - P2P por número.
Comparta la confirmación en línea y el crédito final en lógica; construye alrededor de webhooks + recon y refundos parciales.
No fije cantidades: Mantenga los límites de los bancos/canales y actualice regularmente.
Para las suscripciones, el paquete primero Bizum → un mandato con una gestión y notificaciones transparentes.