Skip to main content
Payment Routing is under Settings, then Payment Options, then Payment Routing. It puts the card methods you have connected behind one Credit/Debit Card row at checkout. Each checkout is given one of them by your rules, and when a card is turned down the buyer is moved on to the next. A card method is one whose row reads “Credit/Debit Card” and its provider’s name, such as Stripe, NMI, Tagada or Square. PayPal, crypto, skins and vouchers stay rows of their own.

Setting it up

You need at least two card methods connected in Payment Methods. Set Up Routing lists them, all ticked: untick any you want left out, then press Turn On Routing. They start with an even share each. From then on the checkout shows one Credit/Debit Card row where the first of them stood. The buyer picks it and presses Pay, and only then is it decided which processor takes the payment. The checkout shows the card glyph and never names the processor behind it, unless the processor’s own page is where the buyer pays: then the button says where it goes. The switch in the Payment Routing Is On card, at the top of the part, switches it off and on. Off, each card method is its own row at checkout again, as before.

How the next checkout is shared

Split says how a processor is picked for each checkout: Press a processor’s row, or Edit Limits in its menu, to set its limits: Amounts are in your store’s currency. A month and a day are counted in UTC, and a cap counts every paid order through that method, routed or not, since it is your limit with that processor. A processor that has reached a cap, or does not take this order’s amount, is skipped for this checkout. The table shows each processor’s share, what it took this month against its cap, how many of its routed card payments were approved, its disputes over the last 30 days, and its fee from Finance, Not Set where you have none.

Rules

Rules are read first to last, before the split. Each says when it applies and what happens then: Every Never that fits leaves its processor out. The first Only that fits picks its processor, if it can take the order. A store has up to 50 rules. Sort sets the order they are read in.

When a card is declined

A card cannot be handed from one processor to another, so the buyer types it again. Where the card is typed on the checkout itself (Stripe, Authorize.net, NMI, Tagada) the next processor’s form shows at once. Where the buyer pays on the processor’s own page, its page lets them try again there, and the checkout’s waiting panel has Try Another Way, which moves the order to the next processor. Each move is in the order’s timeline, with which processor turned the card down.

Health Guard

A pause or a disputes alert is emailed to your alerts address under Notifications (or your account’s address when there is none) and posted to your store’s Discord where errors go. A paused processor says why on its row, and Put Back in Rotation in its menu returns it. The last processor left is never paused. A disputes alert is sent once a week at most for a processor, and not before it has taken 10 paid orders. Routing never moves payments away from a processor because of its disputes: the figure is there for you to watch, as the card networks watch it.

Fees

A product’s Payments tab has one Credit/Debit Card line under Fees while routing is on. That fee is added whichever processor takes the payment, so a buyer moved on after a decline pays the same total. The processors’ own fees are kept, and charged again if you switch routing off.

The figures

Taking one out

Take Out of Routing in a processor’s menu takes it out, with its rules. Add Processor puts another card method in, and the shares are made even again. Disconnecting a payment method takes it out too, and when the last one is gone routing switches off.

Your server

Three webhook events come from Payment Routing: routing.processor_paused when Health Guard pauses a processor, routing.processor_resumed when one is put back, and order.rerouted when an order is moved to the next processor. With an API key, your server can do everything this part does: read it, switch it on and off, change how checkouts are shared, add, change, sort and take out processors and rules, and put a paused processor back. Reading needs Read Payment Routing and the rest Change Payment Routing. See Payment Routing in the API reference.