Bancontact Bélgica: tarjetas y A2A

1) Ecosistema: Bancontact y Payconiq

Bancontact es un esquema nacional de pagos sin efectivo de Belgia con un fuerte componente de tarjeta (tarjetas de débito, a menudo co-badge con Maestro/Debit Mastercard) y soporte para e-commerce/POS/NFC.
Payconiq by Bancontact es una capa de pagos A2A/móviles (QR/App2App/P2P «en el teléfono») ampliamente utilizada en línea y fuera de línea.

• Dos rieles: el de tarjetas (card rails) y el bancario A2A (Payconiq).
• Una sola marca en la taquilla: el logotipo de Bancontact/Payconiq es reconocible y familiar para el usuario.
• SCA/PSD2: confirmación en el banco/solicitud, bajo frod.
• Confirmaciones instantáneas en línea y cálculos rápidos (ver más abajo).

2) Roles y participantes

Esquema de Bancontact/Payconiq: reglas, certificación, routing.
Issuer (banco del pagador): el emisor de la tarjeta y/o cuenta Payconiq, límites y antifraude.
Acquirer/PSP: conecta el merchant (mapa/A2A), da API/SDK, informes y cálculos.
Merchant: inicia el pago, procesa los estados/devoluciones, mantiene la conciliación.

3) Canales y flow

3. 1 Tarjeta de Bancontact (POS/e-commerce/NFC)

POS/NFC: pago clásico de débito por terminal; Autorización offline/online para la configuración del emisor.
E-commerce (CNP): página de alojamiento/widget PSP, confirmación SCA (flow similar a 3DS).
Co-badge: si hay una aplicación internacional (Maestro/Debit MC), el terminal/PSP selecciona la ruta.

3. 2 Payconiq (A2A: QR/App2App/Link)

QR per-order: el merchant genera un QR dinámico (suma + orderId); el usuario escanea con la aplicación Payconiq/banco → confirma → el merchant recibe el estado en línea.
App2App/Deeplink: desde la aplicación web/merchant se abre la aplicación bancaria inmediatamente en el pago.
Pay-by-Link: factura/enlace en correo electrónico/SMS/mensajero.
P2P «al teléfono»: transferencias entre usuarios por número de contacto.

3. 3 Scripts offline

QR estático (raramente para merchantes) - la suma a mano, conveniente para donados/micropagos.
SoftPOS: recepción de tarjetas/Payconiq en teléfonos inteligentes (donde se admite).

4) Límites y comportamiento de los bancos

• Per-transaction/per-day/week para la tarjeta y por separado para Payconiq.
• Nuevo receptor/nuevo merchant: umbrales reducidos/velocidad de obturación.
• Reglas de canal/velocity: móvil vs web, geo/device, frecuencia de operación.
• P2P/QR/NFC pueden tener micro límites separados.

5) Estados y cálculos

Tarjetas (Bancontact card)

Estado online: 'authorized/approved', 'declined', 'referred', 'timeout'.
Settlement: normalmente T + 1/T + 2 días bancarios a través del ecuador; los ajustes/reversales son posibles.
Chargeback: disponible bajo reglas de tarjetas (plazos/códigos, pruebas).

Payconiq (A2A)

Estado online: 'success',' pending ',' failed ',' canceled ',' expired '.
Settlement: crédito bancario rápido (a menudo T + 0/T + 1, depende del banco/PSP).
No hay chargeback: devoluciones - una nueva operación de crédito de merchant al pagador (se admiten refundidos parciales).

6) Tarifas y economía

Carril de mapas: fix/porcentaje de MDR al ecuador + 3DS/SCA-gastos de PSP.
Payconiq (A2A): normalmente por debajo de los MDR de tarjeta; las tarifas de QR/widgets/informes son posibles.
Hipoteca el coste de soporte/ODR, trabajando con 'pending/expired' y recon.

7) Devoluciones y Dispouts

Mapa: procedimientos de chargeback sobre reglas de mapas; almacene proof-of-delivery/services, registros SCA.
A2A: no hay charjback, hacer refund (full/partial) como operación separada; plazos T + 0/T + 1/T + 2 dependiendo del banco.

8) Seguridad y cumplimiento

PSD2/SCA en el banco/anexo; device binding y antifraude del emisor.
Minimización PII, cifrado de ganchos web, HMAC/nonce, protección de respuesta, registro de auditoría.
GDPR: transparencia en el almacenamiento y eliminación de datos a petición (DSAR).

9) Patrones UX

Smart-routing: por defecto, ofrezca Payconiq (A2A) para comisiones bajas; fallback - mapa.
Mobile-first: con tráfico móvil - App2App; en el escritorio - QR/redesp.
Cheques: cantidad, fecha/hora, 'transactionId', canal (Card/Payconiq), UTR/referencia, contactos de sapport.
Idempotencia: 'orderId' + clave, repeticiones seguras durante los tiempos de espera.
Recuperación: con 'pending/expired' - un botón de repetición, una alternativa al método.

10) Integración de merchant

Opciones

1. Hosted/Embedded de PSP (mapa + Payconiq): inicio rápido, widgets listos, estados y errores.
2. Server-to-Server + Redirect/App2App/QR: control completo de UX, selección nativa del canal, QR dinámico por pedido.
3. Pay-by-Link/Invoice: cuenta por correo electrónico/SMS/mensajero (especialmente para B2B/servicios).
4. POS/SoftPOS: recepción de tarjetas/NFC y Payconiq-QR al por menor.

• API: `createPayment`, `refund`, `webhook`, `queryStatus`, `reconcile`.
• Webhooks (HMAC, retraídas, dedoop), tabla de idempotencia.
• Recon: daily auto-recon + periódico full-recon; Almacenamiento de referencias UTR/fin.
• SLA Dashboards: conversión por canales, 'pending→success/expired', latencia a settlement.

11) Reincorporación y mandatos

Tarjeta: débito tokenizado clásico (tokens de red/COF) con SCA en el primer pago + MIT.
A2A: a través de los mandatos e-mandate/SEPA DD/open-banking: primer pago → mandato para los cargos posteriores (límite/periodicidad/notificaciones).

12) Verticales de alto riesgo (incluyendo iGaming)

En Bélgica, la regulación estricta: la disponibilidad de canales y los límites dependen del PSP/banco y de la ley local.
Espere límites reducidos, CUS/monitoreo avanzado, posibles hold's.
Planifique raíles alternativos (mapa, SEPA, otros PIS) y enrutamiento por perfil de riesgo.

13) Arquitectura «Bancontact/Payconiq Gateway»

La capa API (NAT/GraphQL) para la caja registradora y el back-office.
Colas de eventos: eventos de estado → facturación/CRM/análisis.
Seguridad: vault para secretos, IP-allowlist PSP, la validación estricta de un URI redireccional, anti-replay.
Fiabilidad: retraídas exponenciales, DLQ para estados inestables, idempotencia.
Datos: catálogos de bancos/límites/códigos de error; revista ODR y mapa de mandatos.

14) Check-list de la salida en el prod

1. Seleccione un PSP compatible con la tarjeta + Payconiq; acordar tarifas/SLA.
2. Implemente 'createPayment' con la selección del canal App2App/QR para mobile/offline.
3. Conecte webhooks, temporizadores, repeticiones e idempotencia.
4. Configure recon (daily + full), almacenamiento de referencias UTR/fin.
5. Apoye los refundidos parciales/completos, procedimientos ODR en sapport.
6. Habilite el routing inteligente (A2A prioritario, tarjeta fallback), alertas de conversión/latencia.
7. Cubrir con pruebas e2e bancos/plataformas móviles/POS.

Tarjeta de referencia

Los estados de la tarjeta son: 'authorized/approved', 'declined', 'timeout'.
Статусы A2A: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement: mapa T + 1/T + 2, A2A a menudo T + 0/T + 1.
Límites: per-txn/day/week; para los nuevos destinatarios: umbrales reducidos.
Recurrent: tarjeta (COF/MIT) o A2A a través de e-mandate/SEPA DD.

El motor de la caja registradora es construible en dos rieles: Payconiq-A2A para bajo costo y la tarjeta Bancontact como un fallback universal.
Compartimos la confirmación en línea y el settlement en la lógica empresarial, incluimos refundiciones parciales y un ODR claro.
No fijamos los importes: mantenemos las confecciones de límites por banco/canal y la actualización regular.
Para mobile - App2App/QR, para retail - NFC + dinámico QR, para suscripciones - primer pago → mandato.