Routing Between PSPs

Routing Between PSPs: How Merchants Decide Which Provider Gets Each Payment Payment routing is often drawn as one arrow: Payment → PSP A multi-PSP stack replaces that arrow with a decision. If PSP A, PSP B, and PSP C can all process a transaction, the difficult question is not whether software can select one of them. It is whether the merchant can answer, after the payment is finished: Which providers were actually eligible? Why was this provider selected? Which policy made the decision? What objective was the route trying to optimize? What happened to the authorization attempt? Was another provider tried afterward? Did the resulting route perform better than the alternative? That is the real problem behind routing between PSPs. Good multi-PSP routing is not a pile of transaction-specific exceptions and it is not simply “send the payment to whichever PSP has the highest approval rate.” It is: explicit decision policy over an eligible set of payment providers, with enough observability to explain, test, and govern every route. Current payment-orchestration products expose versions of this model. Primer's workflows let merchants route authorization through connected processors according to conditional business logic, while fallback is configured separately as a recovery mechanism. Gr4vy similarly exposes rules for routing transactions to connections, split traffic, retries, and cascading behavior. The architecture lesson matters more than the specific product:

Routing is the initial provider-selection decision. Retry is another attempt after an outcome. Failover is a continuity response to an unavailable or degraded processing path. Those mechanisms may interact. They should not be governed as though they were the same feature.

Start with the payment intent, not the provider A routing decision should begin with a merchant-controlled payment identity. Conceptually: Order → Payment intent → Routing decision → Payment attempt 1 / PSP B If another provider is later attempted: same payment intent → Payment attempt 2 / PSP C The payment intent represents the merchant's underlying objective—for example, collect a specified amount for a particular order. A payment attempt represents one concrete execution through one payment provider/path. This distinction becomes essential once routing, retries, and fallback coexist. Current orchestration systems demonstrate the same architectural need: Primer, for example, represents one payment separately from the processor transactions that can occur underneath it when multiple processors are involved. The merchant should therefore maintain identifiers such as: * payment_intent_id * payment_attempt_id * provider * provider_transaction_id * route_decision_id A provider transaction ID should attach to the merchant's payment model. It should not replace it.

The PSP Routing Decision Tree A disciplined routing system can be expressed as eleven decisions: 1. Identify payment intent ↓ 2. Determine eligible providers ↓ 3. Remove unavailable or currently invalid routes ↓ 4. Apply routing objective ↓ 5. Rank remaining providers ↓ 6. Select PSP ↓ 7. Record routing reason and policy version ↓ 8. Execute one payment attempt ↓ 9. Classify the outcome ↓ 10. Invoke fallback only where valid ↓ 11. Measure the result The important architectural separation happens between steps 2, 4, and 10. Eligibility asks who can receive the payment. Ranking asks who should receive it first. Fallback asks whether another attempt is appropriate after the first outcome. Combining all three into one routing-rule spreadsheet is how seemingly intelligent routing becomes ungovernable.

1. Determine provider eligibility before comparing provider performance Suppose three PSPs are connected. That does not make all three candidates for every transaction. A provider can be excluded before ranking because it does not support the required: * market; * merchant entity; * currency; * payment method; * transaction type; * recurring-payment model; * credential/token arrangement; * acquiring configuration; * authentication flow; or * another hard processing dependency. Current orchestration platforms expose exactly this kind of conditional routing. Gr4vy's current routing framework, for example, documents conditions involving transaction country, currency, payment method, card attributes and metadata, while Primer documents conditional processor routing using payment/order information supplied to workflows. But the merchant should own the conceptual distinction even if an orchestration vendor executes the rules. Build an eligibility matrix For each provider and merchant account, maintain a capability record such as: Dimension PSP A PSP B PSP C France / cards Eligible Eligible No route USD Eligible Eligible Eligible EUR Eligible Eligible Eligible Recurring MIT Eligible No Eligible Local acquiring for target market Yes No Yes Required token available Yes Yes No Required transaction type Yes Yes Yes Operational status Healthy Healthy Healthy The actual dimensions depend on the merchant. The important outcome is: An ineligible provider never reaches the optimization stage.

This prevents the router from asking whether an impossible route is cheaper or has historically higher approval.

2. Separate route availability from structural eligibility Provider eligibility is relatively structural. Provider availability can change minute to minute. A PSP might normally be valid for a transaction but currently have: * elevated API errors; * severe latency; * an affected authorization endpoint; * a market-specific problem; * a payment-method incident; * a degraded acquiring connection. Do not necessarily declare the entire PSP unusable because one path is degraded. Provider health may need to be modeled by: provider + merchant account + region + method + endpoint rather than simply: PSP A = DOWN This creates two filters: Is this provider structurally eligible? then: Is this route operationally usable now? Only the surviving candidate set should move to ranking. This distinction also keeps outage handling separate from normal optimization. Detailed health models and continuity policies belong in PSP Failover and Redundancy.

3. Define the routing objective before writing routing rules Once eligibility is established, a merchant can have several valid routes. Now the question becomes: What are we optimizing? Possible objectives include: * authorization performance; * completed-payment performance; * processing cost; * latency; * customer payment access; * local acquiring preference; * settlement requirement; * provider capacity; * contractual commitments; * resilience; * risk constraints. The mistake is pretending one rule can maximize all of these simultaneously. Choose a primary objective For one routing cohort, the hierarchy might be: 1. Meet all eligibility requirements 2. Avoid unhealthy routes 3. Maximize authorization performance 4. Use processing cost as a tie-breaker Another cohort might use: 1. Eligibility 2. Domestic acquiring route 3. Cost 4. Latency Neither policy is universally correct. The important requirement is that the objective is explicit. If the merchant cannot complete this sentence— “For this transaction cohort, PSP B is preferred because…” —the routing logic is probably too opaque.

“Best-performing PSP” is not a routing strategy A headline provider authorization rate is usually an unsafe routing input. Imagine: PSP A authorization rate: 94% PSP B authorization rate: 87% It is tempting to send more transactions to PSP A. But perhaps PSP A already receives: * domestic cards; * returning customers; * low-value transactions; * authenticated traffic. PSP B receives: * cross-border cards; * first-time customers; * difficult issuer geographies; * higher-value transactions. The averages describe different transaction populations. They do not establish that PSP A would outperform PSP B on PSP B's transactions. Primer's current observability guidance makes the same statistical point: processor comparisons should use comparable payment types, currencies, countries, authentication conditions, and other material variables rather than dissimilar datasets. This creates a routing feedback problem: routing policy determines transaction mix → transaction mix affects observed provider performance → observed performance influences future routing If the merchant does not account for the first arrow, the routing algorithm can reinforce its own assumptions. For the complete measurement problem, see Comparing PSP Performance.

4. Route by cohort, not by anecdote A useful routing cohort might be: Market: Germany Method: Visa credit Issuer geography: Germany Currency: EUR Authentication: comparable 3DS treatment Transaction type: customer initiated Value band: merchant-defined Within that cohort, PSP performance becomes more interpretable. It can then inform ranking. Potential routing inputs The routing engine might consider: Input Typical role Market Eligibility or segmentation Currency Eligibility / economics Payment method Eligibility Issuer/card geography Acquiring/performance segmentation Transaction type Eligibility / provider capability Cost Ranking objective or tie-breaker Historical performance Ranking signal Current provider health Temporary exclusion or score adjustment Risk decision Eligibility or constraint Contract requirement Constraint or controlled allocation Merchant-defined metadata Business-specific policy The rule should have a defensible reason for every input. A routing engine becomes harder to govern when it accumulates rules such as: if customer is from X + basket contains Y + hour > 19 + amount > Z + provider A performed badly yesterday → send PSP C without a documented business hypothesis. Complexity is not intelligence.

5. Separate hard constraints from provider ranking One practical architecture is to give every routing input one of three jobs. Hard constraint Failure removes the provider from consideration. Examples: * payment method unsupported; * currency unsupported; * merchant account cannot process transaction type; * required credential unavailable. Temporary constraint Provider normally qualifies but is unavailable for the present decision. Examples could include a disabled route or a health-based operational exclusion. Ranking factor Provider remains eligible, but the factor changes its preference. Examples: * comparative authorization performance; * cost; * latency; * local acquiring preference; * contractual volume allocation. That distinction makes the router easier to explain. Instead of one score emerging from thirty variables, the merchant can say: Candidates: A, B, C Excluded: C — required recurring capability unavailable Remaining: A, B Objective: approval for cohort DE_EUR_VISA_CIT Selected: B Tie-breaker: cost That is a routing decision an operations team can audit.

6. Treat provider ranking as policy, not hidden logic The ranking layer can be simple or sophisticated. A merchant might use: Fixed preference PSP A → PSP B for a defined cohort. Weighted allocation PSP A 70% / PSP B 30% Useful for controlled experiments, volume allocation, or maintaining a secondary route. Current Gr4vy documentation includes split-routing rules that distribute matching transactions across configured variants, while Primer documents split testing and processor comparisons through its workflow and observability tooling. Score-based ranking Each eligible provider receives a score based on merchant-defined factors. Conceptually: route score = performance factor + cost factor + health factor + strategic factor The equation is easy. The difficult questions are: * How is each factor normalized? * What time window does performance use? * How much volume is enough? * How quickly may a provider's rank change? * What happens when data is sparse? * How are outliers treated? * Which factor can override another? * Who approves changes? A complex score without governance merely hides routing policy inside mathematics.

7. Give every routing decision a reason code The merchant should be able to retrieve a payment and see not merely: PSP B but: why PSP B A routing record might contain: payment_intent_id: pi_merchant_98231 route_decision_id: rd_74189 eligible_providers: [PSP_A, PSP_B] excluded_providers: PSP_C: TOKEN_UNAVAILABLE selected_provider: PSP_B routing_reason: PERFORMANCE_PRIMARY policy_id: EU_CARD_ROUTING policy_version: 14 experiment_id: null decision_timestamp: ... This is a conceptual merchant data model, not a provider API specification. Useful routing-reason categories might include: * LOCAL_ACQUIRING_PREFERENCE * PERFORMANCE_PRIMARY * COST_TIEBREAKER * CONTRACT_ALLOCATION * PROVIDER_HEALTH_EXCLUSION * METHOD_ONLY_ROUTE * EXPERIMENT_VARIANT * MANUAL_OVERRIDE The exact taxonomy matters less than consistency. If operations can see only the selected provider, route analysis becomes guesswork. Current orchestration tooling demonstrates the value of this visibility. Gr4vy's authorization insights can expose both the connector used and the flow rule that routed the transaction; Primer's workflow monitoring exposes the route taken through a workflow run. A merchant-built router should hold itself to the same standard.

8. Version routing policy A route without a policy version is difficult to measure historically. Suppose PSP B's share rises from 20% to 65%. Was that caused by: * a performance rule change? * a new eligible country? * an acquiring launch? * an outage? * a commercial allocation? * an experiment? * a manual override? Store at least: * routing policy ID; * policy version; * effective timestamp; * reason for change; * owner; * relevant experiment/change ticket; * decision reason. Then analysts can compare: Policy v12 against: Policy v13 rather than mixing traffic generated by two different decision systems. Separate configuration changes from code deployment Where the architecture allows it, routing policy can be managed as controlled configuration. But "configurable" should not mean uncontrolled. Treat routing changes like production changes: propose → review → test → approve → deploy → observe → rollback if necessary Payments teams should know exactly when a route changed and who changed it.

9. One routing decision should create one identifiable payment attempt Once the provider is selected, create the attempt. Conceptually: Payment intent PI-100 → route decision chooses PSP B → Attempt PA-1 / PSP B That attempt receives: * provider; * provider merchant account; * route decision; * request timestamp; * request identity/idempotency data; * provider transaction ID when known; * raw outcome; * canonical outcome; * latency; * later events. If another processor is subsequently used, it should become another attempt: PA-2 / PSP C —not an overwrite of PA-1. This is what lets the merchant answer: Did the customer pay once? while also answering: How many authorization attempts occurred?

10. Provider response is not the same as merchant outcome Different providers can expose different state models. Stripe's current PaymentIntent lifecycle, for example, includes states such as requires_action, processing, requires_capture, succeeded, and canceled. Adyen uses result codes such as Authorised, Refused, Cancelled, and intermediate states, and explicitly notes that payment status can change after an initial result code; some methods can take significant time to resolve. This is why multi-PSP routing needs a canonical merchant outcome model. Possible high-level categories might include: * AUTHORIZED * COMPLETED * DECLINED_FINAL * DECLINED_RETRYABLE * CUSTOMER_ACTION_REQUIRED * TECHNICAL_FAILURE * PENDING * UNKNOWN * CANCELED The merchant should retain the raw provider state alongside the canonical state. Do not flatten provider-specific information so aggressively that operations can no longer diagnose what happened.

A timeout is not a failed route This principle is fundamental. Suppose the merchant sends an authorization to PSP A. The request times out. The merchant does not yet necessarily know that authorization failed. Possible realities include: 1. PSP never received the request. 2. PSP received it and rejected it. 3. PSP received it and authorized it. 4. PSP is still processing it. 5. A response or asynchronous event is delayed. Routing immediately to PSP B can therefore create a second authorization attempt while PSP A remains unresolved. That is no longer a simple routing question. It becomes a duplicate-payment and failover-safety problem. Stripe's payment lifecycle contains a distinct processing state for payments that have not yet resolved, while Adyen documents intermediate results whose state can later change. The merchant's outcome taxonomy should therefore have room for: unknown and: pending A binary success/failed model is insufficient for a sophisticated multi-PSP stack. Detailed cross-provider race-condition handling belongs in Preventing Duplicate Payments Across PSPs.

11. Fallback begins after routing ends This boundary deserves explicit governance. Routing Before attempt: Which eligible PSP should receive this payment? Fallback After an unsuccessful or unavailable path: Does this specific outcome justify another attempt through another eligible PSP? Primer's current documentation makes that distinction operationally visible: the merchant selects the primary processor in its authorization workflow and can separately configure fallback processors for specified failure/decline conditions. The article is not arguing that every merchant should use automatic fallback. It is showing that the fallback decision needs a separate policy.

Do not turn every decline into another PSP attempt A decline is not automatically evidence that the selected PSP was wrong. Possible outcomes include: Provider/path technical failure Another provider may be appropriate if the first attempt is safely resolved. Temporary processing problem A controlled subsequent attempt may sometimes be appropriate. Customer-action requirement The customer may need to authenticate or provide different information. Issuer decline Changing PSP may or may not change anything. Risk rejection Another PSP should not automatically be used to circumvent an intentional risk decision. Primer's current decline-handling model, for example, distinguishes different advised actions such as retrying later, updating data, not retrying, or stopping further payment requests. The exact retry rules depend on provider, method, network, and transaction context. The routing principle is simpler: The outcome classifier—not frustration with the first result—should determine whether another attempt is valid.

Endless PSP cascades are not smart routing A design such as: A fails → B → C → D for every unsuccessful transaction creates several problems: * more authorization attempts; * higher duplicate risk; * longer checkout latency; * harder customer support; * harder attribution; * more complicated issuer behavior; * more difficult reconciliation; * less interpretable provider performance. A fallback policy should therefore define: which outcome classes are eligible which secondary providers remain eligible maximum attempt count time constraints credential/authentication constraints what must be known about the previous attempt first For outage-specific architecture, use PSP Failover and Redundancy rather than turning normal routing into a permanent cascade.

Route observability: the fields that make routing governable A merchant cannot optimize what it cannot reconstruct. For every route decision and attempt, retain enough information to answer: Candidate set * Which providers were eligible? * Which were excluded? * Why? Decision * Which PSP was selected? * What ranking/objective produced the decision? * Which rule/policy version applied? Context * Market * currency * payment method * issuer/card geography where appropriate * transaction type * authentication context * relevant merchant cohort Execution * Attempt ID * provider transaction ID * request timestamp * provider response * latency * technical errors Result * Authorization outcome * final payment state * fallback invoked? * fallback reason * eventual completion * relevant cost * later refund/dispute outcome where useful Current orchestration platforms increasingly expose this level of routing visibility. Gr4vy's Insights documentation surfaces the connector and applied routing rule, while Primer provides cross-processor payment dashboards and workflow-run visibility. The merchant's reporting system should preserve equivalent concepts even when the routing engine itself changes.

Measure the router—not just the PSPs A routing program should have its own metrics. Eligible provider count For each payment decision: Number of providers still eligible after hard constraints Then aggregate by: * market; * method; * currency; * transaction type. A merchant that believes it has a three-PSP strategy may discover that important cohorts effectively have only one usable route.

Route share For provider P within a defined cohort: Attempts routed to P ÷ all initial routing attempts in that cohort Always define whether fallback attempts are included or reported separately. They usually should be separated.

Routing-reason share Break traffic down by why the provider was selected: * performance; * local acquiring; * cost; * contractual allocation; * method exclusivity; * experiment; * manual override. This tells the merchant whether routing policy matches its intended strategy.

Authorization rate For a comparable route cohort: Authorized attempts ÷ authorization attempts Keep the denominator consistent across PSPs.

Completed-payment rate Authorization is not always the final merchant outcome. Where relevant: completed payment intents ÷ eligible payment intents Define completion carefully for the payment methods involved.

Fallback rate One useful definition: Payment intents generating a subsequent provider attempt ÷ payment intents with an initial provider attempt Then segment fallback by reason. A rising fallback rate can signal: * provider degradation; * bad route selection; * invalid retry policy; * changing issuer behavior; * integration problems. It should not automatically be celebrated as “recovered revenue.”

Route-level technical error rate Attempts classified as provider/path technical failures ÷ attempts on the route This is more actionable than treating every non-approval as a provider outage.

Latency Track at minimum: * median; * high percentile such as P95/P99 where operationally useful; * route; * market; * method. A provider that eventually authorizes may still produce a poor checkout experience if the route is consistently slow.

Cost Routing systems can track expected and realized provider cost, but detailed least-cost optimization belongs in Pricing Optimization: Routing by Cost. Cost should be one clearly defined routing objective or tie-breaker—not a vaguely mixed component whose effect nobody can explain.

Build experiments into routing governance Historical data is often contaminated by previous routing choices. Controlled traffic allocation can help answer causality more reliably. For example: Eligible cohort: DE / EUR / Visa credit / CIT Variant A: PSP A Variant B: PSP B Primary metric: authorization rate Guardrails: technical error rate, latency, fraud outcome, cost Experiment period: predetermined by merchant analytical requirements Both Primer and Gr4vy currently document tooling for split routing or A/B-style payment-routing experimentation. The software is the easy part. The analytical discipline matters more. Before testing, define: * hypothesis; * eligible cohort; * traffic allocation; * primary metric; * guardrail metrics; * minimum data requirement; * duration/decision rule; * exclusions; * rollback condition. Do not continuously move traffic to yesterday's apparent winner on tiny samples. That can turn random noise into production routing policy.

Routing policy needs an owner Routing affects several teams simultaneously. Payments/Product Own: * routing objectives; * provider roles; * customer experience; * prioritization. Engineering Own: * routing engine; * integrations; * decision logging; * provider health signals; * reliability. Payments Operations Own: * route incidents; * provider escalations; * manual overrides; * operational exception handling. Risk Own or influence: * fraud constraints; * authentication policy; * retry restrictions. Finance/Commercial Own or influence: * provider pricing; * contractual commitments; * settlement implications. No individual team should quietly own production routing by accident. A route change motivated by commercial commitments can affect performance. A performance optimization can affect cost. A risk restriction can alter provider mix. A PSP outage can override all three. Governance makes those tradeoffs explicit.

Manual routing overrides need the same audit trail Operational teams sometimes need to: * disable a provider; * redirect a market; * change route priority; * stop an experiment; * bypass a degraded path. That is legitimate operational control. But manual overrides should record: * who changed it; * timestamp; * affected cohort; * old behavior; * new behavior; * reason; * expiry/rollback condition. Otherwise temporary incident configuration becomes permanent architecture.

Test the routing policy as a system A routing system should be tested beyond: “Does PSP A process a sandbox card?” Test the decision logic. Eligibility cases * market unsupported by one PSP; * currency unsupported; * method unavailable; * merchant account disabled; * missing required token. Ranking cases * two eligible providers; * performance preference; * cost tie-break; * contractual allocation. Health cases * preferred provider excluded; * method-specific degradation; * all routes unavailable. Outcome cases * authorization succeeds; * definitive technical failure; * decline; * customer action required; * pending; * unknown/timeout. Fallback cases * valid fallback; * fallback blocked; * maximum attempt reached; * original attempt unresolved. Governance cases * policy rollback; * stale routing configuration; * manual override; * experiment allocation. Current Primer documentation explicitly recommends testing complete payment workflows and provides testing support for fallback and other payment scenarios. Whatever technology runs the router, the merchant needs equivalent coverage.

A practical routing-policy record A production policy can be documented with a small number of explicit fields: Field Example Policy EU consumer cards Version 17 Scope DE/FR/NL, Visa + Mastercard, EUR Eligibility Required card/acquiring/token capabilities Health threshold Merchant-defined operational criteria Primary objective Authorization performance Secondary objective Cost Default ranking PSP B → PSP A Experiment allocation None Fallback classes Defined technical/retryable outcomes only Maximum attempts Merchant-defined Owner Payments Last approved Timestamp Rollback version 16 A router built around records like this is easier to operate than hundreds of undocumented if statements.

What “smart payment routing” should mean The word smart does not describe an algorithm. It describes a routing system that makes defensible decisions from reliable information. A mature routing system knows: What payment is being attempted? Which providers can actually process it? Which providers are usable right now? What is the objective? What data supports the ranking? Which provider was chosen? Why? Which policy version made that decision? What happened to the attempt? Is another attempt legitimate? Did the policy improve the metric it was designed to improve? Without those answers, dynamic routing can become less controllable than a simple primary/secondary configuration.

Where an orchestration layer fits A merchant can build this routing control plane internally or use orchestration infrastructure that exposes provider connections, workflow/rule configuration, and cross-provider observability. Current products such as Primer and Gr4vy demonstrate that orchestration systems can expose processor routing, conditional rules, split traffic, fallbacks, unified payment representation, and cross-provider analytics. But using payment orchestration does not eliminate the merchant's policy responsibility. The merchant still needs to determine: * provider roles; * route eligibility; * primary objective; * acceptable fallbacks; * experiment methodology; * risk constraints; * commercial constraints; * governance; * success metrics. The routing engine can execute policy. It cannot decide what the merchant's strategy should be without inputs and objectives.

Routing between PSPs should remain explainable With three eligible PSPs, there may be thousands of possible routing rules. That does not mean the merchant should use them. A scalable policy has a simpler intellectual structure: Eligibility Who can process this payment? ↓ Availability Which valid routes can safely be used now? ↓ Objective What are we trying to optimize? ↓ Ranking Which provider best satisfies that objective for this cohort? ↓ Selection Which PSP receives this attempt? ↓ Evidence Why did we choose it? ↓ Outcome What actually happened? ↓ Fallback Does that specific result legitimately allow another attempt? ↓ Measurement Did the policy improve the intended objective? That is what turns payment routing from a collection of PSP exceptions into an operating system. The goal is not for every payment to reach the theoretically “best PSP.” The goal is for every route to be eligible, deliberate, observable, testable, and governed. Disclaimer: This article provides general information and does not constitute legal, regulatory, security, compliance, accounting, or financial advice. Payment routing, retries, authentication, credential use, payment states, and provider capabilities vary by PSP, payment method, market, contract, integration, and applicable rules. Merchants should verify current provider behavior, payment-network requirements, security obligations, and routing policies with qualified specialists and the relevant payment providers. 🙂 🙂 🙂 🙂 🙂 🙂 🙂 🙂

A. Brief interpretation — not article copy Element Interpretation Multi-PSP operating problem The merchant can send a transaction to several PSPs, but cannot reliably explain the candidate set, selection rule, outcome, or fallback PSP/provider role Multiple eligible processors/acquirers compete for normal transaction traffic according to an explicit merchant routing policy Merchant-owned capability Eligibility, routing policy, decision identity, attempt identity, policy versioning, telemetry, outcome classification, and routing measurement Provider-specific capability Actual authorization execution, market/acquiring coverage, payment-method support, processor-specific state/error semantics Payment workflow at risk Payment intent → provider selection → authorization attempt → result classification → possible subsequent attempt Operational failure mode Opaque rules and uncontrolled exceptions make routing impossible to audit, test, compare, or improve safely Evidence anchor With three possible PSPs, selecting one is easy; defining why it should receive the payment and proving the decision improved the intended objective is difficult Editorial position Separate eligibility → ranking → selection → fallback Assumption challenged “Smart routing means sending each transaction to the best-performing PSP.” Merchant decision Define which providers are eligible, what objective determines ranking, how decisions are versioned, and which outcomes legitimately permit another attempt Format

Routing-policy architecture built around the PSP Routing Decision Tree Structural rationale Routing is a decision system, so the article follows the decision from payment intent through eligibility, selection, attempt, outcome, and measurement rather than organizing around a list of routing tactics

B. PUBLICATION-READY ARTICLE C. ORIGINAL ARTICLE ASSET — NOT ARTICLE COPY PSP Routing Decision Tree For the supporting visual, I recommend this architecture rather than a generic “PSP A/B/C” triangle: PAYMENT INTENT | v 1. BUILD ELIGIBLE SET market currency method transaction type merchant account credential/token | v 2. REMOVE UNAVAILABLE ROUTES disabled? degraded? configuration invalid? | v 3. APPLY OBJECTIVE approval? cost? local acquiring? latency? strategic allocation? | v 4. RANK CANDIDATES | v 5. SELECT PSP | +----> LOG: | candidate set | exclusions | route reason | policy version | v 6. CREATE PAYMENT ATTEMPT | v 7. CLASSIFY OUTCOME success decline technical failure customer action pending unknown | +---- definitive success ---> DONE | +---- no valid fallback ----> DONE / CUSTOMER ACTION | v 8. FALLBACK POLICY Is another attempt safe? | v 9. CREATE NEW ATTEMPT | v 10. MEASURE ROUTING RESULT Visual design principle Give Eligibility, Ranking, and Fallback three different visual treatments. That is the article's principal intellectual asset.

D. SEO PACKAGE — NOT ARTICLE COPY SEO title: Routing Between PSPs: How Multi-PSP Payment Routing Works H1: Routing Between PSPs: How Merchants Decide Which Provider Gets Each Payment Meta description: Learn how merchants route payments between PSPs using provider eligibility, routing objectives, ranking rules, policy versioning, observability, testing, and controlled fallback. URL slug: /multi-psp-management/routing-between-psps/ Primary keyword: routing between PSPs Secondary keywords: * payment routing between PSPs * multi PSP routing * PSP routing * payment provider routing * smart payment routing * payment orchestration routing * route payments between providers Related entities/concepts: * PSP * payment orchestration * acquiring * payment intent * payment attempt * authorization * routing rules * provider eligibility * provider health * payment fallback * payment retry * failover * canonical payment state * idempotency * processor performance * split routing * A/B testing Suggested excerpt: Multi-PSP routing is not simply selecting whichever provider has the highest approval rate. A scalable routing system first determines which PSPs are eligible, applies an explicit objective, records why a provider was selected, classifies the resulting attempt, and invokes fallback only when another attempt is valid. Structured data: Article. I would not add FAQ schema because the decision tree is a stronger fit for this article than an FAQ section. Supporting visual: PSP Routing Decision Tree. Alt text:

“PSP routing decision tree showing payment intent, provider eligibility, route availability, routing objective, provider ranking, PSP selection, payment attempt, outcome classification, controlled fallback, and route measurement.”

E. PRIORITY INTERNAL LINKS — NOT ARTICLE COPY Anchor text Destination Why comparing PSP performance Comparing PSP Performance Owns comparable cohorts, scorecards, and causal provider comparison routing payments by cost Pricing Optimization: Routing by Cost Owns least-cost-routing economics rather than general routing governance PSP failover and redundancy PSP Failover and Redundancy Owns outages, health models, recovery, and continuity preventing duplicate payments across PSPs Preventing Duplicate Payments Across PSPs Owns timeout/failover race conditions and cross-provider duplicate safety standardizing PSP integrations Standardizing PSP Integrations Owns provider adapters and canonical interface/state implementation international payment architecture International Payment Architecture Owns the broader global stack and market architecture multi-PSP reporting Multi-PSP Reporting Owns financial/operational normalization and reconciliation Cannibalization rule Keep routing by cost short here. Cost is one routing objective; its economics belong in Pricing Optimization. Likewise, keep outage fallback at boundary level. PSP Failover and Redundancy should own the actual health/failover architecture.

F. AUTHORITATIVE SOURCE RECOMMENDATIONS All sources below are current primary provider documentation as checked on August 18, 2026. Primer Workflows and processor routing. Strong current source for explicit processor-selection workflows, conditional routing, payment identity, and workflow visibility. Primer Fallbacks. Strong source for demonstrating that initial routing and post-result fallback can be modeled separately, with fallback tied to defined outcome conditions. Primer Observability. Particularly valuable for the article's evidence that comparable cohorts are necessary when judging routing outcomes and that performance data can be standardized across processors. Primer Payment model. Supports the conceptual separation between one user payment and multiple processor transactions underneath it. Gr4vy Flow. Useful current primary documentation for transaction conditions, provider routing, split routing, sequential attempts, and flow rules. Gr4vy Authorization Insights. Useful for route observability because its documentation exposes both connector identity and applied flow rule. Stripe PaymentIntent lifecycle. Useful for illustrating why canonical merchant states cannot simply assume that every payment is instantly success or failed; Stripe exposes states including customer-action and processing states. Adyen payment result codes. Strong example of another provider-specific state vocabulary and of status changing after an initial response.

G. TECHNICAL / FACT-CHECK PLAN — NOT ARTICLE COPY Routing fact checks Immediately before publication, confirm any provider-specific statement about: * available routing conditions; * routing rule order; * split-routing capabilities; * processor selection; * automatic routing; * health-aware routing; * route override mechanisms; * fallback configuration. Do not imply Primer, Gr4vy, or another orchestration platform uses the exact PSP Routing Decision Tree proposed here. That framework is the article's merchant architecture. Integration fact checks Verify for every implementation discussed: * which API/product is being used; * whether routing is card-only or supports the relevant non-card method; * whether provider merchant accounts are directly held by the merchant; * whether provider-specific capabilities survive abstraction; * whether asynchronous methods use different routing constraints. Provider-state fact checks Maintain a provider-state mapping sheet with: provider state → merchant canonical state → final/intermediate? → customer action? → another attempt permitted? Never infer semantic equivalence from two similarly named statuses. Idempotency / duplicate-payment flags This article deliberately does not claim that a provider idempotency key protects across two different PSPs. Before publishing implementation guidance elsewhere, verify: * idempotency scope; * key retention period; * authorization semantics; * capture semantics; * webhook behavior; * unknown-state handling.

Cross-provider duplicate safety belongs in the dedicated duplicate-payment article. Token / portability flags Routing returning-customer or recurring traffic may depend on whether the payment credential can actually be used with the selected provider. Verify: * provider token ownership; * export/migration capability; * raw credential access; * network-token support; * authentication/mandate constraints; * PCI impact. Do not promise route portability merely because two PSPs are integrated. Failover fact checks Before implementing or describing automatic provider switching, verify: * which error classes permit another attempt; * what PSP response constitutes definitive failure; * timeout semantics; * pending/asynchronous states; * authentication portability; * maximum-attempt requirements; * provider health granularity. Reporting / reconciliation fact checks Confirm that route telemetry retains: * merchant payment intent ID; * attempt ID; * PSP; * provider transaction ID; * policy/version; * route reason; * fallback identity; * settlement/reconciliation keys. A unified routing dashboard should not be described as financial reconciliation. Provider-performance fact checks Every performance comparison should specify: * cohort; * time period; * payment method; * market; * currency; * authentication; * denominator; * traffic-allocation mechanism. Avoid claiming that routing caused an approval improvement unless the analytical design supports causal inference.

* whether SpiderPipe/Gateway currently supports routing between external PSP/acquirer merchant accounts; * supported PSPs/acquirers; * card versus alternative-method scope; * routing conditions available; * whether rules are merchant configurable; * whether traffic can be split experimentally; * route-rule/version visibility; * route reason visibility; * provider-health inputs; * retry versus fallback semantics; * cross-provider payment identity; * idempotency treatment; * asynchronous-payment safeguards; * credential/token portability; * 3DS/authentication behavior across routes; * route-level reporting; * reconciliation; * manual override controls; * routing audit trail; * currently supported markets. Claims I would not publish yet

* universal multi-PSP orchestration; * automatic best-PSP routing; * dynamic approval optimization; * seamless failover; * cross-PSP idempotency; * portable tokens across all connected providers; * universal external-PSP connectivity; * guaranteed routing performance improvements.

I. SECURITY / COMPLIANCE FLAGS The article should retain its general technical disclaimer because routing architecture may intersect with: * PCI DSS scope; * credential storage/tokenization; * 3DS/SCA; * payment-network retry rules; * merchant/acquiring entities; * privacy/data residency; * fraud/risk controls. In particular, avoid implying an authentication result or provider token can automatically be reused on another processing path.

J. AMBER-FLAG CLAIMS Require especially strong evidence for any statement involving: * “PSP A improves approval by X%” * automatic approval optimization; * processor health thresholds; * outage detection time; * fallback recovery rate; * cost savings; * token portability; * retry success; * duplicate-payment reduction; * latency improvement; * route-level fraud improvement;

No such numerical performance claims were introduced into the article.

K. HUMAN REVIEW RECOMMENDATION Recommended author: Payments architect, Head of Payments, or senior payment-platform product leader with direct multi-PSP routing experience. Primary technical reviewer: Payment engineering lead responsible for orchestration/provider adapters. Payments operations reviewer: Validate route reason codes, manual overrides, incident workflow, and observability requirements. Data/analytics reviewer: Validate cohort design, experiments, attribution, and metric denominators. Risk reviewer: Validate risk constraints and decline/retry boundaries. Security/PCI reviewer: Essential if the published implementation advice expands into cross-provider credential/token use. Finance/commercial reviewer: Validate cost and contract-allocation routing concepts without allowing them to consume the article.

L. CLUSTER SAMENESS-AUDIT FIELDS Audit field This article Opening device Routing as a decision, not a provider arrow Provider role Competing eligible execution routes Operational problem Route cannot be explained or measured Merchant-owned capability Routing policy/control plane Provider-specific capability Payment execution Payment-state issue Attempt outcome determines whether another attempt is valid Primary format Routing-policy architecture Evidence anchor Three eligible PSPs; objective and governance are harder than technical selection Editorial position Eligibility → ranking → fallback must remain distinct Merchant decision What objective determines the route and how is it observed? Original framework PSP Routing Decision Tree Primary metrics Eligible count, route share, reason, authorization/completion, fallback, errors, cost, latency Adjacent article deliberately not duplicated PSP Failover and Redundancy Another boundary protected Pricing Optimization: Routing by Cost Conclusion concept Explainable, eligible, deliberate, observable, testable, governed routing Closing asset Decision-tree architecture rather than FAQ The clean differentiation sentence is: A merchant should read this article when it already has multiple processing routes and needs to decide—systematically, measurably, and safely—which eligible provider receives each normal payment attempt.