Payment Gateways: Integration Process

The purpose of this article is to discuss ease of integration with a credit card processor’s payment gateway software 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.

While some processors/payment gateways offer good rates to merchants, the cost of integrating with them might offset the savings on going with the “lower-rate” processor/payment gateway. This is especially relevant in cases when there is an already-established merchant relationship and a new player comes in with an alternative option.

The two aspects of integration

When it comes to integration, the things to be considered are the connectivity method and the format of the integration specification.

Communication Protocol

What matters is not only how the message itself is formatted, but also how it is communicated. Some of the processors may still use older (pre-HTTPS) technology and might require low-level socket communication. Virtual private network (VPN) connectivity might be needed, and it takes both time and money to put in place. At the same time, the cost of putting the VPN in place, as well as the time frame that it takes, might not be in line with what a business can afford.

Message Format

In terms of message format, many newer payment gateways support XML/JSON-based formats (web-services/direct post) for real-time processing and simple delimited file formats for batch processing (real-time vs batch processing will be covered in one of the next posts). These modern formats are a lot easier to deal with than the ones used on legacy platforms.
On the older legacy platforms businesses may be required to deal with ISO-8583 or other older formats, which are a lot more difficult to understand and implement. For instance, an integration with a payment gateway using XML message format can take as little as 3-4 days (or more, depending on the features to be implemented), while an integration with a payment gateway using ISO-8583 format will take at least 2-3 weeks.
Beside that, the skills of a developer (and consequently the integration cost) will be higher for the projects that deal with legacy platforms and older standard based technology.

Merchant perspective

It is important for merchants to analyze the scope of integration works, their cost and time frame before making any decisions affecting their existing processing mechanisms and infrastructure.

Example

A health club is already processing cards with payment gateway “SuperPayments”. Then it gets an offer from another payment gateway “SaveOnPayments” allowing it to save $5,000 annually on processing if the club switches to its services. But the cost of conversion (integration with “SaveOnPayments” gateway) might end up being $10,000. While the club would start saving money in the year 3, the first two years would go at loss. Consequently, the club’s management has to think carefully about whether it makes sense to do this.

Conclusion

With all of the above taken into account, the recommendation for merchants is as follows: choose the processor/payment gateway that uses modern communication technology communication and easier-to-deal-with message formats, i.e. go with someone who is new and not archaic.

Reseller perspective

In general, problems faced by a reseller are very similar to concerns of a merchant. However, a single merchant’s inconvenience in day-to-day operations, arising from legacy platform usage, might be multiplied 200 times in the case of a reseller dealing with 200 merchants. That is why in some situations it is more reasonable for resellers to invest money in modernization, in order to reduce future operations’ support cost.

Example

A fitness software company is successfully dealing with a processor\payment gateway using a legacy platform operating ISO-8583 format. Once the term of the contract with this processor comes to an end, the software company decides to consider alternative options and, possibly, go with another payment gateway, which uses modern technology. Initial estimates show that integration process will take about two weeks and cost $8,000, but after the integration is done, fewer development resources will be required, so that in a month or two savings on maintenance will compensate the integration expenses.
Beside that, usage of a modern technology makes it easier to research various types of customer inquiries that might occur during day-to-day operations.

Conclusion

Just like merchants, resellers are recommended to select processors\payment gateways, which use modern communication protocols and provide simple integration APIs. At the same time, while it is important to consider integration costs, resellers need to take into account the cost of operations’ support as well.

Our next installment will cover settlement (capture) mechanisms.

Payment Gateways: Processing Costs

The purpose of this article is to discuss credit card transaction processing cost 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.

Although processing cost is not the only factor to consider while selecting a processor, it is nevertheless, extremely important. Understanding the processing cost anatomy is not easy. For more information on credit card processing costs, fees and rates, refer to this article.

Processing cost components and transaction pricing strategies

To put it shortly, processing cost consists of base costs (which include interchange fees and assessments) and markups. Within card processing cost it is mostly markup that is negotiable. The three pricing strategies predominant in the industry include: “cost plus” (also called “interchange plus” or “pass through”), tiered (or bundled) pricing and blended rate. Every other pricing strategy, after closer consideration, usually turns out to be a variation of these three.

Blended rate pricing

Blended rate pricing strategy is the easiest to understand; it does not take the differences in card types and transaction costs into account at all. Under blended rate pricing, the processing fee is usually established as an average processing cost plus some fixed markup.  In other words, regardless of the card type, the same price is charged for every transaction.

So if a business has a good variety of cards it is constantly dealing with, under blended rate pricing these differences don’t matter much. But if a merchant knows that some card types are predominant in the transactions processed (for instance, the  business is dealing mostly with debit cards), then this merchant is going to consistently overpay.

Tiered pricing

Tiered pricing, in essence, is an extension of blended rate pricing model, where transactions are assigned to different tiers. These “tiers” or “levels” are defined by ISOs/processors based on transaction qualifications, card types or other factors. The problem with tiered pricing is that the processor’s scheme of transaction qualification may be really difficult to understand. And without understanding it, a merchant would often be unable to predict the cost of a transaction before it settles. At the same time, even with multiple tiers, some averaging of cost still occurs (similarly to blended rate model) and, consequently, there remains a risk of systematic overpayment by a merchant.

Cost plus

Cost (interchange) plus is the most transparent of credit card processing pricing models, because the processor’s markups do not depend on base interchange.  All markups are charged as a fixed rate fee on top of true cost, which comes from an association (Visa, MasterCard, etc) for every transaction.

Merchant Perspective

Naturally, any merchant will look for a processor offering the most cost-efficient pricing model. While considering the processing cost, it’s important to remember that different transactions cost differently. In general, some transactions (as a group) will cost cheaper to process than others. For example, debit cards would cost considerably less to process than reward cards (or credit cards with cash-back option), and swiped credit cards would qualify for a lower rate than keyed cards. A merchant would want the processing fees to be structured based on true cost. Actually, a merchant would wish the final cost to be as close to the true processing cost as possible, with the above-mentioned differences in transaction costs (interchange qualifications) taken into account.

Beside the price that the merchant gets quoted, the merchant also needs to think about the types of cards it processes (debit or reward, keyed or swiped, etc) and fee structure that is offered. Any merchant would definitely want to go with someone whose pricing model reflects the differences in card types.

Example

The health club chosen as an example is going to be dealing with a variety of cards, but might be heavier on the card-not-present side (all membership dues are collected as card-not-present). To optimize the cost it would be best for it to go with a processor providing “cost plus model.

Conclusion

In general, the advice to a merchant who wants to get a transparent and flexible model reflecting card type differences is: go for “interchange plus” pricing. The recommendation is especially relevant for those who are more on the debit cards side.

Reseller Perspective

Traditional types of resellers (such as ISOs) are generally interested in flexible and affordable pricing structure. Software companies acting as resellers might also be interested in the ability of the processor\payment gateway to combine software fees and processing fees.

Example

Usually, software companies tend to charge separate fees for software usage and separate fees for transactions processing services. For instance, a fitness software company wanting to offer merchant services to its customers could charge a certain amount in dollars per month for software (say, $100 per location) plus optional 2.5 % for processing. However, in today’s environment it might be more beneficial from the marketing standpoint (and more profitable) to offer managed processing at 5 % with software included for free.

Conclusion

In general, a reseller should prefer to partner with the processor\payment gateway offering “cost plus” pricing model, as it makes it easier to price and resell, and seems to be more appealing in today’s market.

Those resellers interested in charging their service fees as part of the processing costs should consider processors\payment gateways capable of accommodating this.

Our next installment will be dedicated to ease of integration with different credit card processors\payment gateways.