iDEAL Países Bajos: pagos A2A

1) Contexto y posicionamiento de iDEAL

iDEAL es un sistema nacional de pagos A2A sin efectivo (cuenta a cuenta) en los Países Bajos. El comprador paga la compra directamente desde su cuenta bancaria a través del banco online/aplicación móvil del banco emisor. El flujo se basa en un redireccionamiento issuer (redireccionamiento a un banco) o en la apertura de una aplicación bancaria por deeplink/App2App. El cálculo es rápido, la comisión para el merchant está por debajo de los MDR de tarjeta, la finalidad es como la de la transferencia de crédito bancario.

• Interoperabilidad a través de bancos emisores (ING, Rabobank, ABN AMRO, etc.).
• SCA/PSD2-conformidad - confirmación en el banco (PIN/biometría).
• Autorización instantánea (status success en línea) y crédito final a través del ecuador/banco receptor.
• Metadatos ricos para la conciliación (purchaseId/orderId, descripción, referencia).

2) Funciones de los participantes

iDEAL (esquema) - reglas, certificación, enrutamiento a los bancos emisores.
Issuer (banco del pagador) - autenticación del cliente, confirmación de pago, estado.
Acquirer/CPSP (Proveedor de servicio de pago): conexión de merchant, API/SDK, informes y cálculos.
Merchant - inicia el pago, recibe los estados/fondos, lleva las devoluciones y la conciliación.

3) Opciones de flujo de pago

3. 1 Issuer-redirect (classic)

1. Checkout merchant → una selección de banco de Issuer Directory.
2. Redirección o App2App al banco → SCA → confirmación.
3. Devuelve al merchant con 'transactionId' y estado (success/failed/canceled/open/expired).

3. 2 App2App / Embedded

En dispositivos móviles, el merchant abre una aplicación bancaria por deeplink/intent (mejor UX, menos fricción).
Embedded/Hosted: el proveedor proporciona un widget de lista de bancos listo, gestión de redirecciones, manejo de errores.

3. 3 iDEAL QR (offline/online)

QR por pedido dinámico con suma incorporada y referencia; el comprador analiza la cámara de la aplicación bancaria y confirma el pago.
QR estático (raramente para merchantes; más para P2R/donados) - la cantidad es ingresada manualmente por el usuario.

3. 4 Recurring/mandates

Modelo «first payment + e-mandate»: el primer cargo por iDEAL con un SCA explícito → la creación de un e-mandato (generalmente conduce a SEPA Direct Debit para los siguientes cargos dentro de los límites/períodos acordados). Adecuado para suscripciones.

4) Límites y políticas de los bancos

• Per-transaction (máximo por operación).
• Por día/24h y semanal (suma y/o número de operaciones).
• Nuevo beneficiario/nuevo merchant: es posible reducir los umbrales y/o la velocidad de obturación.
• Reglas de canal/riesgo (móvil vs escritorio, velocity, geo/device).

Práctica: no hardcode los números - mantenga la guía de límites de los bancos y muestre al usuario un error comprensible «banco excedido límite» con alternativas (aplastar, otro método, repetir más tarde).

5) La Comisión y la economía

• tarifas de proveedor (gateway, widget, hosted checkout),
• el costo de las devoluciones/operaciones de ODR,
• Apoyo e investigación de incidentes.

6) Estados, cancelaciones, devoluciones

Los estados de las transacciones son: 'éxito', 'abierto' (espera), 'fallado', 'cancelado', 'expired'.
Cancelación previa a la confirmación: por parte del cliente (en el banco) o por timaut (expired).
Chargebacks como en los mapas, no. La devolución es una nueva operación de crédito del merchant al pagador (refund), las devoluciones parciales son posibles.
El plazo de devolución depende del PSP/banco; a menudo T + 0/T + 1 por transferencia bancaria.

7) Seguridad y cumplimiento

SCA en el banco emisor + device binding y políticas antifraude en el lado del banco.
La display name/IBAN en algunos emisores reduce el riesgo de misdirection.
PSD2/GDPR: minimización de PII, protección de hooks web (HMAC), registro de auditoría.

8) Conciliación y presentación de informes

Guardar 'transactionId' (iDEAL), 'purchaseId '/' orderId', time, issuer, estado final, referencia UTR/bancaria de los informes PSP.
Personalice el auto-recon diario y el full-recon periódico (conciliación de revoluciones, devoluciones, ajustes).
En los informes PSP: opciones de pedido originales, estados, actualizaciones tardías (por ejemplo, 'open → success/expired'), movimientos de devoluciones.

9) Patrones UX

Directory → Bank pick: prepagar y clasificar los bancos por popularidad/última opción.
Mobile-first: ofrece automáticamente App2App, fallback - web-rednat.
Retry/recovery: si falla, muestre una repetición simple y métodos alternativos.
Idempotency: 'orderId' + clave de idempotencia para repeticiones seguras.
Cheques: especifique la cantidad, fecha/hora, 'transactionId', referencia, canal (QR/App2App/Redesp).

10) Cancelaciones recurrentes a través de mandatos electrónicos

Escenario «El primer pago de iDEAL → un mandato para futuros cargos» (generalmente a través de SEPA Direct Debit).
El mandato fija el límite per debit, la periodicidad, el derecho de cancelación.
En la interfaz, una pantalla de administración de mandatos (pause/cancel/update) y notificaciones antes de cargar.

11) iDEAL e iGaming/categorías de alto riesgo

La disponibilidad de iDEAL para algunos verticales se limita a los bancos/PSP sobre políticas de riesgo y derecho local.
Para iGaming, espere: controles más estrictos, límites reducidos, cumplimiento local obligatorio y flow ODR/Refund transparente.
Planifique los raíles alternativos (mapas, SEPA, open banking A2A) y la segmentación del tráfico.

12) Integración de merchant: opciones

1. Hosted/Embedded iDEAL Checkout от PSP

Inicio rápido, actualización automática de la lista de bancos, estados y errores.

2. Server-to-Server + redirecciones

Control UX flexible: página de selección propia del banco, generación QR, integración profunda en el cajero.

3. iDEAL QR

Para POS/offline: QR dinámico por orden con suma/etiquetas, mejor para la conciliación y anti-sujeción.

• Эндпоинты: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Idempotencia y tabla dedupe por 'orderId'.
• Webhooks con firma HMAC, retraídas por expositor, sondeo por pull en degradación.
• Catálogos: bancos/límites/códigos de error; Métricas SLA por emisor.

13) Esquema arquitectónico «iDEAL Gateway»

Capa API: NAT para la caja registradora + integración con la API PSP/iDEAL.
Colas de eventos: eventos de estado → facturación/CRM/análisis.
Observabilidad: métricas de conversión por banco/canal (Redamb/App2App/QR), fracción 'open→expired', latencia media a éxito.
Seguridad: secretos en vault, IP-allowlist de PSP, protección de URL redireccional, tokens anti-replay.
Datos: registros de pagos/devoluciones, registro ODR, mapa de mandatos.

14) Check-list de la salida en el prod

1. Seleccione PSP/Ecuador con iDEAL (Hosted/Embedded/App2App/QR).
2. Implemente 'createPayment' + redirecciones/Arr2Arr, pantalla de selección de banco.
3. Incluya hooks web, idempotencia, temporizadores y repeticiones de estados.
4. Configure recon (daily + full), descargas y alertas por rassincrones.
5. Apoye los refundidos parciales/completos y el reglamento ODR en sapport.
6. Añadir UX-fallback (métodos alternativos, repetición), cheque con 'transactionId'.
7. Pruebe sus App2App/QR en los principales bancos (iOS/Android/desktop).
8. Prepare una guía de límites bancarios y una página de estados de incidentes.

Tarjeta de referencia de límites

Per-txn/24h/7d: almacenar en una configuración; comprobar antes de iniciar el redireccionamiento.
Nuevos beneficiarios/merchantes: límites de inicio reducidos y/o retrasos.
Canal: en la App2App móvil, los límites/políticas de Frod pueden diferir de la web.
Los mandatos: los límites/periodicidades son dados en condiciones del mandato (para las amortizaciones recurrentes).

Resumen

Apueste por el App2App/Embedded para la conversión y por el QR dinámico para el offline.
No coser cantidades duras: mantenga las confecciones de los límites y las normas de comportamiento de los bancos.
El proceso se construye en torno a webhooks + recon, estados claros y refundiciones parciales.
Para suscripciones: primer pago de iDEAL → e-mandato; administre los límites y las notificaciones de manera transparente.