Disconnect a provider

Archives a connected payment processor so it stops processing, and archives every legal entity route on it in the same call, so nothing routes to it any more: the payment methods it carried come off the checkout, saved cards vaulted against it stop working, contracts collecting from those cards stop collecting, and refunds and captures on payments taken through it are refused. The processor connection itself is not revoked and no vaulted token is deleted; restoring the provider later brings the connection back but not the routes. The same call archives a fraud screening workflow, which stops screening but leaves every route that used it untouched. It is sent as a status change: anything else in the body is discarded.

Where you can do this

Merchant Setup: Managing a connection (Disconnect {name})
API: Update a gateway (PUT /gateways/{gateway_id}) — body carries status ARCHIVE

Before you start

The provider exists on the instance, as a payment gateway or as a fraud screening workflow.
Its status is not already ARCHIVE. Sending ARCHIVE to a record that already holds it is not a status change at all but an ordinary settings save (see Rules).

Inputs

Input	Required	Meaning and constraints
status	yes	ARCHIVE. Only a value that differs from the stored status is treated as a status change; `DELETE /c/api/workflows/{workflow_id}` supplies it instead of the caller.
fields that belong to another function and are accepted on the same call; see Update a provider's settings	no	Discarded. A status change ignores `values`, `currencies`, `payment_method_types`, `legal_entity`, `name`, `code`, `division`, `metadata`, `tags`, `receipt_format` and `oauth_data`: nothing but the new status is sent on, so none of it reaches the stored object. Merchant Setup sends the whole record, including `legal_entity` set to null, on every disconnect.

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
A gateway call must carry a gateway object	The API	VALIDATION_ERROR: "API body error: missing gateway object"
The gateway must exist	The API	NOT_FOUND: "gateway not found" (404); apiValidation.error.not.found "payment_gateway "
Sending ARCHIVE to a record that is already archived is not a status change: the call falls through to the ordinary settings save with whatever else the body carries (see Update a provider's settings, Dismiss an archived provider's notice)	The API	the record is re-saved, not archived again
Any status name is accepted without transition checks; a name the platform does not know fails	The API	IllegalArgumentException
Nothing guards outstanding transactions, unspent authorisations, refundable payments, vaulted cards or live contracts. Merchant Setup is the only place a warning appears, and only when the gateway holds at least one vaulted method	Merchant Setup screen	confirmation modal: "Any vaulted payment methods will no longer be available"
`DELETE /c/api/gateways/{gateway_id}` is not implemented; only workflows have a delete route	The API	NOT_IMPLEMENTED: "Functionality not supported" (501)

What happens

The provider's status is ARCHIVE. It stops processing entirely: no payment, refund, capture or void is sent to it, and no call is made to the processor even to read its settings or connection state. Refunds on payments taken through it can no longer be issued (Refund a payment) and unspent authorisations can no longer be captured (Capture an authorised payment). It moves to the archived providers in Merchant Setup, where Restore an archived provider is the only way back.
Every legal entity route on the provider is archived outright, including the run-down routes that were keeping saved cards resolving. The payment methods those routes carried come off the checkout, and restoring the provider does not bring them back: they have to be routed again (contrast Stop offering a payment method, which keeps existing cards and contracts working).
Saved payment methods are left in place and no token is deleted at the processor, but they stop working. A customer is no longer offered a saved card held on this provider, and a checkout opened with one pre-selected fails at submission (Take a one-off payment).
Any ACTIVE contract still collecting from a saved method on this provider becomes FAILING at its next due date. The attempt is recorded as an INVALID_PAYMENT_METHOD transaction reading "Payment method no longer available (gateway archived)", its next payment date is cleared and its retries are marked complete, so it will not try again until another payment method is attached (Change the payment method on a contract).
Webhooks GATEWAY.UPDATE and GATEWAY.ARCHIVE are delivered, and LEGAL_ENTITY_ROUTE.UPDATE plus the route archive event for each route archived (delivered under an unexpected name; see Stop offering a payment method). No email or SMS is sent to anyone. The API answers 200 with the archived record; a workflow deleted through the delete route is answered 204 No Content.
A fraud workflow archived this way raises no webhook at all and touches no route: it simply stops being called, and the payment methods that named it keep being offered.

Who can do this

Roles: Admin only. Support holds neither payment_gateway nor payment_workflow, and provider setup is Admin work by design.
Permission keys (for clients managing permissions directly): payment_gateway (or *) on the gateway, checked by Shuttle; without it UNAUTHORIZED: "Unauthorized" (401). Shuttle additionally requires the session's team to hold save rights on the record, but a refusal there is swallowed (see Rules). Nothing at all is checked for a workflow: neither the status change nor the delete route reaches the permission check, so any valid session for the instance can archive a workflow. Merchant Setup gates the screen on payment_gateway, but leaves Disconnect clickable without it, greying the label rather than disabling it, so the control is offered to a reader and refused by the server.
App options: none. Disconnect is offered on a single-provider deep link as well as on the full provider list, and is hidden only while a provider is being connected for the first time.