Rails

Failover Notes

Failover Notes is for the awkward moment when the main payment rail is down, delayed, or giving mixed signals.

When the primary rail misbehaves

Failover Notes focuses on what should happen when the usual payment route is unavailable or unreliable. It sets out the questions a South African team should answer before switching channels, retrying a payment, or pausing the flow.

A useful note starts with the failed step, not a vague outage label. Record whether the issue sits with PayShap availability, an Instant EFT status that has not moved, or a DebiCheck mandate step that cannot complete. Add the bank involved, the order stage, and whether the customer is waiting in store, online, or at dispatch cut-off in Johannesburg, Durban, or Cape Town.

Keep the first evidence exactly as staff saw it. That means the reference, timestamp, bank name, and any pending or rejected message before anyone refreshes the screen. Saved properly, this gives finance and support one shared version of the event instead of three retellings in email and chat.

Switch rules before retry rules

Map the switch points before a payment run starts. It should spell out which rail becomes the backup, who may approve the change, and what evidence must be saved when Instant EFT, PayShap, or DebiCheck cannot follow the usual route. Short notes beat broad policy when staff need to decide whether to retry, route elsewhere, or stop the handover.

Keep the linked rails and operating notes close before adding another backup option. Include the checkout screen or payment status view that staff actually use when sending detail through the contact form. Screenshots matter more than summaries when the failure only appears on one bank flow.

  • Trigger points for changing payment rails
  • Captured proof before any refresh
  • Bank, time, and status logged

Checks shaped by South African payment conditions

South African failover decisions are rarely just technical. PayShap can suit urgent low-value recovery, Instant EFT can stall on confirmation, and DebiCheck has mandate rules that limit what staff may do next. Notes should also reflect bank-specific behaviour if one institution regularly shows delayed status updates.

Load-shedding, weak branch connectivity, and courier release times all affect whether a team waits or switches. An online order near dispatch cut-off needs a different note from a customer standing at a counter with a phone in hand. Write the note for the setting where the decision happens, not for a boardroom summary.

Operated by Astros Marketing (Pty) Ltd from 2 Makro Place, Sunnyrock 1401.

What to capture from the incident

Log the failed action, the visible message, and the exact point where staff stopped. Include device type, bank selected, retry count, and whether stock, booking, or collection was being held while payment status remained uncertain.

File the note while the timeline is still easy to reconstruct. Link it to the order, the proof kept by finance, and any handover instruction used by support or dispatch so the next incident follows the same rule set.

What our Real-Time Payments customers say

Verified Google reviews