> ## Documentation Index
> Fetch the complete documentation index at: https://developers.pcibooking.net/llms.txt
> Use this file to discover all available pages before exploring further.

# Validate and Authenticate a Card

> The different ways to validate or authenticate a card in PCI Booking, and what each one actually confirms.

PCI Booking offers several independent ways to validate or authenticate a card, each confirming something different. You can use any single one, or combine several, depending on your flow and how much assurance you need before relying on a card.

## At a Glance

| Method                                                             | What It Confirms                                                                                        |
| ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------- |
| [Luhn algorithm](#luhn-algorithm)                                  | The card number is a validly-formatted card number (checksum).                                          |
| [Card expiration threshold](#card-expiration-threshold)            | The card is valid at least until a date you specify (not just "not yet expired").                       |
| [Card brand limitation](#card-brand-limitation)                    | The card is a brand your downstream flow can actually handle.                                           |
| [Name-on-card validation](#name-on-card-validation)                | The cardholder name meets your own requirements.                                                        |
| [3D Secure authentication](#3d-secure-authentication)              | The person entering the card is very likely the actual cardholder.                                      |
| [Risk assessment](#risk-assessment)                                | Fraud risk score from the card issuer's country, the payer's billing country, and their IP geolocation. |
| [Gateway-level verification](#gateway-level-verification-tokenize) | The PSP recognizes the card/account as valid, with no charge attempt.                                   |
| [Small-amount PreAuth](#small-amount-preauth)                      | The PSP will actually place a hold on this specific card, for a real (small) amount.                    |
| [Full-amount PreAuth](#full-amount-preauth)                        | The PSP will hold the *actual* amount you intend to charge later.                                       |

## Luhn Algorithm

Checks that the card number passes the [Luhn checksum](https://en.wikipedia.org/wiki/Luhn_algorithm) - the same format check every valid card number satisfies. This catches typos and obviously-invalid numbers, but says nothing about whether the card is real, active, or able to be charged.

This is enforced by default on the hosted card capture forms. On [Store Paycard (Card Migration)](/api-reference/tokenize-cards/store-paycard), it can be disabled with `validateLuhn=false` - useful when migrating cards you know include test/dummy numbers that intentionally fail the checksum.

## Card Expiration Threshold

Confirms the card's expiration date is not just in the future, but valid at least until a date you choose - useful when the card needs to remain valid through a future event (e.g. a check-in date). Set `minExpiration` (format `mmyyyy`) on the [Request Card Entry Form](/api-reference/tokenize-cards/request-card-entry-form#minexpiration) to enforce this at capture time.

## Card Brand Limitation

Restricts which card brands are accepted at capture, so you never end up holding a token for a brand your downstream PSP or process can't actually handle. Set `cardTypes` on the [Request Card Entry Form](/api-reference/tokenize-cards/request-card-entry-form#cardtypes) to a comma-separated list of accepted brands.

## Name-on-Card Validation

Confirms the cardholder name meets your own requirements. Two options, depending on how much control you need:

* **Built-in check.** Set `nameOnCardValidation=NO_DIGITS` on the [Request Card Entry Form](/api-reference/tokenize-cards/request-card-entry-form#nameoncardvalidation) to reject names containing digits. No integration work required.
* **Your own rule, via `CustomValidation`.** Enable `useCustomValidation=true` and PCI Booking pauses tokenization to send you a [`CustomValidation` postMessage](/capture-cards/postmessage-notifications#custom-validation) with the masked card details (including the name). Apply whatever rule you need and approve or reject the submission from your own page.

## 3D Secure Authentication

Confirms - to the extent 3DS2 can - that the person entering the card is the actual cardholder, using the issuer's own authentication (frictionless or an OTP/biometric challenge). This is the only method on this page that produces a liability-shift-eligible result usable by a PSP later. Enable with `ThreeDS=true` - see [PSD2 and 3D Secure Implementation](/use-cases/comply-with-psd2) for the full flow, and [3DS Auth Management](/manage-tokens/3ds-auth-management) for how the result is stored and reused.

<Warning>
  `UnavailThreeDSAuth` defaults to `Accept`, meaning a 3DS failure still tokenizes the card, just without 3DS data. If you're relying on 3DS as your validation method, set this to `Reject` - see [Request Card Entry Form](/api-reference/tokenize-cards/request-card-entry-form#3d-secure).
</Warning>

## Risk Assessment

A different kind of check than the others on this page: instead of confirming the card itself is valid, it flags likely fraud by cross-referencing the card issuer's country (looked up from the card's BIN), the payer's billing country, and the client's IP geolocation. It does not validate or authenticate the card - it scores the *context* the card is being used in.

Send the token along with the payer's IP address and billing details to [Risk Assessment](/api-reference/manage-tokens/risk-assessment). The response includes a `RiskLevel` (`VeryLow` to `VeryHigh`), the issuer's country and bank name, and whether an anonymous proxy was detected - see the full [Risk Assessment](/use-tokens/risk-assessment) page for the response fields and what each risk level means.

<Info>
  Risk assessment is advisory only - it doesn't accept or reject the card. Combine it with your own fraud rules, and with the other methods on this page, to decide whether to proceed.
</Info>

## Gateway-Level Verification (`Tokenize`)

Sends the card to your actual PSP for a real verification check - the PSP confirms the card/account is valid - **without attempting any charge**. Use the `Tokenize` operation on [Process Transaction](/api-reference/process-cards/process-transaction); unlike other operations, `Amount` is not required for it.

This confirms the PSP accepts the card at all, but doesn't confirm the PSP will actually authorize a hold on it - for that, use a small-amount PreAuth instead.

## Small-Amount PreAuth

A genuine [PreAuth](/use-tokens/authorize-capture) for a small amount (e.g. $0.50–$1), immediately followed by a [Void](/use-tokens/refunds-voids) once you've confirmed it succeeded. This actually places a real (if small and temporary) hold at the PSP, which is stronger confirmation than gateway-level verification alone - it tells you the PSP will authorize a hold on this specific card, not just that the card format/account is recognized.

<Info>
  Whether a PreAuth can be voided (versus left to expire) is gateway-specific - check [Gateway-Specific Guidance](/use-tokens/gateway-guidance) for your PSP before relying on immediate release.
</Info>

## Full-Amount PreAuth

The standard [Authorize & Capture](/use-tokens/authorize-capture) flow: a PreAuth for the *actual* amount you intend to charge later. This is the strongest validation on this page - it confirms the PSP will hold the real transaction amount on this card, not just a token amount - at the cost of holding real funds against the cardholder's limit until you capture or void.

## Choosing What to Use

These methods are independent and additive - pick whichever combination fits your flow:

* **Low-friction capture, charge immediately after:** Luhn (default) + card brand limitation is often enough; the charge itself will fail if the card can't be processed.
* **Card kept on file for a future charge (e.g. booking held for a future stay):** add card expiration threshold and either gateway-level verification or a small-amount PreAuth, so you find out the card is good well before the actual charge date.
* **Liability shift needed:** 3D Secure is the only method here that provides it - combine with any of the others as needed.
* **Fraud screening:** risk assessment doesn't validate the card itself, so pair it with at least one of the other methods above rather than using it alone.

## Related

* [Authorize & Capture](/use-tokens/authorize-capture). The two-step PreAuth/Capture flow.
* [PSD2 and 3D Secure Implementation](/use-cases/comply-with-psd2). Full 3DS setup and flow.
* [Card Validation Errors](/reference/card-validation-errors). The specific error messages each validation check can return.