{"id":66,"date":"2026-05-04T15:54:01","date_gmt":"2026-05-04T14:54:01","guid":{"rendered":"https:\/\/lukaskoren.tech\/?page_id=66"},"modified":"2026-06-29T19:18:51","modified_gmt":"2026-06-29T18:18:51","slug":"dynamic-routing-payment-gateway","status":"publish","type":"page","link":"https:\/\/lukaskoren.tech\/?page_id=66","title":{"rendered":"Dynamic Routing Engine"},"content":{"rendered":"\n

TL;DR<\/strong><\/h2>\n\n\n\n

The EVX Technologies Ltd payment orchestration platform lifted debit card authorisation rates from 78% to 91% in production. The programme was a zero-to-one infrastructure build targeting clean high-risk merchants – a segment the mainstream acquiring industry rejects through blunt MCC-level risk categorisation. What made it hard was designing a five-model probabilistic routing architecture and proving its commercial case before any acquirer would formally underwrite the merchant book.<\/p>\n\n\n\n

CONTEXT<\/strong><\/h2>\n\n\n\n

EVX Technologies Ltd built a payment orchestration layer for merchants in high-risk verticals – online gambling, sports betting, nutraceuticals, and subscription commerce – that generate legitimate card volume but are routinely declined or de-banked by tier-1 payment gateways and acquiring banks. The structural failure is consistent: mainstream payment gateways apply static MCC-level risk categorisation, assign merchants a single processing route, and provide no fallback when that acquirer’s risk appetite shifts.<\/p>\n\n\n\n

The commercial gap was an orchestration layer this segment had never had access to: one that could match each transaction to the acquirer most likely to approve it in real time, while maintaining the fraud and chargeback posture required to keep Visa and Mastercard scheme monitoring programmes inactive.<\/p>\n\n\n\n

PROBLEM<\/strong><\/h2>\n\n\n\n

User problem<\/strong><\/p>\n\n\n\n

Merchants in MCC 7995 were experiencing debit card authorisation rates below 80% – not because of fraudulent cardholders, but because their single assigned acquirer applied blanket decline rules across the entire category regardless of individual transaction risk. In many cases a Barclays UK debit card from a returning player with 14 prior successful deposits received identical treatment to a first-time prepaid virtual card. Merchants had no visibility into decline reasons and no fallback route.<\/p>\n\n\n\n

Business problem<\/strong><\/p>\n\n\n\n

Static single-acquirer assignment produces measurably sub-optimal commercial outcomes. Transaction data shows approval probability for the same BIN – Barclays, MCC Gambling, \u00a30\u201350 – varying from 92% on one acquirer to 81% on another. That differential was not being captured. Every misrouted transaction was recoverable revenue destroyed by an infrastructure gap rather than by genuine issuer risk. Each percentage point of lost authorisation rate represented a direct and recoverable commercial loss – recoverable with the right routing architecture, but not recoverable within a single-acquirer model.<\/p>\n\n\n\n

Technical and operational problem<\/strong><\/p>\n\n\n\n

Solving this required reframing routing as an expected value maximisation problem rather than a configuration problem. The orchestration layer needed to evaluate a composite score across five probability models – approval, fraud, chargeback, retry success, and velocity – for each candidate acquirer, in milliseconds, on every transaction. Acquirer credential isolation had to be maintained per merchant and per environment without conditional logic in the live transaction flow. The absence of live merchant volume at programme inception meant routing assumptions had to be proven from first principles rather than from observed data – a sequencing constraint that shaped every architectural decision.<\/p>\n\n\n\n

APPROACH<\/h2>\n\n\n\n

Reframing the routing objective: expected net value, not approval rate<\/strong><\/p>\n\n\n\n

The foundational programme decision was defining what the routing engine optimises before any architecture was committed. The engine does not maximise approval rate. It maximises expected net value to the gateway per transaction , the margin remaining after subtracting expected fraud losses, chargeback costs, and acquirer processing fees:<\/p>\n\n\n\n

EV = (P_approve \u00d7 Net margin per approved transaction) \u2212 (P_fraud \u00d7 FraudLoss) \u2212 (P_cb \u00d7 ChargebackCost)<\/code><\/pre>\n\n\n\n
Where net margin = gateway processing fee \u2212 acquirer fee. Every term except net margin and acquirer fee is a probability estimate, recalculated fresh on every transaction. On a \u00a3100 gambling deposit, this distinction is decisive: Acquirer C at 94% approval with high fraud and chargeback exposure generates negative EV. Acquirer B at 86% approval with low fraud and chargeback exposure generates materially positive EV. Routing to Acquirer C destroys gateway margin while appearing to perform on the headline metric.<\/p>\n\n\n\n
The five probability models<\/strong><\/p>\n\n\n\n
The EV formula draws on three probability models. Two further models , velocity scoring and retry success , gate transactions before routing and recover value after soft declines respectively. All five are described below. All five share one mathematical foundation: Bayesian updating.<\/p>\n\n\n\n
Bayesian updating , the mathematical foundation of all five models<\/strong><\/p>\n\n\n\n
Every probability estimate in the system is maintained as a Beta distribution with two parameters:<\/p>\n\n\n\n
    \n
  • \u03b1 = number of times the outcome of interest was observed (approval, fraud, chargeback, retry success)<\/li>\n\n\n\n
  • \u03b2 = number of times the outcome was not observed<\/li>\n<\/ul>\n\n\n\n
    The current best estimate of the probability is:<\/p>\n\n\n\n
    P<\/mi>=<\/mo>\u03b1<\/mi>\/<\/mi>(<\/mo>\u03b1<\/mi>+<\/mo>\u03b2<\/mi>)<\/mo><\/mrow>P = \u03b1 \/ (\u03b1 + \u03b2)<\/annotation><\/semantics><\/math><\/div>\n\n\n\n
    After each new transaction outcome arrives, one parameter increments by 1:<\/p>\n\n\n\n
      \n
    • Outcome observed \u2192 \u03b1 = \u03b1 + 1<\/li>\n\n\n\n
    • Outcome not observed \u2192 \u03b2 = \u03b2 + 1<\/li>\n<\/ul>\n\n\n\n
      The estimate recalculates immediately. This means every model is continuously learning , each transaction makes the next routing decision more accurate. Before any real transactions flow, the model is seeded with pseudo-counts derived from acquirer benchmark data and industry benchmarks, giving the system an informed starting point rather than a blank slate.<\/p>\n\n\n\n
      The Bayesian approach is superior to a simple frequency count for one critical reason: it is confidence-aware. A model with \u03b1=9, \u03b2=1 (90% from 10 observations) knows its estimate is uncertain. A model with \u03b1=900, \u03b2=100 (90% from 1000 observations) knows its estimate is reliable. The routing engine can weight high-confidence estimates more heavily than low-confidence ones , particularly important on sparse transaction profiles where little historical data exists.<\/p>\n\n\n\n
      The five models in detail<\/strong><\/p>\n\n\n\n
      1. Approval <\/strong><\/p>\n\n\n\n
      P(approval | BIN, Acquirer, MCC, Amount, Country, Device, 3DS, Velocity)<\/code><\/pre>\n\n\n\n
      The probability that a specific acquirer will approve this specific transaction given its live profile. This is the primary input to the routing matrix , the lookup table that stores historical approval rates per BIN\/MCC\/amount band\/acquirer combination. The routing matrix is not static. Every completed transaction updates the relevant \u03b1 and \u03b2 counts, so the approval rate estimates continuously improve. The same Barclays BIN routes differently at \u00a30\u201350 versus \u00a350\u2013200 because the matrix learns issuer behaviour at that granularity. When a transaction profile has never been seen before, the engine relaxes input variables one at a time , from specific to general , until a matching row is found.<\/p>\n\n\n\n
      2. Fraud <\/strong><\/p>\n\n\n\n
      P(fraud | Device, Velocity, Geo, BIN, Amount, Merchant, Behaviour)<\/code><\/pre>\n\n\n\n
      The probability that this transaction is fraudulent based on observable signals. Fraud labels arrive with a 30\u201390 day lag , confirmed via chargeback reason codes or acquirer fraud flags , meaning the model trains on older data and relies on leading indicator signals observable right now. Velocity anomaly, device fingerprint, and geo mismatch are the strongest real-time fraud signals precisely because they are observable at transaction time without waiting for outcome confirmation. Note: acquirer is deliberately excluded from the fraud model inputs because fraud risk is a property of the transaction, not the routing decision. However, acquirer fraud flag sensitivity varies , different acquirers flag at different thresholds , which creates a label normalisation requirement when updating fraud probability estimates from acquirer-reported data.<\/p>\n\n\n\n
      3. Chargebacks<\/strong><\/p>\n\n\n\n
      P(chargeback | Merchant, PlayerType, Issuer, MCC, Amount, History)<\/code><\/pre>\n\n\n\n
      The probability of a downstream chargeback dispute. Distinct from fraud , chargebacks are initiated by legitimate cardholders disputing charges through regret, friendly fraud, or genuine service failures. Chargeback labels carry the longest lag of all models: 30\u2013120 days. The model compensates with strong leading indicators observable at transaction time: first-time depositor status, credit card type, prior friendly fraud history, and the merchant’s own rolling chargeback ratio. Critically, P(chargeback) is not just a per-transaction cost , it is a MID survival signal. Scheme monitoring programmes trigger at portfolio-level chargeback ratios. The RouteScore weighting w\u2083 can be increased for merchants approaching these thresholds, aggressively penalising high-chargeback profiles even at the cost of approval rate.<\/p>\n\n\n\n
      4. Velocity<\/strong><\/p>\n\n\n\n
      VelocityScore = Transactions_window \/ ExpectedTransactions_window<\/code><\/pre>\n\n\n\n
      A real-time ratio metric , not a Bayesian probability model , that measures how far a cardholder’s current transaction frequency deviates from their expected baseline. A score of 9 (18 actual deposits per hour vs 2 expected) flags high anomaly. VelocityScore serves two roles: as a hard pre-routing gate when it exceeds a defined threshold (ERR_RISK_REJECTED before any acquirer API call), and as an input signal into P(fraud). It is the fastest-responding signal in the system because it requires no outcome label , anomaly is detectable in real time from transaction counts alone.<\/p>\n\n\n\n
      5. Retry Success<\/strong><\/p>\n\n\n\n
      P(retry_success | DeclineCode, Issuer, Acquirer, TimeDelay, 3DS)<\/code><\/pre>\n\n\n\n
      When an acquirer returns a soft decline code, the retry model scores three candidate paths: same acquirer immediately, alternative acquirer immediately, and time-delayed retry. It selects the path with the highest predicted success probability. The model updates immediately after each retry outcome , making it the fastest-updating Bayesian model in the system. Retry scoring is governed by card scheme retry rules that limit how many retry attempts are permitted per transaction within a time window. The model therefore gates retries not just on probability of success but on whether the expected value of the retry attempt , net of fraud and chargeback risk , justifies consuming a retry quota slot.<\/p>\n\n\n\n
      The explore vs exploit tradeoff: building the routing matrix<\/strong><\/p>\n\n\n\n
      The routing matrix can only estimate P(approval) for an acquirer on a given transaction profile if transactions have actually been sent to that acquirer on that profile. This creates a cold-start problem: routing everything to the best known acquirer means never learning whether an alternative acquirer might perform better on specific profiles.<\/p>\n\n\n\n
      The programme addressed this through deliberate traffic splitting using an epsilon-greedy strategy. A defined percentage \u03b5 of transactions are routed to exploration acquirers , not the highest EV choice , specifically to generate observed approval rate data across the full acquirer pool. The remainder exploit the current best known routes.<\/p>\n\n\n\n
      \u03b5<\/mi>(<\/mo>t<\/mi>)<\/mo>=<\/mo>\u03b5<\/mi>0<\/mn><\/msub>\/<\/mi>\u221a<\/mtext>t<\/mi><\/mrow>\u03b5(t) = \u03b5\u2080 \/ \u221at<\/annotation><\/semantics><\/math><\/div>\n\n\n\n
      Exploration rate starts higher early in the programme when the matrix is sparse, and decays automatically as transaction volume grows and estimates become reliable. This is an explicit commercial tradeoff: short-term EV is sacrificed on exploration transactions in exchange for a routing matrix that improves in accuracy over time. The routing matrix was seeded at launch with acquirer benchmark data provided during commercial onboarding , informed priors that gave the system a starting point before live transaction data was available.<\/p>\n\n\n\n
      The RouteScore formula: how all five models combine into one decision<\/strong><\/p>\n\n\n\n
      The EV formula produces a raw expected value per acquirer. But EV alone is not always the right decision criterion. A merchant approaching a Visa chargeback threshold needs the platform to weight chargeback avoidance more heavily than raw margin. A VIP player deposit warrants prioritising approval rate over cost sensitivity. The RouteScore formula applies configurable weights to each dimension:<\/p>\n\n\n\n
      RouteScore = (w\u2081 \u00d7 P_approve) \u2212 (w\u2082 \u00d7 P_fraud) \u2212 (w\u2083 \u00d7 P_cb) \u2212 (w\u2084 \u00d7 AcquirerCost) + (w\u2085 \u00d7 CustomerValue)<\/code><\/pre>\n\n\n\n
      The weights w\u2081\u2013w\u2085 are operator-configured per merchant vertical. They do not change the underlying probability estimates , those are fixed by the Bayesian models. They change how much each dimension contributes to the final routing decision. The acquirer with the highest RouteScore wins, not necessarily the highest EV acquirer. This is the operator’s judgment encoded as numbers , translating commercial priorities into routing behaviour without touching the probability models themselves.<\/p>\n\n\n\n
      How RouteScore and EV relate<\/strong><\/p>\n\n\n\n
      EV and RouteScore answer different questions:<\/p>\n\n\n\n
        \n
      • EV asks: “What is the expected net profit of routing to this acquirer?”<\/li>\n\n\n\n
      • RouteScore asks: “Given our current commercial priorities, which acquirer should we route to?”<\/li>\n<\/ul>\n\n\n\n
        When weights are set neutrally , equal importance to all dimensions , RouteScore approximates EV. When weights are tuned , for example, w\u2083 increased for a merchant near chargeback threshold , RouteScore diverges from EV deliberately. The platform may route to a slightly lower EV acquirer that carries lower chargeback risk, accepting a small margin sacrifice to protect MID health.<\/p>\n\n\n\n
        This is the operator judgment layer that sits above the mathematics. The probability models tell the truth about each acquirer’s historical performance. The RouteScore weights determine which truth matters most on this transaction, for this merchant, right now.<\/p>\n\n\n\n
        Sequencing irreversible dependencies ahead of visible features<\/strong><\/p>\n\n\n\n
        Consumer-facing merchant tooling was explicitly deferred until the routing core was stable. The GatewayRouterService was designed so that per-merchant acquirer assignment lives in the data model, not in application logic, enabling acquirer reassignment and A\/B routing experiments without code deploys. Five specialist acquirers were evaluated and costed alongside the two live integrations.<\/p>\n\n\n\n
        The RouteScore formula is the final decision layer. It sits above all five probability models and the EV formula. Understanding it requires understanding what it is – and what it is not.<\/p>\n\n\n\n
        What RouteScore is not<\/strong><\/p>\n\n\n\n
        RouteScore is not a separate probability model. It does not estimate the likelihood of any outcome. It does not learn from transaction data directly. It is a weighted aggregation formula that combines the outputs of the probability models into a single comparable score per acquirer.<\/p>\n\n\n\n
        What RouteScore is<\/strong><\/p>\n\n\n\n
        RouteScore is the operator’s commercial judgment, expressed mathematically. It takes the raw probability estimates from the Bayesian models and applies weights that reflect current business priorities.<\/p>\n\n\n\n
        RouteScore = (w\u2081 \u00d7 P_approve) \u2212 (w\u2082 \u00d7 P_fraud) \u2212 (w\u2083 \u00d7 P_cb) \u2212 (w\u2084 \u00d7 AcquirerCost) + (w\u2085 \u00d7 CustomerValue)<\/code><\/code><\/pre>\n\n\n\n
        Each term in this formula is either a probability from one of the Bayesian models or a fixed known value:<\/p>\n\n\n\n
        Term<\/th>Source<\/th>Type<\/th><\/tr><\/thead>
        P_approve<\/td>P(approval) model<\/td>Bayesian probability, live<\/td><\/tr>
        P_fraud<\/td>P(fraud) model<\/td>Bayesian probability, lagged<\/td><\/tr>
        P_cb<\/td>P(chargeback) model<\/td>Bayesian probability, most lagged<\/td><\/tr>
        AcquirerCost<\/td>Commercial contract<\/td>Fixed known value<\/td><\/tr>
        CustomerValue<\/td>Player profile data<\/td>Calculated from history<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
        What the weights actually do<\/strong><\/p>\n\n\n\n
        Each weight is a multiplier that amplifies or dampens the contribution of that term to the final score.<\/p>\n\n\n\n
        Consider two scenarios with identical probability estimates but different weights:<\/p>\n\n\n\n
        Scenario A – Normal operations, w\u2081=1.0, w\u2082=1.0, w\u2083=1.0, w\u2084=0.5, w\u2085=0.5<\/strong><\/p>\n\n\n\n
        The platform weights approval, fraud, and chargeback equally. Cost and customer value play a smaller role. The engine selects the acquirer with the best balanced risk-adjusted outcome.<\/p>\n\n\n\n
        Scenario B – Merchant approaching chargeback threshold, w\u2081=0.8, w\u2082=1.0, w\u2083=2.0, w\u2084=0.5, w\u2085=0.5<\/strong><\/p>\n\n\n\n
        The chargeback penalty is doubled. The engine will accept lower approval rates and slightly higher fraud risk in exchange for routing away from high-chargeback profiles. MID survival takes priority over margin.<\/p>\n\n\n\n
        The probability estimates have not changed. The acquirer’s actual performance has not changed. Only the operator’s judgment about what matters most right now has changed – and that judgment is encoded in the weights.<\/p>\n\n\n\n
        How RouteScore relates to EV<\/strong><\/p>\n\n\n\n
        The EV formula is embedded inside RouteScore. You can see it if you set w\u2081 = net margin, w\u2082 = FraudLoss, w\u2083 = ChargebackCost, w\u2084 = 1, w\u2085 = 0:<\/p>\n\n\n\n
        RouteScore \u2192 EV = (P_approve \u00d7 Net margin) \u2212 (P_fraud \u00d7 FraudLoss) \u2212 (P_cb \u00d7 ChargebackCost) \u2212 AcquirerCost<\/code><\/code><\/pre>\n\n\n\n
        Pure EV maximisation is a special case of RouteScore where the weights are set to the financial values of each outcome. RouteScore generalises EV by allowing the operator to adjust those weights based on non-financial priorities \u2014 MID health, VIP treatment, risk appetite \u2014 that pure financial EV does not capture.<\/p>\n\n\n\n
        The complete decision sequence<\/strong><\/p>\n\n\n\n
          \n
        1. Transaction arrives with live profile<\/li>\n\n\n\n
        2. VelocityScore calculated \u2014 if above threshold, block. If below, continue.<\/li>\n\n\n\n
        3. For each candidate acquirer, the three Bayesian models return P_approve, P_fraud, P_cb<\/li>\n\n\n\n
        4. EV calculated per acquirer using those probabilities and known financial values<\/li>\n\n\n\n
        5. RouteScore calculated per acquirer using those same probabilities plus operator weights<\/li>\n\n\n\n
        6. Acquirer with highest RouteScore selected \u2014 not necessarily highest EV, not necessarily highest approval rate<\/li>\n\n\n\n
        7. Transaction dispatched to selected acquirer<\/li>\n\n\n\n
        8. Outcome received \u2014 approved, soft decline, or hard decline<\/li>\n\n\n\n
        9. If soft decline: P(retry_success) model scores three retry paths, selects highest, re-enters routing<\/li>\n\n\n\n
        10. If approved or hard declined: Bayesian models update \u03b1 or \u03b2 for this profile on this acquirer<\/li>\n\n\n\n
        11. Routing matrix updated \u2014 next transaction on this profile benefits from this outcome<\/li>\n<\/ol>\n\n\n\n
          Every step feeds the next. The system improves continuously because step 10 and 11 never stop running.<\/p>\n\n\n\n
          ARCHITECTURE<\/strong><\/h2>\n\n\n\n
          Diagram 1 – Statistical routing matrix<\/strong><\/p>\n\n\n\n
          The routing matrix is the lookup table the scoring engine reads at decision time. It stores historical approval rates for every observed combination of BIN, MCC, amount band, and acquirer – updated after every completed transaction. The engine does not calculate approval probability from first principles on each request. It reads the nearest matching row from this table, feeds that approval rate into the EV formula alongside fraud and chargeback probabilities, and selects the highest-EV route. The table below shows a representative slice.<\/p>\n\n\n\n
          BIN<\/strong><\/td>MCC<\/strong><\/td>Amount band<\/strong><\/td>Acquirer<\/strong><\/td>Historical approval rate<\/strong><\/td><\/tr>
          Barclays UK debit<\/td>Gambling 7995<\/td>\u00a30\u201350<\/td>Acquirer 1<\/td>92%<\/td><\/tr>
          Barclays UK debit<\/td>Gambling 7995<\/td>\u00a30\u201350<\/td>Acquirer 2<\/td>81%<\/td><\/tr>
          Barclays UK debit<\/td>Gambling 7995<\/td>\u00a350\u2013200<\/td>Acquirer 1<\/td>84%<\/td><\/tr>
          Barclays UK debit<\/td>Gambling 7995<\/td>\u00a350\u2013200<\/td>Acquirer 2<\/td>67%<\/td><\/tr>
          Monzo debit<\/td>Sports betting 7995<\/td>\u00a30\u2013100<\/td>Acquirer 2<\/td>89%<\/td><\/tr>
          Monzo debit<\/td>Sports betting 7995<\/td>\u00a30\u2013100<\/td>Acquirer 1<\/td>82%<\/td><\/tr>
          Revolut virtual<\/td>Gambling 7995<\/td>\u00a30\u201350<\/td>Acquirer 2<\/td>92%<\/td><\/tr>
          Revolut virtual<\/td>Gambling 7995<\/td>\u00a30\u201350<\/td>Acquirer 1<\/td>77%<\/td><\/tr><\/tbody><\/table><\/figure>\n\n\n\n
          The table makes visible what static routing cannot see: the best acquirer for a Barclays debit card is not the best acquirer for a Revolut virtual card. Without this matrix, every transaction takes the same route regardless of these differentials. With it, each transaction is routed to the acquirer statistically most likely to approve it – and every outcome updates the table, so the next similar transaction is routed from better data.<\/p>\n\n\n\n
          Diagram 2 – Transaction processing pipeline<\/strong><\/p>\n\n\n\n
          This diagram shows how a transaction flows from merchant API call through the pre-risk engine, deduplication, route scoring, acquirer dispatch, and soft decline recovery. The pre-risk engine and deduplication run before routing – not after – because a transaction blocked post-routing contaminates the routing matrix with a data point reflecting operational failure rather than genuine issuer behaviour, distorting future approval rate estimates for that BIN\/acquirer combination.<\/p>\n\n\n\n\n\n
          \n\n  
          \n    
          <\/span>EVX DYNAMIC ROUTING ENGINE \u2014 TRANSACTION FLOW<\/div>\n    
          EVX TECHNOLOGIES LTD \u00b7 AUTHORISATION & ROUTING ARCHITECTURE \u00b7 v2.4<\/div>\n  <\/div>\n\n  \n\n  \n    \n      \n        \n      <\/marker>\n      \n        \n      <\/marker>\n      \n        \n      <\/marker>\n      \n        \n      <\/marker>\n      \n        \n      <\/marker>\n    <\/defs>\n\n    \n\n    \n    \n    \u25b6 PHASE 1 \u2014 INGEST \u00b7 VALIDATION \u00b7 PRE-RISK<\/text>\n\n    \n    \n    \u25b6 PHASE 2 \u2014 GATEWAY ROUTING \u00b7 ACQUIRER SELECTION \u00b7 ROUTE SCORING ENGINE<\/text>\n\n    \n    \n    \u25b6 PHASE 3 \u2014 ACQUIRER DISPATCH \u00b7 ISSUER RESPONSE \u00b7 OUTCOME ROUTING<\/text>\n\n    \n    INGEST<\/text>\n    VALIDATE<\/text>\n    PRE-RISK<\/text>\n    DEDUP<\/text>\n    ROUTER<\/text>\n\n    \n\n    \n    \n    \n    \n    \n    \n    \n    \n    \n    \n    \n    \n    \n    \n    \n    \n\n    \n    \n    \n    \n    \n    \n    \n    \n    \n\n    \n    \n    \n    \n    \n    \n    \n    \n    \n    \n    \n    \n\n    \n    \n\n    \n    \n    \n\n    \n    \n\n    \n    \n\n    \n    \n\n    \n    \n\n    \n    \n\n    \n    \n\n    \n\n    \n    \n    \n    \n    \n    \n    \n    \n    \n    \n\n    \n\n    BLOCK<\/text>\n    PASS<\/text>\n    DUPLICATE<\/text>\n    PASS<\/text>\n    3DS<\/text>\n    SUCCESS<\/text>\n    SOFT DECLINE<\/text>\n    HARD DECLINE<\/text>\n    ALT ACQUIRER \u00b7 62% retry rate<\/text>\n    \u27f2 feedsback<\/text>\n\n    \n\n    \n    \n    \n\n    \n    \n    \n\n    \n    \n\n    \n    \n    \n\n    \n    \n\n    \n    \n    \n\n    \n    \n    \n\n    \n    \n    \n\n    \n    \n\n    \n    \n    \n\n    \n    \n    \n\n    \n    \n    \n\n    \n    \n\n    \n    \n    \n\n    \n    \n    \n\n    \n    \n    \n\n    \n    \n    \n\n    \n    \n    \n\n    \n    \n    \n    \n    \n    \n\n    \n\n    \n    MERCHANT API<\/text>\n    REQUEST<\/text>\n\n    \n    VALIDATE<\/text>\n    amount \u00b7 currency<\/text>\n    card \u00b7 MCC<\/text>\n\n    \n    PRE-RISK<\/text>\n    VelocityScore<\/text>\n    MCC arbitrage<\/text>\n\n    \n    ERR_RISK<\/text>\n    _REJECTED<\/text>\n\n    \n    DEDUP<\/text>\n    cache check<\/text>\n\n    \n    ERR_DO_NOT<\/text>\n    _RETRY<\/text>\n\n    \n    GATEWAY ROUTER<\/text>\n    forMerchant()<\/text>\n    AcquirerCredential env-scoped<\/text>\n\n    \n    ROUTE SCORING<\/text>\n    EV formula \u00b7 RouteScore<\/text>\n    statistical routing matrix<\/text>\n\n    \n    ACQUIRER<\/text>\n    ADAPTER<\/text>\n\n    \n    RAPYD<\/text>\n    VALITOR<\/text>\n\n    \n    XPATE<\/text>\n\n    \n    QASHPAY<\/text>\n\n    \n    ISSUER<\/text>\n    RESPONSE<\/text>\n\n    \n    RETURN<\/text>\n    redirect_url \u2192 merchant<\/text>\n\n    \n    P(retry_success)<\/text>\n    DeclineCode \u00b7 Issuer \u00b7 Acquirer \u00b7 TimeDelay \u00b7 3DS<\/text>\n    probabilistic retry model<\/text>\n\n    \n    ERR_DO_NOT<\/text>\n    _RETRY<\/text>\n\n    \n    STORE TOKEN<\/text>\n    gatewayCardToken<\/text>\n    PaymentInstrument record<\/text>\n\n    \n    WRITE TX<\/text>\n    acquirer_trans_id \u00b7 auth_code<\/text>\n    status \u00b7 timestamp<\/text>\n\n    \n    UPDATE ROUTING<\/text>\n    statistical matrix<\/text>\n\n    \n\n  <\/svg>\n\n  
          \n    FLOWCHART \u00b7 EVX DYNAMIC ROUTING ENGINE \u00b7 TRANSACTION AUTHORISATION LIFECYCLE<\/span>\n    ORANGE = PRIMARY FLOW  |  DASHED AMBER = RETRY\/FEEDBACK  |  RED = ERROR TERMINUS  |  GREEN = SUCCESS  |  \u27f2 = FEEDBACK LOOP<\/span>\n  <\/div>\n\n<\/div>\n\n