Sofort/Klarna: pay-by-bank

1) Qué es Sofort/Klarna Pay-by-Bank

Sofort (ahora Klarna Pay Now/Pay-by-Bank) es una herramienta A2A que permite al comprador pagar el pedido directamente desde su cuenta bancaria a través de un banco en línea/aplicación móvil. El flujo se construye típicamente sobre la issuer-redirect/App2App de confirmación SCA (PSD2), y el merchant recibe la autorización en línea (success) y luego el crédito bancario sobre los informes/pagos del proveedor.

• Bajo costo con respecto a las tarjetas MDR.
• El estado en línea (éxito/fracaso) es casi inmediato, con la acreditación de fondos no siempre instant (normalmente T + 1/T + 2).
• Amplia geografía en la UE/EEE (especialmente fuerte Alemania/Austria), apoyo a decenas de bancos emisores.
• Un mínimo de detalles de pago del comprador es la elección del banco y la confirmación.

2) Roles y participantes

Klarna/Sofort (esquema/proveedor): routing a los bancos, estados, informes, cálculos, devoluciones.
Issuer (banco del pagador): SCA, confirmación de cargo, límites/antifraude.
Merchant PSP/Acquirer: conexión de merchant, API/SDK, webhooks y recon.
Merchant (vendedor): inicio de pago, procesamiento de estados/devoluciones, conciliación.

3) Flujos de pago: Redaprox y App2App

3. 1 Classic redirect

1. Checkout merchant → la selección de «Pay by bank (Sofort/Klarna)».
2. La lista de bancos → redireccionar a un banco en línea (o a una página hosted del proveedor) → SCA.
3. El banco confirma el pago → la devolución al merchant con estado (success/failed/canceled/pending).
4. Merchant registra el pedido como «pagado/pendiente», esperando un webhook/informe de inscripción.

3. 2 App2App / Mobile

En los dispositivos móviles, el merchant abre la aplicación bancaria por deeplink/intent → confirmación → devolución según el esquema anterior.
La conversión es anterior, la fricción es menor; Mantenga el back en redireccionamiento web.

3. 3 Request-to-Pay/Embedded opciones

Una serie de bancos están disponibles request-to-pay/PIS a través de las interfaces del proveedor (el comprador recibe la solicitud en el banco-app).
Los widgets embedded de PSP simplifican la lista de bancos, errores y estados.

4) Límites y comportamiento de los bancos

• Per-transaction, per-day/week en el banco del pagador.
• Nuevos destinatarios/merchantes - umbrales reducidos, la velocidad de obturación es posible.
• Canales (mobile/web), reglas de velocidad, señales geo/device.
• En algunos países/bancos, las exenciones de SCA por umbral (RA, TRA) son posibles - dependen del banco.

5) Estados y matrícula (authorization vs settlement)

Online status: `success`, `pending`, `failed`, `canceled`, `expired`.
El pending es posible cuando se retrasa la confirmación o la verificación asíncrona.
Settlement: el crédito real viene de los informes del proveedor (generalmente T + 1/T + 2 días bancarios; depende del país/banco/esquema de compensación).
Para servicios críticos, utilice el modelo de «autorización ⇒ ejecución condicional» antes de confirmar la inscripción.

6) Devoluciones, devoluciones parciales y dispouts

Chargeback (como en las tarjetas) no existe. La devolución es una nueva operación de préstamo a través de un proveedor al pagador.
Los refundidos parciales son compatibles.
Los plazos de abono de la devolución son bancarios (T + 1/T + 2).
Las dispouts/quejas pasan por el procedimiento ODR del proveedor + a través del banco del pagador; preparar registros de pedidos, proof-of-delivery/servicios.

7) La Comisión y la economía

Normalmente, un fix/bajo porcentaje con una transacción + tarifa de función de plataforma (checkout alojado, informes, ODR).
Tenga en cuenta el costo de soporte (pending/expiries), los incidentes de riesgo y los costos de transacción de recon.

8) Conciliación y presentación de informes (reconciliation)

Guardar 'paymentId/transactionId' del proveedor, 'orderId', banco-issuer, etiquetas de tiempo, estados.
Habilita webhooks sobre cambios de estado y auto-recon diario.
Combine los eventos en línea (éxito/pending) con los informes financieros (acreditaciones/reembolsos/correcciones).
Guarde la referencia UTR/bancaria del informe para cada transacción.

9) Prácticas UX

Directorio de bancos: presione la última opción, ordene por popularidad/lata del dispositivo.
Mobile-first: ofrecer App2App, fallback - redireccionamiento web.
Errores y repetición: entendamos las causas (límite, fallo SCA, tiempo de espera), el botón de repetición y las alternativas.
Idempotencia: 'orderId' + clave de idempotencia para repeticiones seguras.
Recibo: cantidad, fecha/hora, 'transactionId', banco, canal (App2App/Redesp).

10) Cancelaciones recurrentes y mandatos

Sofort clásico - one-off. Para los modelos recurribles se utiliza un conjunto: el primer pago A2A → e-mandate/SEPA DD/Open Banking PIS para el futuro.
Administrar los mandatos (límite, frecuencia, notificaciones), almacenar los registros de aceptación.

11) Cumplimiento, seguridad, datos

PSD2/SCA: confirmación en el banco, device binding, antifraude del banco.
Minimización PII: almacena sólo los atributos necesarios; cifrar PII; Firmas HMAC de ganchos web.
GDPR/Logs: consentimiento, derecho de eliminación, auditoría de cambios.

12) Verticales de alto riesgo (incluyendo iGaming)

La disponibilidad de Pay-by-Bank para algunas categorías se limita al proveedor/banco por políticas internas y derecho local.
Espere límites reducidos, dop. CUS/Finmingering, posibles hold's.
Mantenga los raíles alternativos (tarjetas, SEPA, open banking A2A, vales) y la segmentación del tráfico.

13) Integración de merchant: opciones

1. Hosted/Embedded от PSP/Klarna

Inicio rápido: widget de selección de banco, estados, errores, webhooks «fuera de la caja».

2. Server-to-Server + redirect/App2App

Más control: página propia de los bancos, manejo fino de errores, QR/Deep Link propios.

3. Facturas/Solicitudes de pago

Envío de una solicitud de pago (correo electrónico/SMS/enlace), conveniente para B2V/servicios.

• Эндпоинты: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Idempotencia y tabla dedupe por 'orderId'.
• Retrés por exponente para obtener estados, letter muerto para respuestas inestables.
• Catálogos: bancos/países, límites/códigos de error, métricas SLA por issuer 'am.

14) Arquitectura «Sofort/Klarna Gateway»

Capa API (NAT/GraphQL) para la caja registradora.
Colas de eventos: eventos de estado → facturación/CRM/análisis.
Observabilidad: conversión por banco/canal, 'pending→success/expired', latencia, fallo de SCA.
Security: vault for secrets, proveedor de IP-allowlist, tokens anti-replay, validación estricta de URIs.

15) Check-list de la salida en el prod

1. Seleccione el canal PSP/Klarna/Sofort con la geografía de bancos deseada.
2. Implementar 'createPayment' + selección de banco + redirect/App2App con fallback.
3. Conecte webhooks, idempotencia, temporizadores y estados de repetición.
4. Configure recon (daily + full), almacenamiento de referencias UTR/fin.
5. Incluya los refundidos parciales/completos y el reglamento ODR en el sapport.
6. Prepare escenarios de fallos/límites UX y métodos alternativos.
7. Pruebe los bancos móviles (iOS/Android) y los principales issuer's en los países objetivo.
8. Mantenga un directorio de límites y una página de estados de incidentes.

Tarjeta de referencia

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement: más frecuentemente T + 1/T + 2; planificar la «ejecución condicional» antes del préstamo.
Límites: per-txn/day/week en issuer 'a; para los nuevos destinatarios - abajo.
Recurrent: a través de e-mandate/SEPA DD/Open Banking.

Resumen

Para la conversión - App2App/Embedded, para la sostenibilidad - claro webhooks + recon.
Comparta la confirmación en línea y el crédito real (T + 1/T + 2) en la lógica empresarial.
No registre sumas estrictas: restricciones de bancos/países + actualizaciones periódicas.
Para suscripciones, utilice el primer pago A2A → mandato, con controles y límites UX claros.