Card Validator checks whether a card number is valid, identifies the card brand, and flags risk. It runs the Luhn checksum, detects the scheme (Visa, Mastercard, Amex and more), returns the PCI-safe BIN and last 4 digits, flags known processor test cards, and returns a composite risk score.
Try it — live request, no key required
No key required to try it. Get a key to use it in your app.
{
"status": "ok",
"error": null,
"data": {
// Card Validator response payload
}
}
About the Card Validator API
Card Validator works by validating the card number against the Luhn algorithm and the brand's prefix and length rules. It identifies the card scheme, extracts the BIN and last four digits, checks the number against a list of known published test cards, and returns a risk score summarizing how safe the number is to trust.
What people use it for
- Payment Processing
- Use the Card Validator API to validate card numbers for payment processing. Use the data to verify card information and prevent fraudulent transactions
- E-commerce Platforms
- Validate card numbers by using the Card Validator API for e-commerce platforms. Use the data to ensure secure transactions, protect customer data, and comply with regulations
- Financial Services
- Secure financial services by using the Card Validator API to validate card numbers. Use the data to verify cardholder information, prevent identity theft, and enhance data security
- Fraud Detection
- Detect fraud by using the Card Validator API to validate card numbers. Use the data to identify suspicious activities, block fraudulent accounts, and protect against scams
Ways to call it
One endpoint, many ways in — REST with JSON, XML, YAML and CSV, plus GraphQL and an MCP interface for AI agents.
- JSON
- Default REST response
- XML
- Markup format
- YAML
- Human-readable
- CSV
- Tabular export
- GraphQL
- Query language
- MCP
- For AI agents
Other ways to use Card Validator
Same data, same APIVerve account, same credit balance — one key works on all of them.
What does the Card Validator API do?
How do I authenticate Card Validator API requests?
How much does the Card Validator API cost?
How fast is the Card Validator API?
What response formats does the Card Validator API support?
What HTTP method does the Card Validator API use?
Request parameters — GET /v1/cardvalidator
Sent in the query string. Premium parameters are accepted on every plan but only take effect on plans that include them. Anything not listed here is dropped rather than passed through.
Required
| Parameter | Type | Example | Description |
|---|---|---|---|
numberRequired | string | 4900264223817524 | The card number to validate length 13-19 |
curl "https://api.apiverve.com/v1/cardvalidator?number=4900264223817524" \
-H "x-api-key: YOUR_API_KEY"Authentication
Send your key in the x-api-key header. That is the only auth step — no token exchange, and no per-endpoint scope to configure.
| Header | When | Value |
|---|---|---|
x-api-keyRequired | Every request | Your API key. Header names are case-insensitive, so X-API-Key is the same header. |
AuthorizationAlternate | Instead of the above | Bearer <key> — for clients that only expose bearer auth. Resolves to the same account and the same billing. |
A 401 means the key is missing, invalid or expired. A 403 means the key is valid but not permitted here — blocked by a key restriction or an IP allow-list. Running out of credits is a 429.
Response — GET /v1/cardvalidator
Every APIVerve endpoint returns the same three top-level keys, so one response handler covers your whole integration: status, error and data. Only data changes shape.
{
"status": "ok",
"error": null,
"data": {
"card": {
"niceType": "Visa",
"type": "visa",
"patterns": [
4
],
"gaps": [
4,
8,
12
],
"lengths": [
16,
18,
19
],
"code": {
"name": "CVV",
"size": 3
},
"matchStrength": 1
},
"brand": "Visa",
"cardNumber": "4900264223817524",
"bin": "490026",
"last4": "7524",
"isValid": true,
"isPotentiallyValid": true,
"isTestCard": false,
"riskScore": 0,
"riskLevel": "low"
}
}
Response fields
Paths are relative to data. Premium fields are absent rather than zeroed on plans that do not include them, so check for presence instead of comparing to 0.
| Field | Type | Example | Description |
|---|---|---|---|
card | object | {...} | Card identification and validation details |
niceType | string | "Visa" | Human-readable card type name like Visa |
typePremium | string | "visa" | Machine-readable card type identifier |
patternsPremium | array | [4] | Starting digit patterns for card type |
gapsPremium | array | [4, ...] | Character positions for spacing formatting |
lengthsPremium | array | [16, ...] | Valid card length values in digits |
codePremium | object | {...} | Security code specifications for card |
namePremium | string | "CVV" | Name of security code like CVV |
sizePremium | number | 3 | Number of digits in security code |
matchStrengthPremium | number | 1 | Confidence level of card type match |
brand | string | "Visa" | Human-readable card brand (e.g. Visa, Mastercard), or null if the scheme could not be identified |
cardNumber | string | "4900264223817524" | The validated card number provided |
bin | string | "490026" | The card's BIN/IIN (first 6 digits), or null if fewer than 6 digits were supplied |
last4 | string | "7524" | The last 4 digits of the card, or null if fewer than 4 digits were supplied |
isValid | boolean | true | Whether the card number is complete and passes the Luhn checksum |
isPotentiallyValid | boolean | true | Whether the number could still become valid (correct brand prefix but possibly incomplete) — useful while a user is still typing |
isTestCardPremium | boolean | false | Whether the number is a known published processor test card (Stripe, Adyen, etc.) rather than a live card |
riskScorePremium | number | 0 | Composite 0-100 risk score combining Luhn validity, test-card and scheme-recognition signals (higher is riskier) |
riskLevelPremium | string | "low" | Risk band derived from the score: low, medium or high |
Response headers
Every response carries your balance, so your own code always knows where it stands without polling anything. All four are exposed to browsers through CORS.
| Header | What it carries |
|---|---|
x-api-remaining-credits | Credits left in the current cycle |
x-api-credits-used | Credits spent in the current cycle |
x-api-max-credits | The allowance for the cycle |
x-api-version | Version of the endpoint that answered |
Errors
Read the HTTP status first, then error for the specific reason. The body names the parameter that has to change.
| Status | Meaning | What to do |
|---|---|---|
400 | Input was rejected | Read error; it names the parameter that has to change. |
401 | Key missing or invalid | Check the header name and the key value. |
403 | Key valid, but not permitted here | A key restriction or an IP allow-list — never a bad key. |
429 | Rate limited, or out of credits | Read error to tell them apart, then back off or top up. |
What a call costs — 2 credits per call
Credits are shared across every APIVerve API — one balance, one key, one bill. Failed requests never count against it, so a rejected input costs nothing.
| Plan | Per month | Credits | Card Validator calls | Per 1,000 calls |
|---|---|---|---|---|
| Free | Free | 200 | 100 | Free |
| Starter | $29.99 | 200,000 | 100,000 | $0.30 |
| Pro | $99.99 | 1,000,000 | 500,000 | $0.20 |
| Mega | $299.99 | 4,000,000 | 2,000,000 | $0.15 |
Calls are what the credits buy at this API's rate — spend them here, on any of the other APIs, or across both. Nothing is reserved per endpoint.
Call it from cURL — GET /v1/cardvalidator
No SDK to install — this is a plain HTTPS call to /v1/cardvalidator with your key in the x-api-key header. Swap in a real key and it runs as-is.
curl "https://api.apiverve.com/v1/cardvalidator" \
-H "x-api-key: YOUR_API_KEY"Resources
Also published for
Only the languages APIVerve ships a client for are listed — the rest call the endpoint directly over HTTPS.
Call it from Node.js — GET /v1/cardvalidator
Install the Node.js SDK, then call the Card Validator API with your key. The client wraps the same HTTPS request, so anything it returns is what the endpoint returns.
npm install @apiverve/cardvalidatorconst res = await fetch("https://api.apiverve.com/v1/cardvalidator", {
headers: { "x-api-key": "YOUR_API_KEY" },
});
const { data } = await res.json();
console.log(data);Resources
Also published for
Only the languages APIVerve ships a client for are listed — the rest call the endpoint directly over HTTPS.
Call it from Python — GET /v1/cardvalidator
Install the Python SDK, then call the Card Validator API with your key. The client wraps the same HTTPS request, so anything it returns is what the endpoint returns.
pip install apiverve-cardvalidatorimport requests
res = requests.get(
"https://api.apiverve.com/v1/cardvalidator",
headers={"x-api-key": "YOUR_API_KEY"},
)
print(res.json()["data"])Resources
Also published for
Only the languages APIVerve ships a client for are listed — the rest call the endpoint directly over HTTPS.
Call it from C# / .NET — GET /v1/cardvalidator
Install the C# / .NET SDK, then call the Card Validator API with your key. The client wraps the same HTTPS request, so anything it returns is what the endpoint returns.
dotnet add package APIVerve.API.CardValidatorusing var client = new HttpClient();
client.DefaultRequestHeaders.Add("x-api-key", "YOUR_API_KEY");
var json = await client.GetStringAsync("https://api.apiverve.com/v1/cardvalidator");
Console.WriteLine(json);Resources
Also published for
Only the languages APIVerve ships a client for are listed — the rest call the endpoint directly over HTTPS.
Call it from Go — GET /v1/cardvalidator
No SDK to install — this is a plain HTTPS call to /v1/cardvalidator with your key in the x-api-key header. Swap in a real key and it runs as-is.
req, _ := http.NewRequest("GET", "https://api.apiverve.com/v1/cardvalidator", nil)
req.Header.Set("x-api-key", "YOUR_API_KEY")
res, _ := http.DefaultClient.Do(req)
defer res.Body.Close()
body, _ := io.ReadAll(res.Body)
fmt.Println(string(body))Resources
Also published for
Only the languages APIVerve ships a client for are listed — the rest call the endpoint directly over HTTPS.
Call it from PHP — GET /v1/cardvalidator
No SDK to install — this is a plain HTTPS call to /v1/cardvalidator with your key in the x-api-key header. Swap in a real key and it runs as-is.
$ch = curl_init("https://api.apiverve.com/v1/cardvalidator");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
curl_setopt($ch, CURLOPT_HTTPHEADER, ["x-api-key: YOUR_API_KEY"]);
$response = curl_exec($ch);
echo $response;Resources
Also published for
Only the languages APIVerve ships a client for are listed — the rest call the endpoint directly over HTTPS.
Call it from Ruby — GET /v1/cardvalidator
No SDK to install — this is a plain HTTPS call to /v1/cardvalidator with your key in the x-api-key header. Swap in a real key and it runs as-is.
require "net/http"
uri = URI("https://api.apiverve.com/v1/cardvalidator")
req = Net::HTTP::Get.new(uri)
req["x-api-key"] = "YOUR_API_KEY"
res = Net::HTTP.start(uri.hostname, uri.port, use_ssl: true) { |h| h.request(req) }
puts res.bodyResources
Also published for
Only the languages APIVerve ships a client for are listed — the rest call the endpoint directly over HTTPS.
Zero-code embed — one snippet, no backend
Drop an interactive Card Validator form onto any page. The widget calls the API for you, so no key ever appears in your markup and there is nothing to deploy.
Changelog — Card Validator API
Every change to this endpoint, newest first. Breaking changes ship as a new version and the previous one keeps serving — response fields are added, never removed or retyped in place, so an integration written against v1 keeps working.
Entries are picked up from dated catalog snapshots, so the first one appears after the next snapshot that moves something. A period where nothing changed produces no entry — silence is a valid changelog for the Card Validator API.
Data Validation
- Card Validator
- Disposable Email Checker
- Disposable Phone Number Checker
- Email Validator
- Password Strength
- Phone Number Validator
- SEO Quick Validator
- Spam Detector
- Username Profanity
Related articles
All articles →
Add Secure Password Generation to Your AppGenerate cryptographically secure passwords via API. Tutorial with code examples for signup flows, admin panels, and password managers.Read
Preventing Fake Signups: Registration Fraud GuideLearn how to stop bots and fraudsters while maintaining conversion rates for legitimate users.Read
Email Validation Best Practices: Beyond Simple RegexEmail validation beyond regex. Learn how to verify deliverability without rejecting legitimate users.Read