Read and Connection Timeout Handling

The purpose of this article is to familiarize merchant services industry players with the mechanisms implemented in payment gateway software for the cases when transaction processing becomes impossible due to temporary loss of connection with the “back end” (for instance, a bank) or due to some other errors.

Problems with transaction processing might be caused by one of the two conceptually different reasons: timeouts and errors.

The first potential reason is a so-called timeout. Essentially, timeout means that there is a connection problem.

There are two types of timeouts sometimes referred to as ‘socket timeout (or connection timeout)’ and ‘read timeout’.

The key differences are as follows.

Connection timeout

Connection timeout usually occurs within 5 seconds. Connection timeout indicates that connection with the back end is impossible, and the server, to which the data needs to be transferred, cannot be reached. Issues with connection can be caused by DNS problems, server failure, Firewall rules blocking specific port, or some other reasons. In such cases the, a backup (or secondary) URL can be used (if available). If no connection can be established through either URL of a given service, further processing of transactions is impossible. It is important to note that no information is communicated to the host server when connection timeout occurs.

Read timeout

Read timeout usually occurs within 40 to 60 seconds. Read timeout occurs when the socket is open, connection to the host server is established, the request is sent, but the response from the server is not received on time, and cannot be read. Since the authorization request has already been sent, the transaction may have been processed (and approved), but, possibly, some error has occurred on the way back from the host server. As there is no clear response, there is a risk of charging the customer for the second time (if transaction is reattempted).

There are two approaches that are used by integrators to deal with situations like the one described above. These approaches are, generally, referred to as ‘authorization and capture’ (explicit or implicit capture) and ‘timeout reversal’.


The basic premise of authorization-and-capture approach is that any authorization processed has to be subsequently captured (confirmed) by an additional request. If timeout occurs, the submitting system does not send out the confirmation (since it never got the response), and, consequently, the host system reverses the authorization (because it has not been confirmed).

The capture operation can be executed in one of two ways: explicitly or implicitly. In case of explicit capture a separate ‘capture’ request is sent to the host server to confirm a previously successful authorization. In case of implicit capture, the reference number of the previously successful authorization that needs to be captured, is included as part of the subsequent authorization, or as part of the final settlement call.

In other words, in case of explicit capture the authorization request is submitted as one message and capture is sent as another separate message, while in case of implicit capture, authorization request is submitted as one message, while capture message (reference number of the successful authorization) is included in the authorization request of the next transaction. The final (end-of-the-day) message includes reference number of the last transaction which needs to be captured (confirmed).

Implicit capture is not recommended when time-initiated host capture is used.

Timeout reversal

Another approach is to explicitly reverse transaction with a host if a timeout has occurred. When a read timeout occurs, one or more attempts to reverse (or ‘void’) the authorization that timed out is made. When a transaction is submitted, and timeout occurs, it is assumed that the problem is temporary. In some cases up to three reversal attempts are made, each 40 seconds apart. It is assumed that within the next 160 seconds (40 seconds – initial waiting, plus 3 reversals) the problem of connection with the server will be resolved. If authorization is successful, subsequent reversals will void it (so that the customer will not be accidentally charged).


When a company integrates with some payment system (especially, if it plans to submit large transaction volumes in real time), it needs to consider and test the system’s processing strategy, keeping in mind the issues, related to read and connection timeouts.

PINless Debit Card Networks

The purpose of this article is to familiarize the key merchant services industry players with the advantages of integrating with PINless debit card networks.

The largest credit card associations, such as Visa and MasterCard, maintain large card networks through which payment card transactions can be processed. When a card transaction is processed, card network charges a certain interchange fee for handling of the transaction (more detailed information on transaction processing cost models and structure can be found in our respective article).

Some banks also created their own card networks called debit networks. For instance, every US-issued card, including those, carrying Visa or MasterCard logo, can be processed through at least two debit networks. Generally, a logo of a debit network, which can be used with a given card (for example, Plus, Interlink, etc.), can be found on the reverse side of the card. ATMs often work through debit networks as well, and usually, logos of supported debit networks are shown on the ATM.

Traditionally, there was an advantage for a merchant to integrate with PINless debit card networks, for several reasons, including funding delays. The primary reason, however, was considerable saving on the interchange cost as compared to the cost of equivalent transaction processed through Visa or MasterCard network.

In 2011, after Durbin Amendment (initially designed to reduce the burden of fees imposed by processors on merchants) was adopted, Visa and other associations were required by law to reduce the maximal interchange rate which they were allowed to charge for debit card processing.

If previously Visa could charge 2.5 to 3 % of transaction’s amount for debit card processing, after the Amendment the maximum interchange amounted to 0.95 %. After the Durbin Amendment was adopted the price difference for merchants integrating with PINless debit card networks versus regular card networks would only represent 10 to 20 basis points. As a result, some merchants, who were previously interested in and considered the prospect of PINless debit card network integration, changed their minds and lost their interest, because potential savings of 10 to 20 basis points could not provide a sufficient incentive (especially, for small and medium-sized merchants).

Although for small and medium-size merchants the advantage of PINless debit card network integration became really insignificant, on large processing volumes even 10 basis points still make a difference, especially in view of pricing wars, witnessed by modern merchant services industry.

Another advantage of debit networks, which still remains relevant, is that there is no policy around chargeback handling in PINless debit networks. If the transaction is processed, the funds cannot be charged back and the transaction cannot be disputed. Consequently, many companies (of all sizes), experiencing problems with high chargeback rates can still find integrations with PINless debit card networks. Even if transaction processing through PINless debit networks does not yield significant additional revenues, the option is still more relevant than processing through Visa and MasterCard networks. As we mentioned in some previous articles, 1 % of chargebacks can put the merchant into the Terminated Merchant File (TMF), and out of business. If some of the cards are processed through a PINless debit network, chargeback rates (as well as percentage of chargebacks resulting from transactions processed through regular Visa and MasterCard networks) decrease.


In spite of the limitations, imposed by the Durbin amendment, if you are a merchant, experiencing problems with high chargeback rates, and\or if you process significant dollar volume, PINless debit card network integration might still be a good solution for you.

4 Cs of Recurring Billing

The purpose of this article is to explain the key mechanisms a business must put in place to implement a coherent recurring billing solution. While in one of our previous articles we described the 3 Cs (creation, conveyance and collections) from a general transaction processing perspective, in this post we are going to focus on recurring billing processing and define 4 Cs of a recurring billing solution.

Each of the Cs reflects a certain aspect of recurring payment processing.


As we mentioned in the article on 3 Cs, creation of payments is associated with a system, from which these payments originate. The key elements around the creation phase of a recurring billing solution are:

  • Subscription Types. Subscription types reflect various service and product options offered by the merchant.
  • Payment Plans. Payment plans reflect specific payment arrangements (frequency of payments’ recurrence etc)
  • Payment Methods. Payment methods include electronic form of payment to be used in recurring billing process
  • Payment Page Security. This aspect incorporates means for capturing and secure processing of cardholder data. Detailed information on payment pages can be found in the respective article.


It has been mentioned that compliance is a critical issue in recurring billing context, as recurring billing requires cardholder data to be stored somewhere in order for subscription-based business to be able to access it at regular intervals, when the actual billing takes place. Detailed information on PCI compliance requirements can be found in the respective article. The items to consider in the context of compliance are:

  • Card Data Storage (who is going to store cardholder data and how it will be stored). Cardholder data storage options are described in the respective article of our blog
  • Tokenization. One of the most common solutions for PCI compliance is tokenization. As we described in our respective post, tokenization is a flexible mechanism allowing companies to reduce their PCI scope or even get out of it completely, while still being able to process recurring transactions. The company must decide, how to implement tokenization in order to make PCI audit as smooth as possible
  • Data Ownership. The inherent problem of tokenization is the ownership of cardholder data. Ownership (and, particularly, change of ownership) of cardholder data is a tricky matter, especially, when it comes to third-party tokenization. If the company uses tokenization services, provided by some external entity, and wants to switch to another tokenization services provider, the original provider might claim the ownership of cardholder data and refuse to handle it to the new provider. In order to avoid situations like this one, data ownership and related matters must be taken care of and agreed upon in advance


As we mentioned in the article on 3 Cs conveyance of payments concerns relationship with payment gateways through which transactions will be submitted to the processor. Conveyance of payments calls for implementation of the following important aspects and relationships in the recurring billing system:

  • Soft Descriptors. Implementation of soft or dynamic descriptors is an important issue, particularly in recurring billing context. The soft descriptors allow customers who have multiple subscriptions (or those who subscribed to a service a month ago) to recall which particular subscription they are charged for, when the statement arrives. Soft descriptors are also an essential feature to be implemented by companies, using aggregation model, as they include the descriptions of the aggregator, the merchant, and the transaction itself. In all described cases implementation of soft descriptors allow companies to avoid chargebacks, erroneously issued by customers
  • PSPs, Acquirers. The company needs to decide, who is going to underwrite its own merchant account or merchant accounts of other businesses that it will be servicing. Respective relationships with PSPs and acquirers must be established, taking into consideration not only pricing, but also the need for different currencies and overall feature set.
  • Gateways. If a company decides to use a payment gateway, it needs to carefully consider the choice of a particular payment gateway solution (hosted, licensed or in-house), which is most suitable for the company’s business model.
  • Direct-to-Processor. Usage of hosted gateways is undesirable when a direct-to-processor integration is necessary. In this case the company needs to find some licensable payment gateway software that can be used to simplify the integration process
  • Hybrid. If the company needs a combination of gateway and direct-to-processor integrations, it also has to implement the optimal (in terms of value-for-money) combination of the respective approaches


Collections of payments calls for implementation of the following items:

  • Reconciliation. Even in the most basic processing scenarios (for example, a gateway for credit cards and a bank for ACH) the entire process of reconciliation (matching of what was processed to what was received as a deposit from the processor) needs to be thought through. The company should implement the most flexible and transparent reconciliation mechanism
  • Decline Management. Decline handling is of particular importance for recurring billing, because if transaction declines, future recurring billings may not be possible. At the same time, contacting cardholder all the time is an expensive process. Some type of retrying\recycling\rebilling mechanism should be defined and implemented beforehand to minimize interactions with the customer.
  • Credit Card Updater. A typical reason for a decline is outdated credit card information (expired card). A common solution to this problem is implementation of credit card updater functionality (described in the respective article on decline recycling) as part of the decline recycling process
  • Customer Communication. No matter how good your decline recycling mechanism might be, some contact with the customer is still unavoidable. Therefore, it is essential to think through the customer communication process and the rules that the agents will follow as they call upon customers trying to collect declined transactions
  • Dunning Management. In some cases communication with a customer proves to be ineffective and debt has to be collected in some other way, be it through additional calls or e-mails, or via some third-party collections company. Some companies might prefer to drop the account and terminate the service while others may engage the services of a third-party collections company to still collect the debt. It is advisable to define collections strategy before getting the actual subscribers. In our respective article collections process is described in greater detail
  • Charge Back Management. In order to preserve its good reputation and avoid getting into the Terminated Merchant File (TMF), any company must keep the number of chargebacks issued by its customers at the minimum. In some cases even detailed soft (dynamic) descriptors are insufficient. Therefore, the company needs specific mechanisms to obtain chargeback information as soon as it is available, as well as to have a process to respond to inquiries and dispute chargebacks (these matters are addressed in the respective article).


In order to implement recurring billing it is not sufficient for a company to just find some recurring payment platform, which will regularly charge certain amounts from the clients. All aspects regarding creation, compliance, conveyance, and collections, must be taken care of in advance. Consequently, all technical features must be analyzed, appropriate business relationships (for underwriting etc.) should be established, and all processes around decline recycling and payment collection should be defined.

Merchant Fraud Protection Tools

The purpose of this article is to familiarize payment service providers and other merchant services industry players with various merchant fraud protection tools. While one of the previously published articles covered consumer fraud protection tools (from merchant’s perspective), the current article is mostly targeted at PSPs who have multiple merchants in their portfolios, and, consequently, require efficient merchant fraud protection tools to ensure stability and security of their operations.

Information on the nature of merchant fraud can be found in our articles on fraud protection aspect of payment gateway selection, chargebacks and ACH returns.

Merchant fraud protection systems are often incorporated in payment gateway software products. They are based on various criteria for monitoring of each merchant’s transaction processing activity. The incoming flow of transactions is analyzed and checked against these criteria on some regular (usually, daily, or monthly) basis. If some deviations take place, they are immediately flagged, underlying merchants or transactions can be identified, and any necessary measures can be taken as efficiently as possible.

Let us now look into the fundamental criteria, providing the conceptual basis for merchant fraud protection tools.

Some criteria are analyzed on daily basis as well as on month-to-date basis. For instance, maximum transaction amount is a criterion analyzed on daily basis only, while maximum processing volume can be analyzed both daily and monthly.

For every particular business, depending on its nature, a limit is, generally, established for one or more criteria. If the limit is exceeded, the incident is analyzed, and, if necessary, respective measures are taken.

Maximum allowed processing volumes

General transaction volume as well as transaction count are analyzed. At the basic level, maximum and minimum transaction (ticket) amount, which a merchant indicated in the merchant application, are monitored. Significant deviations from these values might indicate some type of merchant fraud.

Maximum deviation from averages

Generally, most businesses follow similar processing patterns from day to day and from month to month with no deviations from average. If any significant deviations from average are registered, they are considered a signal for checking the specific case behind the deviation. Normally, permitted deviations amount to approximately 5-10 %. If this limit is significantly exceeded, it may raise suspicions. Deviation limits should be observed in an average per-transaction amount, average daily (monthly) transaction count, and average daily (monthly) processing volume (in dollars). Generally, 60-day window is used for daily averages, and 12-month window for monthly ones.

For some types of businesses deviations from average are typical (for instance, seasonal or induced by sale of some highly-demanded product), so the criterion is not always a decisive one, but in some cases it can be helpful.

Fraud suspects

One of the signs, which may cause suspicion, is a large number of so-called micro-transactions (below $1). In some situations a large number of even-amount transactions can also be a sign of fraud. For example, if a merchant is a retail business and transaction amounts usually include taxes, an even-amount transaction is rather an exception, than a rule, while for e-commerce businesses even-amount transactions are more common.


Duplicates can either signify actual fraud or just a human error. Duplicates can be analyzed according to several criteria.
For some businesses too many transactions with the same amount are untypical, so this is the case when they might signify fraud. On the other hand, some businesses offer a limited number of products\subscriptions, and for those businesses many transactions with the same amount are common.
Another duplicate-related criterion is the number of transactions associated with the same card number. If the number is too large, it may be a sign of fraud.
In some cases a large number of transactions with the same amount paid using the same card (a combination of the two criteria) during a short period of time (say, a day) may also signify fraudulent activity.

Transaction types

Unusually high percentage of transactions of a certain kind in the overall transaction volume is another representative indicator. If maximal allowed percentage of credits, refunds, verifications (“zero-dollar” transactions), declines, ACH returns or chargebacks is exceeded, it may be a sign of merchant fraud being committed.

Entry mode

In terms of card entry mode there are three basic card transaction groups: swiped, keyed and CNP. If some type of entry mode is dominant for a business, a sudden increase in the number of transactions with a different entry mode may signify fraud.

Off-hours transactions

Some transactions may be submitted during the time, when the business is normally closed (for example, before 8 am or after 8 pm).
For some businesses after-hours processing is acceptable, but unusually large number of transactions submitted after hours may be a sign of potential fraud.
If transaction volume is, usually, consistently distributed across the merchant’s working schedule (for instance, most transactions happen in the morning), sudden shifts in this distribution may also seem suspicious and, potentially, indicate merchant fraud.

Merchant inactivity period

Some merchants stop processing transactions, but do not close their merchant accounts. Such merchant accounts can, potentially, be used by fraudsters. Consequently, the number of days during which there is no activity on the account, should be monitored, in order to prevent potential fraud due to merchant’s lack of attention.
Absence of activity does not signify fraud, but rather, indicates that the merchant is not using the account any more.


Some merchants normally process transactions only on certain days of a week or a month. If such a pattern is broken (for example, a merchant normally processes on Monday, and now there is activity for entire week, or a merchant, normally processing transaction for 20 working days a month, suddenly starts processing for the whole 31 day, it may indicate fraud).


Monitoring of potential merchant fraud signals is critical for payment service providers, which service large numbers of merchants, and assume financial risk and liability for the merchants in their portfolios. In order to efficiently prevent fraud, such businesses need to utilize merchant fraud protection tools.

Visit the UniPayGateway website if you are interested in the diagram illustrating this topic

Hosted, Licensed and In-house Payment Gateway Solutions

With the advance of electronic payment industry and online payments in the world, and with the increase of online payments’ percentage in the total number of payments, more and more companies are redefining their online payment processing strategies.

In order to become a payment service provider, a business needs to consider three aspects of the payment processing sometimes referred to as creation, conveyance and collection (this is the subject of our previous article).

When a business has established relationships with customers and banks, the question becomes – what particular payment gateway solution should be implemented?

The purpose of this article is to review the available payment gateway solution options as well as analyze advantages and disadvantages of each one of them.

While we previously published an article that reviewed payment gateway solutions on higher level, this time we are going to take a more in-depth look, adding another option to the “mix”. The three options we are looking at are:

  • Hosted gateway solution (“Hosted solution”)
  • Development of a payment gateway software system using internal resources (“In-house yourself”)
  • Licensing of a payment gateway software product from a third party (“Licensed solution”)

Hosted payment gateway solution

Under this option a merchant utilizes a third-party payment processing gateway, the gateway software product is hosted within the data-centers owned by the gateway service provider; per-transaction fees (and, usually, some monthly fees) are charged to the merchant.

The advantages of a hosted solution are:

  • Absence of significant upfront cost involved
  • No need for PCI-compliant infrastructure
  • Out-of-the-box high availability support
  • Overall ease of operation

The disadvantages of a hosted solution are:

  • Per-transaction and, potentially, monthly subscription fees that are felt sharply as volumes grow
  • Limited control over the processing environment
  • Lack of control over the feature-set and inability to add new features quickly
  • Potentially high cost of adding new features
  • Inability to keep specialized knowledge (such as solutions for your business-specific needs) in-house (as it becomes the property of the “host”)

For these reasons many people decide to have there own in-house solution. Here there are two options available. Solution can either can be built by an internal team (from scratch), or it can be licensed.

Self-developed payment gateway solution

The idea of a self-developed (in-house) solution is that the entire gateway software product, as well as the hosted environment is designed, built and maintained by the internal team.

The advantages of a “do-it-yourself” solution are:

  • Tailored system architecture. The system, from its “point of conception” is going to be built around the business model specific to you, and, therefore, is going to accommodate your various business needs
  • Uniqueness. The system is going to be unique to you (nobody else is going to have it, so specialized knowledge can be kept in-house as a “know-how”; features, functionality and APIs remain yours exclusively)
  • Full control over the development cycle and overall payment eco-system

The disadvantages of a “do-it-yourself” solution are:

  • A need for a group of specialized developers. Development of this type of systems, due to their complexity, requires a group of people with highly-specialized knowledge of payment processing and architectures of payment systems, as well as development skills.
  • Long initial development cycle. Depending on the complexity of the software that has to be written, it can take from 1 month (in extremely basic scenario) to 2-3 years (in case of an enterprise-level system). One to five full-time developers with specialized knowledge (see above) will have to be engaged during that period.
  • Complexity of cost forecasting. Modern payment gateways, generally, provide a multitude of features around integration APIs, on-boarding, integrations, reporting, terminal support etc. The overall scope of works is quite significant. Therefore, it might be difficult to forecast the actual cost from the very beginning, as development efforts tend to extend beyond initially allocated limits.
  • De-concentration of efforts. Quite often companies requiring payment gateways also develop and maintain their own core software product, so if payment system development is undertaken internally, some part of the internal development team has to be dedicated to payment processing as opposed to core product functionality.
  • Complexity of operations. All aspects of development and deployment have to be considered and closely monitored (core functionality, general architecture, technologies to use, high-availability deployment (clustered configuration, fail-over configuration), card storage solutions, PCI compliance)

For those that find themselves in a situation where they can’t wait to get an internal development team or they don’t want to get involved in complex development process, licensed solution can be a more suitable option.

Also, in many cases companies in need of payment processing are purely financial services companies, and for them software development services is simply an “alien” type of activity.

Licensed payment gateway solution

In a licensed solution payment gateway software is licensed from a third-party software development company, which deploys and maintains the product to a PCI environment owned by the licensee. The environment can be cloud-based servers or the licensee’s internal data center.

The advantages of licensed solution are:

  • Out-of-the-box functionality. A ready-to-use solution available on Day 1 with pre-defined set of functions. The product is already developed, and most of the aspects are already thought through (APIs already defined, general architecture is designed, there are integrations available out of the box, the approach for PCI audit is already defined, and high-availability deployment configurations are already provided). Beside that, licensed offering, usually, comes from a software company which provides professional services, including customized development. Consequently, you don’t need an internal development team, while you still benefit from the contributions that are made by other people because of the overall development of the product
  • Availability of development resources. Under licensed solution your own development team can concentrate on your core product, while payment processing related works can be outsourced.
  • Fixed initial cost. The initial cost is not only fixed, but also, generally, lower, than the cost of building equivalent functionality in-house.
  • Benefit of collective contribution. The product is based on feedback from multiple companies using the solution, therefore, if some feature becomes popular, it might get implemented in the product without the explicit investment of the licensee (paid by someone else)

The disadvantages of a licensed solution are:

  • Reliance on a “third party”. Choosing a third-party product you assume the software providers to be there for you when you need them. If the product is sunset, you are no longer getting any product updates or might not even be able to use the product
  • Excessive feature set. The product might come with numerous features that are not necessarily needed, and, because of that, it might be difficult to use
  • Inability to leave the know-how in-house. Like in case of a hosted solution, if you have something highly specialized “for yourself”, you’re obliged to share it with the external development team (licensor)
  • Potential inconsistency with the business model used. Some features might be conceptually incompatible with the current business model your company is using, and you are not necessarily in the position to change them


For those, whose budgets are limited, hosted solution is a preferable option. Those, who already use a hosted solution, may consider the option of switching to a licensed one, but in this case they need to choose from among commercial open-source products, as these reduce some risks, because the source code is available for purchase.