API to check card

You need to validate a payment card fast, ideally before charging it or routing the transaction. By the end of this guide, you’ll have a working call that checks a card’s BIN (first 6 digits) and returns brand, type, level, issuer, and country using a single Finance API on Zyla API Hub—ready to paste into your integration today.

What this API does and when to use it

The Card Checker API verifies a 6-digit BIN and returns card metadata such as brand (e.g., MASTERCARD), type (CREDIT/DEBIT), level (e.g., GOLD), issuer name, and issuer country. Applications use this to:

Reject unsupported card brands or types before authorization.
Route transactions to the right processor based on issuer country.
Pre-fill issuer info for customer support or compliance checks.
Enhance fraud checks by validating the BIN is legitimate.

Zyla API Hub centralizes thousands of Finance & Payments APIs under one account, one API key, and one subscription model. You can manage your access and usage across services from your developer dashboard on zylalabs.com.

Getting started on Zyla API Hub

To integrate quickly:

Open the Card Checker API page on Zyla: Start 7-day trial on Card Checker API.
Click Subscribe (or Start Free Trial when available). For this API, the first API offers a 7-day trial or 50 requests.
Copy your API key from your dashboard. Authentication is via HTTP header: Authorization: Bearer YOUR_API_KEY.

Billing is subscription + quota (not pay-per-call). There is no Free Plan. For current access options and pricing, check the API page on Zyla.

Endpoint you’ll call

The Card Checker API provides one simple endpoint that validates a BIN and returns card details. All requests are GET and authenticated with your bearer token.

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

What it does: Validates the supplied BIN and returns a JSON payload containing validation status and card metadata (brand, type, level, issuer, and country).

cURL you can paste and run

Replace YOUR_API_KEY with the key from your Zyla dashboard and run this in your terminal:

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

Official example 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"
    }
}

Fields you’ll typically use:

status: HTTP-like status code returned in the payload (200 indicates success).
success: boolean success indicator for the API operation.
isValid: whether the BIN is recognized as valid.
message: a human-readable validation result.
data.bin_iin: normalized BIN/IIN returned by the API.
data.card_brand: card network (e.g., MASTERCARD, VISA, etc.).
data.card_type: CREDIT/DEBIT (useful for routing or fee calculations).
data.card_level: e.g., GOLD, PLATINUM (sometimes used for benefits logic).
data.issuer_name_bank: issuing bank name.
data.issuer_bank_phone: issuer phone (for support workflows).
data.iso_country_name / data.iso_country_code: issuer country (e.g., TR for Turkey).

Python example: validate a BIN and branch logic

This example calls the same endpoint and uses the response fields to allow only MASTERCARD credit cards issued in a specific country. Adjust logic to your needs.

import os
import requests

API_KEY = os.getenv("ZYLA_API_KEY", "YOUR_API_KEY")
BIN = "444444" # first 6 digits of the card

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=10)
resp.raise_for_status()
data = resp.json()

if not data.get("success"):
raise RuntimeError(f"Card check failed: {data}")

if not data.get("isValid"):
print("BIN is not valid. Block or fall back.")
else:
meta = data.get("data", {})
brand = meta.get("card_brand")
ctype = meta.get("card_type")
country = meta.get("iso_country_code")
issuer = meta.get("issuer_name_bank")

print(f"BIN valid. Brand={brand}, Type={ctype}, Issuer={issuer}, Country={country}")

# Example policy: accept only Mastercard credit cards from TR
if brand == "MASTERCARD" and ctype == "CREDIT" and country == "TR":
print("Proceed with authorization flow.")
else:
print("Route differently or decline based on business rules.")

Practical integration notes that save time

BIN length: Only the first 6 digits are required (the endpoint expects a 6-digit number).
When to call: Run the check as early as you can after collecting card digits, before submitting an authorization to your PSP.
Caching: BIN-to-metadata mappings change infrequently. Cache successful responses (e.g., 24 hours to 7 days) to reduce latency and quota usage, and invalidate by BIN.
Privacy: You never send full PANs to this API—only the BIN. This reduces scope for sensitive data handling in your service.
Timeouts and retries: Use a sane client timeout (e.g., 5–10s). For transient network issues, a single retry with jitter is usually enough before falling back to a default flow.
Quotas: This API runs on a subscription + quota model (not pay-per-call). Monitor your usage in your Zyla dashboard and batch or cache to stay within plan limits.
Failure handling: If success is false or the request fails, decide whether to allow a best-effort authorization or require a supported network/type. Log the payload for audit.
Auditing: Persist the BIN and the response data fields you rely on (brand, type, issuer, country) alongside your payment attempt record for traceability.

End-to-end flow example

Customer enters card number on your checkout form.
Your frontend extracts the first six digits (BIN) and sends it to your backend over TLS.
Your backend calls the Card Checker API with that BIN.
If isValid is true, use card_brand, card_type, and iso_country_code to choose a processor route or enforce policy (e.g., only CREDIT allowed).
Cache the BIN result. Continue with authorization or 3DS flows accordingly.

Use cases you can ship this week

Card acceptance gating: Block unsupported brands or types early to reduce gateway declines downstream.
Geo-based routing: Send transactions to a processor optimized for the issuer’s country using iso_country_code.
Fee computation: Differentiate fees based on card_type or card_level (e.g., GOLD/PLATINUM) in your pricing logic.
Support tooling: Show issuer_name_bank and phone to agents to speed up escalations.
Risk rules: Combine BIN validity with device, IP, and velocity checks to raise or lower friction.

Working with the Zyla MCP endpoint from AI agents

If you use AI coding environments or agents (e.g., Claude Code, Cursor, Windsurf), you can call Zyla APIs through the MCP bridge. Configure your client to connect to the Zyla MCP endpoint and supply your API key. Learn more here: MCP. From there, the agent can invoke the same Check card endpoint with the bin parameter and your bearer token under the hood.

This lets you prototype prompts like “Validate BIN 444444 and tell me the issuer’s country” and wire the result directly into your code generation or runbooks—without leaving your IDE.

Testing checklist

Happy path: A known valid BIN returns success=true and isValid=true with complete data fields.
Invalid input: Non-numeric or wrong-length input is rejected or returns isValid=false (handle gracefully in your UI).
Policy branching: Confirm your brand/type/country rules reflect correctly in acceptance and routing outcomes.
Caching: Verify repeated checks for the same BIN hit cache and reduce outbound calls.
Observability: Log the status, isValid, and key data fields; add metrics for cache hit rate and API errors.

Reference: Endpoint summary

Check card (GET): https://zylalabs.com/api/2333/card-checker-api/2243/check-card
- Required param: bin (number)
- Auth: Authorization: Bearer YOUR_API_KEY
- Returns: status, success, isValid, message, and data with BIN/IIN metadata (brand, type, level, issuer, country)

Why Zyla API Hub for Finance integrations

With more than 10,000 public APIs accessible under one account and one key, Zyla reduces overhead for teams shipping multiple integrations. You can subscribe to the Card Checker API and layer it with other Finance & Payments tools as your stack evolves, all from your Zyla dashboard on zylalabs.com.

FAQ

Can I validate a complete PAN or only the BIN?
This endpoint validates a 6-digit BIN only. Do not send full PANs. Use your payment gateway for PAN-level validation and authorization.

Which header do I use for authentication?
Send Authorization: Bearer YOUR_API_KEY with every request.

What happens if the BIN is not valid?
The response will indicate isValid as false (and success may still be true if the call executed). Use that signal to adjust your flow, e.g., block the card or request an alternative payment method.

How many requests can I make?
Zyla uses subscription + quota (not pay-per-call). For the first API, there is a 7-day trial or 50 requests. Check the API page for current limits and pricing.

Can I call this API from an AI agent?
Yes. Connect your agent to the Zyla MCP endpoint and authenticate with your API key. The agent can invoke the Check card endpoint with the bin parameter.

Ship your integration

Validate BINs, route transactions smartly, and reduce preventable declines with one call. Start here and get your key: Start 7-day trial on Card Checker API. Once subscribed, use the GET endpoint above with your bearer token and ship your Finance workflow this week.