3 Cs for Payment Service Providers

The purpose of this article is to explain some essential components and mechanisms needed for a business to become a payment service provider.

With the increased use of electronic payments worldwide, there are more and more companies that are contemplating the idea of becoming payment service providers. However, many people, pondering the idea, lack the conceptual understanding of the essential components of the process that have to be implemented in order for these potential payment service providers to be able to operate.

There are three aspects to the formation of a payment service provider that can be called creation, conveyance and collection each dealing with various types of relationships, namely relationships with future clients (merchants), payment gateway provider(s) and an underwriting banks/processors.

Creation

The 1st group of relationships consists of the actual merchants and, in many cases, software vendors, through which the future payment service providers are going to service these merchants.

Basically, creation aspect of the process deals with the systems from which transactions originate. Some software products are necessary to originate transactions (for processing) or subscriptions (for recurring billing).

In case of a payment service provider servicing charities it might be as simple as just a web-site, a single page which will accept credit card donations and pass them on for processing. In the opposite “extreme” case, it can be as complicated and elaborate as an enterprise-scale POS or recurring billing software system.

Conveyance

The 2nd group of relationships involves either a gateway software provider, or a gateway services provider. A gateway software provider is a company that is going to supply gateway software product, while the gateway services company is going to provide the hosted offering for the gateway.

Conveyance of payments is conducted via a payment gateway through which payments are actually delivered from the originating system to the transaction processor.

Usually, PSPs will need to communicate with a multitude of payment processors and banks as well as with a multitude of the originators of the transactions (or, usually, the customers of the PSP – other software companies, POS vendors etc.). Consequently, there is a need a unified API and a unified approach that the originators could use to potentially communicate with a multitude of back-end processing systems.

That is where the need for a payment gateway software, or a payment gateway services provider (a.k.a. payment gateway) comes from.

In addition to gateway software provider, the potential future PSPs will also need to work out the PCI compliance strategy.

Collection

Lastly, the 3rd group of relationships will be banking relationships, i.e. banks willing to underwrite merchants and facilitate the process of subsequent merchant funding (settlement).

Collection of the payment is the phase during which the payment is actually processed and the merchant is funded. It requires a relationship with a bank.

Unless a PSP has direct relationships with card associations, it will need to rely on an existing account underwriter, usually a bank. While there are different arrangements around who takes/accepts the underwriting risk, some third party would be required to verify and approve the initial merchant application, and subsequently facilitate actual money transfers that follow settlement of authorized transactions.

Conclusion

While many people, who come from the small-business transaction-processing world tend to see the creation/conveyance/collection system as one complete piece (such as PayPal or Authorize.Net), in reality, there are 3 separate aspects involved, and any business wanting to become a PSP will need to search for solutions specific to each of these aspects.

What is payment gateway software?

What is payment gateway software?

Payment gateway software is a server application facilitating exchange of payment related data (cardholder and transaction information) between a merchant and a payment processor or an acquiring bank. For example, payment gateway software can provide connectivity between merchants’ POS systems and a legacy processing platform used by some bank; often it also handles PCI-compliance-related issues, such as credit card tokenization, reducing merchants’ PCI scope exposure.

What is a licensed payment gateway solution?

In case of licensed payment gateway solution a company (a merchant or a payment service provider) licenses, either in a binary form, or in the form of software code, a payment gateway software from another company and deploys it within its own PCI-compliant infrastructure.
It allows the licensee to have greater control of payment gateway infrastructure. Licensed payment gateway cost is more significant upfront, but subsequent use of the payment gateway solution doesn’t impose any per-transaction processing fees.

What is a hosted payment gateway solution?

In case of hosted payment gateway solution a merchant (payment service provider) uses (“white-labels”) an existing solution that resides within a PCI-compliant environment of the hosted payment gateway provider. This payment gateway solution does not require merchants to incur any gateway maintenance costs or to have their own PCI-compliant environments, but merchants do have to pay per-transaction processing fees. In case of hosted solution the merchant might be required to go through payment gateway integration before transaction processing is possible. More information on hosted and licensed payment gateway solutions can be found here.

What is a white label payment gateway?

White label payment gateway is a hosted payment gateway solution, which is sold by a company under its own brand, while the actual service provided by one of its vendors on sub-contractual basis. The white label payment gateway concept allows the company to bolster its image in the eyes of its customers by providing a new critical service under its own brand. More information on the subject can be found here.

Becoming a Payment Service Provider

The purpose of this entry is to review the key elements which a business needs to consider to become a payment service provider.

Many ISOs and payment service providers after several years of operations realize that they can significantly reduce their costs and optimize their processing if they rely on their own payment management platform.

However, taking everything in-house may be a challenging process because of the complexity, associated with payment processing and PCI compliance.

In this article we are going to cover the essential components of the process and the challenges of getting your own payment gateway.

Payment gateway software selection

First of all, a business wanting to have its own payment gateway solution (white-labeled or exclusive) will need some payment gateway software.

The options might be to build some software in-house, to buy some connectors and integrate them into an existing customer management product, or to license an already existing payment gateway software. When it comes to existing payment gateway software, the two common options are: to license the software and self-host it or to use a hosted version. For more information, see articles on payment processing solutions and payment gateway solutions on our blog.

The next step in the process is to decide on PCI environment where the payment gateway software is going to reside.

Payment service provider hosting

To become an independent payment service provider, a business can either implement its own server infrastructure or use a PCI-compliant hosting (such as firehost or rackspace).

Self-hosted server infrastructure implies maintenance of a data center, availability of development personnel and annual PCI-audit. PCI-compliant hosting, on the other hand, works in the same way that a general VPS hosting (thus eliminating the need for data center and network engineers), except that the servers are located within an already PCI-compliant network.

Because of the additional PCI requirements, servers at PCI-compliant hosting are more expensive than an equivalent configuration in a non-PCI-compliant environment.

PCI compliance and card storage

An important consideration the business needs to take into account on the way to becoming a payment service provider is PCI compliance. The business will need to find the suitable PCI-auditor company, determine the scope of PCI-audit and request quotes from the preferred service provider (assessor). Examples of possible partners include security metrics and coalfire .

One of the challenges to overcome within the context of PCI-audit is the strategy for credit card storage. If you consider using some form of appliance-based tokenization, the cost of the appliance needs to be factored into the overall estimate. For additional information on tokenization (either through appliance of as service), check the respective article on our blog.

Selection of banks and processors

The final issue to be addressed is the selection of banks and\or processors which will be actually processing transactions.

In some cases becoming a payment service provider will require integration with other payment gateways, credit card processors and\or banks. In case you decide to license a payment gateway software from a third party, it is always a good idea to check what types of integrations they already have.

When evaluating the scope of potential integration efforts, consider these guidelines.

  • Integrations with payment gateways tend to be easy and usually do not require time-consuming certification process.
  • Integrations with banks are, generally, not complicated, and smaller in scope than credit card integrations, but some community banks may not have the technology, advanced enough to enable full automation of the processing.
  • Integrations with credit card processors can be rather complex, especially, if legacy platforms are involved, and even if the software that you license, already has such an integration, it will still have to be certified under your name and your PCI environment.

Here is an illustrative example of possible costs.

Example

Gateway software license $ 50 000 – 250 000
Tokenization appliance $ 50 000 – 100 000
Annual PCI audit $ 25 000
Monthly PCI hosting fee (average number of servers needed is 4 (2 of them for backup)) $ 2 500 – 3 500
Additional integration with new banks/processors (each) $ 5 000 – 15 000

These estimates provide the basis for calculating the approximate cost of a common payment solution that would be required by an average payment service provider.

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.