Restore an archived provider

Brings a disconnected payment processor (or fraud-screening workflow) back into use by setting its status to ACTIVE. It is the reverse of the status change that archived it, and only of that: the stored credentials are not re-tested, and for a gateway the routes archived at disconnect are not brought back, so the provider returns able to take money but with nothing routed to it. What it does restore immediately is everything that was blocked because the provider was archived: refunds, captures and voids on payments already taken through it, and collection from cards vaulted against it. Used when a provider was disconnected in error, when a merchant returns to a processor they had stopped using, or when a screening workflow was switched off for an investigation.

Where you can do this

Merchant Setup: Your integrations (Restore {name})
API: Update a gateway (PUT /gateways/{gateway_id}) — body carries status ACTIVE on an archived gateway

Before you start

The gateway or workflow is archived. Sent against a record in any other status the call is not a restore at all: it becomes a settings save (see Rules).
The processor integration behind it is still active. Where it has been withdrawn the provider still restores, but it reports itself unavailable and no call reaches the processor.
For the restore to be worth anything the stored credentials must still work at the processor; nothing on this path checks that.

Inputs

Input	Required	Meaning and constraints
status	yes	ACTIVE. The published specification names two other values for this field: RUNDOWN (existing saved payment methods only, no new ones) and ARCHIVE (see Disconnect a provider). No screen offers RUNDOWN; through the API it is accepted here in place of ACTIVE.
fields that belong to another function and are accepted on the same call; see Update a provider's settings	no	Accepted and then dropped, but only on a restore. Once the status in the body differs from the stored status Shuttle sends the status change on its own, and values, currencies, payment_method_types, name, code, division, legal_entity, receipt_format, tags, metadata and oauth_data go no further. Send the status the record already has, or no status at all, and the identical body is saved in full as a settings change.

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 gateway or workflow must exist	The API	NOT_FOUND: "Gateway not found" (404); from Shuttle, NOT_FOUND: "apiValidation.error.not.found" naming the object type and key
No transition is checked. The status sent is written as it stands, so a provider that was CREATED or LINKED before it was archived comes back as ACTIVE, and a restore can be sent to a gateway that has never taken a payment	The API	status set as sent
Sending status ACTIVE to a provider that is already ACTIVE is not a no-op: the status is compared with the stored one and, being equal, the call falls through to a settings save of the whole body instead, with the provider connection test that goes with it (see Update a provider's settings)	The API	the settings save's errors, for example VALIDATION_ERROR code INVALID on a failed connection
The archive reason is cleared by every restore, whatever the caller sends. The status change raised on a restore carries no reason at all, so the reason is written empty; only a call that does not change the status leaves it alone (see Dismiss an archived provider's notice)	The API	reason lost
The stored credentials are not re-tested before the restore. A provider whose credentials have expired or whose authorisation was revoked restores successfully; the failure only shows in the connection status reported against the record afterwards	The API	restore succeeds, connection reported as failing later
For a gateway, the legal entity routes archived at disconnect are not reactivated: each stays INACTIVE, so the checkout still will not offer the provider until routing is set up again (see Route a payment method to a provider)	The API	provider active with no payment method routed to it
Archiving a workflow never removed it from the legal entity routes, so restoring one resumes fraud screening on every route that still names it, with nothing further to configure	The API	screening resumes on the next payment

What happens

The provider's status is ACTIVE. In Merchant Setup it moves out of the archived list and back into the list of active providers, and its archived notice and archive reason are gone.
Everything that was refused because the provider was archived works again at once: refunds, captures and voids against payments already taken through it (see Refund a payment), and collection from saved cards vaulted against it.
New checkout payments still do not reach it. Its routes were archived at disconnect and stay archived, so until payment methods are routed to it again the provider is active but unused (see Route a payment method to a provider).
The record that comes back carries the provider's connection status again, which is where an expired credential or a revoked authorisation shows up; it is not a reason the restore is refused, so check it before telling a merchant they are back in business.
Webhook GATEWAY.UPDATE is delivered for a gateway. Restoring a workflow raises no webhook.
A restored workflow screens payments again immediately, on every route that still names it.

Who can do this

Roles: Admin only. Provider setup is Admin by intent and no other role holds a provider key.
Permission keys (for clients managing permissions directly): payment_gateway (or *) on the gateway, checked by Shuttle before anything else; without it UNAUTHORIZED: "Unauthorized" (401). Shuttle checks the same key again on the status change and answers NO_PERMISSION: "apiValidation.error.permissions" (403). The workflow form is checked by Shuttle alone, for payment_workflow (or *) — and when the call is addressed to an instance (/c/api/instances/{instance_key}/workflows/{id}) it runs as that instance, which Shuttle waves through, so any session that can reach the instance, including a read-only one, can restore a workflow.
Merchant Setup gates every other provider control on payment_gateway and shows the screens read-only without it, but leaves Restore live on every archived row, so a user who cannot change providers is offered the control and refused by the server.
App options: none. Single-provider deep links never reach the provider list, so the control does not exist in that mode.