Aller au contenu
D1
FR

Cartes de paiement

BIN Checker gratuit

Identifiez marque, type, pays et banque via les 6–8 premiers chiffres BIN/IIN. Saisissez le BIN uniquement — jamais la carte complète.

Ce formulaire appelle le point de terminaison relatif: /site-api/tools/bin

Comment utiliser le Vérificateur BIN

  1. Enter only the first 6 to 8 digits of a payment card (BIN/IIN). Never paste full primary account numbers, CVV, expiry, or cardholder names — DN01 is not a PCI card vault and must not receive complete PAN data.
  2. Submit to query our BIN dataset for network brand, card type (debit/credit/prepaid when known), issuing institution, and country hints when the prefix is cataloged.
  3. Treat results as fraud-review context, not approval to charge. A matching BIN does not prove the card is active, has funds, or belongs to the customer name on file.
  4. Copy non-sensitive metadata into risk review tickets. Pair with WHOIS on merchant or customer domains and Vérificateur de listes noires on checkout IP addresses for broader signals — we do not store your BIN queries in a searchable global fraud graph.

Card networks and BIN signals

Bank Identification Numbers route transactions to issuing banks and networks. The table summarizes major network prefixes for orientation — exact ranges evolve as issuers allocate new BINs. DN01 reports dataset matches when available; gaps mean unknown or newly issued ranges, not automatic fraud. Never enter full PAN — PCI scope and user safety demand BIN-only input.

ChampPourquoiExemple
VisaCommence par 4 — réseau retail le plus courant411111
MastercardPlages 51–55 et 2221–2720555555
American Express34 ou 37 — souvent cartes 15 chiffres378282
DiscoverPlages 6011, 644–649, 65601100
UnionPayPréfixe 62 courant en Chine620000
JCBPlage 3528–3589353011
Banque émettriceInstitution liée au BIN si dans le jeu de donnéesExample National Bank
PaysIndice ISO du pays émetteurUS, GB, BR

When BIN lookup helps risk teams

E-commerce chargeback review: customer claims US card but BIN country shows high-risk geography — one signal to escalate, not auto-decline alone. Combine velocity rules, AVS/CVC results, and device fingerprinting your platform already owns.

Support desks identify card brand for routing (Amex disputes vs Visa) without asking customers to read full numbers aloud — ask for first six digits only.

Developers test payment forms with official network test BINs documented by processors — verify UI brand icons and routing before production keys.

Investigators mapping carding forum leaks see BIN lists — lookup contextualizes issuer without handling stolen full tracks. Report crimes to issuers and law enforcement; DN01 does not ingest dark-web databases.

Merchant onboarding sanity: marketplace seller payout card network incompatible with payout rail — BIN check catches obvious mismatches early.

Chargeback representment sometimes needs issuer country evidence — BIN country is a supporting exhibit, not sworn testimony; follow card network dispute rules and never include full PAN in mailed PDFs.

Subscription renewals with updated BIN ranges after card reissue may fail AVS while BIN still maps to same issuer — Vérificateur BIN explains network context; payment retry logic stays in your PSP integration.

Marketplace split payouts across regions need BIN country hints for tax reporting — one data point among many; consult finance systems of record, not DN01 alone, for VAT and 1099 workflows.

Fraud rings test stolen BIN prefixes in small increments — velocity and device signals matter more than one BIN lookup; use Vérificateur BIN to enrich case notes, not as sole auto-block rule.

Corporate procurement cards share BIN ranges with consumer products — issuer name in results may read generic; combine with employer expense policy context.

Virtual card numbers rotate frequently — BIN may point to issuer program while PAN changes per transaction; fraud rules should not treat BIN alone as stable customer identity.

Acquirer reconciliation reports group by BIN and network — DN01 spot lookup helps support desks interpret processor CSV columns without loading full BI warehouse.

Trial subscriptions using prepaid BIN products may lack issuer bank detail — unknown issuer field means dataset gap, not necessarily stolen card; escalate to PSP with transaction id.

Troubleshooting BIN results

Unknown BIN: new issuer range or prepaid program not yet in dataset — retry after updates or consult processor documentation.

Debit vs credit ambiguity: same network prefix may cover multiple products — treat type field as hint, not legal contract.

Co-badged cards (debit + international network) confuse brand detection — expect single primary network in results.

Do not use BIN country as sole geolocation — customers travel; IP geolocation differs from issuance country.

BIN length 6 vs 8 may return different issuer granularity — use longest prefix your policy allows without typing full PAN.

BIN intelligence limits and PCI hygiene

PCI DSS forbids storing sensitive authentication data and limits PAN storage — BIN-only lookup keeps this tool outside full card data handling when used correctly. Train staff never to paste full numbers into chat or browser tools.

DN01 does not verify Luhn checksum on full PAN, run authorization holds, or access live issuer APIs — static/reference dataset only, not real-time account status.

Fraud platforms score thousands of signals; BIN is one lightweight enricher. Vérificateur de listes noires on IP, WHOIS on young merchant domains, Vérificateur de certificats SSL on phishing checkout clones add orthogonal evidence.

API automation must still send BIN-only prefixes per policy — we do not offer PAN tokenization or 3-D Secure orchestration.

Merchant category codes and interchange live in processor APIs — Vérificateur BIN does not return MCC; fraud analysts should pull MCC from authorization payload.

Regulatory reporting for cross-border cards uses BIN country as hint — compliance officers still need cardholder billing address and KYC records from core banking systems.

Tokenized wallets hide PAN but BIN may still appear in DPAN ranges — interpret wallet tokens under PSP docs, not retail BIN tables alone.

Subscription retry logic after soft declines should not loop BIN lookup — same prefix will not change until issuer reissues card; focus on PSP retry rules and customer outreach.

Gift card fraud may use domestic BIN while shipping overseas — BIN country mismatch is a signal, not automatic decline; pair with shipping address and device fingerprint policies.

BIN lookup does not validate Luhn on partial PAN — never type full card number to «complete» validation; issuer approval only happens at authorization time.

DN01 does not store BIN query history for fraud graph analytics — export results to your case management tool if retention is required.

Never photograph cards to capture BIN — typing first six digits manually protects cardholder privacy and PCI scope.

Issuer name strings in BIN datasets update slowly after bank mergers — treat stale bank labels as data lag, not fraud proof.

DN01 Vérificateur BIN complements WHOIS on merchant domains — card metadata plus domain registration context for lightweight marketplace risk reviews.

Prepaid reloadable cards share BIN ranges with gift products — customer support should ask product type, not only network brand from BIN lookup.

Corporate virtual cards for subscriptions often rotate monthly — BIN stable while PAN changes; fraud models should key on customer account not BIN alone.

Marketplace escrow releases use issuer context from BIN — legal settlement still follows platform terms, not DN01 lookup output.

DN01 never asks for CVV or expiry — if a workflow demands them, stop; that is cardholder data outside BIN-only scope.

Issuer phone numbers for cardholder verification live in banking apps — BIN lookup does not return customer service numbers for cardholders.

DN01 BIN pages stress PCI scope hygiene in every locale — training contractors remains your responsibility, not automated by lookup tool alone.

Export BIN lookup results to fraud case PDFs without full card numbers — redact everything beyond first eight digits.

Documentez chaque vérification dans le ticket de support avec horodatage ; DN01 ne conserve pas d'historique global ni de cartes de propagation.

Documentez chaque vérification dans le ticket de support avec horodatage ; DN01 ne conserve pas d'historique global ni de cartes de propagation.

Five-step checkout fraud triage

  1. Collect BIN-only (6–8 digits) and transaction metadata — never full PAN in tickets.
  2. Vérificateur BIN for network, country, issuer hints.
  3. Vérificateur de listes noires on source IP; WHOIS on email domain if disposable.
  4. Compare AVS/CVC and velocity in your PSP dashboard — DN01 does not replace PSP risk scores.
  5. Document decision; escalate to issuer/PSP with their required secure channels.

Vérificateur BIN vs processor tools and full BIN DBs

Stripe Radar, Adyen Risk, and issuer systems see live authorization behavior — deeper than public BIN tables. DN01 offers quick browser lookups beside DNS and WHOIS utilities without another PSP login.

Commercial BIN databases update daily with wider coverage — we provide practical free lookups with honest gaps, not proprietary issuer contracts.

We do not run Luhn validators on full card numbers, store PAN, or map propagation of fraud rings globally.

Eight locales (EN/RU full guides), API where enabled, localized shorter content elsewhere — companion to Vérificateur de listes noires, not a payment gateway.

PCI SAQ merchants still need processor contracts and ASV scans — BIN lookup does not satisfy compliance questionnaires asking about PAN storage; our UI blocks full card entry by design and policy.

Gift cards and closed-loop prepaid products use BIN ranges outside major networks — unknown BIN may mean closed-loop product, not fraud; consult processor docs before auto-declining checkout.

Why use DN01 Vérificateur BIN

  • BIN-only lookup for network, issuer, and country hints — designed to keep full PAN out of the browser.
  • Integrated with WHOIS and Vérificateur de listes noires for lightweight fraud context on the same site.
  • Localized UI, API options, local history — no PCI vault, no live authorization.
  • Honest dataset limits: reference prefixes, not account balance or card-active verification.

FAQ

FAQ du BIN Checker

Recherche de préfixe carte, contexte émetteur et manipulation sûre des données de paiement.

Que peut-on saisir sans risque dans un BIN checker ?

Saisissez uniquement les 6 à 8 premiers chiffres de la carte. Ne saisissez jamais un PAN complet, le CVV, l'expiration ou des données titulaire. Le guide du BIN checker précise ce que l'outil affiche ou non.

Que permet d'identifier une recherche BIN ?

Si le préfixe existe dans la base, l'outil peut indiquer le réseau de paiement, la banque émettrice, le type de carte et le pays. Il ne confirme pas qu'une carte est active.

Pourquoi combiner BIN avec d'autres outils ?

En revue fraude, le BIN n'est qu'un signal. Vérificateur de listes noires apporte la réputation IP, et WHOIS aide à inspecter les domaines marchands ou clients.

Peut-on automatiser une recherche BIN ?

Oui. Utilisez la documentation API et inscription API pour une automatisation autorisée, sans envoyer de données carte complètes.

Qu'est-ce qu'un numéro BIN ?

Le BIN (Bank Identification Number) désigne les premiers chiffres d'une carte de paiement qui identifient le réseau et l'émetteur potentiel. On parle aussi d'IIN dans les normes récentes — le lookup utilise le préfixe, pas le numéro complet.

La recherche BIN est-elle légale ?

Interroger des préfixes publics avec 6-8 chiffres est courant en prévention fraude quand vous n'envoyez pas de PAN complet ni de CVV. Respectez la politique PCI de votre organisation et ne stockez jamais de données carte complètes dans les tickets.

À quelle fréquence les données BIN sont-elles mises à jour ?

Les émetteurs lancent de nouvelles plages au fil du temps ; le dataset DN01 est mis à jour périodiquement mais peut manquer un préfixe tout récent. Traitez un miss comme signal incomplet, pas comme preuve de carte invalide.

Le BIN indique-t-il la limite de crédit ?

Non. Le lookup BIN décrit les métadonnées de l'émetteur et du réseau de paiement, pas le solde, la limite ni l'éligibilité de la carte. Seul le processeur de paiement autorisé fournit ces réponses.

Le BIN peut-il détecter les cartes prépayées ?

Parfois le type de produit apparaît comme crédit, débit ou prépayé quand le préfixe est dans le dataset. Ce n'est pas une vérification en temps réel — confirmez avec votre processeur si la distinction est critique pour la décision.

Pourquoi le BIN diffère-t-il des derniers chiffres ?

Le BIN identifie l'émetteur et le réseau ; les chiffres finaux identifient le compte individuel et le chiffre de contrôle Luhn. Vous n'avez jamais besoin des derniers chiffres pour un lookup BIN sûr — en fait vous ne devez pas les saisir.

Le BIN checker est-il gratuit ?

Oui pour des recherches manuelles avec de courts préfixes. Les flux à fort volume en revue fraude peuvent utiliser la documentation API après demander un jeton API, toujours sans données carte complètes.

Le BIN remplace-t-il le scoring antifraude ?

Non. Le BIN apporte le contexte émetteur ; le scoring antifraude combine vélocité, appareil, historique et signaux du processeur. Utilisez le BIN avec le Vérificateur de listes noires et revue manuelle — pas comme seule règle d'approbation.

Sélecteur d'outil

Choisissez la prochaine étape de votre flux de travail domaine ou sécurité.

Catalogue complet d'outils

Guides

Guides pratiques pour les tâches courantes avec BIN Checker — enregistrements DNS, dépannage et liens vers nos outils gratuits.

Retour à BIN Checker