What Payment Gateways do Companies Like Airbnb and Uber Use?

“What payment system does Airbnb use?”, “Who is the payment gateway and processor behind Uber?”, “What payment processor/gateway do big websites use like Uber, Airbnb, Lyft, Reddit, LinkedIn, etc?”

These are the typical questions, which are asked by many people on a regular basis. Most probably, you can find accurate answers to these and similar questions only if you consult the management of the aforementioned companies. We do not know the managers of these companies and, consequently, the answers to the listed questions. However, we feel that people, asking such questions, just want to implement payment processing logic, similar to the logic used by Airbnb and Uber, in their applications. In this article we will try to explain the essence of this logic, and provide guidelines for those, who search for similar solutions.

So, what is the common feature, which unites Airbnb, Uber, and other similar companies, emerging with every coming day?

Airbnb is a marketplace for accommodation rental, while Uber is a marketplace for transportation services. Vacation rental and online transportation networks are not the only business types. If we set company names aside, we can see that the common feature is an online marketplace business model. A marketplace is an online setting, where various small-size vendors offer their products and services to various customers. In cases of Airbnb and Uber these vendors are either individuals or small businesses, providing services to other individuals and small businesses.

Online marketplaces, generally, face a challenge when it comes to payment processing. When a customer makes a purchase the payment amount should, generally, be split between multiple parties. For instance, in the case of Uber, some part of the amount should be retained by the corporate office, providing the software product, while another part should go to the driver. The case of Airbnb is conceptually the same. In some other cases, the number of recipients may be larger. For example, tomorrow Airbnb may allow cleaning companies to register on the web-site and provide their services to accommodation owners. As a result, during each rental, the payment will include Airbnb’s share (payment for web-site/online marketplace operation), the accommodation owner’s share, and the cleaning company’s share. Moreover, some part of the payment may represent taxes. Distribution of such payments is a serious challenge. Making separate charges for each recipient from the customer’s card is undesirable.

The challenge around payment distribution is solved through split funding (or split payment) mechanism. Different companies offer this mechanism as a service on the market. For example, PayPal is offering adaptive payments, Stripe and some new payment gateway software providers (such as United Thinkers) support split payment functionality, while Zift offers such functionality to software vendors.

In most cases a company like Uber of Airbnb follows a classical payment facilitator model. Uber drivers (or Airbnb accommodation owners) are its sub-merchants that need to be funded. As the number of these sub-merchants is large, beside split funding, smooth merchant on-boarding, provisioning, and remittance logic is also extremely important.

For most present-day marketplaces the opportunity to automatically onboard and provision newly singed-up merchants (or sub-merchants) is extremely relevant. In the case of Airbnb these sub-merchants are accommodation owners, while in the case of Uber they are car owners. That is why another important technology alongside split payment mechanism is merchant on-boarding technology (otherwise provisioning of each new sub-merchant would be a laborious procedure).

Conclusion

If your company uses an online marketplace business model and you want to “replicate” the business operations mechanism of Uber or Airbnb, try to find a payment service provider that supports split funding mechanism, has a smooth merchant on-boarding system, and compiles clear merchant statements, that would be easily interpreted and used for reconciliation by your customers.

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.

Split Funding Challenges

The purpose of this article is to address some challenges, associated with implementation of split funding. First, we are going to review a common approach, used by today’s companies, and then – suggest an alternative one, which you might find more appropriate for your particular needs.

In our previous articles we wrote about development of online marketplaces and the need for split funding logic in online marketplace models. In spite of increasing demand for split funding functionality, some payment service providers decide to refrain from development of the respective logic, because they do not want to face some common challenges, related to split funding. One of the most common problems is handling of chargebacks and refunds of payments, which were split when the purchase was made. Let us describe the traditional approach to chargeback and refund handling under split funding model.

PSP-centric split funding model

A split payment involves at least two business entities: a merchant and at least one affiliate (as described in the article on online marketplaces). Consequently, when a payment is made, the main transaction is processed by the merchant and part of the payment amount goes to the affiliate.

For example, if a $100 transaction is processed, the merchant gets $80, and the affiliate receives $20.

The challenges arise when a chargeback or refund of the transaction is necessary.

From the standpoint of the payment system the most natural thing to do is to collect $80 from the merchant and $20 from the affiliate, and return $100 to the cardholder. If both the merchant and the affiliate have sufficient funds on their accounts, the approach works fine. However, if the affiliate does not have sufficient funds on the account at the moment of the chargeback, the situation becomes more complicated. While the $20 debt can be recorded as payable by the affiliate, it is not immediately clear, who should give the money back to the cardholder, and when. In the case of chargeback, the burden can be put on the payment service provider.

Moreover, it is unclear, how the PSP can collect the debt from the affiliate, because in contrast to merchants, affiliates do not take part in transaction processing. All transactions are processed through merchants while affiliates just get their share. As long as this mechanism works, there is no need for affiliates to go through formal underwriting process and submit their details to the PSP. But when an affiliate has a debt, it becomes problematic for the PSP to collect it, because the PSP may not have all the necessary information.

As we can see, under the traditional model, the PSP faces considerable risk.

Another potential problem is that the primary merchant may, for some reason, owe money to the PSP (unpaid fees, chargebacks, etc.).

For example, the primary merchant owes $90 to the PSP. A payment of $100 comes in. $20 should go to the affiliate. Under the traditional distribution logic, $20 immediately go to the affiliate, while $80 go to the merchant only to be later collected by the PSP (leaving the merchant with $10 outstanding balance). However, this distribution scenario is not preferable for the PSP, since in the end the PSP continues to hold the debt (while preferring to shift it to the merchant).

The question is: how can the PSP improve the situation to protect itself from the listed risks?

Merchant-centric split funding model

In the previous scenario the merchant and the affiliate were considered equal players. This resulted in considerable risks for the PSP.

However, if we consider transaction split funding and transaction processing as two separate consecutive processes, then the situation can be improved (in terms of risks for the PSP and complexity).

In the first of the previously described examples, when $100 comes in, $80 goes to the merchant and $20 goes to the affiliate, just like under the PSP-centered model.

Now let us return to the chargeback\refund case. Instead of trying to collect respective shares of chargeback amount from the merchant and the affiliate(s), the PSP should collect the total chargeback amount from the primary merchant. If the affiliate does not have the necessary amount, it will be recorded as outstanding balance and be taken into account in further mutual payments. As we can see, the PSP will not have to assume the financial liability.

Finally, if $100 are processed by the merchant, the first thing it should do is pay off any outstanding balance to the PSP. If the affiliate is entitled to $20, but the merchant owes $90 to the PSP, then the PSP should get its $90, first and foremost. The remaining $10 should go to the affiliate, while another $10 should be considered as outstanding balance, owed by the merchant to the affiliate. This outstanding balance should be taken into account during future payments made between the merchant and the affiliate.

The main advantage of the merchant-centric model is that the transaction processing mechanism remains a classical one. The merchant processes transactions in the ordinary way. After that, on remittance phase, the merchant can transfer respective amount shares to the affiliates. If the merchant (or an affiliate) does not have the necessary amount available, it should be recorded on the balance as a future payable, owed by the merchant to respective affiliates (or the other way round). This system makes the clearing of payments between the merchant and its partners (affiliates) much more transparent.

Remittance issue in split funding

It is important to keep track of inter-merchant payments at two levels, corresponding to the two basic phases of transaction processing: settlement level and remittance\funding level.

Once a transaction is processed (settlement level), all the amounts, which the parties are entitled to should be recorded. However, as the actual funds become available to the primary merchant only at later period, it is necessary to record all the balances at the moment of remittance as well.
Remittance is a separate level, i.e. a sub-phase of the whole process, signifying the availability of the actual funds on the account.

Otherwise, the merchant may face the situation when the funds are available only from “gross” (settlement), but not from “net” (remittance) perspective. In such a situation it might be unable to pay the respective shares to its partners.

Conclusion

As we can see, PSP-centric model does have its issues and challenges, and it can lead to a conclusion that it is unprofitable and risky to support split funding. The merchant-centric approach is more difficult to implement. However, it is closer to the traditional merchant services model. It also provides a reasonably elegant resolution for the most common split funding problems.

PSPs, Payment Facilitators, and Aggregators

Depending on particular region of the world, the terms payment service provider (PSP), payment facilitator, and payment aggregator can denote different concepts and have slightly different meanings, i.e. one and the same type of entity can be called in a different way. However, globally, the three different concepts do exist, no matter how you might call them.

The purpose of this article is to explain the difference between the three crucial concepts, defining the three types of important merchant services industry players. Let us now provide a more detailed explanation of the differences.

Payment Service Providers

A payment service provider (PSP) is an organization, which provides individual merchant accounts to its merchants (i.e. provides traditional merchant services). Such a company works with a group of merchants, however it, generally, does not participate in the process of merchant funding.

A PSP facilitates merchant underwriting and payment processing, but merchant funding is, generally, done directly by the acquirer. Subsequently, a payment service provider can derive certain residual revenue only from the processing fees collected by the acquirer.

Payment Facilitators and Aggregators

A payment facilitator is similar to a PSP, but in contrast to a PSP, a payment facilitator does fund the merchants directly. However, the entities which conduct sub-merchant funding can be further subdivided into two groups.

The first group includes classical payment facilitators. In this case each business (merchant) is treated as a sub-merchant of the payment facilitator. This means that there is a separate MID, that is issued for each merchant involved in processing.

The second group includes the so-called aggregators. In case of an aggregator the same MID is used for every sub-merchant.

Examples

An example of a payment service provider is any independent sales organization (ISO). ISOs and resellers of merchant services can serve as examples of merchant service providers. Almost every bank nowadays has a department dealing with merchant services.A restaurant software (gym software, club management software, or any POS software) company is an example of a classical payment facilitator. Each restaurant using the software can get the merchant account through the POS development company. In this case the payment facilitator (being the software and financial services company) is going to review the account, collect the proper information from the customer and register it as a sub-merchant in their payment facilitator’s portfolio.

Another example includes such companies as lodging services (for instance, Airbnb) or marketplaces. A person renting accommodation through Airbnb does not have his own MID. A general aggregate MID is used for the whole service. The aggregator funds the apartment owners, and ensures that appropriate payments are deposited to respective apartment owners’ accounts.

One of the principal differences between payment facilitators and aggregators is the size of businesses (merchants) the two types of entities are dealing with. Payment facilitator model is suitable and effective in cases when the sub-merchant in question is a medium- or large-size business. Classical payment aggregator model is more suitable when the merchant in question is either an individual or a small business. Consequently, sub-merchants of classical aggregators must follow certain constraints of maximal processing volumes. When transaction volumes of a merchant become larger, this merchant can be obliged to have its own MID, or even become an independent business.

Conclusion

As the need for payment service providers and payment facilitators grows, you may consider becoming one. It is important to identify the specific model that you want to follow and ensure that you have necessary banking relationships, procedures, and software to handle the needs of the respective market segment.

Visit the UniPayGateway website if you are interested in the diagram illustrating this topic.

Handling of Convenience Fees

If you want to implement convenience fees within your payment software system or payment gateway, this article is for you. In payment card industry context a convenience fee is a fee charged for card processing. It allows the merchant to pass the cost of card processing to the cardholder. Some more information on convenience fees can be found in our previous articles here and here.

The purpose of this article is to analyze the technical aspects of adding convenience fee handling functionality into a payment system.

Fundamentally, there are two approaches used for convenience fee implementation.

Convenience fee handling approaches

The first approach can be applied when merchant funding is handled by the payment gateway or PSP (i.e. by the system that processes the transaction). The second approach can be applied when funding is not handled by the system that processes the transaction (i.e. by the processor).

The main difference is that under the first approach convenience fees can be withheld at the time of funding, while under the second approach they can not, since the funding is handled elsewhere. Consequently, under the second approach, convenience fees have to be processed in a particular way at the time of processing.

Let us compare the two approaches based on a simple example.

Before describing the example, we should note, that in most cases a convenience fee is a surcharge, which is, generally, kept by the service provider that facilitates the payment (payment gateway, processor etc) (some part of that fee might be shared with the a reseller). The primary part of the transaction (100% of the original amount) is, naturally, deposited back to the merchant.

Example

For example, if a $100 payment is made and $5 convenience fee is charged, the cardholder actually pays $105, of which $100 go to the merchant and $5 are withheld by the service provider. The surcharge includes the actual cost of transaction processing and an additional markup.

Under the first approach, the entire transaction (primary transaction amount and the convenience fee) can be processed as a single transaction using the same MID. At the time of funding the principal amount can be funded to the merchant and the convenience fee – withheld by the payment service provider (who facilitates the funding process and, therefore, can hold the funds).

Under the second approach, the PSP or payment gateway relies on some underlying processor to handle funding. In this situation if both the primary payment and the convenience fee are processed as a single transaction (as in the first case), all $105 will go directly to the merchant. Therefore, it is necessary to process two separate transactions ($100 payment and $5 convenience fee) using two different MIDs.

Peculiarities of the two approaches

First approach: MID and MCC

We should stress, that every MID is associated with a certain merchant category code (MCC) used for classification of products and services the merchant provides. Convenience fees are allowed to be processed only under certain MCCs (for instance, supermarkets are not allowed to charge convenience fees, while utility companies are).

Consequently, if you choose to implement the first of the two approaches, you need to use the MID (and the respective MCC) which allows you to charge convenience fees (sometimes a separate MID with a different MCC may be required to charge them).

Second approach: critical aspects

If you choose to implement the second approach, you need to think about several particular aspects.

  • When will convenience fee be charged? Will it be charged on successful payments only or on declines as well?
  • What should be done when a payment is not authorized because there are no funds on the card?
  • What should happen if the primary transaction succeeded but there are no sufficient funds to process convenience fee?
  • How to handle the situation when the primary transaction is voided or refunded back to the cardholder? Should convenience fee be refunded in such cases?
  • What descriptor should be used on the MID through which convenience fees are processed? How to ensure that the cardholder understands that it is related to the original payment?

These and similar questions must be addressed as part of your planning process.

Calculation of convenience fees

Calculation of convenience fee amount is another important aspect. Convenience fee is usually calculated in one of three ways.

  • It can be a fixed amount.
  • It can be a certain percentage of the principal transaction amount.
  • It can be a combination of the two.

It is desirable for the amount of convenience fee to be derived from the actual cost of transaction processing (include the actual cost plus bring some revenue). In order to achieve this, one of the several approaches can be used (similarly to transaction pricing strategies).

  • Unified “blended” rate. Same rate is used to calculate convenience fees for all transactions. However, handling of different cards may have different price, so some more sophisticated and flexible techniques might have to be used (allowing you to differentiate the fees, depending on card processing costs, instead of charging everyone maximal rates).
  • Buckets or tiers. Under tiered pricing, the fee can vary, depending on card type and transaction amount.
  • Customized logic. You can develop some customized logic, which will calculate interchange amounts based on card types and industries (e-commerce, retail etc), and define convenience fees based on interchange amounts. The technique is the most complicated one; however, it provides greater flexibility.

Conclusion

If you want to add convenience fee handling functionality to your payment system, you need to decide, how and when the amount of convenience fees are going to be calculated, as well as how and when they are going to be charged.

Saving on Merchant Services Fees (Part 2)

In this article we are going to explain how large-size merchants, PSPs, and MSPs can reduce and save on merchant services fees.

Merchant services fees: merchant perspective

Transaction processing industry is organized in such a way, that there are several parties in between the cardholder, holding the card at the point of sale, and the issuing bank, that approves or declines the transaction. These parties include software companies, providing POS software, payment gateways, acquirers that issued merchant accounts to respective merchants, and others.
Each of these parties represents an intermediary link in the process, and makes something of every transaction processed, and you as a merchant pay for it.

The closer to the network you are, and the fewer middlemen and intermediary links there are in the “food chain”, the greater your savings are. Consequently, to save on merchant services fees you need to get as close to the processing network as possible.

It should be noted, that often, in addition to merchant services fees, merchants are surcharged gateway fees by the gateway service providers that they use.

One of the ways to reduce the total fees amount is to use your own payment gateway, or negotiate the possibility of subscription-based pricing (as opposed to transaction-based pricing) with your current (or new) payment gateway provider. In such an arrangement a certain monthly fee is paid for the use of gateway software and hardware, as well as network bandwidth for an unlimited or capped transaction volume (as opposed to transaction-based fees, depending on the number of transactions being processed).

The tendency of moving from per-transaction fees to subscription-based fees is already manifesting itself on the gateway services market. A similar trend was once witnessed in telecommunication industry, where subscription model replaced the one, in which every call was separately paid for.

Merchant services fees: PSP perspective

The concepts of a “food chain”, including many intermediaries, and subscription fees, as opposed to per-transaction fees apply to PSPs as well as to large-size merchants. However, in case of a PSP there is an additional dimension to the problem.

At the high level there are three things that a PSP needs to facilitate for its sub-merchants:

  • Underwriting and on-boarding
  • Processing
  • Remittance (merchant funding)

Traditionally, all three functions could be delegated to an underlying processor. In this case, the processor does most of the work, and, usually, charges additional premium for that.

Processing function, one way or the other, always remains with the processor, unless you go directly into the network (but that is a complicated scenario, which will only save you money if you process really huge transaction volumes).

As for remittance and underwriting, these two processes can be handled by a PSP on its own. If you, as a PSP, handle underwriting (and, therefore, assume more risk) and merchant funding as well, then you not only get more control over the entire process, but you can also negotiate better pricing with the processor, since less work is now done on the processor’s end. Another advantage of handling of merchant funding is that your processor will not be able to see your profit margins, and you will be able to negotiate still better pricing with the processor.

You can also optimize the process and save more if you optimize transaction routing, i.e., if you send specific transactions to specific entities for processing. For example, debit card transactions can be routed to a PIN-less debit network, while American Express cards can be processed directly through Amex (and not through your current processor).

Conclusion

As your business grows, the fees, that seemed reasonable and acceptable yesterday, might feel overbearing in your today’s business scenario. It never hurts to review your current merchant arrangement and the fees you are paying on a periodic basis to see if it can be optimized to save some money for your business.

Implementing Your Own Payment Terminal Solution

If you are a player in the retail space, thinking that your business needs support for payment terminals, or if you are considering different payment terminal solutions in search of the most suitable one, this article is for you.

The need for customized payment terminal solutions is gaining urgency in view of approaching introduction of EMV standards and requirements in the US, scheduled for the end of 2015.

In this article we are going to consider several solutions, available for payment gateways and payment service providers with respect to their EMV strategy.

In essence, a terminal is a mini-computer with its own OS, where a terminal application has to function. Payment gateway must integrate with this terminal application to support EMV properly.

Payment solution offered by the acquirer

The first and, seemingly, the simplest solution is using payment terminal application, offered by an acquirer.

Many present-day acquirers offer you some form of payment terminal solution, which some PSPs or gateways may consider using. Upon closer inspection, however, you realize that there are a couple of issues with that.

One of the issues is that most payment terminal solutions (applications) offered by acquirers are tied directly to their platforms. Particularly, because of the tight EMV regulations, they avoid sending transactions from the terminal to some third-party gateway, intermediary CRM, or software system, which would then forward them to the acquirer. This may present a problem, because they need to keep track of these transactions to accommodate the business model of a PSP/gateway. The problem with the solution is that these transactions become invisible to the third-party gateway providers within their systems.

Because of that, many gateways and PSPs choose to integrate their software system with a terminal in a way which they can fully control.

Integration with a terminal

Integrating with a terminal can be done at two levels. At a higher level a PSP/gateway can utilize an existing terminal application and integrate with it using integration SDKs. At a lower level a proprietary embedded application can be written and subsequently integrated into the overall payment processing ecosystem.

SDK-based integration

The advantage of the first solution is that the SDK-based integration, usually, is much quicker than development of an embedded terminal application. Major payment terminal manufacturers (such as Ingenico, VeriFone, and PAX) offer their own terminal applications, which can be used in various ways, and thus, it is possible for payment gateways to take advantage of these applications.

While this solution is the simpler of the two, it has its disadvantages:

  • The gateway will not always be able to customize the terminal application (its interface or logic). For instance, you might be unable to add non-payment-related functionality, such as quality survey, to the application, when you need it.
  • SDK-based integration method may not be conceptually suitable for your application. Traditionally, platforms that used terminals, were desktop applications (only desktop applications existed). That is why many terminal integration SDKs still rely on the so-called native code, such as Windows-compiled DLL library. This imposes the requirement on the application to be able to deal with the native code. While this is, generally, not a problem for a desktop application, it does present a challenge for a web-application, which operates from within a sandbox, and, usually, does not have security privileges to operate at such a low level.

Embedded solution

The advantage of an embedded solution is that you can customize everything, and the application can do whatever you choose for it to do. You can develop an SDK or integration API, that will work for you, or your customers in any way, that you find appropriate.

On the other hand, this solution has a price tag attached to it, and is associated with some challenges:

  • Writing your own terminal application requires your own specialized knowledge, and a special costly certification, that has to be competed with the respective vendor in order to acquire preliminary knowledge and access to SDKs, allowing to do embedded development.
  • Building and testing the application, definitely, takes time. Therefore, immediate integration with the payment gateway solution is impossible.

In the next post we will describe some specific methods of integration and implementation of various SDK, allowing you to incorporate the terminal application into some software solution or payment ecosystem.

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 aggregation?

What is payment aggregation?

Payment aggregation is a processing arrangement when a large business (called the aggregator) is processing transactions on behalf of many smaller businesses belonging to its portfolio.

How can payment aggregation be practically implemented?

Payment aggregation can be implemented in one of the two ways.
In case of so-called straight aggregation, the aggregator (payment service provider) gets underwritten by credit card payment processor and processes transactions of all of its sub-merchants using the same merchant ID (MID).
In case of sub-merchant aggregation (sub-merchant funding) the aggregator processes transactions of the smaller businesses under different MIDs, remits the funds to sub-merchants and withholds the fees but still bears financial responsibility for all the accounts.
Due to increased possibility of fraud with the straight aggregation model, sub-merchant aggregation is a preferred way to organize processing.
In respective articles you can find some more detailed information on payment aggregation model and sub-merchant funding.

Who can benefit from payment aggregation?

One of the categories of merchant services industry players, frequently using payment aggregation, includes software and service companies, customers of which need to accept payments from their respective customers. Payment aggregation model allows software providers to function as payment service providers using either payment processor integration or some white label payment gateway offering, which they use under their own brands.

What are the risks associated with payment aggregation?

In these types of arrangements the payment aggregator usually gets the preferred processing rate from the underlying payment processor or bank. In return, it, generally, assumes the risk (financial liability) for its entire portfolio. Consequently, aggregator becomes responsible for any transaction fraud or chargeback associated with its sub-merchants.