Routing payments across multiple processors without breaking checkout

Sooner or later, a growing store wants more control over how money moves. The reasons are always good ones: shaving processing fees by sending volume to whichever acquirer is cheapest, adding redundancy so a single processor outage doesn't take down sales, using a local acquirer in a region where it lifts approval rates, or steering high-risk orders through a gateway with better fraud tooling. All legitimate. All things a bank or a custom storefront would handle without blinking.

Then they discover the hard truth: Shopify's checkout is not yours to rewire. And the first thing I do on these projects is make sure everyone understands exactly where the line sits before a single line of code is written.

The constraint nobody tells you about up front

Shopify's checkout is a hosted, native surface. It's fast, it's PCI-compliant out of the box, and it converts well precisely because Shopify controls it end to end — including Shop Pay, which is one of the highest-converting checkout flows on the internet. The price of all that is control. You don't get to drop arbitrary payment-routing logic into the page and fan out to whatever processors you like.

It used to be that people tried to bend checkout with checkout.liquid and Additional Scripts. That door is now closed. checkout.liquid is fully deprecated — Plus stores lost it in 2025, and non-Plus stores are auto-upgraded off it by August 26, 2026. The supported surface today is Checkout Extensibility: UI Extensions for what the customer sees, Shopify Functions for backend logic, and Web Pixels for tracking. On top of that, the old Scripts engine is being retired — Shopify Functions replace it, with a hard cutoff of June 30, 2026. If your "payment routing" plan involves legacy scripts, it has an expiry date attached.

You can influence Shopify's checkout. You cannot replace its payment engine from inside it.

Hold that sentence in your head, because it's the dividing line between the three patterns below.

Pattern 1 — Steer methods inside checkout (Plus, Functions)

This is the lightest option and, for a lot of merchants, the one they actually needed. Shopify Plus exposes payment customization Functions that let you hide, reorder, or rename payment methods based on the cart, the customer, or their region. Functions run in a WebAssembly sandbox, you write them in JavaScript or Rust, and you deploy them as an app.

What this gets you: a customer in one market sees a local method first; high-value carts hide a method you don't want them using; B2B customers see terms-based options. The shape of the logic looks like this:

// payment-customization Function (run target), simplified
export function run(input) {
  const operations = [];
  const country = input.cart.deliveryGroups[0]?.deliveryAddress?.countryCode;

  // Push a local method to the top for one region
  if (country === "DE") {
    const sepa = input.paymentMethods.find(m => m.name.includes("SEPA"));
    if (sepa) operations.push({ move: { paymentMethodId: sepa.id, index: 0 } });
  }
  return { operations };
}

What this does not get you: actual routing to external acquirers. You're steering between the providers Shopify already knows about, not introducing your own. For "show the right methods to the right people," this is the correct, supported, upgrade-safe answer. Reach for it first.

Pattern 2 — Multiple gateways through approved providers

The next step up is running more than one payment provider that Shopify supports, and letting an orchestration layer handle the routing on the provider's side rather than yours. Several gateways and payment orchestrators present themselves to Shopify as a single approved provider, then make the cheapest-acquirer or failover decisions behind their own walls.

This keeps you inside Shopify's compliance umbrella — the customer still pays through the native checkout, you don't touch raw card data, and Shop Pay and the standard flow stay intact. The routing intelligence lives with the orchestrator. The tradeoff is that you're constrained to what that provider supports and what Shopify permits, and the most flexible payment configurations sit behind Shopify's invite-only programs. For most merchants who think they want "multi-processor routing," this is the pattern that gets them 90% of the benefit without leaving the platform.

Pattern 3 — Custom checkout outside Shopify

This is the heavy path, and it's the one I built for a store doing eight figures a year when the requirement genuinely couldn't be met any other way. Here you take the payment step out of Shopify's checkout entirely: a custom, often headless, product and cart experience where you collect payment, you route across processors with whatever logic you want, and you create the order in Shopify afterward through the Admin API (typically via draft orders) once payment clears.

The power is total. You own the routing — cheapest-acquirer, region-based, failover, fraud-tiered, whatever the business needs. The cost is equally total, and it's mostly invisible until you're deep in it:

• PCI scope becomes yours. The moment card data touches your surface, your compliance burden jumps from Shopify's SAQ A toward something far heavier. Tokenize early, never let raw PAN hit your servers, and budget for the audit reality.
• You lose Shop Pay and the native conversion lift. That's a real revenue line, not a footnote. The fee savings have to clear that bar before this makes sense.
• Reconciliation is the hard part, not payments. Orders created out-of-band have to match what each processor actually captured. You need idempotency keys so a retried request never double-charges, webhooks from every processor to confirm capture, and refund/void parity so a refund in Shopify actually reverses the right charge on the right acquirer.
• You own the edge cases forever. Partial captures, currency mismatches, a processor timing out mid-capture, a customer closing the tab between charge and order creation. Each one is a support ticket and a potential chargeback if you get it wrong.

Done right, it's a genuine competitive advantage. Done casually, it's a way to lose money in four directions at once. The engineering isn't the scary part — the operational correctness is.

So which one do you actually need?

Start at the top and only move down when forced:

• "Show the right methods to the right customers" → Pattern 1, payment customization Functions on Plus.
• "Lower fees / add a fallback processor" → Pattern 2, an orchestrator behind an approved provider.
• "We need routing logic Shopify will never allow inside checkout, and the math clearly justifies it" → Pattern 3, custom checkout with order creation via the Admin API.

The mistake I see most often is reaching for Pattern 3 to solve a Pattern 2 problem — taking on PCI scope, losing Shop Pay, and rebuilding reconciliation to save a fee that an orchestrator would have saved anyway. The interesting engineering is fun. Make sure the business actually needs it before you sign up to maintain it.