In test mode, card numbers control the outcome so you can deliberately exercise every path — success, failover, hard decline, and degradation — before going live.
The authoritative, always-current matrix is shown in your dashboard under Integration Kit → Test cards. The cards below are the core scenarios.
CardScenario
4242 4242 4242 4242Approves on the first gateway attempted
4000 1000 0000 0000Retryable decline on priority 1 → transparent failover, approves on priority 2
4000 0000 0000 9979Fraud-class decline — surfaced immediately, never retried on another gateway
Use any future expiry date and any 3-digit CVC.

​
What to verify with each card

  • Success card — your onSuccess callback fires with capturedVia set to your priority-1 gateway and failoverUsed: false.
  • Failover card — your onSuccess callback still fires (the customer never sees the first decline), but capturedVia is your priority-2 gateway and failoverUsed: true. The payment’s attempt trail in Analytics shows both attempts with the decline code from attempt 1.
  • Fraud-class card — your onDeclined callback fires immediately with the decline code. There is exactly one attempt in the trail: fraud-class declines (stolen/lost card, fraud suspected) are terminal by construction and never re-presented to another gateway.

​
Testing webhook retries

Your webhook endpoint can be tested independently of cards: return a 503 from your endpoint and SwitchFlow will retry with exponential backoff (up to 5 attempts), then mark the delivery failed and surface it in the dashboard webhook log for manual redelivery. A 4xx response is treated as terminal (no retries) — see Webhooks.