How to Use Card Checker API

Your checkout needs to flag bad BINs before you even touch payment rails. By the end of this guide you’ll validate BINs and instantly read card brand, type, level, issuer, and country using a single HTTP GET to the Card Checker API on Zyla API Hub—ready to paste into your backend today.

What this API gives you

The Card Checker API returns validation for a card BIN (Bank Identification Number; the first 6 digits) and enrichment fields you can immediately use for routing, fraud screening, and UX:

Illustration: How to Use Card Checker API

isValid and message to confirm whether the provided BIN is recognized
card_brand (e.g., MASTERCARD), card_type (CREDIT/DEBIT), and card_level (e.g., GOLD)
issuer_name_bank, issuer_bank_phone, issuer_bank_website
iso_country_name and iso_country_code

It’s a single endpoint with a single required parameter, designed for quick integration in finance flows such as checkout, PSP routing, BIN-based rules, and issuer-specific customer messaging.

Getting started on Zyla API Hub

Zyla API Hub aggregates more than 10,000 public APIs under one account, one API key, and a subscription + quota model. To start using this finance API:

Open the Card Checker API page and subscribe. There’s a 7-day trial available on the listing. Check the API page for current access options and pricing.
Copy your API key.
Call the endpoint with the Authorization: Bearer YOUR_API_KEY header.

Start 7-day trial on Card Checker API

Endpoint overview

The Card Checker API has one endpoint:

Method: GET
URL: https://zylalabs.com/api/2333/card-checker-api/2243/check-card
Required query parameter:
- bin (number): a 6-digit BIN. Example: 444444
Auth: Authorization: Bearer YOUR_API_KEY

On success, the response includes a top-level status, success, isValid, message, and a data object with issuer and card attributes.

cURL you can run now

Replace YOUR_API_KEY with your key from Zyla API Hub and run:

curl -s -X GET "https://zylalabs.com/api/2333/card-checker-api/2243/check-card?bin=444444" \
  -H "Authorization: Bearer YOUR_API_KEY"

Official sample response

{
    "status": 200,
    "success": true,
    "isValid": true,
    "message": "The BIN number is valid.",
    "data": {
        "bin_iin": "557829",
        "card_brand": "MASTERCARD",
        "card_type": "CREDIT",
        "card_level": "GOLD",
        "issuer_name_bank": "AKBANK T.A.S.",
        "issuer_bank_website": "------",
        "issuer_bank_phone": "4442525",
        "iso_country_name": "TURKEY",
        "iso_country_code": "TR"
    }
}

Field notes you’ll actually use:

isValid and message: quick validation gate before further processing
data.card_brand / data.card_type / data.card_level: routing rules, UX badges, fee logic
data.issuer_name_bank and data.issuer_bank_phone: issuer-aware support flows
data.iso_country_code / data.iso_country_name: regional logic, regulatory checks, SCA prompts

Python example (requests)

This example calls the same endpoint, checks validity, and branches on brand/type for routing logic.

import os
import requests

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

url = "https://zylalabs.com/api/2333/card-checker-api/2243/check-card"
params = {"bin": BIN}
headers = {"Authorization": f"Bearer {API_KEY}"}

resp = requests.get(url, params=params, headers=headers, timeout=15)
resp.raise_for_status()
data = resp.json()

# Basic guardrails
if not data.get("success"):
raise RuntimeError(f"Lookup failed: {data}")

if not data.get("isValid"):
print(f"BIN {BIN} is not valid: {data.get('message')}")
else:
card = data.get("data", {})
brand = card.get("card_brand")
ctype = card.get("card_type")
level = card.get("card_level")
issuer = card.get("issuer_name_bank")
country = card.get("iso_country_code")

print(f"BIN {BIN} is valid: {brand} {ctype} {level} issued by {issuer} ({country})")

# Example routing logic
if brand == "MASTERCARD" and ctype == "CREDIT":
# Route to a specific processor or apply fees/limits
pass

# Example UX logic
if country == "TR":
# Localized copy or SCA hints for Turkish cards
pass

Implementation tips that save time

Server-side calls only. Never expose your API key in client code.
Cache BIN results for a short period to cut latency at checkout. BIN data changes infrequently, but always design for revalidation.
Validate input length: accept only 6 numeric digits for bin before calling the API.
Use isValid as the first branch: if false, fail fast and prompt the user to recheck their card number.
Idempotency: This GET request is safe to retry on transient network issues.

Real-world finance use cases

Checkout pre-validation: Detect obviously incorrect BINs before you initialize a payment intent.
Processor routing: Route by card_brand or card_type to optimize authorization rates or fees.
Risk and compliance: Use iso_country_code to trigger step-up authentication or deny risky corridors as policy requires.
Issuer-aware UX: Display issuer_name_bank or provide issuer_bank_phone in support flows.
Payment method controls: Block unsupported combinations (e.g., corporate CREDIT on certain product lines) using card_level where applicable.

Calling it from AI agents via MCP

If you prefer to wire this into AI development tools (Claude Code, Cursor, Windsurf, or any MCP-compatible client), point the client to the Zyla MCP endpoint and use your Zyla API key. Your agent can then invoke the same Card Checker API capability behind the scenes.

MCP endpoint: MCP
API key: pass your Zyla API key as configured by your MCP client
Call semantics: perform the same GET request to the check-card path with the bin parameter

This keeps your workflow in the IDE while still using the same Authorization: Bearer YOUR_API_KEY header and the exact request URL shown above.

Testing checklist

Return shape: Confirm presence of status, success, isValid, message, and data.* fields before using values.
Input validation: Reject non-numeric or non-6-digit BINs before hitting the network.
Timeouts: Set a sane HTTP client timeout (e.g., 10–15s) and retry only on idempotent GETs.
Observability: Log the top-level status and isValid for triage; avoid logging full PANs—only the first 6 digits for BIN checks.
Caching: Cache by BIN; invalidate on deployment or after a time window that fits your risk posture.

FAQ

What parameter does the endpoint require?
A single query parameter: bin (6-digit number). Example: bin=444444.

What’s the exact endpoint and method?
GET https://zylalabs.com/api/2333/card-checker-api/2243/check-card

How do I authenticate?
Send Authorization: Bearer YOUR_API_KEY in the request header. Get your key from the Zyla API Hub subscription page for this API.

What fields are returned?
Top-level status, success, isValid, message, and a data object with bin_iin, card_brand, card_type, card_level, issuer_name_bank, issuer_bank_website, issuer_bank_phone, iso_country_name, and iso_country_code.

Is there a free plan?
There is no free plan. A 7-day trial is available on the listing; check the API page for current access options and pricing.

Ship your BIN validation today. Subscribe on the Card Checker API listing, grab your key, and drop the single GET call into your checkout or risk pipeline: Start 7-day trial on Card Checker API. Then expand to the rest of the finance catalog on Zyla API Hub as your roadmap grows.