Routing between your own payment accounts

You do not need a second shop to use GatewayChanger. A single shop with several payment accounts can let its rules decide which of its own accounts charges each order — a payment orchestrator for one shop, with the same rules, failover, limits and ledger you get when several shops work together. And you can mix both: some orders on your own accounts, others on a partner shop.

When it helps

• High-risk and low-risk goods in one shop. Top-ups, CBD or adult content go to your high-risk acquirer; T-shirts and caps go to your Stripe. Each account only ever sees the goods it approved.
• A backup account. When the main account fails or is switched off, the next one takes the payment.
• Cost and acceptance. Large amounts to the account with the better rate, cards from one country to the local acquirer, one currency to the account that settles in it.
• Limits. "At most €20,000 a day on this account, the rest on the other."

Set it up

1. Connect the shop and install the plugin, as in Getting started.
2. On the shop's Checkout page, under What this shop does, tick Customers buy here and This shop takes payments with its own payment accounts, and keep Only for its own orders selected. No card-scheme declaration is needed: nobody else's payments go through your accounts, and GatewayChanger never sends another shop's order to them.
3. Add each payment account under the shop's Payment accounts — for example Stripe, emerchantpay and Paysafe.
4. Label your articles under Shops → Products (for example top-up), then write the rules under Routing → New rule. The template Between a shop's own payment accounts asks for the label, the account and a backup account, and fills in the rest.

An example: a casino with a merchandise shop

The full story is on Use cases.

Writing high-risk rules safely

• Put the high-risk rule first, list only the accounts approved for those goods, and set If no account can take it to refuse the order. A top-up then can never fall through to a later rule whose account was not approved for it.
• Give the low-risk rule the condition nothing labelled top-up, so it can only ever match baskets without one.
• Use Try an order on the routing page to see which rule and account a basket would get before you switch a rule on.

Failover

If an account fails for a technical reason during the checkout, the plugin asks again and GatewayChanger answers with the next account of the same shop that the rule lists — not with a different shop. An account that keeps failing is switched off by the safety switch until you turn it back on (Needs you shows it, with the button).

What your customer sees

• The card form of the account that won — nothing else changes in your checkout.
• No extra checkbox. The "processed by … on behalf of …" sentence only appears when another business takes the payment. (Plugin versions before 1.8.0 show a plain "I agree to pay … to …" checkbox instead.)
• One order. The payment is booked on the order the customer placed; the plugin creates no second bookkeeping order in your shop (1.8.0 and newer).
• Your name on the receipt and on the bank statement, as with any payment you take yourself.

What stays your responsibility

GatewayChanger decides which of your accounts charges an order; it never changes what an account is told. Each account must be approved for the goods you send it, and a low-risk provider must know who runs the shop it serves. Using routing to pass goods through an account that did not approve them breaks the card-scheme rules. Licences — a gambling licence, for example — stay with you.

For developers

• Shops: own_orders_only: true together with roles: ["seller","charger"] (POST/PATCH /api/v1/shops).
• Rules: the candidate's shop is the selling shop itself; every condition, strategy, cap and on_no_candidate works as usual. Another shop's order skips such a shop with the trace reason own_orders_only.
• /route: consent.required is false when the shop charges its own order. exclude_candidates: [{shop, processor}] skips one account; a shop that excludes itself after charging the checkout itself is narrowed to the accounts it already tried. See the API reference.