Payment Smart Routing

Team: Payment Orchestration · First production rollout: PedidosYa Argentina

I owned the proposal, technical design, and rollout planning for success-rate-based payment routing. I also implemented the calculation and evaluation logic.

Read the detailed STAR account or the one-screen brief.

Business context

Prod-Ops maintained an ordered list of payment service providers (PSPs) for each country. The primary PSP received transactions, followed by backup providers when necessary.

Previously, Prod-Ops manually disabled the primary when it had problems. Existing routing then selected the next backup. Prod-Ops restored the primary after recovery.

Success-rate reporting relied on transaction events and calculations from the data team. This reporting introduced delay before alerts reached Prod-Ops.

Manual intervention added further delay. During that interval, unsuccessful payments could cause lost orders and reduce gross merchandise value (GMV).

Objective and scope

Smart Routing automated the exclusion of underperforming PSPs from subsequent routing decisions. It retained the existing ordered provider list.

The first production rollout covered PedidosYa Argentina and all payment methods. The system calculated success rates per PSP, across payment methods.

The system did not retry a failed payment through another PSP. Failover affected subsequent transactions.

My responsibility

I drafted the RFC, compared alternatives, shared the proposal with stakeholders, and obtained approval for the selected solution.

I then developed the detailed technical design and obtained approval for the internal RFC. I prepared the implementation plan and issues.

The team implemented the solution. I developed the success-rate calculation and rule evaluation, contributed code reviews, and planned the gradual rollout.

I also designed the production metrics, dashboards, and observability requirements.

Data collection decision

I compared two approaches:

• Consume transaction events and aggregate final outcomes in a listener service.
• Poll the transaction service for outcomes through a scheduled job.

We selected polling to avoid additional event infrastructure costs and complexity. The polling job ran in the Insight service.

Insight collected successful and failed transaction counts in one-minute buckets and stored them in Redis.

Evaluation and routing

Prod-Ops configured the evaluation window and success-rate threshold. Fifteen minutes was an example window, rather than a fixed requirement.

The evaluation also required a minimum transaction count. Below that minimum, the system continued routing to the PSP without excluding it through success-rate evaluation.

The first release counted all failures. This included failures that did not indicate a technical PSP problem, such as insufficient funds.

A separate health indicator represented a PSP’s eligibility under Smart Routing. This indicator remained separate from its existing activation configuration.

The routing library consulted configuration from the control plane and outcome data in Redis. It selected an eligible provider from the ordered list.

The system applied success-rate evaluation only to PSPs with that feature enabled. Other PSPs retained their existing behavior.

Embedded library decision

A separate routing service would add a synchronous network call to payment processing.

I recommended an embedded library in the Payment Integration Gateway to avoid that additional service call and its latency.

The library still depended on Redis and control plane configuration. Embedding it avoided the additional routing-service hop; it did not remove those dependencies.

Rule representation

The configuration and evaluation model presented a difficult design choice.

I considered condition trees, key-value rules with a small custom evaluator, a dedicated rule engine, and Spring Expression Language (SpEL).

I benchmarked SpEL rule evaluation before selecting it. The benchmark showed that it could handle 50 times our expected workload.

This capacity margin supported my decision. It described rule evaluation, rather than the capacity of the complete payment flow.

We stored rules as SpEL expressions and introduced a function that expressions could call.

This case study does not include the absolute evaluation rate, latency measurements, or benchmark environment.

Failure and recovery behavior

If the library could not calculate a success rate for any reason, routing bypassed that evaluation and processed the payment through the selected PSP.

This fallback included Redis failures. A calculation failure did not itself exclude the PSP. The library did not cache the data.

I asked Prod-Ops to retain at least one fallback PSP outside success-rate-based exclusion. This provided an option when other providers fell below their thresholds.

Prod-Ops manually restored a PSP after automatic exclusion and resolution of its issue. The first release did not provide automatic recovery.

Rollout and production observation

We started with a gradual rollout in a country with low traffic: Argentina on PedidosYa.

I compared production performance with the previous week to check normal operation. After several days, the system also triggered automatic failover.

In one production incident, approximately 1,300 orders completed through the backup PSP after automatic failover.

Earlier PSP outages or performance problems had affected the overall payment success metric. We used those incidents to assess the benefit of automatic failover.

The completed orders were an observed result. The number that would have failed under the previous process remains an estimate.

Limitations and planned improvements

The initial release prioritized automatic failover within a limited operational scope.

Planned improvements included:

• Evaluate technical failures separately from customer or business declines.
• Restore recovered PSPs automatically.
• Enable evaluation during meaningful operating periods, such as peak hours, instead of low-traffic periods.

These improvements were plans, rather than confirmed production capabilities.