Trustly: pagos bancarios directos

1) Qué es Trustly

Trustly es un proveedor A2A (account-to-account) de pagos y pagos que conecta los merchantes con los bancos de los pagadores a través de redirect/App2App. El comprador confirma la transferencia en su banco (SCA por PSD2), el merchant recibe al instante la confirmación en línea y el abono de los fondos llega a través de los informes/cálculos del proveedor.

• Bajo costo con respecto a las tarjetas MDR.
• Amplia geografía en Europa (Nordics, DACH, Benelux, UK, Southern EU, etc.) + bancos locales.
• Pay-ins y Payouts (incluidos los pagos instantáneos para los bancos admitidos).
• Soluciones especializadas para iGaming (por ejemplo, Pay N Play: «depósito → cuenta creada/verificada»).

2) Línea de productos y guiones

Pay-in (pago bancario): redirect/App2App al banco del pagador → SCA → éxito en línea/rechazo → crédito posterior.
Payouts (pagos): transferencia a la cuenta del usuario; para un número de bancos - instantáneamente (de lo contrario T + 1/T + 2).
Pay N Play (iGaming): combina el depósito con el onboarding: se extraen señales KYC de los datos bancarios (nombre, IBAN/BIC, etc.), se crea una cuenta de juego sin registro separado, es posible volver a Fast Withdraw a la misma cuenta.
Cuenta Info/Check (opcional): confirmación de la propiedad de la cuenta, verificación de nombre/IBAN para anti-mule/ODR.

3) Flujos de pago: Redaprox y App2App

3. 1 Classic redirect

1. Checkout merchant → selección de banco (directory/search).
2. Redireccione a la página del banco o a la pantalla de → SCA alojada.
3. Devuelve al sitio de merchant con estado (success/pending/failed/canceled/expired).
4. Espera webhook/informe de inscripción (settlement).

3. 2 App2App (móvil)

Abrir una aplicación bancaria a través de deeplink/intent → confirmación → devolución.
Mayor conversión y menos pagos abandonados; asegúrese de mantener el fallback en el redireccionamiento web.

3. 3 Payouts

Inicie el pago a través de la API con la referencia orden/ganar; obtiene el estado en línea «aceptado para el procesamiento» y el total de webhook/registro.
Mantener la idempotencia y la tarjeta de estado de pago es crítica (hasta repeticiones/retrocesos).

4) Límites y políticas de riesgo

• Per-transaction y per-day/week limites en el banco del pagador.
• Nuevos destinatarios/merchantes: umbrales reducidos y/o velocidad de obturación.
• Reglas de canal/velocity, señales geo/device, anti-mulas.
• Para payouts: comprobaciones de cuotas/umbrales individuales (especialmente instant).

5) Estados y cálculos: éxito en línea vs crédito real

Online status: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement: inscripción real en los informes/registros Trustly (a menudo T + 1/T + 2 días bancarios; para algunas direcciones/pagos - instant).
Para los servicios críticos, aplique el modelo de «ejecución condicional antes del crédito» (por ejemplo, activación de un artículo digital después de confirmar settlement).

6) Devoluciones y Dispouts

Chargeback como no hay mapas. Devoluciones - una nueva operación de crédito a través del proveedor al pagador.
Los refundidos parciales son compatibles.
Los plazos de devolución son bancarios (normalmente T + 1/T + 2).
Disputs - a través de los procesos ODR del proveedor y el banco del pagador: prepare registros de pedidos, confirmación de entrega/prestación del servicio, comunicaciones payout↔pay -in.

7) La Comisión y la economía

Por lo general, fix/bajo porcentaje por transacción + tarifas por funciones de plataforma (checkout alojado, reporting, ODR, payouts/instant).
Planifique los costos de soporte para pending/expiries, ODR y recon.

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

Almacena 'paymentId/transactionId' del proveedor, 'orderId', banco-issuer, etiquetas de tiempo, UTR/referencia bancaria de los informes finales.
Conecte webhooks para cambiar el estado; ejecute el auto-recon diario y el full-recon periódico (movimiento de inscripciones/devoluciones/correcciones).
Para payouts: registros individuales y correlación con los balances de pago/juego originales.

9) Prácticas UX

Directorio de bancos: búsqueda rápida, clasificación por popularidad/última elección.
Mobile-first: ofrecer App2App; si se rechaza - fallback en la web.
Errores y repeticiones: códigos de causa claros (límite, fallo SCA, tiempo de espera), botón de repetición, métodos alternativos.
Idempotencia: 'orderId' + clave de idempotencia para safe-retry.
Recibo: cantidad, tiempo, 'transactionId', banco, canal (App2App/Redesp), enlace a sapport.
Payout UX: ETA transparente (instant/T + 1), estado de seguimiento, notificaciones.

10) Pay N Play (para iGaming)

Onboarding sin formulario de registro: el usuario elige el banco, confirma el depósito, y el proveedor da al merchant los datos bancarios verificados (nombre/cuenta) - se crea una cuenta de juego.
Las señales KYC del banco reducen la fricción y aceleran el primer depósito.
Fast Withdraw: pagos en la misma cuenta confirmada, a menudo instantáneamente.
Se requieren políticas estrictas de juego responsable, límites de depósitos, registro de mandatos y ODR transparente.

11) Cumplimiento y seguridad

PSD2/SCA, device binding y antifraude del banco emisor.
GDPR/PII-minimización: almacenar sólo los atributos necesarios, cifrar PII, restringir el acceso.
Webhooks: firmas HMAC/nonce, protección contra replay, allowlist IP.
AML/sanciones: monitoreo de transacciones, verificación del nombre de la cuenta (name match), señales anti-mule.

12) Verticales de alto riesgo

La disponibilidad y los límites para algunas categorías (incluyendo iGaming, cripto, etc.) dependen del país y de los bancos asociados.
Espere: límites más estrictos, KYC ampliado, posibles hold's y pruebas adicionales.
Mantenga raíles alternativos (tarjetas, SEPA, PIS de banca abierta de otros proveedores), enrutamiento por perfil de cliente.

13) Integración de merchant: opciones

1. Hosted/Embedded del proveedor

Inicio rápido, lista de bancos terminados, estados, errores, webhooks.

2. Server-to-Server + Redirect/App2App

Más control: propia página de selección de banco, procesamiento profundo de errores, deeplink/QR propios.

3. Factura/Solicitud de pago

Referencia de enlace de pago por correo electrónico/SMS/mensajero instantáneo; conveniente para B2V/servicios.

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

14) Arquitectura «Trustly Gateway»

Capa API (NAT/GraphQL) para los servicios de caja y cajero.
Colas de eventos: eventos de estado → facturación/CRM/backend/análisis de juegos.
Observabilidad: conversión por banco/canal, 'pending→success/expired', latencia media a settlement, cuota instant payouts.
Security: vault for secrets, IP-allowlist, validación estricta del URI redireccional, tokens anti-replay.

15) Check-list de la salida en el prod

1. Seleccione geografías/bancos y conecte el canal Trustly con PSP.
2. Implementar 'createPayment' + selección de banco + redirect/App2App con fallback.
3. Conecte webhooks, temporizadores y repeticiones para obtener estados.
4. Configure recon (daily + full), almacenamiento de referencias UTR/fin.
5. Incluya refundidos parciales/completos, registros ODR, procedimientos de sapport.
6. Para iGaming - ejecutar Pay N Play, límites de depósito, Fast Withdraw, seguimiento del juego responsable.
7. Construya el monitoreo de SLA a través de bancos/canales y alertas de incidentes.
8. Pruebe los bancos móviles (iOS/Android) y los principales issuer's por países.

Tarjeta de referencia

Статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
Settlement pay-in: con más frecuencia T + 1/T + 2; payouts - instant donde está disponible, de lo contrario T + 1/T + 2.
Límites: per-txn/day/week en issuer 'a; nuevos destinatarios: umbrales reducidos.
Recurrent: a través de e-mandate/SEPA DD/Open Banking (primer A2A → mandato).

Resumen

Apueste por App2App/Embedded de conversión e instant payouts para retener.
Comparta la confirmación en línea y el crédito real en la lógica empresarial.
No registre cantidades: Mantenga los límites de los bancos/países/canales.
Para iGaming, utilice Pay N Play con KYC transparente, límites y pagos rápidos.