Payment Gateway Cloud

In our previous article we described collaborative payment processing, based on payment gateway cloud concept. Although payment gateway cloud concept is a new one, it incorporates the results of a long evolution of payment technologies. This evolution was spurred and directed by the needs of merchants and other payment processing industry users. In order to understand it better, we are going to analyze it in comparison to a similar evolution process, which took place in web hosting industry.

Shared hosting – Payment gateway

Small online businesses and bloggers often face the need to create and maintain their own web-sites. To save money, they use a classical shared hosting, where they create their web-sites, alongside thousands of other hosting users. A similar need in payment services industry is faced by startup merchants and (again) small-size businesses. An equivalent to shared hosting in payment systems world is integration with a payment gateway. Startup merchants use the services of such companies as Authorize.Net, Stripe etc.

Virtual private server – Hosted or white-label payment gateway

With time users of a shared hosting face its limitations resulting from throughput constraints, viruses, problems with server, caused by other people, unavailability of support personnel, etc. For some businesses these problems are tolerable, while others choose to go to the next evolutionary phase, which is the virtual private server (VPS), giving them greater control over their environment and less of impact from the actions of others. An equivalent from the payment processing world is a hosted payment gateway solution, where a payment gateway instance is allocated for a specific merchant or a group of merchants.

Often VPS-based solution is also better for web-design companies with many sites and clients because it provides them with greater control over the process. In the merchant services world web-design agencies have their analogues: payment service providers and payment facilitators. PSPs and PayFacs often search for dedicated hosted payment gateway instances, commonly known as white-label payment gateways.

Dedicated server / Licensed payment gateway

While virtual private servers do guarantee significant efficiency improvement, they have their own flaws, because physical hardware is shared among several virtual machines or appliances. As a result, new limitations become evident, particularly, in cases, when high availability and fault tolerance are required. In such cases, large business users switch from VPS to dedicated servers. In payment processing world the equivalent of a dedicated server is an on-premise license of a payment gateway and deployment of the gateway in the company’s own PCI-compliant environment.

Dedicated servers solve most of the problems of web-design agencies, large online businesses etc., but support of such systems is a very complex task. Similarly, in the payment processing world, to support a licensed payment gateway solution, one has to face new issues related to server hardware, PCI compliance, etc.

We should mention a particular problem, specific to payment technologies, that doesn’t exist in the web-site hosting world. We are talking about implementation of payment integrations (with banks, processors, gateways). From technical viewpoint, integration between a gateway and a bank should not take more than a month. However, in practice, as a result of human factor, lack of organization, bureaucracy related to certification agent assignment, and instability of test servers, the process may take 8 to 12 months. If you are not familiar with integration process, you can read about it here.

Payment gateway cloud

Until recently there was no solution, allowing businesses with on-premise gateway deployments (particularly PSPs and PayFacs) to reduce the costs associated with new integrations. However, a new technology (implemented by such companies as United Thinkers) does allow your business to solve this problem.

The idea of payment gateway cloud technology is that an existing payment ecosystem can implement protocols (for transaction processing, chargeback disputing, and merchant provisioning), that are supported by the cloud within itself. If these functions are implemented, the payment ecosystem becomes capable of communicating with any other ecosystem, also connected to the cloud, where these protocols are implemented as well. As a result, any node of the payment gateway cloud can use the local integrations, implemented by any other node of the cloud.

Conclusion

If you face regular problems with integrations and the need for more back ends, but do not have the time and funds to invest in respective development efforts, you can consider exploring a UniPay-backed payment gateway cloud technology.

On the Way to Collaborative Payment Processing

Many businesses go through an evolutionary cycle as they grow. They usually start as small companies with very basic needs. Then at some point, as their processing needs become more sophisticated, they tend to outgrow the payment processing platform, chosen at the very beginning. In this article we are going to follow through a typical evolutionary path of such a company, see, which challenges it experiences, which traditional solutions can be used, and what new collaborative payment processing technology can offer.

Our story starts in a small warehouse. A group of people decides to open a book-selling business and launch a web-site, through which they are going to sell books.

Classical third-party payment gateway service

Having neither previous transaction processing volume nor PCI infrastructure, the company chooses the simplest route: to partner with an existing payment gateway, that can connect it to one or more processors that it needs.

As time goes by, the book-selling business expands rapidly, its revenue grows. It gets recurring orders from schools and universities. It starts opening stands and kiosks at book fairs, in airports and other places. Consequently, the need for card-present EMV solution as well as recurring billing solution arises. New payment processing logic is required. Beside that, the company is expanding to other geographies. Support for more currencies is needed.

The current gateway cannot accommodate all of these needs. The company starts thinking of integrations with several gateways. However, these gateways solve similar problems in different ways and cater to different market segments. The gateway, used for US dollars, has robust recurring billing, while the gateway used for Euros has an excellent on-boarding system. And still, there is no common denominator and the bookselling business has to compensate all the differences using its own development team, and, beside that, implement integrations with multiple payment processing back ends.

Gradually, the bookselling company reaches a decision to invest in its own infrastructure and develop some in-house payment gateway that would be used as a centralized system of record.
The managers start to analyze the problem of in-house payment platform development and list related costs and tasks, such as: logic to be developed, integrations, needed for payment processing, implementation of recurring billing functions and reconciliation processes. At the same time, they realize the additional costs of a new data center, PCI audit procedures, tokenization appliances and other operation costs. The company understands that the problem is too complicated to try to solve it with internal resources only.

As a result, the management decides, that the payment ecosystem should be based on some existing open-source payment technology.

Open-source payment gateway solution

The bookselling company licenses and implements an open-source payment technology (adding the missing functionality in-house) and its growth continues. Now it has its own infrastructure, which it fully controls.

With time, however, the company starts facing new problems. First, it has to redo all the necessary certifications and implement new integrations. These integrations start taking too much time to complete. Second, supporting card-present solutions in different geographical locations is not an easy task, so it poses additional challenges. Third, as the company’s core product begins to mature, the management decides to expand their operations to Europe (in addition to North America, where the business is already solidified), and understands that they need to include marketplace offering, allowing participating stores to use the company’s merchant services.

It seems like an endless cycle of growing needs, product updates and constant re-certifications. The solution comes in the form of collaborative payment processing.

The essence of collaborative payment processing

While a payment gateway can connect to a bank or a processor, it can also connect to another instance of itself, running elsewhere (in another ecosystem). Therefore, two payment ecosystems, that use the same payment processing platform as foundation, can connect to each other, forming a cloud.

While the bookselling company expands to Europe, it finds out that there is a payment service provider that uses the same open source payment processing technology. This technology has a cloud capability, allowing the two instances to get connected and, automatically, provision accounts and set them up for processing, as well as process transactions through each other.

The company signs a contract with its European partner (PSP), which allows it to underwrite merchants using the integrations of the PSP. At the same time, collection of merchant and transaction data (as well as other data) is performed using the existing in-house technology, built by the original business. As a result, without the need for any additional integrations, the bookselling company immediately gains access to all of the processing capabilities of their partner in Europe.

After some time, as the company expands further, a similar collaborative payment processing mechanism is replicated in Australia. The three companies (headquartered in the US, Europe, and Australia) form a three-sided partnership, allowing them to benefit from each other’s processing functionality.

Conclusion

Each individual case of a company’s growth is unique, and you should be looking for solutions that work best for you. However, the example, described above, is very typical of what we have observed within the industry. If you feel that this scenario resembles your business and would like to learn more about the concept of collaborative payment processing, we will be glad to provide additional information at UniPay Gateway.

In the next article we are going to describe the concept of payment gateway cloud in greater detail.

Credit Card Processing for Startups

Online commerce, electronic payments, and credit card processing have become fundamental aspects of today’s economy. As a result, almost all startup companies need to decide, how they are going to process payments for themselves or on behalf of their clients.

People often tend to ask questions like: “What are the best payment processors?” (sometimes “What are the best online payment processors?”), “What is the best payment processor for accepting micropayments?”, “What is the best processor for honest pricing?”, “With regards to fees, what is the best payment processing service for a SaaS company with a low monthly price ($5 per user per month)?”, “What is the best Payment gateway for Java which can only validate cards without posting any charge on the card?”, “What’s the best payment gateway for an online factoring invoices marketplace?” etc. In fact, there are no universal answers to these questions, as the situation is a bit more complex and context-dependant. In our article we are going to explain why, and provide some guidelines, which startup businesses can follow to find optimal solutions for themselves.

As we wrote in “Payment Gateways” series, when you are choosing a potential solution to implement, before you look at credit card processing costs, associated with a particular gateway, you need to understand, whether it supports all the functionality you need.

Let us list the fundamental questions, which are relevant for you as a startup company.

Fundamental questions regarding credit card processing

  • Do you need to process payments for yourself only, or do you need to process payments on behalf of your clients (i.e. do you need to function as a payment facilitator)?
  • Do you need only card-not-present (CNP) solution for online recurring payments, or is card-present solution (EMV) also necessary?
  • Do you need to support multiple currencies or not?

In many cases before thinking about your pricing options, you need to verify, whether the listed functions are supported, and whether the gateway supports your MCC code. Beside that, if you are trying to get a merchant account abroad, you need to check, whether you can get it with the gateway you are planning to partner with.

For example, if you are an Indian merchant, trying to get a merchant account in the US, you need to check, that you have all the necessary documents to be underwritten in the US. In the very least you must have a tax ID in the US.

Then (as we’ve mentioned), you need to verify the MCC code and check, if the logic you need is available within the gateway.

As a result of this analysis, it may turn out, that your choice of payment gateways/processors can be reduced to one or two payment platforms.

Reality check

Before addressing a particular payment gateway or processor, you can also perform a “reality check”. Keep in mind that a processor’s revenue amounts approximately to 1% of your processing volume. So, if your processing volume is $ 5000, the processor gets $50. For such a modest reward processors will not offer you complex or customized solutions.

True, Stripe and PayPal may seem to be costly solutions for your business. However, if your processing volume is not very high yet, they may be the only solutions available in your case, because they have a well-developed infrastructure, allowing them to work with the so-called micro-merchants. Larger processing companies may not have such an infrastructure.

Card-present solution

If you need a card-present solution, it is important to analyze the technology you are planning to implement, the upcoming integration, and the cost of devices you are going to use. You should also verify, whether you have all the necessary EMV certifications.

PayFac model

If you need to function as a payment facilitator and issue merchant accounts, then you should pay attention to merchant onboarding and underwriting rules, adopted by your potential processing partner. You should also check, whether your potential partner has some API in place, which allows to simplify onboarding of new merchants.

Availability of starting capital

Being a startup, you may have the funds, allowing you to rent a payment platform for your business needs. If you have both money and time, you can even develop a processing platform using your in-house development team. Finally, you can license an existing white-label payment gateway solution, as we explained in our previous articles.

In these latter cases you can expect lower processing costs, but you will have to pay for support of the necessary infrastructure.

Conclusion

If you have neither the starting capital, nor processing volume, you should not try to find the “cheapest” credit card processing solution, because you are getting what you pay for. If the profit the processor gets from your transactions is low, you are going to be treated accordingly.

In these cases it might be more secure to pay slightly higher processing fees, but partner with a company, which offers robust technologies and has no funding delays. If you save 25 cents on a transaction, but then find that your account is suddenly frozen or closed, it is not a preferable option.

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

Conclusion

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.