TWINT Suiza: QR y en-app

1) Contexto y posicionamiento de TWINT

TWINT es un esquema suizo de pagos móviles A2A y billetera integrado con los bancos del país. El usuario paga desde la aplicación TWINT/bank: en línea - a través de in-app/App2App o Deep Link, fuera de línea - a través de QR (estándar «TWINT QR»). La confirmación se realiza en el anexo (SCA: PIN/biometría), los fondos se cargan en la cuenta/tarjeta asociada y se acreditan al merchant con un crédito bancario.

• Marca única/QR para online y POS, alta cobertura de usuarios.
• Confirmación instantánea en línea para UX y settlement rápido (dentro de las ventanas bancarias).
• P2P por número de teléfono/contacto dentro del ecosistema.
• Feed bajo debido a SCA y device binding.

2) Participantes y roles

TWINT (diagrama/switch): reglas, directorios de miembros, enrutamiento.
Bancos participantes/emisores TWINT: KYC, límites y antifraude.
PSP/Equyers: conectan merchant (en línea/POS), proporcionan API/SDK, ganchos web e informes.
Merchant: inicia el pago/solicitud, procesa los estados/devoluciones, mantiene la conciliación.
Pagador: confirma las transacciones en la aplicación TWINT/banco.

3) Canales y scripts personalizados

3. 1 E-commerce: in-app / Deep Link / App2App

En el cheque, el merchant crea un intent de pago → da a Deep Link/el botón «Pay TWINT».
La aplicación TWINT se abre (App2App), el usuario confirma → devolución a la caja registradora con el estado.
Para el escritorio, se muestra un QR por pedido dinámico; el cliente escanea en la aplicación y confirma.

3. 2 POS/offline: TWINT QR

QR dinámico en la pantalla de la caja registradora/terminal: suma, ordenId, metadatos.
El usuario analiza → confirma en la aplicación → el merchant recibe el estado en línea.
El QR estático (la suma se introduce manualmente) es aplicable para donados/pequeños minoristas, pero peor en la conciliación.

3. 3 P2P «por teléfono»

Transferencias entre personas por número de teléfono/contacto con confirmación push y crédito instantáneo al destinatario.

3. 4 Request-to-Pay / Pay-by-Link

Merchant inicia una solicitud de pago (cantidad/destino/término) → el cliente confirma en la aplicación → el pago pasa por el flow A2A normal.

4) Estados y tiempos

Los estados tipo son: 'iniciated' → 'pending' → 'success'/' failed '/' canceled '/' expired'.
Para QR/escritorio, tenga en cuenta el tiempo de espera para la confirmación (muestre el temporizador).
Settlement: crédito bancario T + 0/T + 1 dependiendo de la ventana de liquidación/PSP; la recon diaria sigue siendo obligatoria para la presentación de informes.

5) Límites y políticas de riesgo

• Per-transaction, per-day/24h, a veces weekly/monthly.
• Nuevo receptor/merchant: umbrales reducidos y/o velocidad de obturación.
• Límites de canal: e-commerce (Deep Link/QR), POS, P2P, Request-to-Pay.
• Las reglas velocity/device/geo son aplicadas por los bancos y el esquema.

6) Economía y Comisiones

Para el merchant, TWINT suele ser más barato que el típico MDR de tarjeta; las condiciones varían en PSP (fix/bajo%).
Ingrese los costos de integración/SDK, procesamiento 'pending/expired', soporte/ODR y conciliación.

7) Devoluciones y Dispouts

Chargeback (como en las tarjetas) no existe. Devoluciones - Una nueva operación de crédito del merchant al pagador; se admiten refundiciones parciales.
Los plazos de devolución son bancarios (normalmente T + 0/T + 1).
Disputs/quejas - por procedimientos PSP/banco; guarde los registros de la orden, confirmación de la prestación del servicio/entrega, paquete de refund↔order.

8) Seguridad y cumplimiento

SCA en la aplicación TWINT/banco (PIN/biometría), device binding.
Antifraude en el banco/PSP: velocity, nuevos destinatarios, puntuación de riesgo.
Minimización y encriptación PII, HMAC/nonce en hooks web, protección de replay, registro de auditoría.
Cumple con los requisitos locales de servicios de pago y con las normas de protección de datos comparables al RGPD.

9) Integración de merchant

Opciones

1. Hosted/Embedded en PSP - inicio rápido, in-app/QR fuera de la caja, estados y errores.
2. Server-to-Server + Deep Link/QR - UX nativo, QR dinámico por pedido, manejo de errores fino.
3. Pay-by-Link/Request-to-Pay - facturación por enlace (correo electrónico/SMS/mensajero).

• API: `createPayment`, `refund`, `requestToPay`, `webhook`, `reconcile`.
• Idempotencia ('orderId' + clave), retraídas exponenciales, dedoup de eventos.
• Recon: daily auto-recon + periódico full-recon; almacene la referencia UTR/bancaria.
• SLA-dashboards: conversión, 'pending→success/expired', tiempo antes de la inscripción/devolución.

10) Conciliación y presentación de informes

Lógica: 'paymentId/transactionId' del proveedor, 'orderId', canal (App2App/QR/Link), banco del pagador, estado, cantidad/moneda, timestamp, UTR.
Desde PSP/banco: registros de inscripción/devoluciones/correcciones, actualizaciones de estado tardías.
Personalice las alertas de acuerdo a los rassincrones y los «colgados» de 'pending'.

11) Prácticas UX

Mobile-first: en móviles - in-app/App2App; en el escritorio, un QR dinámico grande con un temporizador.
Recuperación: con 'timeout/expired' es una repetición y alternativa segura (mapa/SEPA/otro A2A).
Recibo: cantidad, tiempo, 'transactionId', canal, UTR, contactos de sapport.
Retroiluminación de riesgos/límites: muestra al usuario quién ha puesto el umbral - el banco o el canal.

12) Reincorporación y mandatos

El TWINT básico es uno-off con SCA. Para las suscripciones se utiliza un paquete: el primer pago TWINT → e-mandate/SEPA DD/Open-Banking para futuros cargos (límite/periodicidad/notificaciones).
Proporcione al usuario una pantalla de administración de mandatos (pause/cancel/update) y una notificación previa antes de realizar el cargo.

13) Verticales de alto riesgo (incluyendo iGaming)

La disponibilidad de los canales y los límites dependen de la política bancaria/PSP y del derecho local.
Esperar umbrales reducidos, KYC reforzado, posibles hold's.
Planifique raíles alternativos (tarjetas, SEPA, otros PIS) y una ruta inteligente por riesgo/canal/banco.

14) Arquitectura «TWINT 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: conversión por canal (App2App/QR/Link), cuota de 'pending→expired', tiempo antes de settlement/devoluciones.

15) Check-list de la salida en el prod

1. Conecte TWINT con PSP/banco; seleccione los canales (App2App/QR/Link).
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/estados suspendidos.
7. Realice pruebas e2e con los principales bancos/dispositivos y POS (si es relevante).

Tarjeta de referencia de límites

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

Resumen

Para el online - in-app/App2App + dinámico QR, para la venta al por menor - TWINT QR, para las traducciones - P2P al teléfono.
Comparta la confirmación en línea y el crédito final; construye alrededor de webhooks + recon y refundos parciales.
No registre cantidades: Mantenga los límites de los bancos/canales y actualice regularmente.
Para las suscripciones, el primer TWINT → un mandato con una gestión y notificaciones transparentes.