Payment Gateways II: Credit Card Payment Aggregation

The purpose of this article is to familiarize the key merchant services industry players (particularly, large-size merchants, wholesale resellers and PSPs) with payment aggregation as an advanced feature to be considered during payment gateway selection. If this is the first time you are reading “Payment Gateways II” series, please, start with the Introduction as it will improve your understanding of the current post.

Payment aggregation concept

Payment aggregation as a concept exists in two aspects covered below.

Straight aggregation

Historically payment aggregation was used to give payment processing capabilities to those businesses, which wouldn’t be able to go through merchant services underwriting otherwise. A central company (PSP) would get underwritten, have its own agreement with a processor and use the same MID to process (aggregate) payments of its smaller customers that wouldn’t go through individual underwriting and have their individual merchant accounts. The PSP would process all their payments and aggregate them through the central account, remit respective funds withdrawing its own fees.
Over time the credit card companies insisted on discontinuing this practice for the most part, as it was used for covering various illegal operations, such as drug sales, money laundering etc. As a consequence, the concept of a sub-merchant was introduced.

Sub-merchant funding

Under this concept each merchant goes through some form of underwriting, but the entire financial liability and risk is on the PSP and its entire portfolio. Instead of using one single MID for all merchants, each merchant is assigned its own MID, but this MID is linked to the portfolio of the PSP. Usually the PSP portfolio has much better processing rates than any member of the portfolio could have gotten on its own. PSP takes care of funding of merchant fees and statements.

Let us look at particular functions and important features of payment aggregation model to be considered during payment selection.

Important aspects of payment aggregation model

Support for aggregation and remittance is an important enterprise feature, primarily targeted at PSPs. To facilitate efficient, transparent and flexible functioning of the payment aggregation model, resellers need to be able to perform a wide range of tasks. Particularly, a reseller, using payment aggregation model, needs to be able to do the following:

  • allow it to easily set up a merchant
  • process transactions on behalf of its multiple customers\sub-merchants
  • manage their accounts
  • use merchant-specific pricing
  • remit processing revenue back to merchants
  • withdraw merchant fees (transparently for the merchant)
  • generate statements (at the end of the month or on per-deposit basis)
  • share residual revenue with channel partners

To simplify each of these tasks, resellers need special tools. But not all processors/payment gateways are able to provide all the necessary tools to resellers. For instance, some are only able to back out their own fees, and some can not accommodate per merchant pricing.

In addition to the issues mentioned, several other considerations should be made. To learn about respective issues that PSPs should bear mind, please, consult the resources covering PCI compliance and credit card chargebacks on our web-site.

To illustrate the importance of payment aggregation support, let us consider a practical example.

Example

A PSP is offered a deal with a processor, allowing transaction processing at very good rates. At the same time the deal envisions full responsibility for underwriting, merchant statements, merchant fees etc, so the PSP needs the technology to execute remittances, generate merchant statements and take out the fees. Consequently, cooperation with a payment gateway supporting respective functionality allows the PSP to accept the offered contract with the payment processor without any additional efforts targeted at support of the aforementioned functions.

Conclusion

If a PSP is using a cost plus pricing model, with a variable pricing for each merchant, and, potentially, variable commission structure, it definitely needs a software platform capable of accommodating these features.

Payment Gateways II: Credit Card BINs and Card Intelligence

The purpose of this article is to familiarize the key merchant services industry players with the concepts of credit card BINs (bank identification numbers) and card intelligence as advanced features to be considered during payment gateway selection. If this is the first time you are reading “Payment Gateways II” series, please, start with the Introduction as it will improve your understanding of the current post.

Card intelligence concept is based on detecting certain patterns (what card types are used, where they come from) based on analysis of processed card numbers. First 6 to 9 digits of a credit/debit card number contain considerable amount of information about card type and its origin (detailed information on issuer identification numbers can be found here ). For example, the first digit usually identifies the association (Visa, Amex, etc), next digits define the card type (debit/credit/gift), country of issue, issuing bank etc.

The concept is fairly new, but it is rapidly gaining popularity among merchants and processors. Payment gateways utilizing credit card BINs are capable of providing additional analytical data to their customers (merchants). Examples of such data are given below.

Why credit card BINs are important

An important card intelligence aspect is differentiation of various card types (credit/debit/pre-paid/gift cards), because in some cases debit cards can be processed in a special way (PIN-debit or PIN-less debit), while pre-paid and gift cards are not a preferred option in the context of recurring billing agreements.

BIN also allows merchants to predict the cost of transaction. For example, if desired, a merchant can exclude (stop processing) reward cards that carry cash back and have high processing cost, or foreign-issued cards.

Credit card BINs can also be used to determine whether the card can be used in specific types of transactions (for example, HSA (healthcare) cards, fleet cards, purchase cards and level-III cards).

BIN also identifies the issuing bank, its location and contact data, enabling merchants to research problems around specific transactions.

Based on credit card BIN data, declines can be analyzed with respect to card types or issuing banks; respective patterns can be detected and measures taken.

In general, credit card BIN data analysis and patterns derived through it might help merchants make informed decisions in the area of credit card transaction processing. Illustrative examples of such patterns and decisions are provided below.

Examples

A merchant gets a certain number of declines during recurring billing, but, due to lack of card intelligence, it is unable to detect a potential pattern in declines. A lot of declines might come from a specific issuing bank. In this case the merchant might try to resolve the problem with the issuing bank.
As mentioned above, an important card intelligence aspect is the ability to identify a gift or pre-paid card during recurring billing. For instance, a health club customer is using a pre-paid card to buy a recurring contract for a year. If the amount on the card is relatively small, then there is a high likelihood of decline after it is consumed.
If some card type (credit/debit/gift or pre-paid) prevails in transactions, it might be appropriate to switch to a processor offering “cost plus” pricing model.
If many clients are using foreign-issued cards, the merchant/reseller might be able to conclude that the business has many customers from abroad (Canada/Europe), and may consider opening a foreign merchant account to reduce the costs.

Conclusion

A payment gateway/processor must be able to deliver the information about a specific card based on the first 9 digits of its number. Using this information, the business management will be able to make intelligent decisions.

The next post will cover aggregation models used by large-size merchants, wholesale resellers and PSPs.

Payment Gateways II: Support for Recurring Billing

The purpose of this article is to familiarize the key merchant services industry players with the concept of recurring billing as an advanced feature to be considered during payment gateway selection. If this is the first time you are reading “Payment Gateways II” series, please, start with the Introduction as it will improve your understanding of the current post.

Recently subscription-based payment model has become very popular. The model is predominantly used by membership-centric organizations, such as health clubs, tanning salons, etc. Even traditionally retail industries are implementing the elements of subscription payments into their business practices. For instance, online stores selling such products as water filters, vitamin supplements, skin care products are offering their customers to purchase these products regularly on subscription basis. Because of increased importance of subscription-based business model, recurring billing becomes an essential part of modern payment processing systems, such as payment gateways.

Recurring billing paradigms

When it comes to recurring billing (also known as subscription billing or recurring payment processing) there are two major paradigms, which can be called committed billing and uncommitted billing.
Uncommitted recurring billing would be an on-line subscription, which carries no minimum time commitment and requires no special handling in case of delinquency (usually the service or subscription simply get discontinued). For example, monthly subscription at eFax or premium membership at linked-in.
An example of committed recurring billing would be a term gym membership or a cell phone contract. In both of these examples, if a payment is missed and an account becomes delinquent, a collection attempt is made to reinstate the account and collect any past due. Simply deactivating the service is not an option in such cases.

An important issue arising in connection with recurring billing is cardholder data storage. If a merchant is storing actual payment card data (for recurring billing), it must go through costly PCI compliance certification procedures. Tokenization and profiling provide solutions allowing merchants to reduce their PCI scope or completely get out of it. For more information on tokenization and profiling see here and here.

Another component of recurring billing to be mentioned is decline recovery, as declines tend to happen more frequently when customers are charged on recurring basis. That is why subscription-based businesses should integrate with payment gateways offering decline recovery mechanisms.

Let consider an example of tanning salon to gain better insight into the needs of a business using subscription-based model.

Example

A tanning salon used to offer exclusively annual or semi-annual memberships to its customers, because it lacked the necessary technology to implement monthly payment process. This made attracting new customers more difficult for the salon, as long-term membership required significant upfront payment to join. Now, by going with a payment processor that offers recurring billing, the salon can offer flexible monthly payment plans, making its membership more affordable. At the same time, presence of decline recovery tools makes it easier for the salon to manage decline recycling and ensure that the revenue is not affected by going with monthly billing vs annual billing.

Conclusion

Depending on the type of recurring billing that a merchant needs (committed vs uncommitted), it might want to look for a payment gateway that accommodates that specific feature set. If the business requires committed recurring billing model, it needs to verify, what decline recovery techniques and collection tools are going to be available within the payment gateway it is using.
If repeat purchases are important for a business, then it is critical to find out in advance, whether the processor\payment gateway it deals with offers some form of tokenization.

Out next post will cover credit card BINs and card intelligence.