Giropay Alemania: banca en línea

1) Contexto y posicionamiento giropay

giropay es un esquema A2A alemán de «pay-by-bank» donde el comprador confirma el pago en su banco de Internet/aplicación móvil del banco emisor. El merchant recibe el estado en línea y el dinero proviene de un préstamo bancario (generalmente T + 0/T + 1 días hábiles, depende del banco/PSP y del carril de liquidación utilizado). El costo de recepción es inferior al MDR típico de la tarjeta, el SCA se realiza en el emisor de acuerdo con el PSD2.

• Issuer-redirect/App2App: redireccionar el banco o abrir su aplicación.
• SCA y device binding: confirmación en el banco, minimización del frode.
• Metadatos ricos para la conciliación: merchant reference/orderId, transactionId.
• Refund a través de transferencia de crédito: charjback como en las tarjetas no.

2) Roles y participantes

Esquema de giropay - reglas, routing a los bancos.
Issuer (banco del pagador) - autenticación del cliente, confirmación, límites/antifraude.
PSP/Acquirer (CPSP) - Conexión de merchant, API/SDK, webhooks, informes y cálculos.
Merchant - Iniciar el pago, procesar los estados/devoluciones, conciliar.

3) Flujos de pago

3. 1 Classic issuer-redirect (web)

1. Checkout merchant → una selección de giropay.
2. La lista de bancos → redireccionar a un banco en línea → SCA/confirmación.
3. Devuelve al sitio de merchant con estado (success/pending/failed/canceled/expired).
4. Espera webhook/registro sobre el crédito real (settlement).

3. 2 App2App (mobile)

En el teléfono, el merchant abre la aplicación bancaria por deeplink/intent → confirmación → devolución.
La conversión suele ser mayor; es obligatorio fallback en redireccionamiento web.

3. 3 QR/Pay-by-Link

PSP puede dar QR/enlace dinámico con suma y referencia (conveniente para facturas/offline).
El usuario escanea el código y lo confirma en el banco siguiendo el esquema anterior.

3. 4 «Primer pago → mandato»

Para facturas recurribles, giropay a menudo se utiliza como el primer pago con SCA y luego - SEPA Direct Debit/open-banking mandato para los cargos posteriores.

4) Estados y cálculos (authorization vs settlement)

Online-статусы: `success`, `pending`, `failed`, `canceled`, `expired`.
'pending' significa que el banco/proveedor aún confirma la realización o se espera un préstamo.
Settlement: inscripción real en los informes PSP/banco (normalmente T + 0/T + 1; en algunos casos durante más tiempo).
Para servicios sensibles al riesgo, utilice el modelo de «ejecución condicional» antes de la inscripción confirmada.

5) Devoluciones y Dispouts

Chargebacks no está. Las devoluciones son una nueva operación de préstamo de merchant al pagador (es posible realizar devoluciones parciales).
Los plazos de devolución son bancarios (T + 0/T + 1/T + 2, depende del canal).
Disputs/quejas - a través de los procedimientos ODR del PSP y el banco del pagador; preparar registros de pedidos, proof-of-delivery/servicios.

6) Límites y políticas de riesgo

• Per-transaction, per-day/week у issuer’а.
• Nuevos destinatarios/merchantes: umbrales reducidos y/o velocidad de obturación.
• Reglas de canal/velocity, señales geo/device, excepciones SCA (TRA/RA) - a discreción del banco.

Práctica: no hardcodes los números. Mantenga un directorio de límites por banco/canal, actualícela, muestre razones claras para las fallas («excedido el límite banco/canal») y sugiera alternativas (romper cheque, otro método).

7) La Comisión y la economía

Para giropay, normalmente se aplica un fix/bajo porcentaje a la dirección PSP; debajo de la tarjeta MDR.
Tenga en cuenta los costos de soporte de pending/expiries, ODR y recon, así como las tarifas de widgets alojados/embedded e informes.

8) Conciliación y presentación de informes

Almacena: 'paymentId/transactionId' del proveedor, 'orderId', banco-issuer, tiempo, canal (Redesp/App2App/QR), estado final, referencia bancaria/UTR de informes finales.
Incluye webhooks sobre cambios de estado, auto-recon diario y recon completo periódico (inscripciones/devoluciones/correcciones).
Personalice las alertas de los rassincrones y los dashboards SLA.

9) Patrones UX

Directorio de bancos: Autocorrección/búsqueda, memorización del último banco.
Mobile-first: ofrecer App2App; fallback - redireccionamiento web.
Errores y repeticiones: causas claras (límite, fracaso de SCA, tiempo de espera), retracción segura con idempotencia.
Recibo: cantidad, fecha/hora, 'transactionId', banco, canal, enlace a sapport.

10) Cancelaciones recurrentes

Utilice el esquema: primer pago giropay → e-mandate (SEPA DD/Open Banking).
En el mandato, fije el límite per debit, la frecuencia, las notificaciones y la gestión (pause/cancel).

11) Cumplimiento y seguridad

PSD2/SCA se realiza en el banco; device binding y antifraude en el lado issuer 'a.
GDPR/PII-minimización: almacenar sólo los atributos necesarios, cifrar PII, restringir el acceso.
Webhooks: HMAC/nonce, protección de respuesta, allowlist IP, registro de auditoría.

12) Verticales sensibles (incluyendo iGaming)

La disponibilidad de giropay y los límites dependen de la política de PSP/bancos y de la ley local.
Espere umbrales reducidos, KYC extendido y posibles hold's.
Planifique raíles alternativos (tarjetas, SEPA, otros PIS de banca abierta), enrutamiento inteligente según el perfil del cliente.

13) Integración de merchant: opciones

1. Hosted/Embedded de PSP - inicio rápido, lista de bancos terminados, estados, errores.
2. Server-to-Server + Redirect/App2App es la página de selección de banco nativa, manejo profundo de errores, enlace QR/Deep nativo.
3. Facturas/Rau-by-Link/QR - conveniente para B2V/offline.

• API: `createPayment`, `queryStatus`, `refund`, `webhook`, `reconcile`.
• Idempotencia (orderId + clave), retraídas por exponente, dedoup de eventos.
• Catálogos: bancos/límites/códigos de error; SLA-métricas por issuer 'am.

14) Arquitectura «giropay Gateway»

La 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 a settlement.
Seguridad: vault para secretos, PSP de IP-allowlist, validación estricta de URI de redireccionamiento, tokens anti-replay.

15) Check-list de la salida en el prod

1. Seleccione PSP/canal giropay (Hosted/Embedded/App2App/QR), acuerde tarifas y SLA.
2. Implementar 'createPayment' + selección de banco + redirect/Arr2Arr con fallback.
3. Conecte webhooks, temporizadores y repeticiones para obtener estados.
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. Cubre con pruebas los bancos móviles (iOS/Android) y los principales issuer's.

Tarjeta de referencia

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

Resumen

Apueste por App2App/Embedded de conversión y por QR/Pay-by-Link dinámico para facturas/offline.
Comparta la confirmación en línea y el crédito real en la lógica empresarial.
No codifique con rigor las cantidades: mantenga las confecciones de límites a través de bancos/canales y actualice regularmente.
Construye el proceso alrededor de webhooks + recon, devoluciones parciales y procesamiento claro 'pending/expired'.