Neosurf: vales en efectivo

1) Qué es Neosurf y cuándo elegirlo

Neosurf es un método de pago de cupón de prepago: el usuario compra un vale de efectivo/tarjeta a socios offline (kioscos, supermercados, gasolineras) o repone el saldo de myNeosurf y luego paga en línea introduciendo el código PIN del bono o autorizando en la cartera. Los fondos se cargan instantáneamente, no hay riesgo de chargeback como en las tarjetas; las devoluciones se ejecutan como transacciones de crédito separadas de acuerdo con las reglas del proveedor/PSP.

Donde funciona bien

Artículos digitales, juegos, suscripciones con cheque bajo.
Audiencias con baja penetración de tarjetas/confianza en efectivo.
Mercados con una red de venta de cupones desarrollada.

2) El ecosistema y las funciones

Proveedor/esquema: emisión de vales, reglas KYC/KYB, antifraude, billetera myNeosurf.
Red minorista: venta de vales/reposición de carteras, emisión de cheques con PIN.
PSP/ecuador: conexión de merchant, hosted-cash/SDK/API, estados, informes y cálculos.
Merchant: inicia el pago, procesa los estados y devoluciones, mantiene la conciliación.
Pagador: introduce el PIN o entra en myNeosurf y confirma el cargo.

3) Productos y escenarios

Neosurf Voucher (PIN): pago con uno o más vales; se admiten cancelaciones parciales y una combinación de cupones (dentro de los límites).
myNeosurf (billetera): pago con saldo; conveniente para compras repetidas y reembolsos.
Factura/Rau-by-Link: enlace de pago de PSP con entrada de PIN/entrada de billetera en la página de alojamiento.

4) Flujos de pago

4. 1 Hosted/Redamb (recomendado)

1. Checkout → la selección de Neosurf.
2. Redireccione a la página de host PSP/proveedor → escriba el PIN o inicie sesión en myNeosurf → confirme.
3. Volver al merchant con 'status' (success/failed/canceled/pending) y 'paymentId'.
4. El crédito final se refleja en los registros diarios (settlement).

4. 2 Embedded/Widget

Widget integrado PIN/myNeosurf en la caja registradora. Requiere el cumplimiento de la política de IU/seguridad y proveedor.

4. 3 Server-to-Server

El backend de merchant inicia el pago y sondea el estado; El PIN siempre se introduce en el lado proveedor/widget para no almacenar datos sensibles.

5) Límites, KYC y comportamiento

• Per-transaction, límites diarios/semanales.
• Límite al número de vales en un pago.
• Restricciones geográficas (país de emisión de cupones vs país de merchant/cartera).
• Para nuevos merchantes/categorías - umbrales reducidos, controles de paso a paso.

6) Estados, cálculos y devoluciones

Los estados online son: 'success',' pending ',' failed ',' canceled ',' expired '.
Settlement: crédito por informes PSP/proveedor (normalmente T + 1/T + 2 días hábiles, contractualmente).
Chargeback está ausente.
Refundidos: operación de crédito independiente (en myNeosurf o por un canal acordado); se admiten refundiciones parciales.
Cargo parcial: el saldo permanece en el PIN/monedero (depende de la configuración/región).

7) Economía y tarifas

Las tarifas, generalmente por debajo del MDR de tarjeta CNP, varían en geo/volumen/categoría (juegos, servicios digitales, etc.).
Recargos: hosted/SDK, sapport y ODR, procesamiento 'pending/expired', recon.

8) Patrones de caja registradora UX

Dónde comprar un cupón: la tarjeta/búsqueda de puntos de venta aumenta la conversión de principiantes.
Combinación de PIN: UI conveniente agregar varios vales + mostrar el saldo.
Errores claros: «PIN incorrecto/ya utilizado», «límite superado», «región no soportada».
Recibo: cantidad, tiempo, 'paymentId', método (PIN/myNeosurf); para la devolución - 'refundId'.
Localización: moneda/idioma/yurtextos del país del cliente.

9) Cumplimiento y seguridad

Autenticación y comprobación del PIN/monedero: en el lado del proveedor (score SCA/conductual).
Minimización PII: no procese el PIN en su lugar; use hosted/widget.
Webhooks: HMAC/nonce, protección de respuesta, dedoup de eventos, auditoría.
KYC/AML/GDPR: requisitos de edad y límite para fondos prepagados; Sanciones/restricciones geográficas.

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

Lógica: 'paymentId', 'orderId', método (PIN/myNeosurf), moneda, cantidad, estado, timestamps, referencia bancaria/financiera (UTR) de los registros PSP.
Diariamente: eventos de efectivo auto-recon con registros de fin (inscripciones/devoluciones/correcciones).
Alertas: «éxito sin inscripción en el registro», «doble deducibilidad», «pending colgante largo».

11) Integración de merchant

Opciones

1. Hosted/Embedded de PSP: inicio rápido y cumplimiento de requisitos de seguridad.
2. Server-to-Server + Hosted PIN: controle los estados sin procesar el PIN que tiene.
3. Pay-by-Link/Invoice - para los pagos diferidos y el zapport.

• API: `createPayment`, `refund`, `queryStatus`, `webhook`, `reconcile`.
• Idempotencia ('orderId' + clave), retraídas exponenciales, DLQ.
• Catálogos: países/monedas, límites/niveles CUS, códigos de error, métricas SLA.

12) Suscripciones y nuevos cargos

• utilizar myNeosurf como fuente de fondos (si se permite),
• o el esquema del primer bono → mandato (SEPA/Open Banking) para futuros adeudos.
• Muestre al usuario una pantalla de administración de mandatos (límite/frecuencia/notificaciones).

13) Políticas antifraude y de riesgo

Señales: no coincidencia geo (IP/voucher/merchant), errores PIN frecuentes, reintentos, comunicación de cuentas a través de los mismos PIN.
Mitigia: límite en el número de PIN por sesión/día, cooling-off, capcha/step-up, fallos leves con explicación.

14) Vertical de alto riesgo (iGaming incluido)

La disponibilidad, los umbrales y los informes dependen del país y de la política del proveedor/PSP.
Espere límites reducidos, supervisión de transacciones mejorada y requisitos de verificación.
Mantenga los raíles alternativos (otros vales, A2A, tarjetas) y smart-routing.

15) Arquitectura «Neosurf Gateway»

Capa API (NAT/GraphQL) de taquilla/facturación.
Colas de eventos: estados → facturación/CRM/analítica/sapport.
Security: vault secrets, IP-allowlist, validación estricta del URI redireccional, tokens anti-replay.
Observabilidad: conversiones (PIN vs myNeosurf), 'pending→success/expired', latencia media, porcentaje de devoluciones parciales/combinadas, métricas de devoluciones.

16) Check-list de la salida en el prod

1. Conecte el canal con PSP y active Hosted PIN/myNeosurf.
2. Implemente 'createPayment' + web hooks (HMAC), idempotencia y repeticiones.
3. Incluye refundiciones parciales, scripts de combinación de cupones y errores comprensibles.
4. Configure daily auto-recon + recon completo periódico; almacenar referencias de fin/UTR.
5. Los dashboards de la SLA y alertas a los colgados 'pending', un alto lote de 'failed', anomalías por geo.
6. Pruebas E2E por país/moneda: varios PIN, devoluciones parciales, PIN/límites vencidos.

Tarjeta de referencia

Estados: 'success/pending/failed/canceled/expired'.
Settlement: normalmente T + 1/T + 2 por registro.
Chargeback: no; refund - operación de crédito separada (en partes permitidas).
Combinación PIN: permitida dentro de los límites.
Recurso: a través de myNeosurf o mandato alternativo (después del primer pago).

Resumen

Elija Neosurf para su audiencia en efectivo y micropagos: hosted PIN/myNeosurf → rápida y segura.
Construye un proceso alrededor de webhooks + recon, admite refundidos parciales y una combinación de cupones.
No «coser» cantidades: mantenga las confecciones de límites/CCA por país y actualice regularmente.
Para suscripciones, el primer bono → mandato/myNeosurf con administración transparente y notificaciones.