From Batch to Retail Payment Processing

Introduction

The landscape of modern payment services market is rapidly changing. More and more well established companies, using legacy software, face the problem of expansion of their existing offerings to accommodate the newer needs of the market. One of transition-related issues is the addition of retail functionality to an existing recurring-billing-oriented payment system.

Problem

A well established business, which traditionally functioned as payment aggregator, has recently become a payment facilitator. Its main function is aggregation and facilitation of recurring payments in some industry (membership dues, insurance, installment payments, utility bills etc). Now the company faces the necessity to add a card-present EMV solution to its business offering.

Context

The problem is most relevant to billing companies, which sell their software products to front-end users. Many of such billing software vendors traditionally focused only on card-not-present transactions. They used to function as recurring payment aggregators for a long time, but (under pressure from associations) switch to payment facilitator model. We should remind, that such a transition also allows these companies to get greater control of merchant underwriting process.
On the other hand, under pressure from their customers, they have to add retail component as well as e-commerce processing to their (initially recurring-payment-oriented) payment system.

The pressure from the customers has the following reasons.

Many customers of such companies are brick-and-mortar businesses, which emerged long before online operations became possible. (Recently founded businesses, in contrast to brick-and-mortar ones, operate mostly online and, consequently, do not need any retail components). Some other businesses, representing the clientele of recurring payment aggregators, follow “mixed” operation modes.

Examples

A fitness center receives membership dues as recurring online payments, but sells physical merchandise, such as apparel, foods, drinks, and supplements, at a physical facility. Another example is an insurance company, which collects recurring payments, but wants to be able to collect past due payments and pre-payments in retail environment or online.

In order to be able to accept card-present/EMV payments, some of subscription-based businesses resort to third-party solutions, such as usage of standalone payment terminals. For handling of online payments these businesses can use PayPal or Authorize.net services on an individual basis. However, we should stress, that reconciliation process becomes more complex, as you, potentially, have to reconcile payments handled by multiple systems.

Another issue, faced by recurring billing companies, concerns handling of non-recurring payments. All the payments, made using a standalone terminal (past due payments or pre-payments, for example), have to be, then, manually input into the primary system of record, used for management of recurring payments.

Consequently, in order to ensure greater convenience and flexibility of operations for its customers, the aggregator/payment facilitator has to add both retail and e-commerce processing functionality.

Addition of a retail component, in fact, calls for implementation of real-time processing functionality. As EMV has recently become an official standard for retail payment processing, in a situation like the one just described, implementation of EMV solution becomes a top priority.

In order for your retail payment processing implementation project to be a success, you can use the following strategy, which includes several important steps, and which poses some challenging questions to be answered.

Strategy in brief

You need to understand both business and technological sides of the problem.

Business-related questions are as follows.

  • How are merchant accounts going to be issued? Who will be underwriting them?
  • Which processing system is going to be used?
  • What is the integration cost and how much time will the integration take?
  • What’s going to be the by-rate charged by processor for retail payment processing and what rate will be charged for the merchants?
  • How will funding be handled?
  • How will merchants acquire the necessary equipment? Who will they buy payment terminals from? Is fulfillment center relationship needed? How the terminals are going to be priced (full price/discounts/subsidies)?
  • Which card brands are you going to handle and in which countries?

Technology-related questions are as follows.

  • How you are going to implement a payment terminal solution and go through EMV certification, if necessary?
  • Which architectural changes need to be introduced into the existing system, initially developed exclusively for handling of recurring payments, in order to enable it to support real-time payments?
  • Are you going to use standalone terminals, or do you need to integrate with some POS systems?
  • Will you need only standard terminals or mobile terminals as well?

Strategy in detail

Here (in greater detail) are some important strategic issues to address.

Who will provide merchant accounts for retail payment processing?

Can you stay with your current processor? If your current processor supports different payment modes, such as e-commerce and EMV, can you use them for both recurring and retail payments? If yes, can you provide retail (real-time processing) services as a payment facilitator (the model you are already successfully using for batch processing), or do you need to switch to a different model (say, a retail ISO) to provide retail services? As we explained in our previous articles, under retail ISO model, you will simply resell merchant accounts, while merchant on-boarding and funding will be handled by the processor. If you stick to the payment facilitator model, you will have to handle merchant on-boarding and funding.

If your current processor is CNP-only, should you try to establish a new retail relationship? I.e., should you try to get merchant accounts for retail from a different processor? Does it make sense to move your entire business (both card present and CNP) to the processor that offers all the functionality you need, a better price, and, possibly, some additional services (such as robust merchant on-boarding, chargeback handling, and cross-brand account updater mechanisms)?

How are you going to technologically implement the integration?

Real-time and batch integrations are conceptually different processes. Consequently, no matter, whether you switch to a new processor or stay with the current one, real-rime integration is needed anyway. Moreover, if you need to use EMV payment terminals or mobile devices, you also need to select an appropriate EMV solution. As we mentioned in our previous use case, you have to study hardware options, supported by your specific processors, and, if you want to use your own customized terminal solution, you have to keep in mind fulfillment-related issues.

During the integration, you can either develop the software using your own development team, or use some third-party software product.

How are you going to handle non-recurring payments?

Your existing recurring billing system is, most probably, not adapted for handling of one-time payments. If, conceptually (and architecturally) the system was not intended for support of one-time payments, then addition of non-recurring payment functionality is quite a challenge.

Even if you have the logic to handle one-time cash or check payments, this logic might be too rudimentary to accommodate real-time credit card or ACH processing. Moreover, this functionality is, probably, not fit for handling of complex transaction lifecycles.

Conclusion

Addition of a retail payment processing component to your recurring-payment-centered system can be a major challenge, given all of the items that you have to consider. However, you can consider this challenge as an opportunity to switch to a more standardized and robust payment management platform (such as UniPay Gateway), that will not only solve the current problem, but also improve the overall quality and the capabilities of your existing payment ecosystem.