Library · Payment orchestration · How to run this
Failover hops are still auths
Primer-class failover retries another connector when the first dies. Every hop is still an auth. Unique orders that look fine can hide a fat auth bill. Type unique orders and failover auths.
Pair: Failover auth count on Payment orchestration. Pollution with CBs: cascade pollution. CRM vs gateway machines: recycle vs cascade.
What you type
Unique orders that entered the failover path in the window.
Failover auths — every hop counted (including the first try on that path).
Auths per order = auths ÷ orders. Extra = max(0, auths − orders). Cut hops when the ratio is the problem — do not invent a “good” chip.
What not to do
Do not invent a hop limit. Do not hop hard fails onto a spare MID. Do not mix CRM Recycle columns into this failover count without naming grain. Do not skip soft vs hard before the next hop.
Related: Payment orchestration, cascade pollution, recycle vs cascade, soft vs hard.
Procedure
- Type unique orders that hit failover.
- Type all failover auths (every hop).
- Cut hops when auths per order is the problem.
Failure modes
- Inventing a hop limit.
- Hopping hard fails onto a spare MID.
- Mixing CRM Recycle columns without naming grain.
Worked example
None on this page yet. When one lands it will be a real case: what broke, the number, and what changed. Not a composite.
Glossary
- Failover auth
- An issuer message on a Primer/Solidgate-class failover path. Every hop counts.
Work with us — We run this job on your accounts. Services
FAQ
- Is this cascade pollution?
- Related. [Cascade pollution](/manuals/cascade-pollution) adds recovered orders and extra chargebacks. This page is only auths per unique order on the failover path.
- Is this recycle vs cascade?
- No. [Recycle vs cascade](/manuals/recycle-vs-cascade) maps CRM ladder vs gateway hops. This page counts failover auths you already ran.
- How many hops is allowed?
- You type the counts. We invent no network hop chip.