Pi Symphony

The most common approach to multi-acquirer routing is a static rule table. An engineer writes logic: if the card brand is VISA, route to provider A. If the transaction is in EUR, route to provider B. If the amount is above £500, try provider C first. These rules are simple to understand, easy to audit, and quick to implement.

They are also deeply limited.

Static rules cannot respond to changing provider performance. If provider A begins declining a certain class of European cards at an elevated rate — because of a gateway issue, a change in their risk policies, or a temporary technical problem — a static rule that sends all VISA transactions to provider A will continue doing so, racking up declines and failed customer experiences, until an engineer manually updates the rule. That manual response loop takes time. During that window, the business is losing authorisations.

Static rules cannot optimise for cost. A routing decision that maximises authorisation rate may not minimise processing fees, and vice versa. Balancing these two objectives simultaneously within a rule system requires complex, nested conditions that become increasingly fragile as the number of providers grows. Most businesses simply do not attempt it, and leave cost savings on the table as a result.

Static rules cannot track contract fulfilment. Most acquirer relationships involve volume commitments — the merchant agrees to route a minimum number of transactions per month through a given provider. If the routing rules do not account for how close each provider is to its monthly target, the business may arrive at the end of the month having under-served one provider's commitment and over-served another's. This creates commercial friction, renegotiation costs, and in some cases financial penalties.

And static rules require ongoing maintenance. Every time a new provider is added, every time a provider's performance changes, every time a commercial agreement is updated, the rules need to be reviewed and potentially rewritten. This creates a permanent engineering dependency on the business's ability to route payments intelligently.

The impact of poor routing decisions compounds quickly at scale. Consider a business processing 50,000 transactions per day across four acquirers.

If routing decisions result in 1% more declines than optimal — because transactions are being sent to acquirers that are statistically less likely to approve them — that is 500 unnecessary declined transactions per day. Each declined transaction is a lost sale, a frustrated customer, and potentially a customer who does not return. Over a month, that is 15,000 lost conversions.

If routing decisions ignore fee differences between providers — where the cheapest provider charges 1.4% and the most expensive charges 1.9% on the same transaction — and the business routes evenly rather than preferring the cheaper provider, the excess cost on €5 million of monthly volume is €25,000 per month, or €300,000 per year.

These are not edge cases. They are the normal operating cost of routing without intelligence.

There are commercial routing optimisation tools available from specialist vendors. These products face the same fundamental problem as third-party fraud tools: they are black boxes trained on industry-wide data, with limited ability to incorporate the specific commercial relationships, contract structures, and provider dynamics of a particular business.

They also add an external dependency to a highly sensitive, latency-critical flow. Payment routing happens in the window of a live authorisation. Adding a third-party API call to that flow introduces latency, availability risk, and a vendor dependency that compounds the operational complexity of the payment stack.

Symphony is built to avoid all of these problems. It is in-house infrastructure, trained on real transaction data from the PayIntelli platform, incorporating the actual commercial structure of each client's acquirer relationships, and operating within the authorisation window without adding external dependencies.

The primary output of Symphony is a ranked list of provider IDs, ordered from most recommended to least recommended for the specific transaction at hand.

This ranking is not static. The same transaction submitted at different points in the month may produce a different ranking — because contract fill levels change as transactions are processed, because routing rules may be active at one time and not another, and because the underlying models incorporate timing signals that capture time-of-day and day-of-week performance patterns.

The calling system is expected to attempt providers in the order Symphony provides. If the top-ranked provider declines or is unavailable, the system falls back to the second-ranked provider, then the third, and so on. Symphony ensures there is always a fallback — providers are demoted, not removed.

For each provider, Symphony estimates the probability that the provider will successfully authorise the transaction. This is a per-provider, per-transaction estimate — not a static performance metric. It accounts for the specific characteristics of the transaction: the amount, the payment method, the card type, the geography, the time of day, and a range of other signals.

Success probability is the primary driver of routing quality. A provider with a high expected success rate for a given transaction gets a higher ranking than one with a lower expected rate, all else being equal.

Success probability estimates are produced by models trained on historical transaction outcomes on the PayIntelli platform. The models learn, from real authorisation history, which transaction characteristics are associated with approvals and which are associated with declines, for each specific acquirer. This means the estimates reflect not just general acquirer performance, but acquirer performance in the context of the specific transaction types that flow through the platform.

Processing costs — interchange, scheme fees, and gateway fees — vary by acquirer and by transaction. These fees are not always visible at the point of routing, but they accumulate into a significant cost line for high-volume businesses.

Symphony incorporates estimated processing cost into its routing score. All else being equal, Symphony prefers the provider that will cost less to process the transaction. This preference is weighted — it does not override a large difference in success probability — but it consistently nudges routing toward lower-cost providers at the margin.

The cost component of the routing score uses a fee normaliser that converts the absolute fee estimate into a comparative score. A provider expected to charge a very low fee scores full marks on the cost dimension. A provider expected to charge near the maximum plausible fee scores zero. Most providers fall somewhere in between.

When a provider's model does not produce a reliable cost estimate — because the provider has insufficient fee data in the training set — Symphony falls back to a pre-configured default cost estimate for that provider. This ensures the cost component remains meaningful even when model data is sparse.

Most acquirer relationships are governed by commercial agreements that include minimum volume commitments. A merchant may agree to route a minimum of 10,000 successful transactions per month through a given provider in exchange for favourable fee terms. Failing to meet that commitment by the end of the month creates commercial problems. Over-routing beyond what is needed wastes volume that could fulfil other commitments.

Symphony tracks each provider's monthly contract fulfilment in real time. At the start of each routing decision, Symphony looks up how many successful transactions have already been routed to each provider this month for this client, and compares that to the contracted monthly obligation.

A provider that has fulfilled only 20% of its monthly obligation gets strong positive weighting — Symphony actively steers volume toward it to catch up. A provider that has fulfilled 80% of its obligation gets moderate weighting. A provider that has fulfilled 99% or more of its obligation is nearly shut off — it receives a fraction of the weight it would otherwise get — because sending more volume to it does not serve the business's commercial interests.

This mechanism operates continuously throughout the month, not just at month-end. As the month progresses and fill levels change with each transaction routed, the routing weights adjust dynamically. No manual intervention is required to rebalance traffic toward under-served providers.

The contract tracking is per client and per provider pair. If a client has not entered into a contract with a provider, that provider is either excluded from routing or receives neutral weighting, depending on configuration.

Payment providers experience incidents. Gateway failures, elevated decline rates for specific card types, regional connectivity problems, and regulatory holds can all affect a provider's ability to process transactions effectively. When these incidents occur, it is important to reduce or stop routing traffic to the affected provider quickly — before the business accumulates avoidable declines.

Symphony includes a rules engine for exactly this purpose. Operations teams can insert routing rules into the system that cause specific providers to be deprioritised — demoted to the bottom of the ranking — for specific transaction types or geographic regions, for a defined time period or indefinitely.

Rules operate at three levels:

• Region-level rules — deprioritise all providers when processing transactions from a specific geographic region. Used when a regional connectivity issue affects all providers equally, or when a specific region presents elevated risk.
• Method-level rules — deprioritise providers for transactions using a specific payment method (e.g. Maestro transactions are having elevated issues today).
• Provider-level rules — deprioritise a specific named provider, optionally scoped to a particular region or payment method.

Rules take effect immediately — there is no deployment, no code change, and no Lambda restart required. They are loaded fresh at the start of every routing decision. When the incident is resolved, the rule is deleted or marked inactive, and traffic resumes to the provider on the next request.

Importantly, routing rules do not remove providers from the ranking entirely. Demoted providers appear at the bottom of the list. This means that if all higher-ranked providers fail (which might happen if the incident is widespread), the system can still fall back to the demoted provider. Symphony provides a safety net rather than a hard block.

Symphony only recommends providers that the client has an active commercial relationship with. At the start of every routing decision, Symphony loads the set of active providers for the client from the contracts table.

If a client has contracts with four providers, only those four providers are considered — even if there are more active providers on the platform. A new provider cannot receive traffic from a client until a contract has been established.

If no contracts are found for a client — which may happen during initial onboarding — Symphony falls back to offering all active providers on the platform. This ensures that routing continues to function while commercial onboarding is completed, rather than failing entirely.

If contracts exist but none of the contracted providers are currently active in the system, Symphony logs a warning and falls back to all active providers, rather than returning an error. Routing continuity is prioritised.

Provider model invocations can fail. A model may not respond within the time budget. A SageMaker endpoint may experience a transient error. A network timeout may prevent a response from arriving.

Symphony is designed to handle these failures gracefully. Failed provider invocations do not cause the routing request to fail. They are collected in a failures list that is appended to the response alongside the ranking. The calling system can inspect this list for diagnostics but does not need to act on it — a partial ranking is still a valid routing recommendation.

Symphony enforces a time budget across all parallel model invocations. If the budget elapses before all providers have responded, Symphony uses the results collected so far. Any providers that did not respond in time are absent from the ranking. Callers should be aware that in high-latency conditions, the ranked list may be shorter than the total number of active providers.

If all provider invocations fail — no response is received from any provider within the time budget — Symphony returns an error rather than an empty ranking. An empty ranking would be worse than an error, because a calling system might interpret it as "no providers available" rather than "an error occurred."

Every request to Symphony must include a valid API key scoped to the Symphony product. Requests without a key are rejected with HTTP 401 before any processing begins. Requests with an invalid key are rejected with HTTP 403. No transaction data is processed and no provider models are invoked for unauthenticated requests.

Routing decisions are computed entirely in isolation. Each API call loads only the providers and contracts associated with the requesting client. The transaction payload of one client is never visible to or combined with data from any other client. Contract states, routing rules, and provider rankings are scoped to the requesting client throughout the evaluation.

All communication between the calling system and Symphony uses encrypted connections. Database connections used internally for contract state and routing rule lookups also enforce encryption in transit. Transaction data is never transmitted or queried in plaintext.

Database credentials used internally by Symphony are not embedded in code or configuration files. They are retrieved at Lambda cold-start from a centralised secrets management service and held in memory only. They are never logged, returned in error responses, or written to any external system.

All Symphony evaluations produce structured log entries. Key events logged include:

• Every invocation (request received, client identified)
• Every successful ranking (providers returned, their order, the transaction's region and payment method)
• Every routing rule application (which rules matched, which providers were affected)
• Every provider model failure (provider name, error type)
• Every unhandled exception (full traceback, error message)

Logs are written to centralised log storage and are available to the PayIntelli operations team for real-time monitoring and historical analysis.

Routing rules are the primary operational control surface for Symphony. The operations team can insert, modify, or deactivate routing rules at any time without requiring a code deployment or Lambda restart. Rules take effect on the next routing request received after insertion.

When investigating an incident or debugging unexpected routing behaviour, the operations team can inspect the active routing rules table to understand which providers are currently subject to BLOCK rules, what their scope is, and when they were created.

Each provider model is invoked independently and independently can fail. Symphony logs all provider model invocations, including whether they succeeded, how long they took, and what prediction values they returned. If a specific provider model is failing consistently — returning errors on every invocation — this will be visible in the logs and can be investigated without affecting the rest of Symphony's operation.

Symphony's underlying infrastructure — the SageMaker Multi-Model Endpoint hosting all provider models — is a managed, persistent service. It does not require per-request provisioning. Symphony monitors for endpoint availability and retries failed invocations once with exponential backoff before marking a provider as failed for that request.