使用卡片检查API

您需要在本周验证和丰富卡片BIN，以便标记风险支付、正确路由交易或在您的金融堆栈中预填发卡方数据。在本指南结束时，您将能够向Zyla API Hub上的卡片检查API发出经过身份验证的请求，可靠地解释响应，并将其连接到生产结账或风险工作流中。

卡片检查API的功能

卡片检查API验证卡片的BIN（银行识别号码，卡号的前6位数字）并返回发卡方和网络详细信息。通过一次GET调用，您将知道BIN是否有效，并检索结构化字段，包括卡片品牌、类型、级别、发卡方名称、发卡方电话和ISO国家信息。团队使用此功能来：

• 在尝试授权之前，在结账时验证BIN。
• 识别卡片品牌（例如，MASTERCARD）和类型（例如，CREDIT）以进行路由和合规逻辑。
• 通过发卡方国家信号推动风险评分（例如，与账单国家匹配）。
• 提供支持工具，快速显示哪个银行发放了卡片。

在Zyla API Hub上开始

卡片检查API可在Zyla API Hub上使用，该平台托管超过10,000个公共API，涵盖金融和相关类别。您只需订阅一次，接收一个API密钥，并立即调用可用的端点。您尝试的第一个API包括7天的试用或50个请求，订阅+配额（不是按调用计费）。请查看API页面以获取当前访问选项和定价。

1. 打开API列表并订阅： 开始7天的卡片检查API试用。
2. 复制您的API密钥。
3. 在每个请求中使用Authorization: Bearer YOUR_API_KEY，文档如下所示的端点。

端点参考

检查卡片

方法： GET

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

描述： 验证6位数字的BIN并返回发卡方和网络元数据。

必需的查询参数：

• bin（数字）：6位数字的BIN。示例：444444

cURL示例（复制/粘贴）

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

官方示例响应

{
"status": 200,
"success": true,
"isValid": true,
"message": "该BIN号码是有效的。",
"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"
}
}

您通常会使用此有效载荷中的内容：

• isValid： 布尔标志，指示BIN被识别且有效。
• data.bin_iin： 返回的查找BIN/IIN（字符串）。
• data.card_brand： 网络/品牌（例如，MASTERCARD）。
• data.card_type： 卡片产品类别（例如，CREDIT）。
• data.card_level： 级别/层次（例如，GOLD），如果可用的话。
• data.issuer_name_bank： 发卡银行名称。
• data.issuer_bank_phone： 发卡方联系电话。
• data.iso_country_name / iso_country_code： 发卡国家（名称和ISO alpha-2代码）。

Python示例

此示例调用端点，检查有效性，并打印您可以用于结账规则或风险评分的字段。将YOUR_API_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)
# 如果Hub返回非200 HTTP，记录以便在日志/警报中可见。
resp.raise_for_status()
return resp.json()

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

# 在使用字段之前应执行的最小检查
if not data.get("success"):
print("查找不成功:", data)
return

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

print("解析的BIN/IIN:", info.get("bin_iin"))
print("品牌:", info.get("card_brand"))
print("类型:", info.get("card_type"))
print("级别:", info.get("card_level"))
print("发卡方:", info.get("issuer_name_bank"))
print("发卡方电话:", info.get("issuer_bank_phone"))
print("发卡国家:", info.get("iso_country_name"), "(", info.get("iso_country_code"), ")")

# 示例：轻量级风险规则
# if info.get("iso_country_code") not in {"US", "CA", "GB"}:
# flag_reason = "issuer_country_out_of_region"

if __name__ == "__main__":
main()

节省时间的实施注意事项

• 授权：始终发送Authorization: Bearer YOUR_API_KEY，格式如示例所示。请勿将密钥放在查询参数中。
• BIN格式：端点期望在bin查询参数中提供6位数字的BIN。去除空格、非数字，并避免发送完整PAN；只需提供BIN。
• 缓存：BIN到发卡方的映射相对稳定。将结果按BIN缓存到您的系统中，以减少重复调用和延迟。当您在日志中观察到发卡方变化时，请使其失效。
• 优雅的回退：如果success为false或isValid为false，请保持您的结账响应。您可以默认使用通用卡片处理，并在增加监控的同时继续进行授权。
• 日志记录：记录data.bin_iin和发卡方字段以便观察。避免记录完整的卡号；您应仅处理此查找的BIN。
• 测试：使用不同品牌和地区的常见BIN组合，以验证您的下游路由或风险逻辑是否处理不同的品牌/类型/级别/国家组合。

您可以通过此API交付的常见金融工作流

• 结账预验证：在格式化卡片输入后并在创建支付意图之前调用API。尽早拒绝明显无效的BIN，或要求特定发卡方的额外验证。
• 发卡方国家匹配：将iso_country_code与账单或IP国家进行比较，以在不匹配时触发增强身份验证。
• 网络路由提示：将MASTERCARD与其他品牌直接指向不同的收单方，或根据card_type应用量身定制的3DS策略。
• 客户支持丰富：当收费因通用拒绝而失败时，在代理控制台中显示issuer_name_bank和issuer_bank_phone以加快解决速度。
• 分析和监控：按issuer_name_bank或iso_country_code聚合交易，以跟踪性能和退款模式。

错误处理和弹性

示例响应演示了成功查找，状态为：200，成功为：true。在您的集成中：

• 检查HTTP状态代码，并适当地处理非2xx响应（如有必要，按需重试，具体取决于您的作业队列或结账策略）。
• 在使用数据字段之前检查success和isValid。如果任一检查失败，请继续使用保守的默认值。
• 在读取嵌套字段之前验证数据是否存在，以避免None/KeyError问题。

安全性和合规性提示

• 仅发送BIN（6位数字）。请勿将完整PAN传输到此服务。
• 将您的API密钥存储在服务器端密钥中（例如，环境变量或密钥管理器）。请勿在客户端代码中暴露它。
• 记录最少必要的详细信息，并避免在日志中包含个人身份信息。BIN本身不足以识别持卡人，但请谨慎地将其与您系统中的其他属性结合使用。

通过MCP从AI代理调用API

您可以通过使用MCP端点的MCP兼容客户端在Zyla上调用API。将您的MCP客户端指向以下URL，并包含您的Zyla API密钥：

MCP

从那里，您的AI代理可以使用Authorization头调用与上面相同的卡片检查API端点。使用代理自动化数据丰富（例如，在审查可疑订单时进行BIN验证），同时保留本文档中记录的确切HTTP方法、URL和参数。

将所有内容整合在一起

在典型的后端流程中：

1. 客户端收集卡片输入，仅将BIN（前6位数字）发送到您的服务器。
2. 您的服务器请求GET /check-card，参数为bin=XXXXXX和Authorization: Bearer YOUR_API_KEY。
3. 如果success和isValid为true，使用data.card_brand、data.card_type和发卡国家应用路由或风险规则。
4. 按BIN缓存响应，以避免重复查找。
5. 根据您定义的规则继续进行支付尝试或升级到3DS/挑战。

故障排除清单

• 401或类似的身份验证问题：确认您的Authorization头确切为Authorization: Bearer YOUR_API_KEY，并且该密钥处于活动状态。
• 数据中没有字段：确保bin参数存在且恰好为6位数字。
• 意外错误：记录完整的JSON主体和相关头部（不包括密钥）以进行诊断；从队列中负责任地重试，以避免阻塞结账。
• 与预期的发卡方不同：发卡方数据库会不断演变；刷新您的缓存并重新检查该BIN的最新响应。

常见问题解答

有效的BIN是什么样的？
有效的BIN恰好为6位数字。在发送bin之前，请去除用户输入中的任何空格或分隔符。

我需要发送完整的卡号吗？
不。仅在bin查询参数中发送6位数字的BIN。

我该如何进行身份验证？
在每个请求中包含Authorization头，值为Bearer YOUR_API_KEY。

账单如何处理？
Zyla上的API使用订阅+配额模型（不是按调用计费）。您尝试的第一个API包括7天的试用或50个请求。请查看API页面以获取当前访问选项和定价。

我可以从AI代理调用这个吗？
可以。使用指向MCP端点的MCP兼容客户端，并确保在代理进行GET调用时设置Authorization头。

准备好在您的金融堆栈中验证和丰富卡片BIN了吗？请订阅并在卡片检查API列表中获取您的密钥： 开始7天的卡片检查API试用。将上面的cURL粘贴到您的终端中，确认isValid，并交付您的集成。