Library · Payment orchestration · How to run this
A fraud block is not an issuer decline
Forter-class tools block before or instead of an auth. Issuers decline after a message. Mixing both into one “decline %” invents approval math and sends dead traffic into dunning.
Pair: Fraud block vs issuer on Payment orchestration. Next action after issuer: soft vs hard. Rebill days: dunning calendar.
What you type
Fraud-blocked $ — volume the fraud tool stopped in the window (never reached a live issuer yes/no, or marked block).
Issuer decline $ — gateway declines where the issuer answered no.
The calculator sums lost volume and names which pile is fatter. Fix the fatter pile first. Do not average them into one rate.
What not to do
Do not invent a block percent. Do not run NSF days on fraud blocks. Do not hop fraud blocks onto a second MID. Do not call a tool block a soft decline.
Related: Payment orchestration, soft vs hard, fraud review queue cost, cascade pollution, dunning calendar.
Procedure
- Type fraud-blocked $ for the window.
- Type issuer decline $ for the same window.
- Fix the fatter pile. Soft vs hard is a different page.
Failure modes
- Mixing fraud blocks into decline-family dunning.
- Inventing a good block percent.
- Hopping fraud blocks onto a second MID.
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
- Fraud block
- Volume a fraud tool stopped before or instead of a live issuer answer. Not an issuer decline family.
Work with us — We run this job on your accounts. Services
FAQ
- Is this soft vs hard decline?
- No. [Soft vs hard](/manuals/decline-code-playbook) is the next action after an issuer answer. This page splits fraud-tool stops from issuer nos.
- Did the issuer see the fraud-blocked order?
- Often no. The tool stopped before auth. Do not dump those into decline-family dunning.
- Can I invent a good block rate?
- No. Type your blocked $ and issuer decline $ for the same window.