Una ruta tiene expected value, no solo precio
Estima probabilidad de authorization exitosa y valor económico de esa venta; resta processing, retries, fraude/disputes, FX, fees y costes operativos. Ese resultado se acerca más a la contribución real que el precio headline.
También evita optimizar approval rate sin economía: más approvals pueden ser peores si son desproporcionadamente caros o riesgosos.
La decisión debe ser contextual
Issuer country, card type, amount, currency, authentication result, merchant entity, channel, provider health y contractual tiers cambian la economía. Un ranking global de PSPs pierde valor cuando el rendimiento varía por segmento.
Los retries pertenecen al mismo modelo
Un primer fallo puede disparar otra acción con coste. Si retry policy se optimiza aparte, el primer intento puede verse bien mientras el journey completo empeora. Modela la secuencia de attempts como una sola decisión económica.
Mide realized economics después del settlement
Compara expectativas con settled economics reales. Contracts, issuer behavior y provider performance cambian; sin feedback loop las routing rules se convierten en supuestos históricos.
Construye un modelo de contribution por ruta
Un buen modelo de routing empieza por expected contribution, no por ranking de fees. Para cada ruta candidata estima la probabilidad de completar el pago y el valor económico si tiene éxito. Resta processing, authentication, retries, FX, fraud, disputes, refunds, reserves, efectos financieros cuando apliquen y carga operativa de excepciones. La fórmula exacta depende del negocio, pero incluir todos los componentes materiales evita optimización local.
El modelo también debe mostrar incertidumbre. Algunos costes son conocidos antes del routing, otros son estimates históricos y otros solo se observan después de settlement o ventanas de dispute. Tratar estimates como números exactos crea falsa confianza. Una ruta puede tener expected margin range o confidence score que se refine con realized data.
Segmenta donde el comportamiento del proveedor realmente cambia
El performance de un provider rara vez es uniforme. Issuer country, método, card type, moneda, amount band, authentication outcome, device context, merchant entity y hora pueden afectar authorization y coste. Routing basado en promedios globales puede enviar tráfico al proveedor estadísticamente 'mejor' y empeorar un segmento específico.
La segmentation también tiene coste. Demasiadas dimensiones producen sparse data y decisiones inestables. Empieza por segmentos con relación causal plausible con el performance y suficiente volumen. Añade complejidad solo cuando cambia decisiones materialmente. Routing intelligence debe reducir incertidumbre, no crear una maraña de rules imposible de explicar.
Separa provider health de provider economics
Real-time health es una señal de horizonte corto; economics suele requerir horizonte más largo. Un proveedor con buenos economics puede degradarse temporalmente por latency o errores técnicos. La capa de routing debe desviar tráfico por resiliencia sin reescribir permanentemente su preferencia económica por un incidente breve.
Esto sugiere control loops distintos: health controls rápidos para failover y circuit breaking, controls económicos más lentos para margin optimization y governance controls para restricciones contractuales o regulatorias. Meter los tres en un único score opaco vuelve el routing difícil de explicar y peligroso de ajustar.
Usa experimentos con cuidado en financial routing
Los experimentos pueden revelar diferencias causales de performance, pero necesitan guardrails. La asignación de tráfico debe respetar contratos, requisitos de autenticación, data residency, elegibilidad de métodos y límites de impacto al cliente. Un experimento estadísticamente interesante no es aceptable si crea exposición material de compliance o customer risk.
Mide hasta settlement y, cuando sea relevante, hasta dispute outcomes. Parar en authorization puede exagerar mejoras. El objetivo no es demostrar que una ruta aprueba más payments, sino si una policy mejora el resultado económico final del segmento probado.
Cierra el loop con realized economics
Todo modelo de routing se degrada si no se recalibra. Cambian contratos, issuer behavior, métodos locales, patrones de fraud y procesos operativos. Realized settlement y transaction-economics data deben compararse con los supuestos que guiaron la decisión.
Un buen review pregunta qué componente esperado fue incorrecto, qué segmento cambió y si la routing policy debe adaptarse. Así routing deja de ser un rules engine estático y se convierte en un controlled learning system manteniendo el governance requerido por infraestructura financiera.
Optimiza expected net outcome.
Usa performance por segmento.
Incluye retry y downstream costs.
Cierra el loop con resultados settled.