> ## Documentation Index > Fetch the complete documentation index at: https://docs.shoply.gg/llms.txt > Use this file to discover all available pages before exploring further. # Payment Routing > Put several card processors behind one card row at checkout, share payments between them by your rules, and move a declined card on to the next 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](/guides/payment-methods.md). **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: | | | | - | - | | **By Share** | Each processor has a share of the month's routed card payments. The next checkout goes to the one furthest under its share. | | **In Order** | The first processor in the list that can take the order, until it reaches its cap, then the next. **Sort** sets the order. | | **Cheapest First** | The processor whose fee for this order is lowest, from the rates you set in [Finance](/guides/finance.md), under **Reports**, **Payment Fees**. A processor with no rate there is passed over, and with no rate for any, the first in the list is used. | Press a processor's row, or **Edit Limits** in its menu, to set its limits: | | | | - | - | | **Share** | Its part of the month's routed card payments, with **By Share**. | | **Monthly Cap** | The most it takes in a calendar month. Empty for none. | | **Daily Cap** | The most it takes in a day. Empty for none. | | **Smallest Order** | Orders under this go elsewhere. Empty for no limit. | | **Largest Order** | Orders over this go elsewhere. Empty for no limit. | 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: | | | | - | - | | **When** | **Buyer's Country**, one of the countries you list (up to 100), or **Order Amount** over or under a figure. | | **Then** | **Only**: this processor takes it. **Never**: this processor is left out. | 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 | | | | - | - | | **Try the Next Processor** | After a decline the order moves on to the next processor, and the buyer sees "Please try again" and types their card once more. One try on each processor, and never after a card the bank reported stolen, lost or fake: that is said as a decline. | | **Keep Returning Buyers Where They Paid** | A buyer who paid you before goes back to the processor that took their last payment, while it can take this one. | 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 | | | | - | - | | **Pause a Processor That Fails** | A processor whose keys stop working, or with too many of its last routed payments declined (8 of the last 20 unless you change it, over 5 to 200), is paused, and checkouts go to the others. | | **Tell Me When Disputes Pass** | When a processor's disputes over the orders it took in the last 30 days pass this percent, you are told. 0.75 unless you change it; empty for never. | 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 | | | | - | - | | **Routed This Month** | Paid orders through the card row this month, and how much. | | **Approved** | Of every routed card payment that was decided this month, the share approved. | | **Saved by a Retry** | Orders paid on a processor after another had turned the card down. | | **Disputes** | Routed orders of the last 30 days that were disputed. | ## 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](/guides/webhooks.md) 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](/guides/api-keys.md), 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](/api-reference/payment-routing/get-payment-routing.md) in the API reference. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.