# Exercise failover

[Choose what to test in the sandbox](https://devportal.qa.winkpg.io/docs/decide/choose-what-to-test.md): Which sandbox scenario proves the part of your integration you're about to ship, and the blueprint that runs it.

Watch a fallback processor approve, and watch what reaches you when failover runs out of processors.

**Your answers so far**

- What are you testing next? What my code does when a processor is slow or unavailable.
- What does the processor do? It refuses to process the payment.

**What to build**

Run the processor failover blueprint. It gives the sandbox merchant a second processor profile, makes the first refuse to process, and runs both outcomes. The exhausted case is the one to write code for.

**Worth knowing**

- Only a processor answering that it didn't process the payment triggers failover, and it happens once. A decline, a timeout, or a transport failure is final, because it's ambiguous about whether money moved.

**Where to go next**

- [Exercise processor failover](https://devportal.qa.winkpg.io/docs/blueprints/exercise-processor-failover.md)
- [Processor routing and failover](https://devportal.qa.winkpg.io/docs/guides/processor-routing-and-failover.md)

- [Start over](https://devportal.qa.winkpg.io/docs/decide/choose-what-to-test.md): go back to the first question.

## See also

- [All documentation](https://devportal.qa.winkpg.io/llms.txt): the machine-readable index of every public page on this site.