Developing a Scalable Card-Linked Cashback Platform for Creators and Brands

  • Country: UK
  • Industry: Finance, Payments & Fintech
  • Team Size: 5

Highlights

  • New Acquirers by Configuration: A new acquiring bank on an already connected gateway is added to the platform through dynamic configuration that sets up its merchant accounts, the payment types they accept and the bank’s share of volume. Routing picks up the new acquirer straight away, so no code change or release is needed.
  • Rules-Driven Smart Routing: Each merchant has its own decision tree, which selects eligible accounts by card brand, issuing country, currency, amount and channel. From there, the engine balances volume across the accounts that qualify.
  • Risk Screening Before Routing: Five chained rule types screen every payment before it is routed, covering uniqueness, duplication, allow lists, block lists and velocity. That way, a bad payment is stopped before it costs an authorization fee.
  • Automatic Cascade on Decline: If a decline is retryable, the platform resubmits the payment once to the next-ranked acquirer or gateway in the background, within the same payment request. The customer never has to re-enter card details or try again, and the merchant only receives the final result.

Client

Axcess Payment Services is a UK payment service provider that works with card-not-present merchants, including those in higher-risk verticals where chargeback and fraud exposure is greater. Many of these merchants sell across borders, so they take payments in many currencies and often hold accounts with more than one acquiring bank.

To support them, Axcess offers utlx, which it positions as an intelligent payments infrastructure. The platform brings smarter payments, complete visibility and total control into one place, backed by more than 300 banking connections and over 30 alternative payment methods.

For merchants with accounts at several acquiring banks, the choice of which bank processes a payment is just as important as getting the payment approved. Sending a transaction to the wrong acquirer can lower the approval rate, cause a merchant to miss a volume commitment or let through a fraud loss that should have been caught before authorization.

Axcess
Country
Industry
Team Size:

Product

utlx sits between the merchant and its payment gateways. When a payment comes in from any channel, the platform enriches it with card and location data, screens it, routes it and records the outcome for reporting and reconciliation.

Merchants can reach utlx through a server-to-server API, a hosted payment page, an embeddable payment widget, a virtual terminal, pay-by-link or scheduled and recurring billing. All of these channels connect to one payments core that handles routing, risk screening, card data enrichment and 3-D Secure. Beyond sales, the same core also processes pre-authorizations, captures, refunds and credit payouts.

Diagram showcasing the nine core payment platform modules of utlx, including Payments API, Routing engine, Risk engine, and Merchant portal.
Platform Modules

Goals and objectives

  1. Smart Routing: Route each payment to the best-fit merchant account using configurable, per-merchant rules.
  2. Dynamic Acquirer Onboarding: Add new acquiring banks through configuration, without a release.
  3. Volume Balancing: Keep acquirer and gateway volume close to agreed percentage splits.
  4. Fraud Prevention: Block fraudulent, duplicate and high-velocity payments before authorization.
  5. Decline Recovery: Recover declined payments by cascading to an alternative acquirer.
  6. Targeted Strong Customer Authentication: Apply SCA where regulation requires it, and skip it where it only adds friction.
  7. PCI Scope Reduction: Keep merchants out of PCI scope with a widget that renders the hosted payment page in an iframe, so card details are entered only in the hosted page and never reach the merchant’s systems.
  8. Recurring Payments: Support recurring and merchant-initiated payments with network tokens.
  9. Automated Reconciliation: Reconcile acquirer settlement files automatically against the transaction ledger.
  10. Merchant Self-Service: Give merchants a portal for transactions, risk rules, webhooks and payment links.
  11. Pluggable Gateways: Connect new gateways without touching the payment core.

Challenges

  1. Card Fit and Volume Commitments Compete: The account best suited to a particular card is often a different account from the one that is behind on its agreed volume share. The router has to balance both at once while still letting a merchant name a preferred account.
  2. Tight Controls Without False Blocks: Merchants need tight velocity and block-list controls, although rules that are too broad end up blocking good customers. To keep that balance, each rule has to be scoped per division, merchant and channel and support explicit allow lists.
  3. Card Attributes Everywhere, Card Numbers Nowhere: Routing and risk screening both depend on card data, and card numbers must stay protected at every step. So the platform had to make decisions with card details and keep the numbers themselves hidden throughout.

Solution

We built a payment pipeline in which every step runs as its own engine. Each payment passes through the same sequence of stages, and because every stage follows its own rules, routing, risk and gateway connections can change independently of one another.

Flowchart detailing the six-step Axcess payment pipeline: Accept, Enrich, Screen, Decide, Balance, and Authorize, along with decline recovery handling.
Payment Pipeline

Smart routing

Each merchant has its own routing rules, which the platform applies to every payment. So when a merchant needs to change where its traffic goes, the operations team updates the configuration and the change takes effect without a software release.

  • Routing inputs: Sales channel (eCommerce or MOTO), transaction type, amount, currency, card brand, card type, card level and issuing country.
  • Account eligibility: Each merchant account lists what it can accept, such as currencies, card brands, wallets (Apple Pay, Google Pay) and 3-D Secure. Accounts that can’t process the payment are skipped.
  • Dynamic acquirer setup: New acquiring banks on a connected gateway, and their merchant accounts, are added and enabled through configuration, and join routing and balancing immediately.
  • Sticky follow-ups: Captures and refunds always go back to the account and gateway that authorized the original payment.
  • Consistent responses: Merchants get the same response format whichever acquirer processed the payment.
Diagram illustrating the candidate ranking order for selecting acquirers and gateways: preferred account first, followed by acquirer deficit, then gateway deficit.
Candidate Ranking Order

Volume balancing

Merchants with several acquiring banks usually commit a share of their volume to each one. To track those commitments, utlx counts each merchant’s monthly transactions per acquirer along with each gateway’s platform-wide share, then scores every candidate account as target % − actual %.

The account furthest below its target is ranked first. Shares update after every payment, so the split corrects itself throughout the month and nobody has to rebalance it by hand.

Balancing works at two levels, with acquirer splits set per merchant and gateway splits set across the platform. Within that setup, recurring payments can be pinned to one acquirer so that card-on-file relationships stay with the bank that holds them.

Chart showing how deficit scores rank acquiring banks by comparing actual monthly volume share against agreed target percentages to balance traffic.
Deficit Score

Risk screening

The risk engine evaluates rules in a fixed order before any authorization is sent. An allow-list match skips the remaining checks, so trusted customers are not caught by broad rules. A block stops the payment before routing, and each rule type returns its own decline reason.

  • Match on the signals fraud leaves: Card, card range, card brand and type, issuing country, cardholder, customer IP, email address and email domain.
  • Velocity limits: Caps on the number and total value of transactions over a set number of days. One limit covers every currency.
  • Scoped rules: Rules can be set for a whole division, a single merchant or one sales channel.
  • Duplicate guard: Repeated submissions of the same merchant transaction are rejected.
  • Targeted 3-D Secure: Strong Customer Authentication is applied where regulation requires it and skipped where it doesn’t, such as recurring payments and wallet payments.
Diagram illustrating the five-step risk rule evaluation sequence — Uniqueness, Duplication, Allow list, Block list, Velocity — and key decision data sources.
Rule Evaluation Order

Services around the payments core

  • Payment widget and SDK: Renders the hosted payment page in an iframe on the merchant’s site, so card details never reach the merchant’s systems and the merchant stays out of PCI scope. Theming, saved cards and five languages.
  • Merchant portal: Transactions, analytics dashboards, risk rules with a visual flow editor, virtual terminal, payment links with QR codes, webhooks and audit log. Six languages, including right-to-left Arabic.
  • Reconciliation: Collects acquirer settlement files and matches them against the transaction ledger automatically.
  • Recurring and tokens: Scheduled payments with retries, merchant-initiated transactions, network tokens for Visa, Mastercard and Amex, and automatic card updates.
  • Token migration: Securely imports a merchant’s saved cards from a previous provider, so merchants can switch without customers re-entering cards.
  • Transaction webhooks: Transaction events are delivered to merchant systems, so order status stays in step with each authorization, capture and refund.

Built for PCI DSS v4.0.1 from the first line of code

Every component of the platform is classified as in scope, connected to scope or out of scope for PCI. Changes to in-scope components then go through a dedicated PCI audit alongside human code review.

Beyond that review process, card data is never exposed in logs, and encryption keys rotate on a schedule. Administrative actions are also recorded in an audit trail, while record-level tenancy restricts access to data so that each merchant sees only its own records.

Tech Stack
  • Kotlin Tech StackKotlin
  • Python Tech StackPython
  • TypeScript Tech StackTypeScript
  • AWS services Tech StackAWS services

Our results

utlx gives Axcess one platform that routes, screens and balances every card payment. Its operations team can also adjust all three directly, so changes take effect without waiting for a software release.

  • New Acquirers Without Releases: Acquiring banks on connected gateways are added through dynamic configuration, while per-merchant rules decide where their traffic goes. That means bringing on a new acquirer or moving volume to it needs no software release.
  • Volume Commitments Held Automatically: Throughout the month, acquirer and gateway shares track their targets on their own, so nobody has to rebalance them manually.
  • Declines Recovered in the Background: When a decline is retryable, it cascades to a second acquirer within the same payment request, and neither the customer nor the merchant has to take any action.
  • Risk Rules Scoped Precisely: Merchants can scope velocity, block-list and allow-list rules as narrowly as a single sales channel.
  • New Gateways Plug In: Because every gateway connects in the same standard way, adding a new one leaves routing and risk screening untouched.
Download this page as PDF share with your network