{"section":"tutorials","requestedLocale":"en","requestedSlug":"mode-off-faq","locale":"en","slug":"mode-off-faq","path":"docs/en/tutorials/payments/transactions/mode-off-faq.md","branch":"main","content":"**Contingency Mode** (formerly known as **Mode-off**) is a VTEX Payments resilience feature that helps protect eligible transactions during temporary outages at payment providers.\n\nThis article covers the following topics:\n\n- [How **Contingency Mode** works](#how-contingency-mode-works)\n- [The impact on transactions](#impact-on-transactions)\n- [Which payment methods and flows may be affected](#affected-payment-methods)\n- [Connector recovery and retry behavior](#recovery-and-retry-behavior)\n- [How to identify **Contingency Mode**](#how-to-identify-contingency-mode)\n- [What to do when **Contingency Mode** is active](#what-to-do-when-contingency-mode-is-active)\n- [Guidance for payment providers](#guidance-for-payment-providers)\n\n> ℹ️ Merchants don't need to configure or activate **Contingency Mode** manually. VTEX automatically manages transaction activation, recovery, and retries.\n\n## How Contingency Mode works\n\n**Contingency Mode** is an automatic protection mechanism for payment connectors. When VTEX detects recurring technical failures in a connector, the system activates this mode to reduce the impact of instability on payment processing.\n\nDuring this period:\n\n- New eligible authorizations are temporarily stopped from being sent to the provider.\n- New eligible transactions may be postponed for later processing.\n- Transactions that were postponed follow an independent scheduled retry flow.\n\nThis protection applies to the affected connector, not to the entire store. Other payment providers or methods not affected by the instability may continue to operate normally.\n\nThe activation and recovery cycle of **Contingency Mode** is independent of the retry cycle of postponed transactions. This means a connector may have already exited **Contingency Mode** while certain transactions are still waiting for the next scheduled retry window.\n\n### Activation\n\n**Contingency Mode** is activated when VTEX detects 5 qualifying technical errors in 5 minutes for the same connector.\n\nQualifying technical errors may include:\n\n- Request timeouts.\n- Connection failures.\n- Requests canceled due to technical instability.\n- HTTP `408` timeout responses.\n- HTTP `5xx` errors from the provider, such as `500`, `502`, `503`, or `504`.\n\n> ℹ️ Expected responses from the authorization process don't activate **Contingency Mode**. For example, insufficient funds, invalid card, expired card, and payment not authorized are part of the normal authorization flow and aren't considered connector instability.\n\n### Contingency Mode cycle\n\nWhen **Contingency Mode** is active:\n\n- VTEX marks the affected connector as temporarily unavailable.\n- New eligible authorization requests aren't sent to the provider.\n- New eligible transactions may be postponed for retry later.\n- The connector remains temporarily unavailable until the automatic recovery period ends.\n- Merchants may see **Contingency Mode** indicated in transaction details or payment logs.\n\nThis behavior helps avoid new calls to an unstable connector while the provider recovers.\n\nThe following diagram shows the activation and recovery cycle of **Contingency Mode** for new authorizations:\n\n```mermaid\n%%{init: {'flowchart': {'htmlLabels': true, 'useMaxWidth': false, 'wrappingWidth': 500, 'padding': 14}}}%%\nflowchart LR\n A[\"New authorization
attempt\"] --> B[\"VTEX starts the
authorization process\"]\n B --> C{\"Is connector
in Contingency Mode?\"}\n C -- \"Yes\" --> D[\"Sends to scheduled
authorization flow\"]\n C -- \"No\" --> E[\"VTEX sends the payment
to the connector\"]\n E --> F{\"Connector returned
qualifying error?\"}\n F -- \"No\" --> G[\"Normal
authorization flow\"]\n F -- \"Yes\" --> H[\"Qualifying error
is accumulated\"]\n H --> I{\"5 qualifying errors
in the last 5 minutes?\"}\n I -- \"Yes\" --> J[\"Contingency Mode is activated
for about 5 minutes\"]\n J --> K[\"New eligible authorizations
stop being sent to the connector\"]\n K --> L[\"After about 5 minutes,
Contingency Mode is deactivated\"]\n L --> M[\"New authorizations are
evaluated normally again\"]\n```\n\n## Impact on transactions\n\n**Contingency Mode** doesn't cancel orders on its own. Transactions affected by **Contingency Mode** may be postponed for an automatic retry later.\n\n> ℹ️ **Contingency Mode** doesn't override the normal rules of payment expiration and cancellation. If payment can't be authorized before the applicable deadline, the order may still be canceled based on the normal order flow.\n\nCustomers may see the payment as processing or pending while VTEX awaits the next retry of the authorization.\n\nMerchants should avoid asking customers to place a new order immediately unless the original order has already been canceled or the payment method requires a new customer action.\n\n## Affected payment methods\n\n**Contingency Mode** applies to payment flows that can be processed asynchronously and retried safely after a temporary provider instability.\n\nPayment methods or flows that require an immediate online response, client redirection, or a new customer action may not be postponed and retried in the same way. In these cases, the transaction follows the standard behavior for those payment methods.\n\n> ℹ️ If you're unsure whether a specific payment method is eligible for **Contingency Mode**, contact [VTEX Support](https://supporticket.vtex.com/support) or your payment provider.\n\n## Recovery and retry behavior\n\nConnector recovery is automatic. After approximately 5 minutes since the last qualifying error, VTEX removes the connector from **Contingency Mode**, and new eligible authorizations can be sent to the provider normally.\n\nExiting **Contingency Mode** only affects new authorization attempts. Previously postponed transactions follow their own scheduled retry flow.\n\n### Retrying postponed transactions\n\nTransactions postponed during **Contingency Mode** aren't necessarily retried immediately after connector recovery.\n\nThese transactions follow an independent retry flow based on:\n\n- The retry rules of the payment method.\n- The payment cancellation time (`delayToCancel`).\n- Information returned by the provider.\n- Other operational conditions of the payment flow.\n\nThe following diagram shows the behavior of scheduled authorizations:\n\n```mermaid\n%%{init: {'flowchart': {'htmlLabels': true, 'useMaxWidth': false, 'wrappingWidth': 500, 'padding': 14}}}%%\nflowchart LR\n A[\"Authorization arrives while the
connector is in Contingency Mode\"] --> B[\"VTEX doesn't call the connector\"]\n B --> C[\"Payment is sent
to a reprocessing queue\"]\n C --> D[\"Payment remains as
scheduled authorization\"]\n D --> E[\"VTEX automatically makes
a new authorization attempt\"]\n E --> F[\"VTEX restarts the
authorization process\"]\n F --> G{\"Is the connector in Contingency
Mode at the time of retry?\"}\n G -- \"Yes\" --> C\n G -- \"No\" --> H[\"Payment proceeds to the
normal authorization flow\"]\n```\n\nThe recovery period of **Contingency Mode** and the retry interval for transactions are independent processes, so:\n\n- The connector may exit **Contingency Mode** after approximately 5 minutes.\n- Postponed transactions may continue to wait for the next scheduled retry window for that payment flow.\n\nThis behavior avoids new immediate calls to still-unstable connectors while preserving eligible transactions for later automatic reprocessing.\n\nThe interval between retries may vary according to:\n\n- The payment method.\n- Information returned by the provider.\n- The payment cancellation time (`delayToCancel`).\n- Operational conditions of the payment flow.\n\nThese factors determine how long the transaction can still be reprocessed and the interval that must be observed between attempts. Therefore, the time until the next retry is not fixed for all payments and may vary depending on the transaction's configuration and context.\n\nIn general:\n\nWhen `delayToCancel` is less than 1 day, retries usually occur every 1 hour.\nWhen `delayToCancel` is 1 day or more, retries usually occur every 4 hours.\n\nFor more information, see the [Create Payment](https://developers.vtex.com/docs/api-reference/payment-provider-protocol?endpoint=post-/payments) endpoint.\n\n> ℹ️ Although [Pix](https://help.vtex.com/docs/tutorials/setting-up-pix-as-a-payment-method) payments aren't affected by the **Contingency Mode**, meaning that transactions made through this method aren't blocked, other issues may interrupt payment processing. In these cases, when the `delayToCancel` field is set between 5 minutes and 1 hour, retry attempts usually occur every 5 minutes.\n\n> ⚠️ The retry time may vary according to the payment method, account settings, and operational conditions. VTEX manages this process automatically to minimize retry intervals and reduce the time transactions spend in the pending queue.\n\n## How to identify Contingency Mode\n\nMerchants may notice **Contingency Mode** when instability in a payment provider affects a specific connector.\n\nCommon indicators include:\n\n- An unusual number of payments are pending authorization or processing for the same provider.\n- Transaction logs indicate that **Contingency Mode** is active on the affected connector.\n- A temporary reduction in the volume of approved payments for a specific payment method or provider.\n- Eligible authorizations being postponed for later retry.\n\nPayment providers may also notice other indicators of integration instability, such as:\n\n- Timeouts.\n- Connection failures.\n- HTTP `5xx` errors.\n\n## What to do when Contingency Mode is active\n\nIn most cases, no action is required by merchants. VTEX automatically protects the transaction flow, re-enables the connector when the instability subsides, and processes eligible transactions according to the automatic retry rules.\n\nRecommended actions:\n\n1. Monitor the affected transactions in the VTEX Admin.\n2. Check whether the issue is specific to a particular provider or payment method.\n3. Contact the payment provider if the instability persists or if the integration requires further investigation.\n4. Contact [VTEX Support](https://supporticket.vtex.com/support) if transactions remain pending longer than expected or if customers report recurring payment issues.\n\n> ⚠️ Avoid canceling or recreating orders manually unless there's a clear business reason to do so, such as a customer request, order expiration, or confirmation that payment can't be completed.\n\n## Guidance for payment providers\n\nPayment providers should investigate and resolve the instability that caused the recurring technical failures.\n\nCommon checks include:\n\n- Availability of authorization endpoints.\n- Response time and timeout behavior.\n- HTTP `5xx` errors.\n- Network connectivity.\n- Recent deployments or infrastructure changes.\n\nOnce the provider stabilizes, VTEX automatically removes the connector from **Contingency Mode**, and new eligible authorizations can be sent normally.\n\n> ℹ️ Previously postponed transactions continue to follow their configured retry rules."}