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.

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.

Is it Time to Switch to a New Payment Gateway Solution?

As merchant services industry is rapidly moving forward, new payment gateway solutions are emerging. These new solutions often offer new functionality. They are more flexible and capable of satisfying the new needs of merchants and resellers/ISO/Payment Facilitators.

The purpose of this article is to outline the main signs, indicating, that it might be appropriate for you to switch your current payment gateway solution to a new one. While some of these signs are relevant for all merchant services industry players, others apply to specific groups, such as merchants or intermediary entities (ISO and payment facilitators).

Let us review some of the signs, indicating that it is time to search for an alternative payment processing platform.

  • Processing costs and fees – your cost of processing is too high and the processing fees are being re-adjusted even though your volume has significantly grown. You may have started with small processing volumes, but now your volumes are much higher, so your current transaction processing cost is significant, because the fees you are paying are the same as before. If you are not able to re-negotiate transaction pricing with your current processor, then you should look for alternatives.
  • Funding delays – it takes too much time to get the funds you are entitled to. The funds are arbitrarily frozen and delayed, while you have a good processing history, there are no problems associated with your account and no particular reasons for suspicion and funding delays. If you are unable to resolve the issue with your current processing partner (i.e., your processor cannot provide a suitable solution), then, perhaps, it is time to look for a new one.
  • Lack of multi-currency support – you need to accept payments in multiple currencies, but your current payment platform does not support multi-currency payment processing. While you can use a different payment platform to handle additional currencies, it might also make sense to find an alternative payment gateway solution that will handle everything with one interface (from one entry point).
  • Lack of the necessary features – when you have started, your processor had a satisfying feature set, but since you started using the existing solution, your needs have changed. Now there are certain features, that you need, that are not available within your current payment processing platform. For example, traditionally, you worked with e-commerce transactions, but now you would like to handle card-present payments as well. You need to work with payment terminals and offer new solutions to your customers, but your payment gateway provider is unable to support the new technology. Or, perhaps, you would like to enroll in 3D secure program, in order to improve transaction security, but your provider does not support the respective features.
  • Reporting issues – reporting is not customizable enough. I.e., the reports are not presentable in the format that you need. There are no ways to export raw data in a format, allowing you to manipulate it. Some of the data, you would like to be able to see, such as details of processing costs is not available, etc. Perhaps, as a result of unclear reporting procedures, you experience problems while trying to reconcile your deposits properly.
  • Integration inconvenience – it is possible, that the technology, offered by your payment service provider, is not the most modern (up-to-date) one. While you managed the initial integration, supporting it imposes unnecessary costs on you. You might consider looking for an easier and more natural solution.
  • Limited branding functionality – you would like to present payment processing interface to your customers under your own brand. However, your current payment platform does not allow you to do that. As a result, lack of required branding functions limits your marketing capability and hampers your relationships with your customer base.
  • Merchant onboarding problems – as we have explained in our previous article, merchant onboarding problems are extremely relevant for payment facilitators and ISOs. More and more systems today offer real-time merchant onboarding and provisioning, which is a critical feature. It becomes one of the driving factors of competitive advantage in the merchant services industry. You may be used to submitting paperwork manually and waiting for a couple of days for the MIDs do get issued. However, your customers are demanding a more streamlined process. If your current payment gateway solution is unable to accommodate it, you may consider some additional or alternative options.

Conclusion

If some of the listed issues resonate with the pinpoints, that you have with your current payment processor, perhaps, you should consider some changes to the existing payment gateway solution, or even switching to a new one.

How to Streamline Merchant Onboarding and Provisioning

This article is primarily targeted at payment facilitators and payment aggregators. As we wrote in our previous articles, in order to process online payments, an entity must obtain a merchant account. This process involves two aspects: underwriting (sometimes also called MID provisioning) and onboarding. In this article we are going to describe, how to facilitate the process in today’s payment gateways, and explain, how payment facilitators can simplify merchant underwriting procedures.

Traditional merchant onboarding

Traditionally, merchant onboarding process was performed manually. Any potential merchant had to complete a paper form and prepare some documents, which were submitted to the underwriter (underwriting bank). If underwriting was successful, the underwriter sent back a MID, which was then configured within a payment gateway.

Some payment systems went beyond manual process. They offered future merchants to complete their merchant application forms online. After the form was reviewed by the underwriter, a so-called “download sheet” (“tier sheet”, “VAR sheet”) was returned to the merchant by e-mail. The sheet contained the merchant ID as well as other parameters needed to configure the payment gateway for processing.

The described onboarding procedure is not very efficient. The key drawbacks are as follows.

  • Data from paper forms has to be manually input into the computer system. This requires considerable effort of many physical operators.
  • The process is time-consuming. In many cases when the process is handled on paper, the process would take several days. Online forms, in some instances simplify the process, but it could still take 24 hours or more to get the MID set up.
  • When the MID is set up, the payment gateway still has to be configured manually.

On top of that, any part of the process, that involves human participation, increases the possibility of human errors, causing further delays and pushing the moment when the merchant can start transaction processing even further away in time.

Improved merchant onboarding practices

More and more software companies, that include credit card processing as part of their product offering, such as POS systems and restaurant systems, are trying to keep up with the requirements of today’s market. Consequently, they want to provide merchants with an opportunity to get their MIDs and start processing right at the moment when the merchant signs up for the core product.

In order to achieve this, several things have to be accomplished. In fact, accomplishing even some of these items will allow underwriters to streamline merchant onboarding process.

The most fundamental component of merchant onboarding streamlining/automation is the opportunity to submit the data to the underwriter online. There are two approaches, commonly used for this end.

  • API or file-based approach. Some underwriters have either API- or file-based process, allowing merchants to send their data online, and underwriters – to verify this data and issue MIDs instantaneously. However, file-based process might still take up to 24 hours.
  • Blocks of MIDs. Some underwriters are able to issue blocks of pre-allocated live MIDs (not yet assigned to any particular merchants). Underwriters allow aggregators and payment facilitators to use these MID blocks only for merchants with certain pre-approved MCC codes, i.e., merchants, selling a certain type of products or services (say, restaurants). These merchants can start processing right away, under condition that the PayFac provides the information on every merchant, that got the new MID assigned, to the underwriter within 24 or 48 hours from the moment the merchant starts processing.

If at least one of the listed approaches is implemented, merchant underwriting process can be almost completely automated.

The next thing to automate is the acquisition of merchant data. This can be accomplished through implementation of an API or an online merchant application form, which an applicant can complete to provide required data.

After the acquisition of merchant data you have to integrate with the acquirer, so that the data, input into the form by the applicant, could be automatically submitted to the acquirer through API or in a file (according to the first approach described above). The acquirer will then issue a MID, which can be used for processing and is automatically configured within the gateway.

If merchant data is not sent to the acquirer in real time, but the acquirer provided a pool of pre-approved MIDs (according to the second approach described above), the MID will be taken from this pool. The next day (within 24 hours) a separate process will include the new merchant into the report on active MIDs, sent to the acquirer. However, the merchant will be able to process transactions during these 24 hours as well.

We should stress, that pre-allocated MIDs are mostly suitable for payment facilitator model, when all the sub-merchant funds are deposited to a main payment facilitator account and it is the responsibility of the PayFac to re-distribute the funds. Otherwise, if the deposit accounts need to be different (there is no PayFac between the merchants and the acquirer), the acquirer will, most likely, expect to receive deposit information before the MID becomes active.

Conclusion

Our recommendation to software companies is to pay attention at merchant provisioning and onboarding mechanisms, used by given payment service provider or payment facilitator, before deciding whether to partner with it or not.

Our recommendation to PSPs is to form partnerships with those acquirers, that can either provide a real-time MID provisioning API or pre-allocate MIDs for immediate merchant activation.

From Batch to Retail Payment Processing

Introduction

The landscape of modern payment services market is rapidly changing. More and more well established companies, using legacy software, face the problem of expansion of their existing offerings to accommodate the newer needs of the market. One of transition-related issues is the addition of retail functionality to an existing recurring-billing-oriented payment system.

Problem

A well established business, which traditionally functioned as payment aggregator, has recently become a payment facilitator. Its main function is aggregation and facilitation of recurring payments in some industry (membership dues, insurance, installment payments, utility bills etc). Now the company faces the necessity to add a card-present EMV solution to its business offering.

Context

The problem is most relevant to billing companies, which sell their software products to front-end users. Many of such billing software vendors traditionally focused only on card-not-present transactions. They used to function as recurring payment aggregators for a long time, but (under pressure from associations) switch to payment facilitator model. We should remind, that such a transition also allows these companies to get greater control of merchant underwriting process.
On the other hand, under pressure from their customers, they have to add retail component as well as e-commerce processing to their (initially recurring-payment-oriented) payment system.

The pressure from the customers has the following reasons.

Many customers of such companies are brick-and-mortar businesses, which emerged long before online operations became possible. (Recently founded businesses, in contrast to brick-and-mortar ones, operate mostly online and, consequently, do not need any retail components). Some other businesses, representing the clientele of recurring payment aggregators, follow “mixed” operation modes.

Examples

A fitness center receives membership dues as recurring online payments, but sells physical merchandise, such as apparel, foods, drinks, and supplements, at a physical facility. Another example is an insurance company, which collects recurring payments, but wants to be able to collect past due payments and pre-payments in retail environment or online.

In order to be able to accept card-present/EMV payments, some of subscription-based businesses resort to third-party solutions, such as usage of standalone payment terminals. For handling of online payments these businesses can use PayPal or Authorize.net services on an individual basis. However, we should stress, that reconciliation process becomes more complex, as you, potentially, have to reconcile payments handled by multiple systems.

Another issue, faced by recurring billing companies, concerns handling of non-recurring payments. All the payments, made using a standalone terminal (past due payments or pre-payments, for example), have to be, then, manually input into the primary system of record, used for management of recurring payments.

Consequently, in order to ensure greater convenience and flexibility of operations for its customers, the aggregator/payment facilitator has to add both retail and e-commerce processing functionality.

Addition of a retail component, in fact, calls for implementation of real-time processing functionality. As EMV has recently become an official standard for retail payment processing, in a situation like the one just described, implementation of EMV solution becomes a top priority.

In order for your retail payment processing implementation project to be a success, you can use the following strategy, which includes several important steps, and which poses some challenging questions to be answered.

Strategy in brief

You need to understand both business and technological sides of the problem.

Business-related questions are as follows.

  • How are merchant accounts going to be issued? Who will be underwriting them?
  • Which processing system is going to be used?
  • What is the integration cost and how much time will the integration take?
  • What’s going to be the by-rate charged by processor for retail payment processing and what rate will be charged for the merchants?
  • How will funding be handled?
  • How will merchants acquire the necessary equipment? Who will they buy payment terminals from? Is fulfillment center relationship needed? How the terminals are going to be priced (full price/discounts/subsidies)?
  • Which card brands are you going to handle and in which countries?

Technology-related questions are as follows.

  • How you are going to implement a payment terminal solution and go through EMV certification, if necessary?
  • Which architectural changes need to be introduced into the existing system, initially developed exclusively for handling of recurring payments, in order to enable it to support real-time payments?
  • Are you going to use standalone terminals, or do you need to integrate with some POS systems?
  • Will you need only standard terminals or mobile terminals as well?

Strategy in detail

Here (in greater detail) are some important strategic issues to address.

Who will provide merchant accounts for retail payment processing?

Can you stay with your current processor? If your current processor supports different payment modes, such as e-commerce and EMV, can you use them for both recurring and retail payments? If yes, can you provide retail (real-time processing) services as a payment facilitator (the model you are already successfully using for batch processing), or do you need to switch to a different model (say, a retail ISO) to provide retail services? As we explained in our previous articles, under retail ISO model, you will simply resell merchant accounts, while merchant on-boarding and funding will be handled by the processor. If you stick to the payment facilitator model, you will have to handle merchant on-boarding and funding.

If your current processor is CNP-only, should you try to establish a new retail relationship? I.e., should you try to get merchant accounts for retail from a different processor? Does it make sense to move your entire business (both card present and CNP) to the processor that offers all the functionality you need, a better price, and, possibly, some additional services (such as robust merchant on-boarding, chargeback handling, and cross-brand account updater mechanisms)?

How are you going to technologically implement the integration?

Real-time and batch integrations are conceptually different processes. Consequently, no matter, whether you switch to a new processor or stay with the current one, real-rime integration is needed anyway. Moreover, if you need to use EMV payment terminals or mobile devices, you also need to select an appropriate EMV solution. As we mentioned in our previous use case, you have to study hardware options, supported by your specific processors, and, if you want to use your own customized terminal solution, you have to keep in mind fulfillment-related issues.

During the integration, you can either develop the software using your own development team, or use some third-party software product.

How are you going to handle non-recurring payments?

Your existing recurring billing system is, most probably, not adapted for handling of one-time payments. If, conceptually (and architecturally) the system was not intended for support of one-time payments, then addition of non-recurring payment functionality is quite a challenge.

Even if you have the logic to handle one-time cash or check payments, this logic might be too rudimentary to accommodate real-time credit card or ACH processing. Moreover, this functionality is, probably, not fit for handling of complex transaction lifecycles.

Conclusion

Addition of a retail payment processing component to your recurring-payment-centered system can be a major challenge, given all of the items that you have to consider. However, you can consider this challenge as an opportunity to switch to a more standardized and robust payment management platform (such as UniPay Gateway), that will not only solve the current problem, but also improve the overall quality and the capabilities of your existing payment ecosystem.

From ISO to Payment Facilitator

Introduction

Recently the term “payment facilitator” has gained popularity. The role of payment facilitators at the merchant services market has grown significantly. The concept of a payment facilitator is actively promoted in the merchant services industry. Consequently, more and more companies consider the idea of assuming the role of payment facilitators.

Problem

A business, selling merchant accounts, is currently functioning as ISO, but wants to become a payment facilitator.

Context

An ISO, generally, relies on other entities in many aspects of its activity. If a business needs to get a merchant account (purchase it from an ISO), the ISO needs to address some other entity (usually, the payment processor) to handle this issue.
Traditionally, the model functioned as follows. ISOs and software companies, which performed the role of ISOs for their clients, referred their clients to the processors and helped sell the accounts, relying on external gateway. Underwriting and funding was handled by the processors. With time, as the number of clients increased, they realized that the model was not very effective. As a result, payment card associations suggested the concept of payment facilitators, which provided these new entities with greater control over the processes of MID issuing, merchant funding etc.
ISOs have various reasons for becoming payment facilitators.
As we’ve mentioned in one of our articles, a payment facilitator actively participates in sub-merchant funding, and each of its sub-merchants is funded under a separate MID. In view of these functions, to become a payment facilitator, an entity needs to perform several important steps and answer some critical questions.

Strategy

Finding a processing partner

If you are an ISO, you already have a certain number of merchant accounts to support.

  • Are you going to become a payment facilitator with your current payment processor, or find a new processing partner? In either case, as mentioned in the respective article, you will have to sign a separate agreement with your processing partner, and go through the payment facilitator underwriting process.
  • If you are switching to a new payment processor, what is the plan for migration of your merchants? Will all the existing merchants from your portfolio be able to go through underwriting process with the new payment processor? If not, what is the “plan B” for those merchants, which are unable to do that? Some tips on migration to a new processor can be found here.

Pricing strategy and underwriting

If you are going to change our processing partner, you need to carefully study the following two issues:

  • What are the underwriting requirements of the given processor? Which documents and guarantees are required? What are the requirements for merchant services reserves? Remember, that before being able to underwrite your sub-merchants, you need to go through underwriting procedure with the payment processor yourself.
  • What transaction pricing model is offered by your potential processing partner? More information on transaction pricing models can be found in our previous articles, such as this one.

Technical aspects

You need to address several technical aspects. Mostly, these concern the peculiarities of new integration(s).

  • What types of payment cards and transactions do you need to support?
  • How will the new merchants be set up? How will the new MIDs be issued? What is the merchant underwriting mechanism you are going to use? If merchant information changes over time, how will those changes be delivered? In other words, what is the strategy for merchant on-boarding and provisioning?
  • Who will implement KYC (know your customer) logic, verification procedures? Is it going to be the processor or your own development team?
  • How will sub-merchant funding, remittance, statement generation, and reporting be organized?
  • Do you need card-present solutions (which, naturally, call for usage of physical payment terminals)? Which terminals are you going to use? Which processor(s) is(are) going to support particular solutions (card-present and card-not-present, or some others)? If several processors are going to be involved, then merchant on-boarding, funding, and chargeback handling procedures have to be worked out for each of the processors. If you need to process only card-not-present transactions, do you need to handle recurring payments and batch transaction processing? How are you going to handle these tasks? What is your solution for merchant information updating (account updater functionality)?
  • Are you going to handle most of the abovementioned processes manually? If yes, you need to develop training materials for your personnel. Otherwise (if the processes are going to be automated), you need to launch the respective development projects in order to implement the necessary logic.

PCI compliance and fraud protection

What is your status in terms of PCI compliance? What fraud protection mechanisms are available? In order to ensure the security of all the processes, you need to go through appropriate PCI audit as a prospective payment facilitator, and implement the best fraud protection tools you can find.

Conclusion

Becoming a payment facilitator, you are getting more control of merchant funding and underwriting processes, but you are also assuming greater risks and responsibilities. Your transition strategy must include all the aspects, needed to ensure smooth handling of the whole life-cycle of your sub-merchants.

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.

The Challenges of Chargeback Disputing and Delivery

While card processing integrations have been an integral part of acquiring business for many years, and most acquirers have the respective documentation available, modern PSPs require additional integrations to handle chargeback delivery and chargeback disputing.

The purpose of the article is to provide you as a merchant or a payment facilitator with a deeper knowledge of chargeback handling process, so that you could take care of all the issues concerning chargebacks while discussing your integration with the payment processor (depending on the approach the processor offers).

The two important aspects of chargeback handling are chargeback delivery and chargeback disputing.

Chargeback delivery mechanisms

It should be kept in mind that initially, when the concept of chargeback came into being, volumes of processed transactions and the scale of credit card fraud were much lower than they are today. Consequently, as of now there are three conceptual approaches to chargeback delivery, which were historically introduced one after another. Let us list them in chronological order.

  • Regular mail and fax. Traditionally, chargebacks used to be delivered via regular mail as printed reports. At some point processors started to send chargebacks by fax.
  • E-mail. After regular mail and fax, the practice of delivery via e-mail emerged. Chargeback information was either delivered as an attachment, or embedded in the body of the e-mail. Usually, one e-mail was sent per chargeback.
  • Data files. As the process became more complicated, printed reports and ordinary e-mails became really impractical, because the number of chargebacks and retrieval requests dramatically increased (proportionally to the total number of transactions). Consequently, the next step undertaken by processors was to export chargeback reports from their system. This method is still used by many processors today. A data file is generated and either pushed to the merchant’s FTP server, or provided for download by the merchant. The file, usually, contains the information about the chargeback, necessary to identify the original transaction and take subsequent action to dispute the chargeback or otherwise.
  • API. Some processors developed APIs allowing to load chargebacks or receive a notification (callback) when a chargeback occurs. The advantage of API is that it provides somewhat better control for the merchant on how delivery of the chargeback occurs.

Chargeback disputing mechanisms

Sometimes, after a chargeback is received, the merchant may want to dispute it. Just like in case of delivery, there are several approaches used for chargeback disputing as well.

  • Fax. Fax is still one of the most popular options. Supporting documentation, as well as the explanation of the original charge is faxed to a number, provided by the processor.
  • E-mail. The same information can be sent as an e-mail attachment. Obviously, both cases assume some human involvement. Even though the initial disputing e-mail can be originated by the system, that processed transactions, supplying the supporting documentation automatically, in some of the cases there can be a reply from the processor (for example, if some information is missing). That reply cannot really be automatically handled.
  • Data file combined with fax or e-mail. Some acquirers/processors prefer merchants to send a text file with charge information and then fax or e-mail supporting documentation. The mechanism is slightly better than the previous one, because the information exchange is organized through the file, while the documents are submitted using more or less appropriate medium.
  • Disputing portal. Many present-day processors started to create special disputing portals, allowing merchants to login, upload supporting documentation and explain the reason for dispute within the portal. The same portal can be used for chargeback delivery, as, beside chargeback disputing, the merchants, who login to the portal, can check if any new chargeback have occurred.
  • Disputing API. The portal-based approach works perfectly well with merchants, but payment facilitators and PSPs find it problematic to use. The reason is that login information for each merchant must be maintained, and merchants can interact with the processor “behind the PSP”. As a result, it becomes very difficult for the PayFac, or the PSP to manage the whole process. That is why some of the processors, which are targeting PSP markets started offering chargeback disputing APIs. Uploading of the documentation and disputing of the chargebacks in such cases can be done using a SOAP- or REST-based API. The API makes the process a lot more fluid, convenient, and flexible for a software or PSP company that is trying to offer an integrated chargeback disputing solution for its customers.

Conclusion

Depending on your needs and purposes, you should try partnering with the processor, offering you the most convenient chargeback delivery and chargeback disputing mechanisms in the context of your business model.

Terminal Solution Components

This year support of EMV standard becomes a mandatory component of payment systems of US-based businesses. Consequently, more and more merchants ask themselves how they are going to implement their terminal solutions in view of the need EMV support.

The purpose of this article is to describe the components of a modern terminal solution in order to help those who are trying to define their strategy of payment terminal usage. The subject is especially relevant for large-size merchants and payment facilitators, who have to deal with a large number of terminal deployments.

A modern terminal solution has to incorporate three key modules, which will address three aspects:

  • Fulfillment management – for ordering, injection, and operation of terminals
  • Terminal application – for transaction processing
  • Terminal support and management system (TMS) – for configuration and updates of terminal applications

Let us address each of these aspects in detail.

Payment Terminal Fulfillment

During fulfillment process the merchant orders a certain number of terminals of specific models with specific injection keys, while the respective fulfillment center (which works directly with the manufacturer) handles the order and supplies the terminals to specific locations (points of sale).

In many cases large payment facilitators and gateways have to work with more than one terminal fulfillment center. The reasons are as follows. First, a fulfillment center may be out of stock for a particular terminal model, so you have to order this model from some other supplier. Second, not every fulfillment center can inject every processor’s key (usually, fulfillment centers have agreements with limited numbers of processors). This is particularly difficult when processing crosses borders, because fulfillment centers tend to specialize within a specific country of operation. Consequently, companies, dealing with merchants in different countries, or doing international processing, may require special tools to manage the entire process and ensure that proper terminals with appropriate keys are ordered from appropriate suppliers.

Another important fulfillment-related issue is injection of third-party keys. It should be noted that lately implementation of end-to-end encryption solutions has become a common practice. In these solutions, PAN data is encrypted with a key. Most payment facilitators and payment gateways prefer to use their own encryption keys. However, not all providers of fulfillment services are equipped to handle the third-party key injection. In order to have the right to inject third-party keys, a company needs to be equipped with special procedures and have special certifications. Beside that, a special agreement is needed by a company to be authorized to inject encryption keys on behalf of a specific third party.

When you consider your terminal solution, all these issues need to be taken into account (even if not all of them are will be handled by your in-house system).

Terminal application

There are several terminal manufacturers and numerous terminal models. Similarly, there are many different terminal solutions. However, from a global perspective, all terminal solutions can be divided into two categories.

  • Terminal applications which have local footprint
  • Terminal applications with no local footprint

A terminal application “with a local footprint” requires installation of some special components on a workstation it is connected to. Usually, these components are DLL libraries, which represent one of the most common approaches nowadays.

A terminal application “with no local footprint” does not require installation of any native libraries or drivers on a workstation that is going to manage the terminal.

The second solution is, naturally, the preferable one, as it allows you to access the terminal and work with it in a unified manner from different web or desktop applications, under different operating systems, using different mobile devices (such as smart-phones and tablets\pads).

Terminal management system

Once the terminals are deployed, they need to be supported and maintained. In this regard several issues need to be addressed.

First, a terminal may break. Some plan of action must be developed for a case when something goes wrong with a terminal (i.e. how the malfunctioning terminal is going to be replaced).

Second, from time to time the terminal logic might need to be updated. Both embedded terminal content and DLL applications have to be updated from time to time.

Finally, the advertisement content of the terminal needs to be updated as well.

A terminal management system must be capable of supporting all the listed functions and updates.

Conclusion

We’ve presented a brief overview of a terminal solution at the high level. In our subsequent installments we are going to address specific terminal solution components and aspects in greater detail. We encourage you to study the topic carefully before making decisions about your preferred terminal solution strategies. In our future articles we will cover more related topics.