Stop offering a payment method
Takes a payment method off the checkout for one legal entity by running its route down. A run-down route stops being offered for a new payment and stops contributing its amount limits and wallet support to the checkout, but it keeps serving what already depends on it: payment methods already saved against that gateway, and contracts that collect through it, still resolve to the same gateway. Archiving the route (INACTIVE) is the harder stop: the route is excluded from every lookup, so saved payment methods on that gateway stop being offered too. Merchant Setup never archives an individual method, but archiving is what happens to every route when a gateway is disconnected.
Where you can do this
- Merchant Setup: Your integrations (Customise checkout)
- Merchant Setup: Managing a connection (Customise checkout (single-provider mode))
- Merchant Setup: Your integrations (Save)
- Automatically (Shuttle): BrightPearl gateway save route reconcile — a merchant saves a connected gateway in BrightPearl with a payment method removed: the route dedicated to that method is run down
Before you start
- The route exists.
- RUNDOWN changes something only if the route is not already run down; a repeat is accepted and does nothing.
- INACTIVE needs no prior status: a live route can be archived directly, and an archived route can be set back to RUNDOWN.
Rules
Checked by the API means Shuttle refuses the request however it is sent; a screen name means only that screen refuses it, and a direct API call would be accepted.
| Rule | Checked by | What you see |
|---|---|---|
The body must wrap the fields in a legal_entity_route object | The API | VALIDATION_ERROR "API body error: missing legal_entity_route object" |
| The route must exist | The API | 404 "legal_entity_route not found"; Shuttle's own check answers apiValidation.error.not.found "legal_entity_curr |
Only RUNDOWN and INACTIVE are acted on; any other status is ignored and the call falls through to a plain route edit, so the status stays as it was | The API | route saved with its status unchanged |
| Archiving uses the literal INACTIVE. ARCHIVE, the value that archives a gateway, is not a route status and falls through to a plain edit | The API | route saved with its status unchanged |
The route version v is accepted and never checked on either status path: Shuttle's status request carries no version field and its archive call receives no body, so nothing detects that the route changed between the caller reading it and the status being set | The API | status change accepted, concurrent edit not detected |
| There is no transition check in either direction: an archived route can be set straight back to RUNDOWN, which makes it serve saved payment methods and contracts again | The API | route reopened with no warning |
| Setting RUNDOWN on a route already run down writes nothing and announces nothing | The API | HTTP 200, no change |
| Nothing checks whether contracts or saved payment methods depend on the route, and no confirmation is asked for, on either status | The API, Merchant Setup screen | accepted as sent |
| Merchant Setup refuses to save a change that would leave every method disabled; the server accepts it | Merchant Setup screen | "Enable at least one method of payment", and Save is withdrawn |
What happens
- RUNDOWN: the method stops being offered for a new payment on that legal entity's checkout, any amount limits it carried stop reaching the checkout, and a wallet routed this way loses its button. The change applies to the next checkout the customer opens.
- RUNDOWN: payment methods already saved against that gateway, and contracts that collect through it, are untouched — they still resolve to the same gateway, so recurring collections carry on and the saved methods stay payable.
- RUNDOWN: subscribers receive
LEGAL_ENTITY_ROUTE.UPDATEand the change is recorded against the route, so an operator can see who ran it down and when. - INACTIVE: the route is excluded from every lookup, so the method is no longer offered and payment methods saved against that gateway stop being listed or accepted at the checkout. Scheduled collections on those stored methods are the exception and continue.
- Either way the route is kept, not deleted, and there is nothing to undo it with in Merchant Setup: re-enabling the method there creates a fresh route and leaves this one behind.
Who can do this
- Roles: Admin only.
- Permission keys (for clients managing permissions directly): Shuttle does check the session's team permissions when it saves the route,
legal_entity_curr(or*) on both the legal entity and the gateway, and swallows a refusal rather than reporting it: see Route a payment method to a provider. Merchant Setup gates its own controls onpayment_gateway. A request with no valid session is refused earlier with UNAUTHORIZED. Shuttle's own save-rights check on the route's legal entity and gateway is the one server-side gate, and when it refuses, the refusal is swallowed rather than returned (see Rules). - Without
payment_gatewayMerchant Setup still draws the payment method toggles and still lets them be moved, but never offers Save or Cancel, so nothing can be sent.
Related
Updated about 3 hours ago
Did this page help you?