Dismiss an archived provider's notice

Clears the reason shown against a provider connection that was archived with one, so the notice stops appearing and the connection's ordinary settings screen comes back. It is not a distinct operation on the server: it is the ordinary gateway edit sent with an empty reason (see Update a provider's settings), and because every provider call is skipped for an archived gateway it cannot fail on credentials. It is what a merchant operator does after reading the notice; it does not reconnect the provider, restore the connection or change anything at the provider.

Where you can do this

Merchant Setup: Managing a connection (Dismiss (archived only))
Merchant Setup: Managing a connection (Dismiss)
API: Update a gateway (PUT /gateways/{gateway_id}) — an archived gateway; body carries status_reason null and no status change

Before you start

The gateway exists on the instance and its status is ARCHIVE.
It carries a status_reason. Without one Merchant Setup shows the ordinary settings form instead, and there is nothing to clear.
Nothing has to be working at the payment processor: the call makes no provider request.

Inputs

Input	Required	Meaning and constraints
gateway_id	yes	Path parameter: the gateway's `gw_` id, or its code
status	no	If sent it must equal the gateway's current status, ARCHIVE; Merchant Setup always sends it. Any other value turns the call into a status change and discards every other field (see Restore an archived provider, Disconnect a provider)
fields that belong to another function and are accepted on the same call; see Update a provider's settings	no	name, code, division, metadata, tags, values, currencies, payment_method_types. Merchant Setup replays the whole gateway record it last read; anything absent is filled in from the stored record before the call reaches Shuttle

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 carry a gateway object	The API	VALIDATION_ERROR: "API body error: missing gateway object"
The gateway must exist on the instance; the id or the reporting code resolves it	The API	NOT_FOUND: "Gateway not found" (404)
The name must be present and the reporting code must be present and unique. A caller who sends status_reason alone still passes: Shuttle replays the stored name and code	The API	validations.name.notempty, validations.reportingCode.notempty, validations.reportingCode.nonunique
Every other edit clears the reason the same way: saving the settings form (Update a provider's settings) or changing the status (Disconnect a provider, Restore an archived provider) leaves the gateway with no reason	The API	reason gone
A reason can only be put on a gateway by a status change that carries one, and no `/c/api` route sends one, so a dismissed notice cannot be restored through the API	The API	no way to set a reason
No provider request is made and the stored settings are neither re-tested nor re-encrypted, because the gateway is archived; the call cannot fail on credentials	The API	none; the call succeeds
Legal entity routes are untouched: no legal entity is sent, and routing is only rewritten when one is	The API, Merchant Setup screen	routes unchanged
Merchant Setup offers the control only on an archived gateway that has a reason. Through the API the same body on any other gateway is an ordinary settings save	Merchant Setup screen	control not shown

What happens

The notice is gone. The provider's screen shows its ordinary connection settings again and the operator is returned to the integrations list. The connection itself does not change: it stays disconnected until it is restored (Restore an archived provider).
Nothing is asked of the payment processor. No credential check, no reconnection, no change at the provider; saved cards and archived routes are exactly as they were.
The notice cannot be brought back through the API. Only a fresh status change carrying a reason will show one again.
The connection silently loses any currency and payment-method restrictions it had, and its receipt number format: restored later, it comes back enabled for every currency and payment method the provider supports.
Webhook GATEWAY.UPDATE is delivered, and the change is recorded in the connection's history against the user who made it. The API answers 200 with the gateway, now carrying no status_reason.

Who can do this

Roles: Admin only. Support holds no provider-setup key, and principle 1 keeps provider setup out of Support.
Permission keys (for clients managing permissions directly): payment_gateway or * on the gateway, checked by Shuttle before the gateway is read; without it UNAUTHORIZED: "Unauthorized" (401). A key held on the client or on every object also passes. Shuttle then checks separately that the session holds some permission on the gateway; without it NO_PERMISSION: "apiValidation.error.permissions", naming the gateway. Merchant Setup gates the settings form on payment_gateway but not the Dismiss control, and its own check passes when the key is held on any object at all, so a user without the key on this gateway still sees Dismiss and is refused by the server.
App options: none. The control appears only on the archived notice screen, beside Cancel.