Most institutions can be reached through more than one of Quiltt's data providers (MX, Finicity, Plaid, and Akoya). When a user links an institution, the Connector connects through one of those providers. If that provider fails, Provider Fallback keeps the same connection attempt moving by rerouting to another eligible provider for the institution, instead of stopping at an error screen.

Provider Fallback builds on Quiltt's provider routing: routing picks a provider when the connection is created, and Provider Fallback recovers within that attempt when the chosen provider does not work.

Link to this section#How Provider Fallback works

When a provider fails during a connection attempt, the Connector reacts in one of two ways, depending on when the failure happens.

• Automatic fallback. If the provider's login fails to load, the Connector moves to the next eligible provider on its own. The user sees a brief loading state and then the working login screen from the next provider. No action is required, and in most cases the user never learns that the first provider failed.
• Prompted fallback. If the attempt fails after the provider's login has opened, and another eligible provider is available, the Connector shows a recovery screen with a Try another provider option. The user selects it to continue with the next provider.

Each eligible provider is tried once per connection attempt. The Connector works through the ranked list in order and does not retry a provider it has already attempted in the same attempt.

The video below shows the automatic path in action: the first provider times out before its login loads, and the Connector reroutes to the next eligible provider while the user sees only a brief loading state.

Link to this section#Which providers are eligible

An institution's provider is eligible for fallback when it:

• Supports the institution.
• Supports the products your Connector requires.
• Is enabled for your environment.

Quiltt ranks the eligible providers and tries them in that order. Ranking favors the most reliable route available for each institution, and it is handled by Quiltt rather than configured in your integration. For more on how Quiltt selects providers, see the Connector overview.

Link to this section#When every provider fails

If every eligible provider has been tried and none succeeds, the Connector shows a clear message and lets the user search for a different institution or close the flow. Provider and institution problems are usually transient, so prompting the user to try again later often resolves them.

If a specific institution keeps failing across providers, contact Quiltt Support with the Profile ID and the institution name so the team can review the route.

Link to this section#What this means for your integration

• No setup. Provider Fallback works automatically on any connector with more than one provider enabled. There is nothing to configure or call.
• Transparent to your app. Fallback happens inside the Connector. Your event callbacks do not fire on each provider switch. A successful connection fires exited.successful as usual, and only a fully unsuccessful attempt surfaces as exited.errored.
• User-fixable problems stay in the provider's flow. Issues that only the user can resolve, such as an incorrect password or a bank account locked at the institution, are handled inside the provider's own login screens rather than by switching providers, since another provider would hit the same block.

Link to this section#Related

• Account linking with the Quiltt Connector for how the Connector selects a provider.
• Reconnect a broken bank connection for repairing a connection that later enters an error state.
• JavaScript API for the Connector events your app can listen for.