Shield
What Shield scores, what it does with the score, and what it never does.
Shield reads every live payment before a provider is called and gives it a number between 0 and 100. Above one of your thresholds the payment is refused outright; above the other it goes through and lands in a queue for you to look at. Nothing about it is a model: each signal it finds adds a fixed number of points, and the same payment always scores the same.
Shield runs whether or not you have configured it. What you configure is how strict it is with your traffic, and what it is allowed to do beyond scoring.
1Scored before routing
Every live payment gets a number between 0 and 100 before a provider is contacted.
2Flagged is not held
Above the review threshold the money still arrives. The queue is a to-do list, not a hold.
3Only a block stops it
Above the block threshold the call returns 403 and no provider ever sees the payment.
Where it sits in a payment
A payment is two calls. Shield runs inside the second one, before the router picks a connection and before any provider is contacted.
| Step | What happens |
|---|---|
POST /payments | The transaction is created. Nothing is scored |
POST /payments/{id} | The operator channel is resolved, your limits are checked, then Shield scores |
| A block | The call returns 403 before a single provider is called |
| Everything else | The payment continues into orchestration as normal |
The order matters: a payment your own limits already refuse never reaches Shield, which is why a refused attempt does not consume a velocity slot or show up in your review queue.
Three outcomes, and only one of them stops anything
| Score against your thresholds | Decision | What the payer sees |
|---|---|---|
| Below the review threshold | Allowed | A normal payment |
| Review threshold or above, below block | Flagged | A normal payment |
| Block threshold or above | Blocked | A 403, with a reference to quote to support |
A flagged payment is not held
review means money came in and you should look at it. The payment is charged, credited and
settled exactly like any other, and only enters your review queue once it has actually been
collected. Shield has no mechanism that holds funds pending a decision, so if a review is a
reason for you not to ship, that logic belongs in your own system.
Two layers, and only one is yours
Wajub screens its own platform, and your settings sit on top of that.
The platform layer blocks at 80 and flags at 50 for everyone, all the time. It is not something you switch off, and it is what applies before you have configured anything.
Your layer replaces those two numbers with your own once you activate Shield. You can be stricter than Wajub, never laxer: a block threshold above the platform's is brought back down to it. Turning Shield off again does not leave you unprotected, it just hands the decision back to the platform numbers.
Everything else Shield can do, the custom rules, the lists, the automatic 3D Secure, only exists while your own configuration is on.
Sandbox is never scored
A sandbox payment takes a different code path entirely, with no risk assessment in it. There is no score, no flag, no queue entry, and the Shield endpoints refuse a test key. You cannot rehearse a fraud decision, which is the reason the thresholds have floors: they are the guard rail you do not get to test against.
What each plan actually gets
Baseline screening is on every plan. What you pay for is the ability to act on it.
| Shield | Shield Advanced | |
|---|---|---|
| Every live payment scored | Yes | Yes |
| Your own thresholds | Yes | Yes |
| Review queue | Yes | Yes |
| Closing a review as approved | Yes | Yes |
| Custom rules | No | Yes |
| Blocklist and allowlist | No | Yes |
| Automatic 3D Secure on cards | No | Yes |
| Blocking or refunding from a review | No | Yes |
Shield Advanced is included on Scale and Enterprise, and available as a paid add-on on the lower plans. Rules and list entries left behind by a downgrade stay in the database and stop being evaluated, so they come back as they were if you subscribe again.
What your integration can see
Nothing. There is no shield object in the payment response, no risk score on the payment, and no
webhook that fires on a Shield decision. The one thing your code sees is the refusal.
The transaction is left at pending and untouched, because the block happens before anything is
written. The BLK- reference identifies that exact decision, so a payer who insists they are
legitimate can quote it and you can find them in the Dashboard.
The endpoints
Shield is configured from the Dashboard under Shield, and the same settings are reachable from the API with your private key.
| Method | Endpoint | Used for |
|---|---|---|
GET PUT | /shield/settings | The on switch, the thresholds, the two Advanced toggles |
GET | /shield/stats | Blocked, reviewed and disputed counts for the current month |
GET POST DELETE | /shield/blocklist | The blocklist |
All of them are live only and require a secret key. There is no endpoint for the custom rules, the review queue or the signal detail: those are Dashboard surfaces.