ForHosting KIT · Validation

Detect a card brand

A payment form that shows the wrong card logo, or a checkout that can't tell a debit BIN from a corporate Amex range, loses trust in the first three seconds. This endpoint reads the leading digits of any card number and tells you the network, so your UI and your risk logic can react before the charge is even attempted.

● StableFree · in your browser

Run — free How it works & API

Use it from WebAPIEmailApp soonTelegram soon

The first six to eight digits carry more than you'd think

Every card number begins with an issuer identification range, historically called a BIN. Those digits aren't random: they're assigned to a specific network and, within that network, to a specific issuing bank or program. Reading them correctly is how a checkout page knows to render a Mastercard mark instead of a generic card icon, or how a risk engine decides a transaction needs a second look before it ever reaches the acquirer.

What comes back in the response

Send a card number or just its leading digits and the task resolves with the detected network — Visa, Mastercard, American Express, Discover, JCB, Diners Club, UnionPay and others as ranges allow — plus basic formatting facts such as expected number length and whether the digits pass the standard checksum used across all major networks. It tells you what the number claims to be; it does not contact any bank, confirm the card is active, or check available funds, because none of that happens at the BIN level.

A range system older than online checkout itself

Bank identification ranges predate e-commerce by decades: they were built so magnetic-stripe terminals could route a swipe to the right network without a live lookup back to a central server. That same offline-friendly design is why brand detection can still run instantly today, entirely from the digits you already have, with no external dependency and no round trip to a card network during the check itself.

Where it sits in your stack

Call the endpoint and you get a task_id immediately; the result lands on your signed webhook or a signed link valid for 24 hours, whichever fits your integration better. Most teams call it the moment a shopper finishes typing a card number, well before the actual authorization request goes to their processor, so the branding and any routing decisions are already settled by the time the real charge attempt happens.

Nothing kept, nothing charged when it fails

Card numbers are sensitive by nature, so results are deleted once the retention window closes and are never used to train anything, regardless of how the request was submitted. And because failures aren't billed — three automatic retries, then a clean, specific error — you never pay for a malformed request that never actually produced an answer.

What you can do with it

Live checkout branding

Show the correct card network logo as a shopper types, instead of a generic placeholder that makes the form feel unfinished.

Pre-authorization routing

Route a transaction to the acquirer best suited for that network before you ever submit it, cutting avoidable declines.

Risk pre-screening

Flag unusual BIN-to-country or BIN-to-network combinations for manual review before an order ships.

Reporting by network

Tag historical transactions by card brand for accounting or negotiating better processing rates with your acquirer.

FAQ

Is this credit card type detection API free?

The tool above runs free in your browser. The API is paid — each call draws from your prepaid ForHosting KIT balance: top up from $10.00 (it never expires), pay each request's published price, and a call with no balance returns HTTP 402. No subscription, no tokens, and a failed task is never charged.

Does it verify the card is real or has funds?

No. It only reads the BIN range to identify the network and checks the number's format and checksum. Confirming the card itself is active or funded happens at your payment processor during authorization.

Which brands can it detect?

Visa, Mastercard, American Express, Discover, JCB, Diners Club and UnionPay, among others, depending on published BIN ranges.

Do I need the full card number, or just the first digits?

The first six to eight digits are enough for accurate detection; sending the full number is fine too and doesn't change the result.

How do I get the result?

The call returns a task_id right away, and the answer arrives on your signed webhook or through a signed link valid for 24 hours.

Can I batch many card numbers in bulk?

Each request handles one number; for volume, call the endpoint once per number and let the async model absorb the throughput.

Is card data stored afterward?

No. Results are deleted after the retention period and are never used for training or any purpose beyond returning your answer.

What does a failed request cost?

Nothing. Failed tasks are retried automatically up to three times, and you're only billed for a request that actually completes.

For developers — API access

Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.

API endpoint

POSThttps://api.kit.forhosting.com/verify/card-type

Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, and soon from our app, email and Telegram.

Call it from your stack

curl -X POST https://api.kit.forhosting.com/verify/card-type \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d &#39;{"items":["valor-1","valor-2"]}'

const res = await fetch("https://api.kit.forhosting.com/verify/card-type", {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${process.env.KIT_KEY}`,
    "Content-Type": "application/json"
  },
  body: JSON.stringify({
    "items": [
      "valor-1",
      "valor-2"
    ]
  })
});
const { task_id } = await res.json();

import os, requests

res = requests.post(
    "https://api.kit.forhosting.com/verify/card-type",
    headers={"Authorization": f"Bearer {os.environ[&#39;KIT_KEY']}"},
    json={
    "items": [
        "valor-1",
        "valor-2"
    ]
},
)
task_id = res.json()["task_id"]

<?php
$res = file_get_contents("https://api.kit.forhosting.com/verify/card-type", false, stream_context_create([
  "http" => [
    "method"  => "POST",
    "header"  => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
    "content" => &#39;{"items":["valor-1","valor-2"]}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"items":["valor-1","valor-2"]}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/verify/card-type", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)

Example request

{
  "items": [
    "valor-1",
    "valor-2"
  ]
}

Example response

{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "verify.card_type",
  "status": "queued",
  "_links": {
    "result": "/tasks/tsk_…/result"
  }
}

The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.

Pricing

Per request$0.002

Published price — no tokens, no invented credits. A failed task is never charged.

Errors

HTTP	Code	Meaning
`401`	`unauthorized`	Missing or invalid API key.
`402`	`insufficient_balance`	Your balance doesn't cover the task price.
`404`	`unknown_type`	That task type doesn't exist.
`429`	`rate_limited`	Too many requests. Use the webhook instead of polling.

Read the full KIT documentation →

Run — free