What is a credit card BIN?

What is a credit card BIN?

CC BIN abbreviation stands for credit card bank identification number. Card BIN includes the first 6 to 9 digits of credit card number. Values of particular digits in BIN of a credit card define various information about the type of the card and its issuing bank. For instance, particular numbers in credit card BINs indicate card association, issuing bank, country of issue, and card type. More detailed information on credit card BIN numbers can be found here.

How can my business take advantage of credit card BINs?

In general, the key advantage of card BINs is that, based on credit card BIN numbers, a business can gain better insights into its customer portfolio. Particularly, a merchant business can find out, which types of cards are used by its customers (credit cards, debit cards, gift or reward cards) and which countries these customers come from. Consequently, for example, most frequently used foreign cards, and issuing banks, whose card transactions result in numerous declines and chargebacks, can be identified. Based on information, “extracted” from credit card BINs, businesses can prevent credit card fraud, plan their credit card processing strategies, and, thus, optimize the process, in order to achieve higher profitability.

How can a business obtain the listing of BIN numbers for credit and debit cards?

There are two ways to get card BIN numbers. Card BIN databases can be purchased online, from various web-sites. However, new card BIN ranges become utilized fairly often, so there is a common practice of getting those from the acquirers that a business uses for its merchant services. For example, First Data has a file that it can deliver to its respective merchants to get updated card BINs on weekly basis.

Google Authenticator

The purpose of this article is to explain the concept of two-factor authentication and its application in credit card fraud protection.

In order to minimize the possibility of online payment fraud, various techniques are used.

Credit Card Fraud and PCI-compliance

Originally, to prevent manipulations with customer information during credit card processing, several Payment Card Industry (PCI) standards were introduced. PCI-compliance is a set of requirements, imposed upon all credit card payment industry players, dealing with credit card data. The requirements are intended to protect customer’s credit card data from being intercepted. More detailed information can be found in respective article on PCI-compliance.

A lot of credit card fraud is being committed because credentials of a given user are getting compromised. Originally user information was often stolen, because inadequate measures were taken when storing usernames and passwords. Also, few adequate encryption mechanisms were available. Later on, stronger encryption techniques were introduced and best practices for user credentials storage were defined. Nevertheless, quite often people used same passwords in different systems, thus if an e-mail of such a person was hacked, the hacker could get access to the person’s bank account. Some other people used simple passwords, which could easily be guessed or hacked. Consequently, passwords were still often compromised.

To reduce fraud due to compromised user credentials, two-factor authentication mechanism was introduced.

Two-factor Authentication for Credit Card Systems

Two-factor authentication process involves two pieces of information: user’s password (so-called user factor) and an additional key (value or token), which is generated by a device (either a device, specifically designed for the purpose, or a mobile phone with appropriate app). Even if username and password are compromised or stolen, in order to access the system, the hacker would still require the possession of the key-generating device.

Traditionally, the implementation of two-factor authentication system was complicated, as it required a device specifically designed to accomplish the task. However, today, there is a simple way to implement the approach rather cheaply, using Google Authenticator app.

Basically, under two-factor authentication, there is a secret key, embedded or injected in the token-generating device. Using that key, in combination with time-based hashing algorithm, the device can generate a temporary token needed to authenticate the user. The system, where the user attempts to log in, is also aware of the key and the algorithm, and is able to generate a temporary value. Consequently, when the two values match at the time of authentication, the access is granted.

It is possible to implement the token-generating logic using the Google Authenticator app.

You can find additional detailed information on Google Authenticator here.

On logon screen additional field can be added for token input. During logon a customer will need to enter username, password, and generate the additional authentication factor through his or her phone.

The mechanism can be also used to secure virtual terminals, payment portals, and to handle e-wallet payments, as well as payments with a card which is stored on file with the processor. Also, when an online transaction is processed the token (two-factor authentication) can be used for additional customer identity verification.

Sub-merchant Funding

The purpose of this article is to familiarize different merchant services industry players (merchants, resellers and payment service providers) with the concept of sub-merchant funding and associated features required from a payment gateway.


The concept of sub-merchant funding becomes relevant when some company is functioning as a reseller (payment service provider, aggregator) of merchant services to other companies. Sub-merchants are, thus, merchants that processes transactions with assistance from a reseller (aggregator, PSP), who is playing the role of an intermediary.

In contrast to merchant funding, where the funds are transferred immediately to merchants, under sub-merchant funding the funds are transferred to sub-merchants from a certain payment service provider’s (or reseller’s) portfolio, while the aggregator gets its revenue portion.

The overall goal of the entire sub-merchant funding mechanism is to get the funds for transactions that a merchant processed to that merchant as quickly as possible.

There are two ways in which sub-merchant funding can be organized; each of these ways has its own advantages and disadvantages.

Sub-merchant Funding Models

Direct Sub-merchant Funding

Under the first model the processor transfers the funds directly to sub-merchants. Merchant services fees in this case are withheld by the processor and part of the fee amount is transferred to the PSP (see article on {residual revenue sharing}).

The advantages of this approach are:

  • sub-merchants get their money faster, as no additional banking transfers are required to move the funds to the PSP and then to sub-merchants
  • fewer bank accounts are involved, so reconciliation becomes easier for sub-merchants

The disadvantages of this approach are:

  • PSP is fully reliant on the processor to do the funding accurately and to service its customers (sub-merchants) well. If quality of this service is not satisfactory for sub-merchants, the reputation of the PSP can tremendously suffer
  • sub-merchants are directly exposed to the processor, so there is a chance that the processor company might try to seize them from the PSP
  • the approach is efficient only in cases when all transaction types needed by a given merchant can be handled by the processor within sub-merchant funding process. For example, if a merchant processes ACH and Amex, but the processor can only handle Visa and MasterCard, and, consequently, the PSP is required to take care of Amex and ACH transactions, the entire approach loses its meaning

Sub-merchant Funding through the PSP

Under the second model the funds are transferred to the PSP, and the PSP transfers them to each of its sub-merchants taking care of fees and funding of its respective sub-merchants on its own.

The advantages of this approach are:

  • Greater independence and more control of the process (funding schedules, merchant statements etc.) for the PSP
  • PSP gets more privacy in portfolio management, and, consequently, greater control over pricing. As a result, it has more potential bargaining power with the processor, since the processor has a lot less visibility into pricing of the sub-merchants

The disadvantages of this approach are:

  • PSP must have some type of software system to take care of sub-merchant funding and merchant statements
  • In cases when the processor funds to the PSP net processed (with fees deducted) versus gross processed transactions, or when reserves (see respective article for details) are withheld, reconciliation process can become rather complicated


If you are a PSP having the necessary technology and expertise to handle sub-merchant funding, it is better to perform it on your own, as it gives you greater control of the process and, probably, guarantees a more profitable arrangement for you. On the other hand, if you do not have skills and/or staff to handle reconciliation, it might be better to go with processors that can offer sub-merchant funding on their platforms.