# Carding Detection/Card Testing

NPS automatically screens every card tokenization for card-testing (carding) attacks using a dedicated, real-time risk analysis service. The protection is fully managed by NPS; it runs inside the hosted payment form, and **no integration work is required** from the integrator. For background on tokenization, see the [Tokenization Overview](/docs/tokenization-overview).

Key Idea:
Every card tokenization is risk-scored in real time before a token is issued. Legitimate customers pass through invisibly; suspicious sessions are challenged or blocked.

## Why Card Detection

In a card-testing (carding) attack, fraudsters use bots or scripts to run large numbers of stolen or generated card numbers through a checkout page to find out which ones are valid. Even when the attempts fail, the attack costs.

NPS tries to prevent these attacks at the **tokenization step**, before a token is ever issued or any payment is attempted, so abusive traffic is prevented as soon as possible.

## How It Works

1. The customer enters their card details in the secure hosted payment form.
2. The form transparently collects signals from the browser session, including device characteristics, entry behavior, and an invisible bot check (Cloudflare Turnstile).
3. When the customer submits, NPS evaluates the session against its risk analysis carding detection service. Multiple independent checks run in parallel and produce a combined risk score.
4. Based on the score, the tokenization request is **allowed**, **challenged**, or **blocked**.


No Setup Required:
All signal collection happens inside the hosted payment form. There is nothing to install, configure, or call; carding detection is applied automatically to every card tokenization.

## What the Risk Analysis Evaluates

The risk analysis draws on several categories of signals. The examples below are representative rather than exhaustive. The specific signals, rules, and models are continually tuned and expanded by NPS.

| Check | What it looks for |
|  --- | --- |
| Attempt velocity | Unusual patterns of repeated tokenization attempts within short time windows, correlated across dimensions such as network origin, device, card range, and geography, that may resemble automated card-testing activity. |
| Device reputation | The device's history and standing across sessions, taking into account factors such as request volume, the variety of cards submitted, how recently the device was first seen, and other reputation signals. |
| Entry behavior | How the payment details are entered, including signals such as typing cadence, paste activity, submission timing, retries, and similar behavioral indicators that help distinguish genuine customers from automated entry. |
| Bot detection | Indications of browser automation or non-human traffic, such as automation frameworks, inconsistent browser characteristics, known automation signatures, and related indicators, complemented by an invisible bot verification. |
| Identity plausibility | Whether the cardholder details provided appear plausible and internally consistent, evaluated through a variety of heuristics and pattern checks. |
| BIN risk | Risk attributes associated with the card's BIN, such as known test ranges, card type characteristics, country of issuance, and similar factors. |


Certain definitive automation indicators may result in an immediate decision, without waiting for the full risk score to be computed.

Alongside the rules-based checks, which already incorporate certain ML-derived signals, NPS is extending the evaluation with a dedicated custom model hosted on SageMaker AI/ML. The model assesses the plausibility of cardholder details and recognizes emerging attack patterns and is continually retrained on production outcomes as the rollout expands.

Privacy by Design:
The service never sees the full card number or CVV. Only the BIN (the first six digits) is evaluated, and it is analyzed inside NPS; no card data leaves the platform.

## Decisions and the Customer Experience

The combined risk score places every tokenization attempt into one of three outcomes:

| Decision | Risk level | What the customer experiences |
|  --- | --- | --- |
| **Allow** | Low | Nothing. Tokenization proceeds normally; the risk check is invisible. |
| **Challenge** | Medium | A simple image CAPTCHA appears inside the payment form. Solving it lets the customer continue; each challenge is valid for a few minutes, and up to three attempts are permitted before the request is blocked. |
| **Block** | High | The tokenization request is rejected. The SDK reports a standard tokenization error via `onError`. See [Error Codes](/docs/ui-sdk-reference#error-codes). No token is issued. |


## What You Need to Do

Very little. Carding detection is enabled platform-wide for all card tokenization performed through the Widget SDK and hosted payment form.

Providing the account holder name and billing address with each tokenization is preferred. These fields feed the identity checks used in carding detection; supplying them improves decision accuracy and helps legitimate customers pass through without unnecessary challenges.

A few things worth knowing:

- Risk thresholds and rules are managed by NPS and can be tuned. They are configurable per integrator via NPS.
- If you believe legitimate customers are being blocked at an unusual rate, contact NPS support with the approximate time window so the decisions can be reviewed.