E-wallets: revisión y comparación

1) Qué es e-wallet y por qué es merchant

• Mayor conversión a través de App2App/One-tap, reconocimiento local y datos almacenados.
• Feed bajo (SCA, device binding, risk scoring del proveedor).
• Flexibilidad de las fuentes de fondos: tarjeta, A2A (transferencia bancaria/banca abierta), vales cash, saldo móvil.
• Geografía avanzada y acceso a audiencias sin mapas ni créditos.

2) Clasificación de billeteras

1. Stored-value (balance)

El usuario guarda el dinero en su billetera. Ficha: top up, ledger interno, P2P, pagos de saldo. Ejemplos: Skrill/Neteller, myPaysafe/myNeosurf, monederos EMI locales.
Ventajas: repeticiones/devoluciones rápidas, fuera de la tarjeta de audiencia. Contras: niveles KYC, límites en top up/retiro.

2. Pass-through / Pay-by-bank / Bank-linked

El dinero se carga directamente desde la cuenta bancaria/a la tarjeta a través de una confirmación en la aplicación (a menudo sin guardar el saldo). Ejemplos: MB WAY, Swish, Vipps, TWINT, Bizum.
Pros: bajo feudo y MDR, préstamos instantáneos. Contras: límites en los bancos, ausencia del clásico chargeback.

3. Híbridos

Monedero + tarjeta/tarjeta virtual/enrutamiento (por ejemplo, rails wallet → card), o super-aplicaciones con facturas, QR, P2P, pay-by-link.

3) Fuentes de fondos y flujos

Arriba: mapa (CNP/3DS), A2A (SCT/SEPA Instant, RTP), vales cash, puntos de agencia.
Pay-in (merchant): App2App/Deep Link, QR per-order, página hosted, tokened COF/Network tokens (para monederos de tarjeta).
P2P: por teléfono/aliasu, dentro de la cartera/circuito.
Cash-out: transferencia bancaria (SCT/ACH/RTP), a la tarjeta (NAT/Push-to-Card), a la red offline, menos común - a un vale.

4) Patrones UX que afectan a la conversión

App2App/Deeplink con la devolución a la caja registradora y la anticipación de la cantidad/órdenes.
QR dinámico por orden (escritorio/fuera de línea), temporizador de vida, auto-actualización de estado.
One-tap/One-click después de la referencia principal (donde se permite).
Errores claros y recuperación: límite, tiempo de espera, fallo SCA; repetición segura + sugerencia de un método alternativo.

5) Límites, niveles de KYC y riesgo

Per-transaction/24h/7d/monthly, umbrales separados para nuevos destinatarios/merchant.
Niveles KYC (anónimo/simplificado/completo): determinan los máximos por top up/gasto/conclusiones.
Velocity/device/geo-regulaciones, sanciones, límites de edad.
Vertical de alto riesgo (incluyendo iGaming): límites más estrictos, colinas, monitoreo avanzado.

6) Devoluciones, Dispouts y Finality

Chargeback: stored-value a menudo no tiene un charjback clásico; los monederos en los raíles de tarjetas tienen reglas de tarjeta.
Refundidos: generalmente una operación de crédito independiente (full/partial) en la cartera/cuenta del cliente.
A2A Finality: los pagos son finales después de la confirmación; trabaje con los procedimientos ODR del proveedor.

7) Economía: comisiones y costos ocultos

MDR/fee generalmente por debajo de las tarjetas CNP; dependen de geo, volumen de negocios, categoría MCC.
Recargos: hosted/SDK, procesamiento 'pending/expired', sapport/ODR, recon, mantenimiento de mandatos/suscripciones, verificación AML/KYC.

8) Estados y cálculos

• `created → pending → success | failed | canceled | expired`
• Settlement: T + 0/T + 2 en los registros de proveedores/PSP. En la lógica empresarial, comparta la confirmación en línea y el crédito real.

9) Matriz comparativa de criterios

Tipo: stored-value/pass-through/híbrido

Fuentes de fondos: tarjeta/A2A/eCash/saldo móvil

Canales UX: App2App/QR/Hosted/Pay-by-Link

P2P/Payouts: hay/no, límites y plazos

Refund/Chargeback: si hay un chargeback; partial refunds

Conversión: prioridad móvil, One-tap

Comisión: referencia contra tarjetas CNP

Riesgo: feudo, finalidad, requisitos regulatorios

Geo-alcance/marca local: reconocimiento entre el público objetivo

10) Integración: opciones y mínimo backend

1. Hosted/Embedded en PSP/monedero - inicio rápido, minimización de PII.

2. Server-to-Server + App2App/QR es un UX personalizado, la página de selección de billetera nativa.

3. Pay-by-Link/Invoice: conveniente para pagos diferidos/colecciones.

• API: `createPayment`, `refund`, `webhook`, `queryStatus`, `reconcile`.
• Idempotencia ('orderId' + clave), retraídas exponenciales, dedoup de eventos, DLQ.
• Webhooks: HMAC/nonce, protección contra el replay, validación estricta del URI de redirección.
• Recon: daily auto-recon + periódico full-recon; almacene UTR/fin. referencia.
• Catálogos: proveedores/países/límites/códigos CUS/errores; SLA-métricas a través de los canales.
• Observabilidad: conversión (por billeteras/canales), 'pending→success/expired', latencia a settlement/devoluciones.

11) Suscripciones y mandatos

• Primer pago → mandato (SEPA DD/Open Banking/monedero-mandato).
• Almacene el límite per-debit, la frecuencia, la ventana de cargo, la pre-notificación y la UI de administración (pause/cancel/update).

12) Prácticas antifraude

Perfilando dispositivos y comportamientos, señales geográficas, velocity.
Paso a paso (autenticación adicional) en caso de anomalías.
Límites a nuevos destinatarios/pagos, cooling-off, ejecución diferida de los servicios a settlement.
Contenido-frod (llaves/pieles digitales): emisión diferida, verificación del historial de la cuenta.

13) Conciliación y presentación de informes (madurez operativa)

• 'paymentId/transactionId', 'orderId', monedero/canal (App2App/QR/Hosted/Link), fuente de fondos (tarjeta/A2A/eCash), estado, cantidad/moneda, timestamps, U2A/eCash TR/enlace bancario, detalles de las devoluciones
• Dashboards SLA: conversiones por billetera, share 'expired', tiempo antes de la inscripción y hasta la refundición, fallas/límites SCA.
• Alertas por rassincrones: éxito en línea sin inscripción en el registro, dobles deducibles, «suspendidos» pending.

14) iGaming y otras verticales sensibles

Compruebe la política del proveedor y la elegibilidad local (disponibilidad, límites, colinas).
Planifique raíles alternativos (mapas/A2A/eCash) y una ruta inteligente por riesgo/geo/billetera.
Prepare informes avanzados (fuente de fondos, límites de jugadores, velocidad de pago, señales de respuesta).

15) Mini comparación de perfiles estándar

A. Billeteras bancarias locales (MB WAY/Swish/Vipps/TWINT/Bizum-similares)

Conversión: alta (App2App/QR, marca familiar).
Frod/chargeback: bajo/inexistente; refund como préstamo separado.
Límites: especifica los bancos/diagrama; más rígido para nuevos destinatarios/pagos.
Uso: pagos masivos, entradas/servicios, iGaming - por políticas PSP/bancos.

B. Stored-value (Skrill/Neteller/myPaysafe/myNeosurf и др.)

Conversión: alta con base de usuario activa.
Frod: bajo, pero requiere un KYC/AML estricto.
Ventajas: refundiciones parciales rápidas, repeticiones instantáneas, P2P.
Contras: límites en el top up/retiro por niveles de KYC.

C. eCash/fuentes de cupones dentro de las billeteras

Audiencia sin tarjetas/bancos: crítico para un geo con economía de efectivo.
Finalidad: alta; reembolso - operación de crédito.
UX: es importante mostrar «dónde comprar el vale» y el temporizador de la acción de la factura/código de barras.

16) Lista de comprobación de salida de e-wallets en prod

1. Fit de mercado: seleccione 2-4 monederos por geo/audiencia; Aprecie el reconocimiento de marca.
2. Contrato/PSP: tarifas, SLA por webhooks/registros, plazos de settlement, política de devoluciones.
3. Integración: 'createPayment' + App2App/QR/Hosted, pantallas de error/límites, repeticiones seguras.
4. Security: HMAC/nonce, allowlist IP, rigurosos rednat-URI, vault secrets.
5. Recon: daily + full, almacenamiento UTR, alertas por rassincrones.
6. Refundidos/ODR: parcial/full, referencia a la orden original, regla de sapport.
7. CUS/límites: confecciones por proveedores/canales, razones de IU de rechazo y propuestas de alternativas.
8. Observabilidad: dashboards de conversión/latencia/expired, cortes por dispositivo/banco/billetera.
9. Pruebas: e2e en bancos/billeteras principales, QR de escritorio, red débil/temporizadores, pending «suspendidos», devoluciones en partes.

Tarjeta de referencia

Статусы: `created/pending/success/failed/canceled/expired` + webhooks.
Settlement: T + 0-T + 2 sobre los informes del proveedor/PSP.
Chargeback: más a menudo no (excepto los raíles de mapas); refund - crédito separado.
Límites/CUS: niveles en la cartera + umbrales de canal en bancos/circuitos.
Suscripciones: «primer pago → mandato» (SEPA/Open Banking/monedero-mandato).

Resumen

Construye una caja registradora alrededor de las billeteras multicartes con App2App/QR y nítido recovery-UX - esto aumenta la conversión y reduce el fodo.
Almacene los límites/CUS/errores en la configuración, no en el código; actualice regularmente por proveedor.
La fiabilidad operativa proporciona webhooks + recon duro, idempotencia y analítica 'pending→success/expired'.
Para suscripciones, utilice los mandatos; para el alto riesgo, mantenga los rieles alternativos y la ruta inteligente en el riesgo y la geografía.