Skip to main content
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

​
Luhn Algorithm

Checks that the card number passes the Luhn checksum - 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), 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 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 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 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 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 for the full flow, and 3DS Auth Management for how the result is stored and reused.
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.

​
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. 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 page for the response fields and what each risk level means.
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.

​
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; 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 for a small amount (e.g. 0.50–0.50–1), immediately followed by a Void 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.
Whether a PreAuth can be voided (versus left to expire) is gateway-specific - check Gateway-Specific Guidance for your PSP before relying on immediate release.

​
Full-Amount PreAuth

The standard 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.