Online Marketplace Model

With the success of eBay, Uber, AirBnB, and other similar online marketplaces, the concept of an online marketplace is rapidly entering new industries. As a result many modern software companies are providing online marketplace software for these different industries. Consequently, the problem of payment handling in marketplace-type systems becomes more and more relevant.

What an online marketplace is

Online marketplace is a platform, allowing its users to exchange products and services, which is provided and supported by a third-party entity. Examples include eBay and AirBnB.
Plenty of different companies develop software for online marketplaces. However, the need for effective organization and support of complex payment processes at online marketplaces maintains its relevance.

The difference between an online marketplace and a conventional business

The main marketplace-specific problem is as follows. During a traditional transaction, when a customer pays a merchant for a purchase, the merchant receives the money with a small processing fee withheld. The fee is retained by the processor (the company that processed the payment).
In an online marketplace two conceptually new components were added to the above-mentioned simple transaction processing mechanism.

The first one is as follows. In an online marketplace situation there is an additional party involved that needs to be paid for the service vended. So, when the merchant is paid, a fee has to be withheld (as in the conventional model). However, it needs to cover not only the cost of processing, but the cost of the service of the marketplace. Let us use examples to illustrate the difference.

Example 1

John purchases a T-shirt for $20 in a store and pays with his credit card. The store receives $19, while $1 is withheld by the bank that handles credit card processing for the store.

Example 2

John buys a $20 T-shirt at an online marketplace. The merchant receives $18.50. $1 goes to the bank that processed the transaction, as in Example 1. However, $0.50 from the transaction needs to go to the marketplace owner.
While it is possible for the marketplace to collect its fee as a monthly subscription, or as a separate (second) transaction, it is preferable to be able to withhold just one fee from the main transaction, and then – split it among any other parties, such as affiliates, that are involved.

Moreover, the marketplace owner is not the only new player in comparison to a conventional business.
Another important thing to consider, when dealing with marketplaces, is the affiliates. We are talking about third-party blogs and web-sites, which handle the promotion of different products (ads, which we see in blogs, leading to online marketplaces like Amazon and eBay, provide vivid examples of such promotions). Say, a blogger writes about different cleaning products and detergents. She writes about unique cleaning products, and references a link to the web-site (online marketplace), where these products can be purchased. It is expected, that the blogger is going to receive some small commission of every purchase that is made through the link from her blog.

Example 3

John smears his newly-bought T-shirt, goes online and finds the blog, providing some useful information on where effective detergents can be purchased. He clicks on the link in the blog and purchases the detergent at the online marketplace. Now, beside the fees, the bank and the marketplace owner are entitled to, the blogger should also get her small share of the transaction amount.

As we can see, the traditional transaction processing model does not fully meet the needs of an online marketplace. Online marketplaces have a need for split funding, i.e, they require the ability to split an original transaction into multiple sub-components (smaller payments), that can be distributed among different parties, such as affiliates.


If you want to build your business in accordance to the online marketplace model, you need to select the right payment processing partner, who, potentially, is capable of providing flexible split funding functionality. Although you can go with a traditional processor and build the split funding logic yourself, you are likely to experience many challenges, and still the process might not be transparent enough. Consequently, it might be better and more profitable for you to partner with a payment platform, which already supports split payment functionality. It might also be useful for you to check, if a payment facilitator model is the right one for you.
In the next article we are going to address two basic split funding models.

Payment Gateways and High Availability Concept

The purpose of this article is to familiarize payment gateway software users with the benefits of high availability and fault tolerance concepts. These two concepts are vitally important for various merchant services industry players, because transaction processing (especially, real-time processing) became mission critical for most businesses, such as online stores, online ticket booking and purchase systems, hotel booking sites etc.

More and more transnational online businesses emerge, which are targeted at customers around the world. Payment system of such businesses must be available 24/7 with the minimal number of the maintenance windows. Fault tolerance in itself is another reason for utilizing cluster architecture for transaction processing. If some node of the system fails, the customers must not even notice it.

Why are high availability and fault tolerance important?

There are several reasons why you should think in advance of the concepts of high availability and fault tolerance as you design the architecture of your future payment ecosystem:

  • Downtime reduction. You should minimize downtime, because your clients might be located around the world, in different time zones. On the other hand, your payment software still needs to be updated from time to time (and this, generally, requires some server restarts or downtime). If your system is designed with high availability in mind, then you are able to service all your customers 24/7, and still perform maintenance operations and updates when necessary.
  • Physical hardware failures. You might experience physical hardware failures, including database storage failures. For these situations, you must develop an effective backup strategy. Sometimes, however, doing a lengthy recovery process from backup and is simply not an option, because the system will not be functional while the process executes. For such cases, maintaining a cluster of data bases, both of which are active at any time, is the only way.
  • Division of labor. You might (sometimes or regularly) have a consistent high volume of authorizations going, while somebody drops a large file for processing, or some resource-intense settlement process has to execute. Running all of these processes on the same server can significantly impair the ability to do real-time authorizations. Therefore, it might be necessary to segment the functionality, so that certain nodes of the cluster are dedicated to authorization, some handle settlement and batch file processing, while other nodes can handle reports and data export.
  • Resource utilization optimization. Similarly to functionality-based segmentation, sometimes a need for customer-based segmentation might arise. Customers with some specific behavior patterns, or customers from specific time zones, can be directed to respective nodes, “reserved” for them (always or at a certain time of the day).
    Some of the company’s customers process transactions 24/7, while other customers process large volumes at particular time of the day or month (these are merchants doing recurring billing through real-time transactions). In such case one node should be dedicated to merchants who process transactions 24 hours a day and have evenly distributed processing patterns, while dedicated nodes could be used for merchants who only process at certain times. Based on the processing times, they could be arranged in such sequence that the servers are never overloaded with transaction volume.
  • Conclusion

    If you are serious about payment processing and customer service, you have to be serious about high availability.

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.

Payment Gateways II: Introduction

In a previously published series of posts we have covered a set of basic features to be considered by merchants and resellers as online payment gateway selection criteria. Posts concerning these fundamental features can be found in Payment Gateways series on our web-site.

Although needs of most merchants and resellers are confined to the features discussed so far, enterprise merchants, wholesale resellers, independent sales organizations (ISO) and payment service providers (PSP) occasionally face some challenges induced by their size and specifics of their business. For the benefit of these groups of players, we have decided to write another series of articles covering the so-called advanced enterprise-level payment gateway features. In the current series we will offer a review of advanced features (which are sometimes no less important than basic ones) to be considered when choosing a credit card processor or online payment gateway provider.

In the installments concerning basic online payment gateway features we have considered merchant and reseller perspectives separately for illustrative purposes. In contrast to basic features, where the two specified perspectives could be clearly defined and understood, enterprise features tend to apply to both resellers and enterprise merchants in the similar way. The only thing for resellers to keep in mind is that a reseller must always strive to select a processor\online payment gateway, capable of supporting the set of features, satisfying all current and potential needs of merchants this reseller is dealing with.

Consequently, in our subsequent posts we are going to look at all of the above-mentioned players from a single perspective. In either case, we will try to supplement the concept explanation with a meaningful example from the industry.

Particularly, this series will look into the following advanced online payment gateway features:

  • Ability to support surcharges (such as convenience fees and taxes);
  • Support for batch transaction processing (especially if there is a need to do recurring billing\process large files);
  • Support of ACH transactions through unified ACH\CC API;
  • Blacklist capability of “never-to-be-active” accounts;
  • Availability of various types of recurring billing schedules;
  • Support for tokenization and hosted paypages (to reduce PCI scope);
  • Built-in merchant on-boarding and merchant account provisioning mechanism (to automate the merchant data collection process);
  • Enterprise reporting for advanced reconciliation;
  • Payment aggregation and remittance for PSPs;
  • Credit card BIN and “business intelligence” (to allow businesses to gain extra-knowledge about their customers).

All aforementioned topics (and more) will be covered in subsequent articles, so stay tuned and wait for new installments to appear.

Payment Concepts: Credit Card Tokenization

This article belongs to the mini-series providing guidelines for merchants interested in attaining PCI compliance. In this installment we are going to cover the approaches to credit card tokenization and possible solutions that make PCI audit more attainable.

If you have not read the intro, we recommend that you start with it, as it will improve your understanding of the current post.

Credit card tokenization concept

The idea behind tokenization is to delegate credit card storage to the payment gateway or payment processing system, as opposed to business-specific software, such as web-site, online storage or CRM. The main purpose of tokenization is to allow merchants not to store credit card numbers for repeated\recurring transactions. To achieve this, credit card numbers are replaced by tokens which are saved and used instead.

Fundamentally, there are two primary approaches to tokenization.

Approaches to credit card tokenization as a process

The two conceptual ways to implement credit card tokenization are commonly referred to as pure tokenization and profiling.

Pure tokenization

Under pure tokenization approach, only credit card (bank account) number is tokenized. However, if necessary, routing number (identifying the branch of the bank) for ACH, social security number, or even driver license number, could be tokenized as well. To put it simply, every sensitive value is replaced by a token (one for one).

When the credit card processing request is issued (during repeat\recurring transactions), the token is used instead of a credit card number, allowing merchants to avoid credit card storage.


The second approach to credit card tokenization (profiling) is a bit more elaborate, as it involves maintaining the full or partial customer profile.

The difference is that in this case the entire billing information, including the billing address, shipping address etc (depending on the system used) would be stored in the customer profile (including credit card number). When a transaction is processed, the ID of the profile is sent, and any fields that are not supplied, are “pulled” from that customer profile.

Some systems use a variation of customer profiles where instead of customer profile an ID of the previous transaction is passed and all of the missing information, such as credit card number etc, is extracted from that transaction.

When repeated\recurring credit card transaction is processed, the profile ID (or ID of the previous transaction) is used in place of the actual credit card number, thereby allowing the merchant to avoid persistence of the credit card number.

Advantage of the first approach is that the business doesn’t have to do any separate maintenance of the profile. It only has one number and the token just replaces it. Advantage of the second approach is that more information can be stored outside of the merchant’s system (web-site\CRM). Consequently, if the merchant has some basic front-end system and doesn’t wish to store all the billing information (ZIP code etc), it can rely on tokenization provider to store that information, which might be more convenient for the merchant. However, with this approach the merchant assumes the responsibility for keeping the profile up to date.

Now let us look at the most common ways to implement credit card tokenization.

Credit card tokenization through appliance

Tokenization through appliance is intended for the pure tokenization approach, described above.

The appliance is a combination of a hardware device (used to encrypt\decrypt credit card numbers) and PA-DSS-compliant software (used to store encrypted values and to generate tokens). The hardware device is usually either a chip on the motherboard or a PCI-card. The appliance (hardware with software written on top of it) is hosted in local network of the merchant\PSP.

Hardware\appliance solution does not eliminate the need for PCI-compliance certification, but it definitely reduces the scope and simplifies the PCI audit, as the storage is delegated to an already PA-DSS-compliant piece of software.

Credit card tokenization through appliance can be an ideal solution for a merchants\PSPs processing large volumes of transactions and already having an existing PCI environment where the appliance could be deployed.

Credit card tokenization as service

The other approach is hosted tokenization service, where, instead of having some type of device in merchant’s own network, the merchant is delegating storage to some other (third) party. In this case the merchant must use some form of API to generate the tokens.

When it comes to credit card tokenization as service, there are 3 conceptually different approaches with minor technical distinctions, nevertheless, important and worth noting:

  • Processor-integrated tokenization – tokenization is an integrated service of the payment processor. The advantage is that the merchant only deals with one and the same party for credit card tokenization and processing. In order to process a transaction there is no need to de-tokenize credit cards (or even to “touch” the actual card number, because it is stored by the underlying processor). If a token is already obtained by the merchant, when transaction is processed, the merchant simply passes this token to the processor and the processor is able to locate the respective credit card number. Under this approach switching to another processor would result in costly data extraction and re-location procedures. And data extraction fees are sometimes really heavy.
  • Gateway-integrated tokenization – the approach is similar to processor-integrated tokenization, except that tokenization is handled by and independent gateway (possibly, servicing several processors). The advantage of this approach is that if a merchant switches from one processor to another (serviced by the same gateway) the tokenization procedure remains the same and costly re-tokenization process is not required. Under this approach the merchant does not touch the card data, remaining completely out of PCI scope.
  • Third party tokenization – cards are stored by the by the third party separate from the one who processes transactions. The merchant uses the API to tokenize/detokenize cards on demand. This option is a little less secure, because although the merchant doesn’t store card number, before it processes the transaction, it has to de-tokenize the transaction, take the actual number and send it to the processor. The merchant is touching but not storing the card number. So, this solution reduces the merchant’s PCI scope, but does not take the merchant out of it.

The next and concluding post in this mini-series will cover payment card data flow and respective solutions allowing merchants to reduce or even get out of PCI scope.

Payment Concepts: Credit Card Chargebacks

Why credit card chargebacks are important

The purpose of this article is to improve the understanding of the important concept of credit card chargeback among merchants, resellers and credit card transaction processors. With better understanding of credit card processing lifecycle in general and chargebacks in particular, they can avoid considerable money losses resulting from online credit card fraud.

Many people do not have a clear picture of the full online credit card processing cycle and mostly concentrate on the initial phase which includes processing and funding. Some are stuck with the misconception that transaction approval is the concluding phase of the process. However, the cycle doesn’t actually stop at this phase. It is important to understand the full lifespan of credit card transactions. Special attention should be given to credit card chargebacks. (To realize, the importance of chargebacks, it is sufficient to check some chargeback statistics ).

Many merchants that do not have thorough understanding of how credit card transaction processing functions often fall victims to chargeback fraud.  Consequently, one should keep in mind the possibility of fraud, induced by the nature of credit card chargebacks.

Credit card chargeback concept

Basically, credit card chargeback mechanism is one of consumer protection instruments. In general terms, a chargeback is a cardholder-initiated dispute over a certain amount of money the cardholder assumes to have been charged illegitimately (or in error) for products or services he or she did not get.

A chargeback happens as follows.

First a purchase-related transaction is processed. Afterwards, the buyer discovers that he or she was charged a certain amount of money for a service\product that he or she didn’t actually purchase (or believes he or she didn’t purchase). The buyer contacts his or her bank and asks for a possible reversal of the charge (known as credit card chargeback). The final decision is made by a card association (Visa, MasterCard etc). If the ruling in the chargeback case is made in favor of the buyer (cardholder), the money is withdrawn from the merchant’s bank account and returned to the buyer. Otherwise it remains with the merchant.

A chargeback decision can be subsequently overruled through an arbitration process. In this case a reversal is issued and the money is returned to the merchant. Quite often, regardless of the decision, a chargeback fee is applied. Regardless of the chargeback outcome, the chargeback rate of the merchant (percentage of chargebacks in the total volume processed) is going to rise. The problem is that when it exceeds 1 %, the merchant gets on the MATCH list (also called Terminated Merchant File ) and can no longer process credit card transactions.

Most people think that if a credit\debit card transaction is processed and gets funded in their bank account, the process is complete. In reality, there is always a possibility of debit and credit card chargebacks, which can take place up to 60 days after the original purchase is made.

Since most people do not look at their statements every day, there is a possibility of credit fraud around credit card chargebacks.

Chargeback fraud

Let’s address the two possible types of fraud involving credit card chargebacks: consumer fraud and merchant fraud.

Consumer fraud

The most common chargeback fraud scheme, that should be mentioned, is a consumer-based one. It is implemented by fraudsters who simply make purchases online using stolen cards, i.e. pay for their online purchases with somebody else’s money.

Merchant fraud

Another chargeback fraud scheme, involving merchant accounts, is more complicated. Let’s assume a fraudster managed to obtain a large set of credit card numbers (possibly stolen from an online store database). The fraudster subsequently obtains a merchant account, uses stolen cards and processes transactions (presumably, not involving large sums, not to get detected by fraud protection tools). The next day the fraudster’s merchant account gets funded, he collects the money and flies to Bahamas (or elsewhere). Within the next 60 days the cardholders discover illegitimate charges on their credit card statements, issue chargebacks and the processor or merchant account underwriter (ISO/bank) is now paying for the lavish vacation of the fraudster with their own money.

It is important to note, that card not present transactions are carrying higher risk of potential fraud. In order to detect and prevent fraudulent CNP chargebacks merchants and resellers can use various tools.

Because of the fraud mechanism described above, all merchants requesting merchant accounts today have to go through a strict underwriting procedure.

Chargeback fraud prevention methods

1) There are some indirect signs, which might indicate high risk of fraudulent CNP chargeback. These signs include risky account locations (billing addresses) outside US, multiple account numbers accompanied by one and the same address, and others.
2) There are prevention tools offered by credit card issuers. These include address verification service (AVS), Verified by Visa (VbV) and MasterCard Secure Code (3D secure), Card code verification (CCV) and others.
3) ISOs and Payment service providers (PSPs) can hold a special chargeback reserve to cover potential credit card chargebacks, issued by merchants’ customers.

A more exhaustive coverage of credit card chargebacks, chargeback fraud and fraud prevention tools can be found in these
guidelines .


In order to avoid money losses resulting from chargeback fraud, merchants, resellers and processors need to understand the transaction processing cycle thoroughly, and introduce respective leverages and tools into their transaction processing systems.

Payment Gateways: Reporting Services

The purpose of this article is to discuss availability of financial reporting services as a criterion to be considered during payment gateway selection.

If this is the first time you are reading our “Selecting a Payment Gateway” mini-series, please, start with the Introduction to improve your understanding of this post.

Irrespectively of business size, it is very important for every merchant to deal with a processor whose payment gateway software includes elaborate financial reporting services. A business involved in credit card processing requires reporting services around the aspects listed below.

Reporting services evaluation criteria:

  • transactions activity – to reconcile transactions sent to the payment gateway and responses received from it. This information needs to be available by activity date (when the transaction was authorized) and by settlement date (when the transaction was settled). Since authorization and settlement date may differ, having the ability to analyze transactions by either of these dates considerably simplifies overall reconciliation process
  • funding – to reconcile bank deposits made by the processor for the transactions processed
  • chargebacks and ACH returns – to reconcile respective deductions from the account
  • processing costs – to analyze the costs charged for processing and the types of cards that the business is dealing with
  • commissions (for resellers only) – to understand residual revenue\commissions that are paid by the processor to the reseller for the business it generated.

It is important to verify that the reports are available not only in summary format (by date or by merchant), but also as a detailed version (on the level of individual transaction). It is particularly useful to have a detailed report listing all types of the transactions processed (including approvals, declines, blacklists, errors, chargebacks and ACH returns) with processing costs (interchange and assessments) available for each.

When a business considers potential partnership with a payment gateway, it should ensure, that the abovementioned data is easily accessible through payment gateway software’s reporting module, as this information is extensively used in transactions and bank deposit reconciliation processes.

Merchant perspective

The ability to dissect and analyze data by various criteria (authorization date, settlement date, merchant ID – especially when multiple MIDs are used) is crucial for a merchant.


It is common for a multi-location fitness club chain to maintain a separate MID for each location to track all the funds coming in and out. Any health club, which has multiple locations, will be routinely dealing with reconciliation process across different MIDs and credit card processing terminals. Availability of a summary\aggregate report across all MIDs with drilling capability for an individual MID will be of great value under such circumstances, and can save a lot of time and money.


To reduce potential reconciliation overhead, it is important for a merchant to deal with a processor that provides aggregate and detailed reporting services at all levels of the merchant’s business structure (company level, MID level, terminal level).

Reseller perspective

Resellers have the same reporting concerns and considerations as independent merchants, but require two additional features: reports around commissions and reports on transactions across different merchants in its portfolio.


As an example of a reseller, let us consider a software company servicing a franchise of small-size fitness clubs for women. The reseller has to deal with a large number of small merchants and multiple club owners, each owning a different number of clubs and having its own processing fee structure. The ability to analyze data at corporate level, individual club level, as well as individual owner level, will be critically important for the reseller.


If the two reseller-specific features are not provided by the payment gateway, the process of understanding commissions will take considerable time and effort. Under such circumstances, if the number of merchants in reseller’s portfolio grows, unavailability of accurate reporting services can make reconciliation process completely unmanageable and cost prohibitive.

The next post will address chargeback information handling.

Payment Gateways: Fraud Protection

If this is the first time you are reading our “Selecting a Payment Gateway” mini-series, please, start with the Introduction to improve your understanding of this post.

With the increase of online commerce and wider adoption of electronic forms of payments, an increase in credit card fraud rate is observed (especially, on CNP transactions). Various tools have been introduced into credit card processing software by different companies, in order to reduce the possibility of fraud. They include GeoIP, minFraud and others. Particularly, these tools perform cardholder’s IP address check, verify his e-mail against a look-up table, and determine the buyer’s overall risk score.

When it comes to fraud protection, four most common approaches used at the point of sale are:

  • 3D secure, introduced by associations (during online purchases an additional password associated with a credit card is required in order to confirm the buyer’s identity), often used in combination with
  • AVS (address verification service provided by card associations to verify the billing address on file against the one provided by the buyer);
  • IP-address-based (i.e. geographical location based) segmentation or filtering, provided by third parties;
  • various types of identity verification – name or e-mail of the buyer is verified against various blacklists);

In some cases additional compensating security controls can be used. They are:

  • so-called “processing cap” – certain processing limits are imposed on the merchant. They reduce/limit the number or total amount of transactions processed by the merchant per hour/day/week/month;
  • reserves – certain percentage of money processed is held by the processor/payment gateway for a certain time period to cover potential chargebacks and ACH returns.

Merchant perspective

Fraud protection issue is especially relevant for merchants that are doing online commerce.


Health club owners/managers decided to sell fitness supplements through the web-site. This activity exposes the health club to potential online fraud. In this case the merchant should opt for a payment gateway with built-in fraud protection tools. Using such gateway is likely to result in considerable savings, as the merchant will not lose money on illegitimate orders and chargebacks.


A merchant dealing with a large number of online transactions, as well as a business involved in a high-risk segment, should make a decision in favor of the payment gateway with built-in fraud protection features.

Reseller perspective

The reseller must keep track of all the merchants it is dealing with, and all their transactions, which is a very challenging task. If some fraud does take place, financial responsibility might fall on the reseller, as not all merchants are responsible enough to perform the necessary checks themselves.


A software company decides to add an online store as a software module. The company management realizes that this action may potentially result in various additional fraud-associated issues, inherent in e-commerce business. Consequently, it is necessary for the company (reseller) to have some fraud protection tools in the online store. Cooperation with the payment gateway, already supporting fraud protection features, allows the reseller to save resources and efforts, required for development of these features on its own.


When a reseller is actively involved in an industry segment, where fraud is common and fraud rates are above average, it might be easier for the reseller to partner with some processor, whose payment gateway software has integrated fraud protection tools, instead of building all the respective functionality on its own.

Our next post will cover core reporting requirements for a payment gateway.

Payment Gateways: Standard Features

The purpose of this article is to discuss standard features to be considered during payment gateway selection.

If this is the first time you are reading our “Selecting a Payment Gateway” mini-series, please, start with the Introduction to improve your understanding of this post.

While people tend to look at a credit card as an ordinary peace of plastic with a magnetic stripe on it, cards can be of different types and there are many different features about cards. Based on what current and future needs are, a merchant might want to choose a processor offering payment gateway software capable of supporting these features.

Card processing levels

When cards are processed they can qualify for one of the three different levels (for more information check this article ). Consequently, if a business needs, for instance, level III processing, it is necessary to ensure that it chooses a payment gateway supporting that particular feature.

Industry-specific features

Some merchants operate within a specific industry with its special requirements or regulations when it comes to credit card processing. Examples of such industries with respective specific features include restaurants (tips), lodging (incremental authorization), healthcare (support for HSA/FSA accounts). Naturally, these merchants should deal with a processor/payment gateway specializing in their industry and providing support for the required features.

Card present vs card-not-present

All transactions can be viewed as card-present (retail) or card-not-present (CNP) (direct marketing\e-commerce). While many payment gateways support both, it is common for payment gateways and processors to specialize in one of these two types. Therefore, it is important to analyse the needs of a business with respect to transaction types that it has to support.

A business should keep in mind that the following types of transactions are only possible within card-present environment:

  • PIN-debit,
  • electronic benefits transfer (EBT),
  • EMV (Europay/MasterCard/Visa standard for integrated circuit or “chipped” cards).

On the card-not-present side it is appropriate to mention such features as

  • PIN-less debit,
  • 3D secure,
  • online fraud prevention.

Gift cards and loyalty cards support

Other categories of cards that a business might consider supporting are gift cards and loyalty cards. Both types of cards are rapidly gaining popularity, especially in the US, and that is why they should also be taken into account. If a business might require (now or later) support for either gift cards or loyalty cards, the decision-makers should keep that in mind while making a choice.

Merchant’s perspective

In the initial article of this mini-series a health club has been chosen as a merchant example, because it requires support of a variety of credit cards and features for its operations. Due to high competitiveness of the business, a fitness club might need to be able to quickly adopt to the new industry trends, such as, for example, gift and loyalty cards.


To enhance customer experience and to improve member retention, a health club wishes to introduce a gift card program (a loyalty program). The program will enable people to get free personal trainings after a certain period of club membership or after they accumulate a certain number of points through purchases.
If the payment gateway the club is dealing with supports this feature, then the club’s tasks, as well as the whole reconciliation process, are considerably simplified. Otherwise, the club might need to deal with a separate processor (the one that supports gift cards) and reconciliation would involve two different companies.


It is desirable for a merchant to choose a payment gateway, supporting the broadest spectrum of cards and features, currently or potentially required by the business.

Reseller perspective

If a business’s goal is to resell merchant services, the rule is as follows. The more flexible and wide the spectrum of services is, the easier it is to offer and resell these services. Moreover, the ability to offer additional services, beside standard features supported by all other resellers, may provide a competitive advantage for a reseller.


Having conducted a research, a fitness software company realizes that a considerable number of purchases are made online. Consequently, there is a need for a brandable mobile payment application that the software company could use to enable its customers to accept online payments. Partnership with a payment gateway, featuring the built-in support for mobile payments, allows the fitness software company to
grant the service to the clients without any complications, as well as consolidate all types of transactions under a single account and greatly simplify the reconciliation process for the company and its respective merchants.


The more features are supported by the payment gateway, the easier the service sales process will be, and the more money can be charged for standard features (retail, e-commerce), because beside them, additional ones (gift card support etc) will be available.

Our next post will cover fraud protection support as a payment gateway selection criterion.