Card Checker API on Zyla API Hub: First Request with curl and JSON

You need to verify a payment card’s BIN/IIN before you ship a checkout flow, block unsupported cards, or route transactions. By the end of this guide you will make a working GET request to the Card Checker API on Zyla API Hub, parse the response, and wire it into your service using curl, Python, or JavaScript—ready to deploy this week.

What the API returns and when to use it

The Card Checker API validates a BIN/IIN (the first 6 digits of a card number) and returns structured metadata about the card, including brand, type, level, issuer, issuer contact details, and country. Typical uses include:

Illustration: Card Checker API on Zyla API Hub: First Request with curl and JSON

Pre-validating BINs at checkout to show brand and issuer immediately.
Blocking unsupported brands or countries server-side before authorization.
Routing logic: e.g., send MASTERCARD CREDIT GOLD issued in TR to a specific processor.
Analytics: segment conversion by issuer or country without handling full PANs.

All calls run through Zyla API Hub, so you use one account, one API key, and a single subscription model across APIs.

Getting started on Zyla API Hub

To call the Card Checker API, go to its listing page and subscribe: Card Checker API on Zyla API Hub. Click Subscribe (or Start Free Trial if available). On Zyla, billing is subscription + quota (not pay-per-call). For your first API, you typically get a 7-day trial or 50 requests; there is no Free Plan. Check the API page for current access options and pricing. After subscribing, you’ll receive an API key. Use it in the Authorization header as:

Authorization: Bearer YOUR_API_KEY

If you don’t have an account yet, create one here: Register.

Endpoint overview

The Card Checker API exposes a single endpoint that validates a BIN and returns card and issuer details.

Name: Check card
Method: GET
URL: https://zylalabs.com/api/2333/card-checker-api/2243/check-card
Required query parameter:
- bin (number): The first 6 digits of the card. Example: 444444

High-level behavior: you provide a 6-digit BIN and receive a validation boolean, message, and a data object with brand, type, level, issuer, issuer contact info, and ISO country.

First request with curl

Make your first call with the official example. Replace YOUR_API_KEY with your token from Zyla.

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 JSON 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"
}
}

Key fields you will use:

isValid: Boolean indicating whether the BIN is recognized as valid.
card_brand, card_type, card_level: Card classification for UI and routing logic.
issuer_name_bank, issuer_bank_phone, issuer_bank_website: Issuer metadata for support workflows or compliance checks.
iso_country_name, iso_country_code: Country (ISO alpha-2 code) for geo-based logic.

Python example: validate and branch on brand

The snippet below calls the same endpoint and branches logic for a specific brand and country. It uses only the documented parameter and header.

import os
import requests

API_KEY = os.environ.get("ZYLALABS_API_KEY", "YOUR_API_KEY")
URL = "https://zylalabs.com/api/2333/card-checker-api/2243/check-card"
params = {"bin": 444444}
headers = {"Authorization": f"Bearer {API_KEY}"}

resp = requests.get(URL, params=params, headers=headers, timeout=10)
resp.raise_for_status()
data = resp.json()

if data.get("success") and data.get("isValid") and data.get("data"):
details = data["data"]
brand = details.get("card_brand")
ctype = details.get("card_type")
level = details.get("card_level")
country = details.get("iso_country_code")

print(f"Brand={brand}, Type={ctype}, Level={level}, Country={country}")

# Example routing condition
if brand == "MASTERCARD" and ctype == "CREDIT" and country == "TR":
print("Route to processor: TR-MC-CREDIT")
else:
print("Route to default processor")
else:
print("BIN not valid or lookup unsuccessful")

To test locally, export ZYLALABS_API_KEY and run the script. Timeouts, retries, and logging are left to your environment.

JavaScript example: edge or Node runtime

This example uses fetch to call the same endpoint and reads the practical fields for a checkout UI.

const API_KEY = process.env.ZYLALABS_API_KEY || "YOUR_API_KEY";
const url = "https://zylalabs.com/api/2333/card-checker-api/2243/check-card?bin=444444";

async function checkBin() {
const res = await fetch(url, {
method: "GET",
headers: { "Authorization": `Bearer ${API_KEY}` }
});
if (!res.ok) {
throw new Error(`HTTP ${res.status}`);
}
const json = await res.json();

if (json.success && json.isValid && json.data) {
const {
card_brand,
card_type,
card_level,
issuer_name_bank,
iso_country_code
} = json.data;

console.log(`Brand: ${card_brand}, Type: ${card_type}, Level: ${card_level}`);
console.log(`Issuer: ${issuer_name_bank}, Country: ${iso_country_code}`);
} else {
console.log("Invalid BIN or lookup failed");
}
}

checkBin().catch(err => {
console.error("Request failed:", err);
});

Use the same code in serverless, edge, or background jobs. Keep the API key on the server side and never expose it to browsers.

Sample responses you can store for local testing

When building UI flows and unit tests, keep a few fixture files with the official sample response so you can iterate without hitting quotas. Here is the official sample JSON again:

{
"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"
}
}

You can also duplicate the same JSON under different filenames (e.g., sample_valid_1.json, sample_valid_2.json) to exercise parser pathways consistently across services.

{
"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"
}
}

For end-to-end tests, load the same fixture and assert that your application maps brand/type/level to the expected UX or routing choice.

{
"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"
}
}

Implementation details that save time

Parameter validation: Accept strictly 6 numeric digits for the bin parameter server-side. Reject anything else before calling the API.
Caching: BIN metadata is not user-specific. Cache successful responses by BIN in your data store or edge cache to reduce round trips.
Timeouts and retries: Set an explicit timeout in your HTTP client. Use conservative retries with backoff only on safe-to-retry categories in your environment.
PCI scope: You only transmit a BIN (first 6 digits), not a full PAN. Keep the call server-side and avoid logging API keys or sensitive headers.
Internationalization: Use iso_country_code to localize UI badges, fraud rules, or routing policies.
Analytics: Persist {card_brand, card_type, card_level, iso_country_code} to group conversion, declines, and chargebacks by cohort.

Mapping the response to application logic

Here is a straightforward mapping pattern that you can adapt to your stack:

On BIN entry (first 6 digits), issue a server-side call to the endpoint with bin.
If isValid and success are both true:
- Show brand icon using card_brand (e.g., MASTERCARD).
- Select processing route using card_type and iso_country_code.
- Enable country-specific 3DS or SCA rules if applicable in your system.
If validation fails (e.g., not success or not isValid), proceed with generic UX or display a non-blocking hint.

Keep the issuer_name_bank available for support logs or dispute workflows.

Calling the API from AI agents via MCP

If you orchestrate dev tasks with MCP-compatible clients (Claude Code, Cursor, Windsurf, etc.), you can also invoke Zyla APIs through the MCP endpoint. Provide your Zyla API key as indicated by your client and call:

MCP base: https://mcp.zylalabs.com/mcp?apikey=YOUR_API_KEY

Review the MCP documentation and connect your client so that your agent can make the same GET request to the Card Checker API endpoint and return the JSON into your workspace. Learn more here: MCP.

Operational notes

Quotas and trial: Zyla uses subscription + quota. For your first API, you typically get a 7-day trial or 50 requests. No Free Plan. Check the Card Checker API page for current details.
Security: Keep Authorization headers server-side. Rotate your key if exposed.
Observability: Log request IDs in your system. Redact API keys and avoid storing full PANs in any internal logs.
Graceful degradation: If the lookup is temporarily unavailable in your environment, allow checkout to proceed with generic copy (don’t block legitimate users on a transient metadata lookup).

Another look at the official JSON for contract clarity

For team handoffs and contract-first integration, keep the official sample in your documentation to clarify field names and nesting:

{
"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"
}
}

Use these exact keys in your serializers, DTOs, or TypeScript types to avoid mismatches across services.

Troubleshooting checklist

401/403 errors in your environment: Ensure the Authorization header is present and the key is active under your Zyla account.
Unexpected JSON shape in your parser: Re-check that you’re calling the documented endpoint URL and only passing the bin parameter.
BINs that seem valid but return not isValid in your UI: Verify you’re sending exactly 6 digits and not stripping leading zeros during numeric parsing.
Intermittent network errors in serverless: Increase timeout slightly and add one retry with jitter; cache previous successful lookups.

Where to go next

Explore the Card Checker API listing for subscription options, quotas, and usage guidance: Card Checker API. Zyla centralizes auth, billing, and monitoring across thousands of APIs, so once this is live, it’s straightforward to add other payments or data enrichment APIs under the same key on Zyla.

FAQ

What is the exact URL and method for the BIN check?
GET https://zylalabs.com/api/2333/card-checker-api/2243/check-card with the bin query parameter and Authorization: Bearer YOUR_API_KEY.

Which parameters are required?
bin (number, 6 digits). Example: 444444. No other parameters are required for this endpoint.

What fields should I consume from the response?
Check success and isValid first. Then read data.card_brand, data.card_type, data.card_level, data.issuer_name_bank, data.iso_country_code (and iso_country_name if you display it).

How is billing handled?
Zyla uses subscription + quota (not pay-per-call). For your first API, you typically get a 7-day trial or 50 requests. There is no Free Plan. See the API page for current details.

Can I call this from AI coding agents?
Yes, via Zyla’s MCP endpoint at https://mcp.zylalabs.com/mcp?apikey=YOUR_API_KEY. Configure your MCP-compatible client to issue the same GET call and return the JSON.

Ready to ship your integration? Create your account, subscribe to the Card Checker API, and get your key here: Register. Then use the curl command above to verify your first BIN and wire the response into your checkout or routing logic.