How to Use Credit Card Validator - BIN Checker API

You have credit-card data flowing into your checkout, KYC flow, or risk system, and you need a fast way to validate the BIN (first 6 digits) and identify brand, type, and issuer metadata—this week, not next quarter. By the end of this article, you’ll be able to validate a BIN and retrieve card brand, type, and issuer information using the Credit Card Validator - BIN Checker API on Zyla API Hub—complete with copy-paste cURL and Python.

What this API does and why it matters

The Credit Card Validator - BIN Checker API returns metadata for a given BIN (the first 6 digits of a card number). With a single GET request, you’ll learn if the BIN is valid and get data such as:

• Card brand (e.g., AMERICAN EXPRESS)
• Card type (e.g., CREDIT)
• Card level when available
• Issuer data (when available)
• Country information (when available)

Teams use BIN checks to pre-validate inputs, auto-select card brand UI elements, apply additional fraud rules, and route payments. Since the request uses only the first 6 digits, it reduces PCI scope compared to sending full PANs.

This API is part of the Finance & Payments category on Zyla API Hub, a marketplace with more than 10,000 public APIs under one account, one API key, and one subscription model. You can manage your usage in one place and call multiple APIs as your stack grows.

Getting started on Zyla API Hub

To try the Credit Card Validator - BIN Checker API:

1. Open the API listing: Start 7-day trial on Credit Card Validator - BIN Checker API.
2. Click Subscribe or Start Free Trial (when available). This API typically supports a 7-day trial to help you build and test quickly. Check the API page for current access options and pricing.
3. Copy your API key from your dashboard.

All requests use a Bearer token in the Authorization header. Billing is subscription + quota (not pay-per-call). There’s no Free Plan; use the trial to evaluate. Keep your key secure; don’t embed it in public front-end code.

Endpoint overview

This API exposes one GET endpoint for BIN validation and metadata:

• Method: GET
• URL: https://zylalabs.com/api/40/credit-card-validator-bin-checker-api/1885/bin-checker
• Query parameter:
  • bin (string, required): First 6 digits of the card (BIN/IIN). Example: 346350
• Auth: Authorization: Bearer YOUR_API_KEY

High-level behavior: You send a BIN, and the API responds with a status code, a success flag, a boolean isValid field, a message, and a data object containing card metadata. If some attributes are unavailable, the response will reflect that with placeholders or nulls.

cURL you can copy/paste

Here is a complete, working example against the live endpoint. Replace YOUR_API_KEY with your key from Zyla API Hub:

curl -s -X GET "https://zylalabs.com/api/40/credit-card-validator-bin-checker-api/1885/bin-checker?bin=346350" \
-H "Authorization: Bearer YOUR_API_KEY"

Official example response

This is the official sample payload returned by the endpoint when querying the BIN 346350:

{
"status": 200,
"success": true,
"isValid": true,
"message": "The BIN number is valid.",
"data": {
"bin_iin": "346350",
"card_brand": "AMERICAN EXPRESS",
"card_type": "CREDIT",
"card_level": "------",
"issuer_name_bank": "------",
"issuer_bank_website": "API Only",
"issuer_bank_phone": "API Only",
"iso_country_name": null,
"iso_country_code": null
}
}

Field notes you’ll likely use:

• status: Numeric HTTP-like status code returned by the service.
• success: Indicates the request was processed successfully.
• isValid: True if the BIN exists and is recognized.
• message: Human-readable validation summary.
• data: Card metadata, where any missing or restricted info may be returned as placeholders or null.

Python example: calling the endpoint and parsing fields

This script sends one BIN, checks validity, and prints selected attributes for routing or display logic.

import os
import requests

API_KEY = os.getenv("ZYLA_API_KEY", "YOUR_API_KEY")
BIN = "346350"

url = "https://zylalabs.com/api/40/credit-card-validator-bin-checker-api/1885/bin-checker"
params = {"bin": BIN}
headers = {
"Authorization": f"Bearer {API_KEY}"
}

resp = requests.get(url, params=params, headers=headers, timeout=10)
resp.raise_for_status()

data = resp.json()

# Basic sanity checks
if not data.get("success"):
raise RuntimeError(f"API reported failure: {data}")

# Use isValid to decide next steps
if data.get("isValid"):
meta = data.get("data", {})
brand = meta.get("card_brand")
ctype = meta.get("card_type")
level = meta.get("card_level")
issuer = meta.get("issuer_name_bank")
country = meta.get("iso_country_name")
print(f"BIN {BIN} is valid.")
print(f"- Brand: {brand}")
print(f"- Type: {ctype}")
print(f"- Level: {level}")
print(f"- Issuer: {issuer}")
print(f"- Country: {country}")
else:
print(f"BIN {BIN} is not valid. Message: {data.get('message')}")

Additional response examples you can test against

When you integrate, keep the JSON shape stable in your parser. Here are additional complete examples using the same official payload so you can verify logging, persistence, and test-paths consistently:

Example for logging pipelines

{
"status": 200,
"success": true,
"isValid": true,
"message": "The BIN number is valid.",
"data": {
"bin_iin": "346350",
"card_brand": "AMERICAN EXPRESS",
"card_type": "CREDIT",
"card_level": "------",
"issuer_name_bank": "------",
"issuer_bank_website": "API Only",
"issuer_bank_phone": "API Only",
"iso_country_name": null,
"iso_country_code": null
}
}

Example for storage (e.g., Redis/DB record)

{
"status": 200,
"success": true,
"isValid": true,
"message": "The BIN number is valid.",
"data": {
"bin_iin": "346350",
"card_brand": "AMERICAN EXPRESS",
"card_type": "CREDIT",
"card_level": "------",
"issuer_name_bank": "------",
"issuer_bank_website": "API Only",
"issuer_bank_phone": "API Only",
"iso_country_name": null,
"iso_country_code": null
}
}

Example for downstream enrichment services

{
"status": 200,
"success": true,
"isValid": true,
"message": "The BIN number is valid.",
"data": {
"bin_iin": "346350",
"card_brand": "AMERICAN EXPRESS",
"card_type": "CREDIT",
"card_level": "------",
"issuer_name_bank": "------",
"issuer_bank_website": "API Only",
"issuer_bank_phone": "API Only",
"iso_country_name": null,
"iso_country_code": null
}
}

How to wire this into your payment or risk flow

Practical patterns developers ship in production:

• Client-side UX assist: As soon as a user inputs the first 6 digits, send the BIN to your back end, call the API, and display the detected brand (e.g., AMERICAN EXPRESS) to reduce keying errors. Keep the API key server-side.
• Routing rules: Use card_type to steer transactions or apply risk thresholds. For example, handle CREDIT differently from DEBIT in downstream scoring logic.
• KYC/Fraud gates: If isValid is false, block the attempt or require step-up verification before proceeding.
• Issuer controls: If issuer data is available, apply business rules by bank or country. Be defensive: issuer fields may be restricted or null.
• Caching: Cache recent BIN lookups for hours or days (based on your risk tolerance) to reduce latency and quota use. BIN metadata changes infrequently, but always allow refresh logic.

Validation, security, and PCI considerations

Only send the BIN (first 6 digits) to this endpoint. Do not transmit or store the full PAN in your logs. Keep Authorization headers out of logs as well. Build a small server-side adapter that accepts the BIN from your client, calls this API, and returns only what you need to render. If you store results, store only the metadata you need and sanitize null or placeholder values.

Behavior you should design around

• Restricted fields: Some issuer fields may be “API Only” or masked. Do not assume a non-empty issuer name/website/phone.
• Null handling: Country fields can be null; make sure your code tolerates that without throwing.
• Message and status: Use both isValid and status to construct user-facing messages or logs.
• Retries and timeouts: Set reasonable timeouts (e.g., 5–10 seconds) and retry only on network timeouts, not on 4xx validation outcomes.
• Idempotence: BIN checks are read-only; you can safely retry network failures with backoff.

End-to-end example: middleware pattern

Here’s a pragmatic flow you can replicate:

1. Frontend sends first 6 digits (e.g., 346350) to your server via HTTPS.
2. Your server calls the BIN Checker endpoint with Authorization: Bearer YOUR_API_KEY.
3. If success and isValid are true, respond to the client with brand and type so UI reflects “AMERICAN EXPRESS · CREDIT”.
4. If not valid, prompt the user to verify the input before allowing any card submission step.
5. Optionally cache by BIN for a short TTL to reduce round-trips on repeat entries.

Field-by-field mapping to typical checkout UI

• Brand badge: Use data.card_brand (e.g., “AMERICAN EXPRESS”).
• Card type hint: Use data.card_type (e.g., “CREDIT”).
• Issuer label: Use data.issuer_name_bank if it’s not a placeholder; otherwise omit.
• Country flag or text: Use data.iso_country_name when available.

Always guard against placeholders (e.g., “------”) or null before rendering.

Testing checklist

• Send a known BIN and assert isValid is boolean.
• Assert presence of data.bin_iin matches the queried BIN.
• Verify brand and type fields are strings and safe to render.
• Ensure null or placeholder values do not break your UI or risk engine.
• Confirm Authorization header is present in all calls and never logged.

Working with AI agents via MCP

If you automate workflows with AI coding tools (e.g., Claude Code, Cursor, Windsurf), you can call Zyla APIs through the Model Context Protocol (MCP). Configure your MCP-compatible client to use the Zyla MCP endpoint and provide your API key. See the integration details here: MCP. This lets an agent trigger the same BIN check workflow, while your server still controls key storage and logging. Keep prompts minimal and validate outputs before acting in payment flows.

Operational tips

• Monitoring: Track success, status, and latency per request. Alert on spikes in failures.
• Throttling: Implement client-side rate limiting and exponential backoff to be a good API citizen.
• Version control: Vendor responses can evolve; pin your parser to known fields and ignore unexpected extras.
• Data lifecycle: Set clear TTLs on cached BIN results and re-validate on significant changes to card-handling logic.

Re-using the sample response across environments

For CI, local dev, and staging, use the official sample payload below as a fixture so you can test your mappers and UI without leaking real card data. Keep a single source of truth for the shape.

{
"status": 200,
"success": true,
"isValid": true,
"message": "The BIN number is valid.",
"data": {
"bin_iin": "346350",
"card_brand": "AMERICAN EXPRESS",
"card_type": "CREDIT",
"card_level": "------",
"issuer_name_bank": "------",
"issuer_bank_website": "API Only",
"issuer_bank_phone": "API Only",
"iso_country_name": null,
"iso_country_code": null
}
}

Production readiness checklist

• Environment variables: Store YOUR_API_KEY in a secrets manager.
• Network policies: Allow outbound HTTPS to zylalabs.com for the endpoint URL.
• Time-bound retries: Retry only network errors; do not retry validation failures.
• Observability: Log request IDs and stripped responses (without secrets) for audits.
• Access control: Limit which services can call the BIN checker to reduce lateral risk.

Common pitfalls and how to avoid them

• Client-side calls with exposed keys: Always proxy via your server.
• Assuming issuer or country is always present: Handle placeholders and nulls gracefully.
• Parsing-only off message text: Use isValid and status for logic; message is for humans.
• Stale cache: Set reasonable TTLs and invalidate if you detect inconsistent metadata.

Where to go next

Browse other Finance & Payments APIs and consolidate your integrations under one account on Zyla API Hub. Keep your risk, payments, and reporting use cases in one ecosystem with a single API key and subscription.

FAQ

Does the API validate full card numbers?
No. The endpoint validates a BIN (first 6 digits) and returns associated metadata. Do not send full PANs.

What authentication is required?
Send Authorization: Bearer YOUR_API_KEY in the header of each request.

Is there a free plan?
There is no Free Plan. Check the API listing for current access. A 7-day trial is typically available to evaluate the service.

How often should I cache BIN results?
BIN metadata changes infrequently. Cache according to your risk posture and refresh schedule. Always handle nulls/placeholders upon refresh.

How do I call this from an AI agent?
Use an MCP-compatible client and point it to the Zyla MCP endpoint documented here: MCP. Keep keys in a secure store and validate outputs before acting.

Ready to ship BIN validation? Start your evaluation and get an API key on the marketplace: Start 7-day trial on Credit Card Validator - BIN Checker API.