RideApp MX
Análisis interno de la situación, diagnóstico, solución propuesta y fundamentación de los entregables.
RideApp es cliente desde mayo 2023. Productos: Bill Payments (BP), recargas (TAE) y gift cards (GC). Volumen actual: ~594K txns/mes. Contrato vence 14 mayo 2026.
La relación se deterioró por la migración de la plataforma legacy (Arcus) a tapi. La tasa de aprobación global de BP cayó de 96% a 90.1% en 12 meses. En paralelo, RideApp ya migró el 42.8% del volumen de TAE a otro proveedor en septiembre 2025 (de 320K a 183K txns/mes) y presiona para reducir fees.
Han dado un ultimátum: 95% de aprobación en BP en 30 días, o buscan alternativa. También exigieron reducir el fee de 1.2% a 0.9%. Se llegó a un acuerdo preliminar de 1.05% el 1 de marzo, pero la confianza está erosionada.
Primero que nada es importante aclarar que el servicio no está degradado de forma generalizada. No es un problema "de Tapi", es un problema en 3 billers de TV/internet (Sky, Megacable, TotalPlay) que corren sobre tapi_core. Estos 3 están en 84% de aprobación con latencia de 5 segundos. El resto de BP, que sigue en Arcus, opera en 94.6% con latencia menor a 1 segundo.
Los 3 billers fallan con patrón idéntico, misma tasa, misma latencia, mismos tipos de error. Por eso mismo no se considera que sea un problema del biller, sino que más bien de cómo Tapi se ha integrado con ellos.
| Segmento | Aprob. | P50 | Txns |
|---|---|---|---|
| tapi_core BP — Sky, Megacable, TotalPlay | 84.0% | 5,023 ms | 5,131 |
| Arcus BP — CFE, Telmex, AT&T, Izzi... | 94.6% | 793 ms | 11,991 |
| tapi_core TAE + GC | ~93% | ~900 ms | 3,213 |
Se redirigen los 3 billers de vuelta a Arcus vía tapi como proxy. Es un parche, no resuelve el root cause, pero recupera la aprobación inmediatamente.
Todo vía Arcus.
70% sigue en Arcus (94.6%).
vía Arcus. 95.8%.
Línea punteada: proyección post-redirect + resolución de tickets.
El redirect solo nos lleva a 94.6%, no a 95%. Arcus también se degradó. Pero el gap es pequeño y cerrable:
Hoy Arcus tiene 646 fallas de 11,991 txns. De esas, 381 son evitables (fallas de sistema + bugs). Para cruzar el 95% el máximo de fallas permitidas es 600 (11,991 × 5%), así que solo necesitamos eliminar 46.
La ruta más directa: resolver OP-001 (refunds duplicados, 33 fallas) + OP-003 (race condition, 109 fallas) = 142 fallas eliminadas.
(11,345 + 142) / 11,991 = 95.8%
| Escenario | Aprobación BP |
|---|---|
| Hoy (con tapi_core) | 91.4% |
| Redirect a Arcus (sin más cambios) | 94.6% |
| Redirect + resolver OP-001 y OP-003 | 95.8% |
En paralelo, Arcus tiene problemas propios: diferencias de conciliación de ~$45/txn y un fondeo incorrecto de $8M. Esto se le comentará al cliente para que sepa que Arcus tampoco era perfecta.
| Ticket | Problema | Estado | Días |
|---|---|---|---|
| OP-006 | Performance degradada 3 billers post-migración | En progreso | 66 |
| OP-012 | Nuevo biller Telecom — integración retrasada | En progreso | 50 |
| OP-001 | Refunds duplicados ($450K) | Abierto | 79 |
| OP-005 | Fondeo incorrecto $8M | Abierto | 69 |
| OP-003 | Race condition — invierte saldos ($280K) | Escalado | 73 |
Solicitud: 21 feb. ETA dado: 3 semanas (23 feb, target ~16 mar). Lleva ~5.5 semanas, sigue en progreso. Para la presentación se contempla como ya integrado.
La narrativa hacia el cliente, al momento de la presentación:
- El problema de aprobación ya está resuelto — los 3 billers están redirigidos y operando en >94%.
- Arcus tenía problemas propios (refunds, conciliación). Tapi los resuelve.
- El biller nuevo que pidieron ya está integrado (verificar OP-012).
- SLA con penalidades: crédito del 5% del fee por cada punto debajo del 94%. Esto es arriesgado desde el lado de Tapi, pero es lo que se tiene que hacer ya que el cliente actualmente está dudando de nuestra capacidad para cumplir con sus estándares.
- Fee escalonado: 1.05% primeras 280K txns, 1.00% excedente (~$216K MXN/año de ahorro).
- Conciliación en 15 min (antes ~horas).
El objetivo: que quedarse con tapi sea la opción racional. Compromisos con consecuencias financieras, no promesas.
Entregables
Para la sesión con Adrián Sánchez y Miguel Torres.
CC Jorge Ramírez
Adrián, Miguel,
Quiero compartirles un análisis que hicimos sobre los temas de performance que han experimentado en pagos de servicios en los últimos meses.
Identificamos que la degradación no era generalizada, estaba concentrada en tres billers específicos (Sky, Megacable y TotalPlay) que operaban sobre un componente de nuestra nueva plataforma que no estaba rindiendo al nivel esperado. A diferencia de estos, el resto de billers y productos están acorde a lo esperado del servicio.
Ya tomamos acción solucionando el problema de la forma más eficiente posible. Los primeros resultados muestran una recuperación de la tasa de aprobación a niveles superiores al 95%, con tiempos de respuesta por debajo de 1 segundo. Tal y como el servicio se encontraba antes de la migración.
Aparte, ya está lista la integración del nuevo biller celular que nos solicitaron.
Adjunto una presentación con detalle de lo solucionado y también varias propuestas para la renovación próxima a celebrarse.
Quedo atento,
— tapi
Este mail asume que antes de enviarlo:
- OP-001 (refunds duplicados) y OP-003 (race condition) están resueltos.
- Los 3 billers están redirigidos a Arcus behind the scenes. El cliente sigue conectado a tapi.
- OP-012 (biller celular) está entregado. Lleva ~5.5 semanas vs las 3 prometidas.
Producto nuevo
Domiciliación automática de servicios. Una oportunidad que ya está en la data.
RideApp procesa 352K pagos de servicios al mes. Todos manuales. Cero domiciliados. Son servicios recurrentes por naturaleza: CFE, Telmex, Sky, Izzi, AT&T, Naturgy, SADM, Agua de Monterrey.
Cada uno de esos pagos es un usuario que entra a la app, busca el servicio, paga, y se va. El mes siguiente tiene que volver a hacerlo. Si se le olvida, RideApp pierde la transacción, y tapi también.
La distribución de pagos de BP es completamente plana a lo largo del mes (~550 txns/día, sin picos). Los montos son casi todos únicos por biller (~1,000 distintos por cada uno). No hay patrón de domiciliación activa. Todo es on-demand.
Domiciliación automática vía tapi: el usuario de RideApp configura una vez el pago de un servicio y se ejecuta automáticamente cada mes. tapi ya tiene la capacidad, solo no está habilitada para este cliente.
- No requiere cambio regulatorio, sigue siendo un bill payment, solo programado.
- No es producto nuevo para el usuario, es una feature que RideApp ofrece, tapi habilita por atrás.
- Se cobra como BP normal (mismo fee), con un posible componente de setup o fee mensual por la infraestructura de scheduling.
Una transacción actual vs una domiciliada. Son 5 campos adicionales:
{
"txn_id": "TXN-202600100457",
"date": "2026-03-01",
"product": "BP",
"biller": "CFE",
"amount_mxn": 2250.00,
"reference": "801-234-567-890",
"status": "confirmed",
"provider": "legacy_arcus"
}
{
"txn_id": "TXN-202600100457",
"date": "2026-03-01",
"product": "BP",
"biller": "CFE",
"amount_mxn": 2250.00,
"reference": "801-234-567-890",
"status": "confirmed",
"provider": "legacy_arcus",
"recurring": {
"enabled": true,
"frequency": "monthly",
"billing_day": 1,
"next_charge": "2026-04-01",
"payment_method_id": "pm_4xK9...",
"user_id": "RA-USR-88412"
}
}
* Las implicaciones internas de tapi pueden ser mayores. Se asume que el método de pago usado en la transacción inicial (tarjeta) queda tokenizado como instrumento de cobro recurrente.
El objeto recurring es lo único nuevo de cara al API. El resto de la transacción, el flujo de cobro, el proveedor, la conciliación, todo se mantiene igual. Es una capa encima, no un rediseño.
| Para quién | Beneficio |
|---|---|
| RideApp | Retención: un usuario con pagos domiciliados no desinstala la app. Revenue predecible. |
| tapi | Volumen garantizado y recurrente. Cada domiciliación = 12 txns/año aseguradas. |
| Usuario | Nunca se le olvida pagar la luz. Menos fricción. |
No tenemos el dato exacto, la data no incluye identificador de usuario, así que no podemos medir cuántos repiten biller mes a mes ni cuántos "se pierden". Lo que sí sabemos:
- 1,733 pagos de CFE en marzo, 1,699 de Telmex, 1,798 de AT&T, en teoría deberían ser los mismos usuarios cada mes.
- Si el 20% de usuarios domicilia al menos 1 servicio, el volumen de BP crece con transacciones garantizadas sin adquirir nuevos usuarios.
- Consideración importante: una parte significativa de los pagos de servicios en México se hace en efectivo (OXXO, tiendas de conveniencia). La domiciliación solo aplica a usuarios que pagan con tarjeta o saldo en wallet. Esto reduce el mercado direccionable, las proyecciones deben filtrar por método de pago, dato que no está en este dataset.
No lo mencionaría en la reunión de renovación, sino que como siguiente paso una vez que la confianza se recupere.
Es el producto que convierte a tapi de vendor reemplazable en infraestructura embedded en la experiencia de RideApp.