Shield

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. The score combines many signals about the payer, the device, the card and the history of each identifier, and Wajub tunes those signals all the time.

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.

1. 1Scored before routing

   Every live payment gets a number between 0 and 100 before a provider is contacted.

2. 2Flagged is not held

   Above the review threshold the money still arrives. The queue is a to-do list, not a hold.

3. 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 when you charge the payment, in the second one, before any provider is contacted.

The order matters: a payment your own limits refuse is not scored, and does not show up in your review queue.

Three outcomes, and only one of them stops anything

A blocked attempt goes to the same queue straight away, with nothing collected. If it was a mistake, close it with allow this customer and their next attempt goes through, whatever your plan.

Two layers, and only one is yours

Wajub screens its own platform, and your settings sit on top of that.

The platform layer applies Wajub's own block and review thresholds to every account. It is not something you switch off, and it is what applies before you have configured anything. Wajub can move these thresholds, and tune the signals, as fraud moves; GET /shield/settings always returns the thresholds that apply to you, so read them there rather than writing a number into code.

Your layer replaces those thresholds 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 thresholds.

Everything else Shield can do, the custom rules, the lists, the automatic 3D Secure, only exists while your own configuration is on.

What each plan actually gets

Baseline screening is on every plan. What you pay for is the ability to act on it.

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 are kept and stop applying, so they come back as they were if you subscribe again. The customers you allowed from a review are the exception: they stay allowed on every plan.

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, which carries error_code: shield_blocked and the support reference in block_reference.

Response · 403 Forbidden

{

"code": 403,

"status": "Forbidden",

"error_code": "shield_blocked",

"message": "Payment blocked: transaction risk score too high. Please contact support and reference BLK-K3M9XQ2P.",

"block_reference": "BLK-K3M9XQ2P"

}

The transaction is left at pending and untouched. Branch on error_code, not on the message. The BLK- reference in block_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 attempt sits in your review queue, where allow this customer releases them for their next try.

The endpoints

Shield is configured from the Dashboard under Shield, and the same settings are reachable from the API with your private key.

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.