Hackatón · Billetera digital en Perú

# Épica: MVP de wallet en Perú para pagos cotidianos

## Resumen

Lanzar un MVP de wallet enfocado en Perú que reduzca la fricción en checkout y acelere el onboarding para comportamientos de pago frecuentes y de bajo monto. La épica prioriza velocidad de salida a mercado sin perder confianza del usuario, con confirmaciones claras, manejo confiable de estados y límites alineados a cumplimiento.

## Problema y oportunidad

La caída en checkout es alta y el onboarding es lento para personas que hacen transferencias pequeñas frecuentes y pagos con QR. La línea base local de pagos muestra una adopción fuerte de interoperabilidad y un comportamiento claro en flujos basados en alias, lo que abre una oportunidad para lanzar ahora una propuesta de wallet enfocada.

## Objetivos

En un trimestre, lanzar el MVP de wallet y lograr:

- Reducir la caída en checkout de 30% a 8%.
- Reducir el tiempo de finalización de onboarding de 8 minutos a 3 minutos.
- Mantener usuarios activos mensuales (MAU) entre 1,000 y 2,000 durante los primeros 3 meses posteriores al lanzamiento.
- Lograr un costo de adquisición de cliente (CAC) de PEN 10 por cada usuario nuevo durante los primeros 3 meses posteriores al lanzamiento.

## Usuarios objetivo

- Usuarios de smartphone que hacen transferencias diarias de bajo monto: necesitan un recorrido rápido y de baja fricción desde la intención hasta la confirmación del pago.
- Pequeños comercios que cobran con QR: necesitan aceptación predecible, confirmación confiable y estabilidad operativa diaria.

## Alcance

### Incluye

- Flujo de onboarding de wallet para el segmento MVP en Perú.
- Flujos núcleo de pago para transferencias de bajo monto y cobro a comercios con QR.
- Visibilidad de confirmación y estado de pago para usuarios y comercios.
- Instrumentación base del funnel de checkout, finalización de onboarding y activación al mes 3.

### Fuera de alcance

- Despliegue multipaís amplio dentro de esta épica.
- Programas avanzados de lealtad o mecánicas de crecimiento no esenciales.
- Paridad funcional completa entre todos los proveedores/bancos externos desde el día uno.
- Exposición de APIs de pago abiertas y autoservicio para terceros.

## Métricas de éxito

- MVP de wallet lanzado dentro de un trimestre.
- La caída en checkout baja de 30% a 8%.
- El tiempo de finalización de onboarding baja de 8 minutos a 3 minutos.
- El MAU se mantiene entre 1,000 y 2,000 en los meses 1-3 posteriores al lanzamiento.
- El CAC es de PEN 10 por usuario nuevo en los meses 1-3 posteriores al lanzamiento.

## Supuestos y restricciones

- El ecosistema es multirriel; el MVP no debe asumir un único riel de procesamiento de extremo a extremo.
- Las integraciones reales son contractuales y con habilitaciones operativas; el alta de proveedores no es autoservicio inmediato.
- Los límites por proveedor pueden estar por debajo del máximo regulatorio; el producto y los mensajes UX deben contemplarlo.
- El producto debe sostener la expectativa operativa de pagos inmediatos con alias (24x7x365).
- El rango de MAU (1,000-2,000) y el objetivo de CAC (PEN 10) son umbrales de negocio definidos por el Product Owner.

## Dependencias y riesgos

- Dependencia: los partners de adquirencia/gateway seleccionados para QR y procesamiento wallet son necesarios para preparar el lanzamiento.
- Riesgo: reintentos sin idempotencia robusta pueden generar duplicidad financiera y desvíos de conciliación.
- Riesgo: transiciones asíncronas del estado de pago pueden deteriorar la confianza si la confirmación no es clara.
- Riesgo: el manejo operativo/legal de reversos y disputas debe ser explícito porque la cancelación unilateral de P2P no está garantizada de forma uniforme.

## Historias de usuario candidatas

- Como usuario que transfiere a diario, puedo completar onboarding rápidamente y entender el siguiente paso en cada punto del flujo.
- Como pagador, puedo completar un pago de bajo monto y recibir una confirmación clara del resultado.
- Como pequeño comercio, puedo cobrar con QR wallet y validar el estado del pago de forma confiable.
- Como operaciones/compliance, puedo monitorear estados de pago y conciliar transacciones núcleo del MVP.

---

# Visibilidad del estado de pagos QR para comercios

Como pequeño comercio que cobra con QR,
quiero ver el estado confiable de cada transacción de cliente,
para decidir correctamente cuándo entregar el producto o servicio.

## Criterios de aceptación

1. El comercio puede visualizar cada intento de pago QR con una referencia única de transacción.
2. Cada intento muestra un estado actual dentro del conjunto de estados habilitado para el MVP.
3. La vista de estado se actualiza cuando callbacks/eventos del proveedor cambian el estado de la transacción.
4. El comercio puede filtrar el historial de estados por fecha y referencia de transacción para su operación diaria.

## Contexto

- Épica: [MVP de wallet en Perú](../epic/peru-wallet-mvp.sp.md).
- La interoperabilidad QR y los rieles de adquirencia tienen presencia material en la línea base del mercado.
- La dependencia de terceros y la confiabilidad de confirmación son riesgos explícitos para la ejecución del MVP.

## Supuestos

- El canal de consulta del comercio (app, web o ambos) queda por definir.

## Preguntas abiertas

- ¿Cuál es el conjunto mínimo de estados requerido para operación de comercios en el lanzamiento MVP?

---

# Conciliación operativa de transacciones

Como analista de operaciones,
quiero una conciliación diaria entre intenciones de pago, resultados del proveedor y asientos del ledger de wallet,
para detectar descalces temprano y mantener la integridad financiera del MVP.

## Criterios de aceptación

1. La salida diaria de conciliación compara registros de transacción de wallet contra registros de resultado de proveedor en los canales MVP.
2. Cada descalce se marca con referencia de transacción, tipo de descalce y estado actual de investigación.
3. Los reportes de conciliación se pueden filtrar por fecha y canal de proveedor.
4. Se genera un resumen diario con totales de registros conciliados, no conciliados y resueltos.

## Contexto

- Épica: [MVP de wallet en Perú](../epic/peru-wallet-mvp.sp.md).
- Los estados asíncronos y la conciliación end-to-end son requisitos explícitos del ecosistema.
- El riesgo de dependencia de terceros exige controles operativos antes de considerar una transacción como definitiva.

## Supuestos

- Las herramientas de conciliación se definirán durante la implementación.

## Preguntas abiertas

- ¿Cuál es la tasa máxima diaria de descalce aceptable para preparación del lanzamiento del MVP?

---

# Confirmación de pagos de bajo monto

Como pagador,
quiero completar una transferencia de bajo monto y recibir una confirmación definitiva del resultado,
para confiar en si el pago se realizó o no.

## Criterios de aceptación

1. Antes de la confirmación final, la pantalla de pago muestra la identidad del destino y el monto de la transferencia.
2. El pagador recibe un único resultado terminal por intento: exitoso, fallido o expirado.
3. Si el pago es exitoso, se muestra una referencia de transacción y queda persistida en el historial.
4. Si el pago falla o expira, el pagador recibe una siguiente acción clara (reintentar o volver) sin crear cobros duplicados.
5. Para la cohorte MVP en Perú, la tasa de caída en checkout de este flujo de pago se reduce de 30% a 8% dentro del trimestre posterior al lanzamiento.
6. Las transacciones exitosas del pagador emiten el evento de activación usado en el cálculo de MAU, para que el reporte de meses 1-3 pueda verificar el objetivo de MAU entre 1,000 y 2,000.

## Contexto

- Épica: [MVP de wallet en Perú](../epic/peru-wallet-mvp.sp.md).
- Esta historia contribuye directamente al objetivo de la épica: reducir la caída en checkout de 30% a 8%.
- Esta historia también contribuye al seguimiento de MAU mediante el evento de activación del pagador para el reporte de meses 1-3.
- Los límites transaccionales por proveedor pueden estar por debajo del máximo regulatorio; la validación de monto visible al usuario debe aplicarse antes del envío.
- El comportamiento de confirmación debe contemplar transiciones asíncronas de estado de pago.

## Supuestos

- Las etiquetas de los estados terminales que verá el usuario quedan por definir con producto.
- El rango objetivo de MAU (1,000-2,000) y el objetivo de CAC (PEN 10) fueron definidos por el Product Owner.

## Preguntas abiertas

- ¿Qué regla inicial de monto bajo se configurará para el lanzamiento MVP por proveedor/canal?

---

# Manejo de fallas de pago y reversos

Como especialista de soporte al cliente,
quiero que los pagos fallidos, expirados y disputados sigan rutas de atención explícitas,
para que los usuarios reciban guía consistente y soporte pueda resolver incidentes de forma predecible.

## Criterios de aceptación

1. Los resultados de pago fallido y expirado se clasifican y almacenan con un código de motivo legible por máquina.
2. La vista de soporte muestra si un pago es elegible para reintento, investigación o flujo de disputa.
3. La ruta de ayuda al usuario diferencia una falla técnica de un escenario de transferencia ya ejecutada.
4. Las acciones de soporte se registran con referencia de transacción y estado de resolución.

## Contexto

- Épica: [MVP de wallet en Perú](../epic/peru-wallet-mvp.sp.md).
- La línea base de evidencia indica que no existe una regla pública uniforme para cancelar unilateralmente transferencias P2P ya ejecutadas.
- La dirección regulatoria incrementa obligaciones sobre fraude, disputas y manejo de devoluciones/reversos desde 2027.

## Supuestos

- Los niveles de escalamiento de soporte y los SLA quedan por definir.

## Preguntas abiertas

- ¿Qué categorías de disputa deben habilitarse en MVP y cuáles se difieren para post-MVP?

---

# Idempotencia en pagos

Como analista de operaciones y confiabilidad,
quiero que los intentos de pago duplicados se manejen con comportamiento idempotente,
para evitar duplicidad financiera y desvíos en conciliación cuando hay reintentos.

## Criterios de aceptación

1. Cada intento de pago se envía con una clave de idempotencia única por pagador, monto, destino y ventana de intento.
2. Una solicitud repetida con la misma clave de idempotencia devuelve el resultado original y no crea una nueva transacción financiera.
3. Los eventos de solicitud duplicada se registran con identificadores de solicitud y identificadores de correlación para auditoría.
4. Las salidas de conciliación distinguen claramente intentos originales de reintentos duplicados.

## Contexto

- Épica: [MVP de wallet en Perú](../epic/peru-wallet-mvp.sp.md).
- El riesgo de idempotencia está documentado explícitamente con comportamiento de payload duplicado en la evidencia del ecosistema.
- Las condiciones multirriel exigen controles transaccionales consistentes, independientemente del camino de procesamiento subyacente.

## Preguntas abiertas

- ¿Cuál es la ventana de retención de claves de idempotencia para el MVP por canal?

---

# Registro y activación del MVP de wallet

Como usuario de smartphone que realiza transferencias diarias de bajo monto,
quiero completar el onboarding de la wallet con un flujo guiado y señales claras de siguiente paso,
para poder empezar a pagar sin abandonar el proceso.

## Criterios de aceptación

1. El flujo de onboarding muestra la secuencia de pasos requeridos y el paso actual en todo momento.
2. Si falta información obligatoria o hay datos inválidos, el flujo bloquea el avance y muestra un mensaje accionable para corregir.
3. Cuando el onboarding finaliza correctamente, el estado de la wallet cambia a activo y el usuario puede acceder al punto de entrada de pagos de bajo monto.
4. El sistema registra eventos de inicio de onboarding, finalización de cada paso y cierre del flujo para analítica del MVP.
5. Para la cohorte MVP en Perú, el tiempo mediano de finalización de onboarding baja de 8 minutos a 3 minutos dentro del trimestre posterior al lanzamiento.
6. La salida analítica de onboarding incluye conteos mensuales de nuevos usuarios activos y la atribución de gasto de adquisición necesaria para verificar MAU entre 1,000 y 2,000 y CAC de PEN 10 por usuario nuevo en los primeros 3 meses.

## Contexto

- Épica: [MVP de wallet en Perú](../epic/peru-wallet-mvp.sp.md).
- Esta historia contribuye directamente al objetivo de la épica: reducir el tiempo de finalización de onboarding de 8 minutos a 3 minutos.
- Esta historia captura la instrumentación de adquisición/activación necesaria para seguir MAU (1,000-2,000) y CAC (PEN 10) en meses 1-3.
- La historia se apoya en el tamaño de oportunidad documentado para comportamiento wallet interoperable en Perú.
- El MVP debe alinearse con expectativas de usabilidad y continuidad en pagos inmediatos.

## Supuestos

- Los requisitos de KYC y documentación para el onboarding deben definirse con cumplimiento y producto antes de implementar.
- El rango objetivo de MAU (1,000-2,000) y el objetivo de CAC (PEN 10) fueron definidos por el Product Owner.

## Preguntas abiertas

- ¿Qué frontera de eventos analíticos define oficialmente la duración de onboarding (timestamp de inicio/fin)?