Vales en efectivo y cadenas minoristas

1) Qué es y cuándo aplicar

Los vales en efectivo y las redes eCash le permiten aceptar el pago sin tarjetas bancarias e IBAN. El usuario compra un cupón de prepago (PIN) o recibe un código de barras/QR (pay-at-store) y paga el pedido en el punto fuera de línea del socio (quiosco, supermercado, gasolinera, oficina de correos) o en el banco de Internet/ATM. El dinero llega al merchant a través de PSP/proveedor de raíles bancarios; charjback no, los riesgos de frod son mínimos.

• Productos/juegos digitales, contenido, suscripciones de cheque bajo/mediano.
• Regiones con alta proporción de efectivo o baja penetración de tarjetas.
• Público que prefiere la privacidad/prepago.

2) Tipología de herramientas eCash

1. vales PIN (códigos de prepago):

Ejemplos: Paysafecard, Neosurf, Flexepin.
UX: ingrese un PIN de 16/10 dígitos en el formulario de alojamiento o pague desde la cartera (myPaysafe/myNeosurf).
Características: amortizaciones parciales, combinación de varios PIN, el saldo se conserva.

2. Códigos de barras/QR «Pague en la tienda» (código de barras de pago cash):

Ejemplos: paysafecash, redes locales (OXXO Pay - MX, RapiPago/PagoFacil - AR, Efecty/Baloto - CO, PayPoint/Payzone - UK, ePot y/Paylink - EU y otros).
UX: el merchant genera barcode/QR → el cliente paga en efectivo en la caja registradora → el proveedor envía una confirmación.
Características: el cheque es válido por tiempo limitado (expiry), la cantidad es fija.

3. Reference/Slip para ATM/banca en línea (datos de facturación):

Ejemplos: Referencias Multibanco - PT, Konbini - JP.
UX: código/referencia + importe, pago en ATM/banco en línea/tienda-socio.
Características: mínimo de frodo, estricta conciliación por referencia.

3) Participantes del ecosistema

Proveedor/circuito (eCash/vales): libera PIN/barcodes, mantiene catálogos minoristas, KYC/AML, antifraude, da API/widgets.
PSP/ecuador: conecta merchant, hosted-cash/SDK, estados, hooks web, registros y cálculos.
Venta al por menor/taquilla: recepción de efectivo/lectura de código de barras, sincronización con el proveedor.
Banco/compensación: liquidación y acreditación de fondos al merchant.
Merchant: inicia el pago/factura, procesa los estados, devoluciones y recon.

4) Flujos de pago

4. 1 cupón PIN (Hosted/Redamb)

1. Checkout → la selección de eCash (por ejemplo, Paysafecard/Neosurf).
2. El formulario Redaprox/Hosted del proveedor → la entrada del PIN/billetera → la confirmación (scoring SCA/conductual).
3. Retorno al merchant: 'success/pending/failed/canceled/expired'.
4. El crédito real es por registros diarios (T + 1/T + 2).

4. 2 Código de barras/QR «pagar en la tienda»

1. Merchant crea una factura: suma + barcode/QR + expiry.
2. El cliente va al punto de venta y paga en efectivo → la caja registradora confirma la operación al proveedor.
3. El proveedor envía el merchant en línea-éxito, a continuación, el crédito en los registros (T + 0/T + 1).

4. 3 Reference/Slip (ATM/online-banking/conbini)

1. Generación de referencia (entity/reference/amount) + fecha de caducidad.
2. Pago en ATM/banco en línea/tienda-socio.
3. Estado en línea 'paid' y settlement posterior en los registros.

5) Estados y cálculos

Estados en línea: 'created '/' pending '/' success' paid '/' failed '/' canceled '/' expired'.
Settlement: normalmente T + 0/T + 2 días bancarios (por contrato/canal).
En la lógica empresarial, comparta la confirmación en línea y el crédito real.

6) Límites, KYC y riesgo

• Per-transaction, 24h/7d, límite de número de PIN por pago/día.
• Para los nuevos destinatarios/merchantes - umbrales reducidos/extracto.
• Geo-reglas (país del bono vs ubicación del cliente/merchant), velocity, señales de device.
• Chargeback no está; Dispouts - por ODR proveedor/PSP.
• Recomendación: Mantenga la configuración de los límites por país/red/CUS y no codifique las cantidades.

7) Devoluciones y cargos parciales

Refund = nueva operación de crédito (en eCash monedero/transferencia bancaria - según las reglas del proveedor).
Los refundidos parciales son generalmente compatibles.
Para los cupones PIN, a menudo están disponibles los cargos parciales y la combinación de PIN; para las facturas barcode - la suma es fija.

8) Economía y tarifas

La comisión para el merchant es generalmente inferior al MDR de la tarjeta CNP, pero varía en geo/volumen/categoría.
Recargos: hosted/SDK, publicidad de puntos de venta, sapport/ODR, procesamiento de 'expired/pending', recon.

9) Patrones UX

Pago PIN: UI comprensible para múltiples PIN e indicador de saldo; mensajes de error: «incorrecto/utilizado», «límite superado», «región no soportada».
Barcode/QR: código grande + temporizador de validez, botones «imprimir/enviar a messenger/email».
Instrucciones de pago fuera de línea: 3-4 pasos con logotipos de redes; mapa de los puntos más cercanos/horas de funcionamiento.
Estado del pedido: «Pendiente de pago» con actualización automática; con 'expired', el botón 'crear nuevo código'.
Recibo: cantidad, tiempo, 'paymentId', canal (PIN/Barcode/Reference), UTR/ref. del registro, contactos de sapport.
Localización: moneda/idioma/textos fiscales, marcas de redes locales.

10) Seguridad y cumplimiento

PII-minimización: PIN/billetera se introducen en el lado del proveedor (Hosted/Widget).
Web Hooks: HMAC/nonce, protección contra replay, dedoup de eventos, registro de auditoría.
KYC/AML/GDPR: reglas de edad/límite para fondos prepagados, sanciones/restricciones geográficas.
Antifraude: límites por dispositivo/sesión, cooling-off, step-up, monitoreo de PIN/barcodes repetitivos.

11) Integración y arquitectura

Opciones de conexión

1. Hosted/Embedded con PSP/proveedor: inicio rápido, responsabilidad mínima por datos sensibles.
2. Server-to-Server + Hosted es su propio checkout con control de estado, sin que usted procese el PIN.
3. Pay-by-Link/Invoice - pagos de referencia y casos de sapport.

Mínimo de fondo

API: `createPayment|createInvoice` (amount + expiry), `refund`, `queryStatus`, `webhook`, `reconcile`.
Idempotencia ('orderId' + clave), retraídas exponenciales, DLQ, dedoop web hooks.
Catálogos: países/redes/límites/niveles CUS, códigos de error, métricas SLA por canal.
Observabilidad: conversión (PIN vs Barcode/Reference), share 'pending→expired', temporizaciones medias antes del pago/settlement, geo-anomalías.

12) Notas geográficas (puntos de referencia)

Европа: Paysafecard, paysafecash, Neosurf, PayPoint/Payzone (UK), ePay/Paylink (EU), Multibanco (PT).
ЛатАм: OXXO Pay (MX), RapiPago/PagoFácil (AR), Efecty/Baloto (CO).
Asia: Konbini (JP) y redes locales (FamilyMart/Lawson/7-Eleven).

13) Check-list de la salida en el prod

1. Seleccione el proveedor/PSP y las redes de destino (PIN/Barcode/Reference), acuerde tarifas/SLA/settlement.
2. Implemente 'createPayment' createInvoice 'con expery, páginas de instrucciones y scripts fallback.
3. Conecte webhooks (HMAC), idempotencia, retraídas y dedoup de eventos.
4. Configurar daily auto-recon + full-recon, almacenar referencias UTR/fin.
5. Habilite los refundidos parciales, los procedimientos ODR y los mensajes de rebote/límite comprensibles.
6. Ejecute SLA-dashboards (conversión, 'expired', tiempo de pago/settlement) y alertas por rassincrones.
7. Realice pruebas e2e: varios PIN, código de barras caducado, cantidad incorrecta, doble pago, devolución de piezas.

Tarjeta de referencia

Статусы: `created/pending/success|paid/failed/canceled/expired`.
Settlement: normalmente T + 0-T + 2 por registros PSP/proveedor.
Chargeback: falta; refund - operación de crédito independiente.
Límites/CUS: dependen del país/red/canal y perfil del cliente.
Recurrent: el primer mandato → de eCash (SEPA/Open-Banking/local) para los cargos posteriores.

Estrategia: eCash-mix (PIN + barcode/QR + reference) para llegar a la audiencia en efectivo y reducir el MDR.
Arquitectura alrededor de webhooks + recon, estricta idempotencia y comprensible UX 'pending/expired'.
Configuraciones de límites/CUS y geo-reglas - fuera de código, con actualización regular.
Para suscripciones, el primer eCash → un mandato, una gestión transparente y notificaciones al usuario.