Working with Card Checker API

You need to validate and enrich card BINs this week so you can flag risky payments, route transactions correctly, or prefill issuer data in your finance stack. By the end of this guide, you’ll make authenticated requests to the Card Checker API on Zyla API Hub, interpret the response reliably, and wire it into a production checkout or risk workflow.

What the Card Checker API does

The Card Checker API verifies a card’s BIN (Bank Identification Number, the first 6 digits of a card number) and returns issuer and network details. With a single GET call, you’ll know if the BIN is valid and retrieve structured fields including card brand, type, level, issuer name, issuer phone, and ISO country information. Teams use this to:

• Validate BINs at checkout before attempting authorization.
• Identify card brands (e.g., MASTERCARD) and types (e.g., CREDIT) for routing and compliance logic.
• Drive risk scoring with issuer country signals (e.g., match against billing country).
• Power support tooling that quickly shows which bank issued a card.

Getting started on Zyla API Hub

The Card Checker API is available on Zyla API Hub, which hosts more than 10,000 public APIs across finance and related categories. You subscribe once, receive a single API key, and call the ready-to-use endpoint immediately. The first API you try includes a 7-day trial or 50 requests, with subscription + quota (not pay-per-call). Check the API page for current access options and pricing.

1. Open the API listing and subscribe: Start 7-day trial on Card Checker API.
2. Copy your API key.
3. Use Authorization: Bearer YOUR_API_KEY on every request to the endpoint documented below.

Endpoint reference

Check card

Method: GET

URL: https://zylalabs.com/api/2333/card-checker-api/2243/check-card

Description: Validates a 6-digit BIN and returns issuer and network metadata.

Required query parameter:

• bin (number): The 6-digit BIN. Example: 444444

cURL example (copy/paste)

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

What you’ll typically use from this payload:

• isValid: Boolean flag indicating the BIN is recognized and valid.
• data.bin_iin: The BIN/IIN returned for the lookup (string).
• data.card_brand: Network/brand (e.g., MASTERCARD).
• data.card_type: Card product category (e.g., CREDIT).
• data.card_level: Level/tier (e.g., GOLD) if available.
• data.issuer_name_bank: Issuing bank name.
• data.issuer_bank_phone: Issuer contact phone.
• data.iso_country_name / iso_country_code: Issuer country (name and ISO alpha-2 code).

Python example

This sample calls the endpoint, checks validity, and prints fields you can use for checkout rules or risk scoring. Replace YOUR_API_KEY with your key.

import requests

API_KEY = "YOUR_API_KEY"
BASE_URL = "https://zylalabs.com/api/2333/card-checker-api/2243/check-card"

def fetch_bin_info(bin_number: str) -> dict:
headers = {
"Authorization": f"Bearer {API_KEY}"
}
params = {
"bin": bin_number
}
resp = requests.get(BASE_URL, headers=headers, params=params, timeout=10)
# If the Hub returns non-200 HTTP, raise for visibility in logs/alerts.
resp.raise_for_status()
return resp.json()

def main():
# Example BIN
bin_number = "444444"
data = fetch_bin_info(bin_number)

# Minimal checks you should perform before using fields
if not data.get("success"):
print("Lookup not successful:", data)
return

print("BIN valid:", data.get("isValid"))
info = data.get("data", {}) or {}

print("Resolved BIN/IIN:", info.get("bin_iin"))
print("Brand:", info.get("card_brand"))
print("Type:", info.get("card_type"))
print("Level:", info.get("card_level"))
print("Issuer:", info.get("issuer_name_bank"))
print("Issuer phone:", info.get("issuer_bank_phone"))
print("Issuer country:", info.get("iso_country_name"), "(", info.get("iso_country_code"), ")")

# Example: lightweight risk rule
# if info.get("iso_country_code") not in {"US", "CA", "GB"}:
# flag_reason = "issuer_country_out_of_region"

if __name__ == "__main__":
main()

Implementation notes that save time

• Authorization: Always send Authorization: Bearer YOUR_API_KEY exactly as shown. Do not place the key in query params.
• BIN format: The endpoint expects a 6-digit BIN in the bin query parameter. Strip spaces, non-digits, and avoid sending full PANs; only the BIN is required.
• Caching: BIN-to-issuer mappings are relatively stable. Cache results keyed by BIN in your system to reduce repeat calls and latency. Invalidate when you observe issuer changes in your logs.
• Graceful fallbacks: If success is false or isValid is false, keep your checkout responsive. For example, you can default to generic card handling and proceed to authorization while increasing monitoring.
• Logging: Log data.bin_iin and issuer fields for observability. Avoid logging full card numbers; you should only ever handle the BIN for this lookup.
• Testing: Use a mix of common BINs across brands and regions to verify that your downstream routing or risk logic handles different combinations of brand/type/level/country.

Common finance workflows you can ship with this API

• Checkout pre-validation: Call the API after formatting card input and before creating a payment intent. Reject obviously invalid BINs early or require additional verification for specific issuers.
• Issuer-country matching: Compare iso_country_code with the billing or IP country to trigger step-up authentication when they don’t match.
• Network routing hints: Direct MASTERCARD vs. other brands to different acquirers or apply tailored 3DS policies per card_type.
• Customer support enrichment: When a charge fails with a generic decline, show issuer_name_bank and issuer_bank_phone in the agent console to speed up resolution.
• Analytics and monitoring: Aggregate transactions by issuer_name_bank or iso_country_code to track performance and chargeback patterns.

Error handling and resilience

The example response demonstrates a successful lookup with status: 200 and success: true. In your integration:

• Check HTTP status codes and handle non-2xx responses appropriately (retry with backoff if needed, depending on your job queue or checkout strategy).
• Inspect success and isValid before using data fields. If either check fails, continue with conservative defaults.
• Validate that data exists before reading nested fields to avoid None/KeyError issues.

Security and compliance pointers

• Only send the BIN (6 digits). Do not transmit full PANs to this service.
• Store your API key in server-side secrets (e.g., environment variables or a secrets manager). Do not expose it in client-side code.
• Log minimal necessary details and avoid PII in logs. BIN itself is not sufficient to identify a cardholder, but combine it cautiously with other attributes in your system.

Calling the API from AI agents via MCP

You can invoke APIs on Zyla through an MCP-compatible client using the MCP endpoint. Point your MCP client to the following URL and include your Zyla API key:

MCP

From there, your AI agent can call the same Card Checker API endpoint as shown above using the Authorization header. Use the agent to automate data enrichment (e.g., BIN validation during triage of suspicious orders) while retaining the exact HTTP method, URL, and parameters documented in this post.

Putting it all together

In a typical backend flow:

1. Client collects card input and sends only the BIN (first 6 digits) to your server.
2. Your server requests GET /check-card with bin=XXXXXX and Authorization: Bearer YOUR_API_KEY.
3. If success and isValid are true, use data.card_brand, data.card_type, and issuer country to apply routing or risk rules.
4. Cache the response by BIN to avoid repeated lookups.
5. Proceed with your payment attempt or escalate to 3DS/challenge based on the rules you defined.

Troubleshooting checklist

• 401 or similar auth issue: Confirm your Authorization header is exactly Authorization: Bearer YOUR_API_KEY and that the key is active.
• No fields in data: Ensure the bin parameter is present and exactly 6 digits.
• Unexpected errors: Log the full JSON body and relevant headers (excluding secrets) for diagnosis; retry responsibly from a queue to avoid blocking checkout.
• Different issuer than expected: Issuer databases evolve; refresh your cache and recheck the latest response for the BIN.

FAQ

What does a valid BIN look like?
A valid BIN is exactly 6 digits. Strip any spaces or separators from user input before sending bin.

Do I need to send a full card number?
No. Send only the 6-digit BIN in the bin query parameter.

How do I authenticate?
Include an Authorization header with the value Bearer YOUR_API_KEY on every request.

How is billing handled?
APIs on Zyla use a subscription + quota model (not pay-per-call). The first API you try includes a 7-day trial or 50 requests. Check the API page for current access options and pricing.

Can I call this from an AI agent?
Yes. Use an MCP-compatible client pointing to the MCP endpoint and ensure the Authorization header is set when your agent makes the GET call.

Ready to validate and enrich card BINs in your finance stack? Subscribe and get your key on the Card Checker API listing: Start 7-day trial on Card Checker API. Paste the cURL above into your terminal, confirm isValid, and ship your integration.