Skip to content
ShuttleShuttle Docs
Status
View as MarkdownPlain text for AI toolsOpen in ClaudeAsk questions about this pageOpen in ChatGPTAsk questions about this pageOpen in GitHub CopilotAsk questions about this page

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

Section titled “Where you can do this”

Before you start

Section titled “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

Section titled “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

Section titled “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

Section titled “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

Section titled “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.
Section titled “Related”

Was this page helpful?