Payment Gateways: Settlement (Capture)

The purpose of this article is to discuss adequate transaction settlement (capture) mechanisms 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.

Credit card payment processing involves two phases. The first one is authorization, when the card is verified (it is checked whether the necessary sum of money is available on the account) and the money is blocked (reserved for subsequent settlement). The second one, usually taking place at the end of the business day, is capture (or settlement), when the reserved amount is withdrawn from the card-holder’s account and transferred to the merchant’s account (the funds are settled). Therefore, to complete transaction processing, settlement has to be performed.

Settlement mechanisms

In general, there are two settlement mechanisms commonly referred to as terminal capture and host capture.
In the case of the host capture most of the work required to settle transactions is actually done by the host system (payment gateway). When host capture is used, payment gateway (the host) keeps track of all the authorizations and takes care of settlement on its own.

Settlement is generally done:

  • once a day at a fixed time
  • multiple times a day within fixed settlement windows
  • on demand when end-of the day settlement message is received.

Generally, no or minimum information is required from a merchant to use host capture. Terminal capture is usually done by sending a settlement message\settlement file with the full information about the transactions that need to be settled. Terminal capture puts all the responsibility for the settlement logic upon the submitter (merchant).

While terminal capture does provide more control over the settlement process, it is easier to deal with host capture whenever it is possible, because it is easier to implement and support.

From the global perspective all types of settlement can be viewed as belonging to one or two groups: merchant-initiated or time-initiated. Terminal capture and on-demand host capture are merchant-initiated. Settlement, performed daily at fixed time, or several times a day within fixed settlement windows, we are talking about time-initiated host capture.

When choosing the settlement approach, every business needs to consider, what the best option is: merchant-initiated versus time-initiated, and host capture versus terminal capture.

Merchant perspective

In each particular case it is important for a merchant to consider all the business needs while making a choice between terminal capture and host capture mechanisms, as host capture may not support certain features needed by the merchant.

Example

A fitness club, that works 24 hours, has three shifts of employees changing during the day. There is a common practice of settling out all of the transactions that were authorized during a shift when a shift is closed. In a situation like this, the scheduled settlement (without end-of-day message) is unacceptable for the merchant, as it has to be performed several times during the day, not necessarily at a specific time. Consequently, dealing with a processor\payment gateway, which supports only scheduled settlement, will be problematic for the fitness club.

Conclusion

While the preference is usually on the host capture side, merchants need to check if it fits their business model, and, at the same time, whether all the necessary features can be accommodated by the host capture system (as some features might be supported by payment gateways only under terminal capture).
If all of the features necessary can be accommodated by the host capture mechanism, it is really the preferred way of settlement.

Reseller perspective

As in the cases of other payment gateway selection criteria, while choosing a settlement mechanism, a reseller must carefully analyze the needs of the merchants it is dealing with.

Example

One of the potential problems to be addressed by a reseller may be that each merchant might need some business specific logic. Particularly, if a payment gateway can perform settlement for a merchant at the same predefined time during the day, and merchants are situated in different time zones, it might be difficult to adjust time settings for each merchant individually to ensure proper settlement time for each timezone. Consequently, in such cases it may be easier for the reseller to delegate control of the settlement process directly to the merchant (terminal capture), than to adjust time settings to every merchant’s time zone (host capture) with the payment gateway.

Conclusion

While making a decision concerning settlement mechanism selection, a reseller should consider all the aspects, which are critical for a merchant. However, if resellers accept some limitations in order to simplify the integration process, they need to understand that any problems resulting from these limitations will be multiplied by the number of the merchants the resellers are dealing with.

Our next post will cover standard credit card features to be considered during payment gateway selection.

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.