Risk Scoring
The families of signals behind the score, and the levers that are yours.
Shield combines many signals about the payer, the device, the card and the history of each identifier into a score from 0 to 100. Wajub tunes those signals all the time, as fraud moves, so the same payment can score differently from one month to the next. History counts too: a new attempt on the same payment is scored again, with what came before taken into account.
Every payment records the signals that fired, and the Dashboard shows them on the payment. This page describes what those signals look at, and what you control.
The bands, and what they are not
| Score | Band |
|---|---|
| 0 to 20 | Low |
| 21 to 50 | Medium |
| 51 to 80 | High |
| 81 to 100 | Critical |
These are labels for reading a list at a glance. The decision comes from
your thresholds, not from the band, so a payment at 62 is high whether your
block threshold is 70 or 60, and only one of those refuses it.
What counts without Shield Advanced
Every family on this page is checked on every live payment. Shield Advanced scores with Wajub's full signal set; the other plans score with a core subset of it. Shield compares the plans.
Where the payer is coming from
Shield checks that the payer's network, location, browser settings and phone agree with one another. A payer whose details all point to the same place looks different from one whose IP address, phone and browser each tell another story.
Shield reads them from the payer's browser. Hosted checkout, payment links, invoices and Wajub
Components send that data for you. If you charge from your own server with a secret key, call
Wajub.signals() in the payer's browser and pass the result unchanged as data._client:
If you run your own checkout shows how.
Whether the request came from a browser at all
Shield recognises automated and headless browsers. Send the payer's browser data with every charge, as above.
How fast the same identifier is moving
Shield watches how fast the same IP address, card range, device, email and phone are used, and recognises card-testing patterns.
These counters are not scoped to you
A phone number, an email, an IP address or a card range is followed across the whole platform, so an attack spread over several merchants is seen as one.
What the platform remembers about this payer
Shield remembers how an email, a phone number or a device behaved across the platform, dispute outcomes included, and notices a phone number that turns up on a new device (SIM swap). This history fades over time: nobody stays marked because of one bad month.
A dispute you concede, with accept or close or from the Dashboard, ends lost like one ruled
against you, but it says little about the payer and weighs less against them. Such a dispute
carries metadata.resolution set to accepted.
Reputation can add a payer to your blocklist
On Shield Advanced, when you lose a dispute to a payer with a poor record across the platform, their email and phone can be added to your blocklist automatically. An entry added this way refuses payments only while Shield and your blocklist are both switched on, like any other entry. Sandbox activity never affects a payer's record and never adds anything to this list.
What the identifiers themselves look like
Shield also looks at the email and the phone number themselves: throwaway email domains, identifiers it has never seen, unusual repetition. That is why a payment from a customer nobody has met before rarely scores zero.
What the card is
Shield compares where and how the card was issued with the payer's location and phone, and takes recent declines into account.
Only the first eight digits of a card number ever reach the risk engine, and nothing longer is stored.
What you and your history say
Shield weighs the customer's disputes with you, how the payment compares with your account's usual activity, and how new your account is.
You can also feed the score yourself. Set risk_flag to high or medium in the payment's
metadata to raise the risk Shield assigns to that payment. The same key on the customer's own
metadata applies to every payment they make, and there only high is read.
The two scores that are not computed
Two things do not depend on the signals at all. They force the score to 100, which refuses the payment on any threshold that can be set.
A blocklist match, on your own list, while the list is switched on.
A sanctions match, against the platform watchlist, on every plan and whether or not you have configured Shield. Sanctions screening is not a feature you buy.
The watchlist is built from the official public lists, OFAC's SDN list and the UN consolidated list, plus Wajub's own additions, and it is refreshed regularly. A payer matching it is refused.
For a possible match, a name that resembles a listed one, you choose what happens, in Shield,
Risk controls or with sanctions_near_match_action on PUT /shield/settings, on
every plan and whether or not your own Shield settings are switched on.
| Your choice | What happens to the payment |
|---|---|
review, the default | It is sent to review whatever its score, with sanctions_possible_match as the reason. Shield, Reviews lists it even when Shield is switched off; you can then only mark it reviewed |
block | It is refused, like a match |
Review is the default because these lists carry thousands of transliterated names, and a payer who happens to share a spelling with someone listed should not have their payment refused on that alone, nor should you have to explain such a refusal to your customer. A review never holds the funds: the payment is collected, and the decision is yours to take afterwards.
What the Rules page shows you
The Shield, Rules page lists the signals with a name, a description and a severity label. That list is a description of what protects you, not a set of switches: you cannot turn a signal off, change how much it weighs, or add one. Wajub tunes the signals for the whole platform.
The severity words on that page, and in the flag detail on a payment, are labels for reading. Your
levers are your thresholds, your rules and lists, and the risk_flag you set.