Reconnect a provider

Re-authorises a gateway whose provider authorisation has stopped working — the processor expired it, the merchant revoked it, or the account it was granted on was closed — by sending a fresh authorisation for the same gateway. It is the ordinary gateway update carrying an oauth_data token: the same route, the same connection test, the same record. The gateway keeps its id, its routes and its saved cards, so nothing has to be re-pointed afterwards. Saved cards are held against the processor merchant account the gateway was first connected to, so the merchant must sign into that same account; nothing on the server checks that they did.

Where you can do this

• Merchant Setup: Managing a connection (Reconnect {name})

Before you start

• The gateway exists, is not archived, and still resolves to a provider integration.
• The processor authorises through OAuth. Processors configured from credentials typed into the settings form have no reconnect; their equivalent is a settings save (Update a provider's settings).
• A completed authorisation at the processor whose oauth_data token has not expired: it is held for one hour.

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.

What happens

• The provider connection is re-authorised in place. The gateway keeps its id, its routes, its reporting code and every saved card held against it; nothing has to be re-pointed, and no contract or payment method is touched.
• Saved cards keep working only where the merchant signed into the same processor account. They are not moved, re-vaulted or re-issued; on a different account the processor declines them, and the number of cards at stake is shown on the settings screen before the merchant starts.
• The connection is tested with the new authorisation before the save is accepted; when it fails, the settings screen shows the processor's message and the save is refused.
• The gateway's enabled currencies and payment methods are recomputed from what the processor accepts at that moment, and the account name and connection status shown against the connection are read from the processor again.
• GATEWAY.UPDATE is raised and the change is recorded in the gateway's audit trail. Nothing is sent to the customer.

Who can do this

• Roles: Admin only. Connecting and re-authorising providers is business setup, not a Support action.
• Permission keys (for clients managing permissions directly): payment_gateway (or *) on the gateway, checked by Shuttle before anything is read or written; without it the caller sees UNAUTHORIZED: "Unauthorized" (401). Merchant Setup checks the same key against any object rather than against this gateway, and without it greys the Reconnect control without disabling it, so a user who lacks the key can still complete the processor's authorisation and is only refused at the save.
• App options: the control is offered only for processors whose integration authorises through OAuth, and only while the gateway is connected and not archived. There is no setting that turns it off; in single-provider deep-link mode it sits on the same combined screen.

Related

• Update a provider's settings
• Connect a payment processor
• Disconnect a provider