ForHosting KIT · Validation

Validate a card number

The Credit Card Validation API runs the Luhn checksum against a card number and tells you, in one call, whether the digits could ever form a real card — no card issuer contacted, no charge attempted, nothing stored. It exists for the narrow but constant problem of a customer mistyping a digit at checkout, which this catches before the form even submits to a payment processor.

● StableFree · in your browser

Run — free How it works & API

Use it from WebAPIEmailApp soonTelegram soon

What the Luhn checksum actually catches

The Luhn algorithm doubles every second digit of a card number from the right, sums the results with the untouched digits, and checks that the total is a multiple of ten; every properly issued card number is built to satisfy that arithmetic. That means a single mistyped digit, two adjacent digits swapped, or a digit dropped entirely will almost always break the checksum, which is precisely the class of error a person makes typing sixteen digits into a small mobile field. The luhn algorithm api runs that exact calculation server-side and returns a simple pass or fail, plus the detected card network based on the number's prefix and length.

What it deliberately does not do

Passing the Luhn check means the number is mathematically well-formed, nothing more — it does not confirm the card exists, is active, has funds, or belongs to the person entering it. That distinction matters: this endpoint is a fast, cheap first filter for obvious typos, not a substitute for authorization through a card network or a payment processor, and it should never be presented to a user as proof that a card is valid for charging.

The request and what's returned

Call POST /verify/card-luhn with the card number and you receive a task_id immediately; the check runs asynchronously so a checkout flow never waits on a blocking call. The response reports whether the Luhn checksum passed and, from the number's leading digits and length, which network it matches — Visa, Mastercard, Amex or others. Nothing about the card number is retained beyond the retention window, and it is never used for anything other than answering that one request. A task that fails outright is retried three times before returning a clear error, and a failed task is never billed.

A checksum older than online payments

The algorithm is named for Hans Peter Luhn, an IBM engineer who patented it in 1954, decades before it became the default check digit scheme for payment cards. It was designed to be simple enough to compute by hand or with the mechanical calculators of the era, which is exactly why it remains cheap to run at scale today: a single pass over the digits, no lookup tables, no network calls, just arithmetic. That simplicity is also its honest limit — it catches transcription errors, not fraud.

Where it belongs in a checkout flow

Because the result returns as structured JSON by webhook, teams call this the instant a card number field loses focus, showing an inline correction prompt before the customer ever reaches the payment step — far cheaper than a decline from the processor. Access requires prepaid balance, which keeps the endpoint fast and abuse-free, and each check is a flat published $0.002 with no invented credits, no card data stored, and nothing recycled into training data.

What you can do with it

Inline checkout validation

An e-commerce checkout runs the Luhn check the moment the card number field loses focus, flagging an obvious typo before the customer reaches the payment step.

Pre-authorization filtering

A payment gateway screens card numbers with a quick Luhn check before sending them on to authorization, avoiding a processor decline fee on a number that was never going to be valid.

Manual order entry

A call-center order system validates a card number as an agent types it from a phone call, catching a mis-heard or mistyped digit immediately instead of after submission.

Form-builder card field component

A form-building platform offers Luhn validation as a built-in field type, giving customers real-time feedback without shipping a checksum library themselves.

FAQ

How do I validate a credit card number with an API?

Send POST /verify/card-luhn with the card number. The luhn algorithm api returns a task_id immediately and delivers the checksum result to your webhook or a signed link once the check completes.

Does a passing Luhn check mean the card is valid for charging?

No. It means the digits satisfy the Luhn checksum mathematically. It does not confirm the card exists, is active, or has available funds — that requires actual authorization through a card network.

Is card number validation free?

The tool above runs free in your browser. The API is paid — each call draws from your prepaid ForHosting KIT balance: top up from $10.00 (it never expires), pay each request's published price, and a call with no balance returns HTTP 402. No subscription, no tokens, and a failed task is never charged.

Does it store the card numbers I send?

No. Card numbers are used only to compute the checksum and are deleted once the retention window closes; nothing is retained for longer, and nothing is ever used for training.

Which card networks does it detect?

The endpoint identifies major networks such as Visa, Mastercard and American Express from the number's prefix and length, alongside the Luhn pass/fail result.

Can I validate many card numbers in bulk?

Yes. Submit each number as its own POST and the tasks run in parallel; every request is billed independently and a failed task is retried and never charged.

Why do payment forms need Luhn validation if the processor checks anyway?

Catching a typo before submission avoids an unnecessary authorization attempt and its associated decline fee, and gives the customer an immediate, specific correction instead of a generic payment error.

How are results delivered?

Either a signed webhook posted to your server the moment the check finishes, which we recommend, or a signed link valid for 24 hours you can fetch on your own schedule.

For developers — API access

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

API endpoint

POSThttps://api.kit.forhosting.com/verify/card-luhn

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, and soon from our app, email and Telegram.

Call it from your stack

curl -X POST https://api.kit.forhosting.com/verify/card-luhn \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d &#39;{"items":["valor-1","valor-2"]}'

const res = await fetch("https://api.kit.forhosting.com/verify/card-luhn", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "items": [
      "valor-1",
      "valor-2"
    ]
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/verify/card-luhn",
    headers={"Authorization": f"Bearer {os.environ[&#39;KIT_KEY']}"},
    json={
    "items": [
        "valor-1",
        "valor-2"
    ]
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/verify/card-luhn", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => &#39;{"items":["valor-1","valor-2"]}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"items":["valor-1","valor-2"]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/verify/card-luhn", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Example request

{
  "items": [
    "valor-1",
    "valor-2"
  ]
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "verify.card_luhn",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Pricing

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

Errors

HTTP	Code	Meaning
`401`	`unauthorized`	Missing or invalid API key.
`402`	`insufficient_balance`	Your balance doesn't cover the task price.
`404`	`unknown_type`	That task type doesn't exist.
`429`	`rate_limited`	Too many requests. Use the webhook instead of polling.

Read the full KIT documentation →

Run — free