🛟 Payment Continuity

The house can't be deplatformed off a single processor. This console watches every payment rail, marks which is primary and which are hot backups, and — when a rail goes dark — routes the buyer to a rail that still works. The lesson a certain deplatformed network learned the hard way: redundancy is the product.

Rails

How failover decides

1	The primary rail is used whenever its health check is green.
2	If primary is down or degraded, the first healthy backup (in order) becomes the active rail automatically.
3	If every card rail is down, the buyer is routed to an always-available off-rail method — the ⚛ Mainframe wallet, in-house credit, a crypto address, or an emailed invoice — so a sale is never lost to a processor outage.
4	The operator can pin any rail as primary, or force a drill, from here. The choice is stored locally on this device (`hmcsRailConfig`); wiring it to the server config is the next seam.

Wiring a real rail (operator)

A rail's health check pings a URL you control and reads { ok: true } (or any 2xx). Add rails by editing RAILS below in continuity.html, or POST them to a future /api/continuity/rails. The always-on off-rail methods need no processor and are the true backstop — they're what keep the house solvent through any ban.

Health	GET the rail's status URL; 2xx within timeout = up, slow = degraded, error/timeout = down.
Route	Continuity hands the buyer the active rail's checkout URL. It does not process the charge.
Off-rail	⚛ wallet / credit / crypto / invoice always report up — they don't depend on a third party.

🔧 Wire a rail's upstream (operator)