Swish Suecia: pagos móviles

1) Qué es Swish

Swish es el sistema nacional sueco de pagos móviles A2A (operador de Getswish AB) con transferencias instantáneas 24/7. El usuario confirma las transacciones a través de BankID (SCA). Se admiten scripts P2P (por teléfono), P2M para negocios (en línea y fuera de línea), donados y pagos.

• Direccionamiento por número de teléfono (o número de merchant/QR), sin IBAN en UX.
• Abono instantáneo en la cuenta bancaria del destinatario; la finalidad de la transferencia bancaria.
• Baja fricción: App2App/QR, confirmación en BankID.
• Amplia cobertura bancaria y alta popularidad en venta al por menor/en línea.

2) Roles y productos

Getswish (esquema) - reglas, catálogos y marca.
Bancos participantes: liberan/conectan Swish, aplican límites y antifraude.
PSP/Equyers - conectan los merchantes (Swish Handel/Swish Företag), proporcionan API/SDK, informes, settlement.

• Swish P2P - transferencias entre particulares.
• Swish Företag - aceptar pagos fuera de línea (escaparate/POS).
• Swish Handel (Swish para e-commerce) es un cheque en línea (QR/App2App/Link).
• Swish Donations - números cortos/alias para donaciones.
• Swish Payouts/Disbursements - Pagos masivos (a través del banco/PSP).

3) Flujos de pago

3. 1 P2P (push)

1. El remitente selecciona el contacto por teléfono → introduce el importe/mensaje.
2. Confirma en BankID (Face/Touch/código).
3. El destinatario ve instantáneamente el crédito en la cuenta y la notificación en la aplicación.

3. 2 P2M: e-commerce (Swish Handel)

• App2App/Deeplink: en el cheque abrimos la aplicación Swish/BankID → confirmación → devolución al merchant.
• QR per-order: se genera un QR dinámico (suma, ordenId, referencia merchant); el cliente escanea con una cámara Swish → confirma en BankID.

3. 3 POS/offline (Företag)

QR dinámico en la caja registradora o número Swish estático (suma manual).
Confirmación en BankID; cheque en el merchant y en la aplicación del cliente.

3. 4 Request-to-Rau/Facturas

Merchant envía un enlace de pago/solicitud (en correo electrónico/SMS/mensajero); el cliente confirma en BankID.

3. 5 Pagos (Payouts)

El negocio envía al cliente una transferencia de dinero al número de teléfono a través del banco/PSP; se aplican anticongelantes y límites a los salientes.

4) Estados y tiempos

Los estados tipo son: 'iniciated' → 'pending' → 'success'/' failed '/' canceled '/' expired'.
Puede haber demoras en la respuesta de la aplicación/ID de BankID para la validación web → mantenga los temporizadores y la repetición de estado (polling + webhooks).
Settlement for Merchant - Crédito bancario en tiempo real/en la ranura operativa más cercana dependiendo del banco/PSP (para reportes, siga haciendo recon diario).

5) Límites y políticas de riesgo

• Per-transaction, per-day/24h; a veces semanalmente/monthly.
• Nuevo receptor/nuevo merchant: umbrales reducidos/velocidad de obturación.
• Límites de canal: P2P, e-commerce (App2App/QR), POS, payouts.
• Velocity/device/geo-regulaciones y puntuación de riesgo en el lado del banco.

6) Economía y Comisiones

El coste para el merchant suele ser inferior al clásico MDR de tarjeta, pero las condiciones dependen del banco/PSP (fix/bajo porcentaje, tarifa QR/SDK/informes).
Implemente los costos de soporte de 'pending/expired', disputs, recon y monitoreo de SLA.

7) Devoluciones y Dispouts (ODR)

Chargeback como no hay mapas. Devoluciones: operación de crédito separada del merchant al cliente (se admiten refundiciones parciales).
Los plazos son bancarios (generalmente T + 0/T + 1).
Disputs - por procedimientos bancarios/PSP: almacenar registros de pedidos, confirmación de entrega/entrega, cumplimiento de datos del cliente.

8) Seguridad y cumplimiento

SCA a través de BankID, binding de dispositivos, verificación de SIM/dispositivos por el banco.
Minimización PII: almacenar sólo los atributos necesarios (teléfono/referencias), cifrar PII; Acceso - por el principio de los privilegios más pequeños.
Webhooks: HMAC/nonce, protección de respuesta, timeline y dedoup de eventos.
Cumple con los requisitos PSD2/GDPR y locales de Finansinspektionen.

9) Integración de merchant

Opciones

1. Hosted/Embedded de PSP - inicio rápido, App2App/QR fuera de la caja, estados y errores.
2. Server-to-Server + App2App/QR - UX nativo, QR dinámico por orden, manejo profundo de errores/repeticiones.
3. Pay-by-Link/Invoice - Enviar un enlace/solicitud; conveniente para servicios y B2B.

• API: 'createPayment', 'refund', 'requestToPay' (si está disponible en PSP), 'webhook', 'reconcile'.
• Idempotencia ('orderId' + clave), retraídas exponenciales, dedoup de eventos.
• Recon: daily auto-recon + periódico full-recon; almacenar la referencia UTR/bancaria.
• 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' del proveedor, 'orderId', canal (App2App/QR/Link/POS), número de destinatario, estado, cantidad/moneda, timestamp, UTR.
Desde PSP/banco: registros de inscripción/devoluciones/correcciones, actualizaciones de estado tardías.
Habilita alertas por rassincronas y anomalías (dobles descargas, suspendidas por 'pending').

11) Patrones UX

Mobile-first: auto-oferta App2App; en el escritorio, un QR dinámico grande con un temporizador.
Errores transparentes: límite, fallo de BankID, tiempo de espera; repetición segura y alternativa (tarjeta/SEPA/A2A de otro proveedor).
Recibo: cantidad, tiempo, 'transactionId', canal, UTR, contactos de sapport.
Temporizador de actividad para QR/solicitudes y escenario de recuperación después de la expiración.

12) Reincorporación y mandatos

El Swish básico es uno-off con SCA. Para las suscripciones se aplica un paquete: el primer pago Swish → e-mandate/Autogiro/Open-Banking PIS para más cargos (límite/frecuencia/notificaciones, pantalla de gestión de mandatos).

13) Verticales de alto riesgo (incluyendo iGaming)

La disponibilidad de canales y límites depende de las políticas bancarias/PSP y de la ley local.
Espere umbrales reducidos, KYC extendido y posibles hold's.
Planifique raíles alternativos (mapas, SEPA, otros PIS) y una ruta inteligente por riesgo/banco/canal.

14) Arquitectura «Swish 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/POS/Link), fracción 'pending→expired', tiempo antes de settlement/devoluciones.

15) Check-list de la salida en el prod

1. Conecte el PSP/banco con Swish Handel/Företag; acordar tarifas/SLA y canales (App2App/QR/POS/Link).
2. Implemente 'createPayment' + QR/App2App dinámico, pantallas de error/límites.
3. Conecte webhooks, idempotencia, retraídas y dedoup de eventos.
4. Configure recon (daily + full), almacenamiento de referencias UTR/fin.
5. Habilite 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 bancos/dispositivos principales, 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 P2P, e-commerce (App2App/QR), POS, payouts.
Velocity/riesgo: el antifraude del banco puede desviar/ralentizar suavemente las operaciones.

Resumen

Para online - App2App + dinámico QR, para offline - QR/POS (Företag), para traducciones - P2P al teléfono.
Comparta la confirmación en línea y el crédito final en la lógica empresarial; construye alrededor de webhooks + recon y refundos parciales.
No fije cantidades: Mantenga los límites de los bancos/canales con actualizaciones regulares.
Para las suscripciones, el primer Swish → un mandato con una gestión y notificaciones transparentes.