Transaction routing

Transaction routing is part of Spreedly's Optimize product line and gives merchants complete control over how their payments are processed. Instead of being locked into a single payment gateway, merchants can dynamically route transactions to different gateways based on flexible business rules and real-time transaction data. This helps send every payment through the best-fit PSP to increase success rates, reduce costs, and improve the customer experience.

Routing is built in Composer, Spreedly's visual, no-code canvas for the payment journey. Routing logic lives in a transaction processing checkpoint, alongside any fraud, identity, or 3DS steps you want in the same flow.

Types of routing

Single (static) gateway routing

The most straightforward approach: all transactions go to one payment gateway. In Composer, add a transaction step (Authorization, Purchase, Verify, or General Credit) to your checkpoint and set its Gateway Token to the gateway you want to use. See Building a transaction processing checkpoint.

Best for:

• Businesses just starting out with a single gateway relationship.
• Merchants who have negotiated favorable rates with one provider and want to consolidate their volume.

Even with a single gateway, you can switch or add gateways later by updating the Gateway Token in Checkpoint Studio and republishing – no code changes required.

Split volume routing (A/B testing)

Why rely on a single payment provider? An A/B Test step splits traffic across gateways by percentage – for example, 70% of transactions to Gateway A and 30% to Gateway B. You can also scope the test with a condition, such as limiting it to a single country. See A/B testing a rule in the Decision editor guide.

Key benefits include:

• Performance comparison: Compare gateway performance, approval rates, and costs head to head.
• Relationship management: Maintain active relationships with multiple providers to keep pricing competitive.

Conditional routing

This is where optimization really comes to life. A Decision step lets you branch a checkpoint on transaction, customer, and card data, then point each path at a different gateway. Paths are evaluated top to bottom, the first match wins, and anything that doesn't match falls through to the Default path. See the Decision editor guide.

For example, you can create paths to:

• Route all transactions in Euros (€) to a designated European gateway to minimize cross-border fees.
• Send all American Express transactions to the gateway with the lowest processing rate for that card brand.
• Direct payments from a specific issuing country to a local gateway that has higher approval rates for that region.

Routing on card attributes such as card brand, card type, or issuing country uses BIN metadata. Add a Get Payment Method Info step before your Decision step to bring that data onto the canvas. BIN metadata requires Advanced Vault at the organization level. See Routing on BIN metadata & normalized fields.

Automatic failover with Recover

Routing decides where a transaction goes first. Recover decides what happens if it fails. Enable Recover on an Authorization or Purchase step to automatically retry soft declines or gateway outages on up to two failover gateways. See Add automatic failover with Recover.

Getting started with Composer

Every routing strategy above is built visually in Checkpoint Studio – from a simple static route to multi-path conditional logic with A/B tests and failover. Changes take effect as soon as you publish, without a code deploy.

• New to Composer? Start with the Composer overview and Quick start.
• Building your first routing flow? Follow Building a transaction processing checkpoint.
• Platform or merchant aggregator? See Composer for platforms and merchant aggregators.
• Using Composer (legacy) workflows today? See Migrating from Composer (legacy). Existing workflow documentation remains available in the Composer (legacy) routing rules guide.