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).


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.

Online Marketplace Model

With the success of eBay, Uber, AirBnB, and other similar online marketplaces, the concept of an online marketplace is rapidly entering new industries. As a result many modern software companies are providing online marketplace software for these different industries. Consequently, the problem of payment handling in marketplace-type systems becomes more and more relevant.

What an online marketplace is

Online marketplace is a platform, allowing its users to exchange products and services, which is provided and supported by a third-party entity. Examples include eBay and AirBnB.
Plenty of different companies develop software for online marketplaces. However, the need for effective organization and support of complex payment processes at online marketplaces maintains its relevance.

The difference between an online marketplace and a conventional business

The main marketplace-specific problem is as follows. During a traditional transaction, when a customer pays a merchant for a purchase, the merchant receives the money with a small processing fee withheld. The fee is retained by the processor (the company that processed the payment).
In an online marketplace two conceptually new components were added to the above-mentioned simple transaction processing mechanism.

The first one is as follows. In an online marketplace situation there is an additional party involved that needs to be paid for the service vended. So, when the merchant is paid, a fee has to be withheld (as in the conventional model). However, it needs to cover not only the cost of processing, but the cost of the service of the marketplace. Let us use examples to illustrate the difference.

Example 1

John purchases a T-shirt for $20 in a store and pays with his credit card. The store receives $19, while $1 is withheld by the bank that handles credit card processing for the store.

Example 2

John buys a $20 T-shirt at an online marketplace. The merchant receives $18.50. $1 goes to the bank that processed the transaction, as in Example 1. However, $0.50 from the transaction needs to go to the marketplace owner.
While it is possible for the marketplace to collect its fee as a monthly subscription, or as a separate (second) transaction, it is preferable to be able to withhold just one fee from the main transaction, and then – split it among any other parties, such as affiliates, that are involved.

Moreover, the marketplace owner is not the only new player in comparison to a conventional business.
Another important thing to consider, when dealing with marketplaces, is the affiliates. We are talking about third-party blogs and web-sites, which handle the promotion of different products (ads, which we see in blogs, leading to online marketplaces like Amazon and eBay, provide vivid examples of such promotions). Say, a blogger writes about different cleaning products and detergents. She writes about unique cleaning products, and references a link to the web-site (online marketplace), where these products can be purchased. It is expected, that the blogger is going to receive some small commission of every purchase that is made through the link from her blog.

Example 3

John smears his newly-bought T-shirt, goes online and finds the blog, providing some useful information on where effective detergents can be purchased. He clicks on the link in the blog and purchases the detergent at the online marketplace. Now, beside the fees, the bank and the marketplace owner are entitled to, the blogger should also get her small share of the transaction amount.

As we can see, the traditional transaction processing model does not fully meet the needs of an online marketplace. Online marketplaces have a need for split funding, i.e, they require the ability to split an original transaction into multiple sub-components (smaller payments), that can be distributed among different parties, such as affiliates.


If you want to build your business in accordance to the online marketplace model, you need to select the right payment processing partner, who, potentially, is capable of providing flexible split funding functionality. Although you can go with a traditional processor and build the split funding logic yourself, you are likely to experience many challenges, and still the process might not be transparent enough. Consequently, it might be better and more profitable for you to partner with a payment platform, which already supports split payment functionality. It might also be useful for you to check, if a payment facilitator model is the right one for you.
In the next article we are going to address two basic split funding models.

Handling Interac Payments in Canada

With this article we continue the series of articles related to EMV standard and EMV certifications. The purpose of this particular article is to describe the peculiarities of integrations with Canadian payment service providers.

Any integration with a payment processing partner in Canada requires integration with Interac Association, which is a non-profit inter-bank debit network, connecting multiple financial entities in Canada. In principle, the process of integration with Interac is similar to integrations with other associations, such as Visa and MasterCard (or integrations with debit networks in the US). However, there are certain requirements, which distinguish integrations with Interac from those done with other associations. The difference lies in the supplemental mechanisms imposed by Interac Association members on processing of card-present and card-not-present transactions.

Let us outline these additional requirements.

Processing of card present transactions by Interac Association

When it comes to processing of card-present payments (both EMV and swipe) by Interac merchants, the distinguishing feature is the transaction validation mechanism. This mechanism involves additional data protection level. To provide this protection, an additional block of data is generated during transaction verification. This block is called message authentication code or MAC.

MAC block of data represents an encrypted line of values. These values are: transaction ID, transaction amount, merchant ID, and terminal ID. For encryption of the data block, including these values, a special key is used, called the session key. It should be stressed, that the session key is a separate value, unrelated to card PINs or P2PE keys. The session key is stored in the terminal memory and has to be updated (rotated) after a fixed number of transactions is processed. MAC values cannot be calculated at POS/gateway level, as they depend on particular terminal hardware.

Encrypted MAC block is used as a kind of digital signature/seal, which is used by the payment processor to ensure that the rest of the message arrived unaltered. When the message is received by the processor, it uses MAC block as well as values provided in the message to verify the integrity of the message. The response, generated by the processor and sent to the terminal, also includes an additional encrypted MAC block of data, which has to be decrypted and validated by the terminal. The terminal must send back confirmation of receipt of unaltered response message.

As we see, MAC ensures the control of transaction integrity. We should remind that MAC is a mechanism, specific for Interac, and intended only for protection of debit (both EMV and swiped) card data.

Processing of card-not-present transactions by Interac Association

When it comes to processing of card-not-present transactions, some (but not all) Interac Association members use an additional data protection mechanism, which is, in a way, similar to 3D secure capabilities, used by Visa and MasterCard.

More or less detailed information on how 3D secure works can be found in the respective Paylosophy article. Here we’d like to remind, that 3D secure protection mechanism redirects the cardholder from the shopping cart application to the bank’s web-site, where he is required to input some additional confirmation of his identity (usually, some confirmation code or password).

Some Canadian providers are using a special online service, similar to 3D secure. A cardholder, paying for products or services online with his debit card, is automatically redirected to the web-site of the aforementioned online service, where he is required to input additional information, confirming his identity.


If you are planning your first integration in Canada, it is important to understand, that, even if you have the experience of conducting integrations in the US, in Canada your integrations will be a bit more complicated, due to additional Interac logic. Particularly, this means that an EMV payment application, developed in the US, would still require quite significant adjustments to be able to support Interac in Canada, because Interac, in its turn, requires the special logic, depending on specific terminal hardware. If you are ordering test terminals to do your integrations, make sure, that they are injected not only with a PIN key, but with the MAC key, needed for integration with Interac.

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).


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.

Migrating from One Processor to Another

Every now and then gateway processing relationships have to be re-evaluated. There are numerous reasons for that. Traditionally, a change of a processor for a PSP represented a new integration project for authorization and settlement, as well as moving of existing MIDs from the current processor to the new one.

In today’s world, as demands of merchants increase, the process looks a lot more complicated. In this article we are going to explain the particularities of the migration process, applied to the modern environment.

The aspects of migration

Just as before, migration of merchants is an important process. All merchants have to be moved to the new processor’s platform and configured.

A modern-time PSP, usually, has several integration points with a processor. Among them is the traditional authorization and settlement. However, many PSPs now offer batch processing – the ability to send files, and, consequently, account updater functionality, allowing for full update of information from issuers (which is, generally, required for recurring billing). This functionality requires additional integration efforts to be supported.

Many PSPs have to deal with on-boarding of numerous merchants on weekly basis and a lot of PSPs today have an integrated on-boarding mechanism, either through API, or through a merchant boarding file. Therefore, switching from one processor to another, potentially, implies changes in the merchant on-boarding mechanism.

Chargeback management has also evolved over time. It used to be a manual process. However, in today’s world, a lot of chargeback handling procedures are automated, and, again, payment facilitators may have existing integrations to retrieve chargebacks, as well as specific procedures around chargebacks disputes and uploads of supporting documentation. Switching to a new processor might mean changes in the existing integrations, or re-training of personnel, that is used to deal with chargeback disputing portal of the current processor.

Reconciliation procedures can also be a challenge, as they, generally, involve various kinds of settlement and fees reports, used for analysis of transactions processed, settled, and funded. Switching to a new processor might mean different reporting formats, or even lack of certain reports.

Loading and updating of BIN-files is another important component of modern-time migration process. More information on BIN-files can be found in our previous articles.

It is also important to understand that while you may get an enthusiastic support during the sales phase, when you go into technical integrations, you might face an extremely tedious and long process trying to put things in place and get them certified.


While change is an inevitable and necessary part of our life, and every now and then a PSP might need to change its major processing partner, this process should be approached with caution, and involve careful preparations. Depending on the size of a PSP, the process might take up to eight months, or even a year, so the PSP must set a reasonable time frame within these limits for the process to be completed. Before making the final decision on migration, a PSP should think about all of the listed aspects and decide how they are going to be organized in the new system. That is why using a standardized processing platform-gateway, which supports all of these aspects may be a reasonable choice. Usage of such standardized processing platform\gateway is extremely relevant for those, who haven’t started any integrations yet, because it will simplify potential further migrations.

Payment System Integration

The purpose of this article is to list the key phases in the payment system integration process that should be followed in order to optimize the effort, reduce integration time, and minimize the investment into the integration process.

At a certain point developers of software products in need of credit card processing services must go through payment system integration process.

Any payment system integration is a challenging task, especially, integration with legacy platforms. Therefore, when it comes to integration, it is wise to make careful preparations and monitor the process closely to ensure its successful and timely completion. The current article is based on extensive experience of integration implementations executed by our team.

Experience suggests that there are certain steps that have to be executed in a specific order to ensure the highest efficiency of the efforts associated with the integration process. The steps are listed below in the chronological order.

Get specifications from the processor

The very first step on the way to integration would be to get the necessary specifications from the processor. Certain important conceptual issues may need to be clarified at this initial stage.

Terminal capture or host capture?

It is desirable to determine at the initial stage if the processor supports terminal capture or host capture (some information on host and terminal capture can be found here). Under terminal capture the, company (integrator) has to implement both authorization and settlement (and settlement requires separate logic and therefore increases the overall scope of work versus host capture). It is also important to determine the mechanism used within terminal capture to settle transactions, and if file and FTP server are involved, it is critical to request connectivity not only for authorization (which is, generally, done in real time), but also for settlement (which would be done through an FTP server).

Conceptual issues around merchant ID and terminal ID setup

Because of the business-specific differences related to credit card processing (e-commerce versus restaurant) the logic of payment system integration (with credit card processor) is divided by industry type. The most common industries are retail, direct marketing (MOTO), e-commerce and restaurant (some information on industry types can be found here). Each industry might have its unique features. It is important to process each submitted transaction with a proper industry indicator, because certain features, such as tip adjustment, might not be available on transactions processed under e-commerce industry type and will only be available under restaurant industry type.

There are two ways in which industry type can be specified within a transaction. Some systems will use a different merchant ID, or a different terminal ID under a merchant ID, that will be configured to specifically handle a certain kind of industry. Some other systems might use the same merchant ID across all industry types, but have the industry type indicator field within the transaction’s request.

Therefore, when planning a payment system integration, the business needs to evaluate the conceptual approach that it uses in its own system (e.g., single MID across several industries) and the conceptual approach used by the system (e.g. separate MID for every industry) and plan for any potential incompatibilities in advance.

Allocate resources and set integration timeline

The next step is to formally allocate the resources that would work on the project, schedule the major tasks and milestones, set initial timeline and expectations\priorities (as integration processes can take from one week to one year depending on the complexity of the underlying system).

Get certification specialist assigned

As specifications may be complicated and questions may arise in the process of the integration, it is important to have someone to address the questions to. Consequently, the next step is to verify that the project is open at the processor’s end and that the responsible specialist is assigned. Larger processors may have really long integration queues and it may take up to two to three months to get an integration specialist assigned to a project on the processor’s end. If certain integration-related questions remain unanswered, some aspects of development process may also have to wait, so the specialist assignment must be taken care of and planned for in advance.

The next several steps (getting test credentials, getting test cards, getting certification scenarios, connectivity testing, and development of a basic prototype, preceding the development of the actual application) can be performed more or less simultaneously.

The term “prototype” used below implies a basic independent fragment of code (mini-application) with just the core functionality, developed as “bare bone” implementation, and targeted mostly at testing of basic scenarios; the main application is, generally, much more complex. Sometimes at the prototype stage architectural mismatches in approaches can be discovered and appropriate scheduling and implementation changes can be anticipated in advance.

Get test credentials

Generally, the ability to test any code that is written is very important. Testing and connectivity credentials are required in order to connect with the processor and to be able to send test transactions.

Without the test credentials it is impossible to test the logic as it is written, so it is extremely important to have test credentials as early as possible, and test the code consistently, as development occurs (and not wait with testing until the entire implementation is done).

Get test cards

Some systems might require physical test cards in order to complete the testing during payment system integration process. Since these are physical cards, that have to be delivered by mail, and the process usually takes time, it is better to order them in advance. For those cases when PIN-debit and EBT functionality are involved, there may be a need for a physical terminal or a PIN-pad with a respective test key injected (to generate appropriate PIN-block). In such cases it is also better to provision a PIN-pad with appropriate key in advance.

Get certification scenarios

Usually, in order to officially complete certification process and receive certification letter from a processor, an integrator has to implement a certain number of test scenarios, execute them and have certification specialist review the data submitted.

Despite the fact that the actual certification process is done at the end of implementation, it is recommended to use the test scenarios to test the code as it is getting implemented, because, according to experience, there are many situations when the information explained in the specification would not match to the actual way in which the system works. In such cases the only way to catch these types of cases is by executing the test scenarios supplied by the processor.

Test scenarios must be obtained from the processor in advance, because when the actual application is implemented, it is better to use these scenarios, and not just experiment with random cases.

Some people prefer to start the implementation right after specifications are available and only utilize test cases in the very end. The testing can be performed on model cases of the integrator’s choice when the whole logic is developed. While it seems that this way is going to be quicker, it might actually end up taking more time. For instance, when the testing happens using the actual scenarios, it might turn out that some initial assumptions were invalid, and, as a result, additional changes have to be introduced into the code already written.

Test connectivity

Once test credentials are obtained (and, sometimes, once the very basic prototype is developed), the first step to take is connectivity testing. To verify FTP connectivity, a standard FTP client can be used. HTTP or socket connectivity can be tested using other tools, such as Telnet or ping. You can test connectivity using either some third-party tool (such as FTP client) or your own prototype (an extremely basic one) as explained below.

Start formal development process

After connectivity and test credentials are confirmed, the formal development can begin. Every large system has its own architectural design that must be respected, so it might take time before communication with the other end is established. Because of that our recommendation is to start communication using a simple prototype, which is separate from the main system,

Make the basic prototype

We recommend starting with development of a small prototype to test connectivity and basic transactions such as sales. Once a sale ‘approval’ is obtained from the processor, it can be concluded that the specifications are clearly understood, test credentials are working, test account is configured correctly, connectivity, interchange protocol and message format are properly implemented. This eliminates potential issues around specifics of the messaging protocol or some encoding requirements that become less detectable when testing happens within the context of a larger system.

Once the basic prototype works, you can go through formal development process to build out your solution, taking into account all architectural needs of your system.

The other approach (as opposed to the prototype-based one explained above) would be to go through all the formal development (sometimes it takes up to 3 to 4 weeks) and then start the testing process. However, with such approach at the time of testing it might become evident that certain assumptions were made incorrectly and much of the code has to be rewritten.

Certify the scenarios

After all the coding is done, the next step is to certify the aforementioned test scenarios in all supported industries, and get approvals on all of the test scenarios. When certification is completed, the integrator receives a certification letter from the certification agent of the processor responsible for the given integration.

Test scenarios can be executed in one of two ways: they can either be manually processed using virtual terminal (through which test transactions are submitted), or an emulator can be built, that will run the entire test script, one transaction at a time, at the software level, without human being involved.

The first option is time-consuming. That is why we recommend not to rely on manual testing, but rather implement all of the test cases as executable code, sometimes referred to as emulator (automatically generating all the test transactions), so that all of the test scenarios could be executed and re-executed multiple times on demand within short time frame (and in different order).

Certification process is often done offline, when test scenario’s execution log and execution time are sent to be analyzed by the certification agent (responsible specialist) of the processor; sometimes calls with the certification agent must be scheduled when he or she needs to record\capture certain data when transactions are submitted. When such calls are needed, it is better to schedule them in advance so that the logic could be corrected step by step. Beside that, it should be kept in mind that a certification agent might also have a busy schedule of his\her own, as he\she is usually working on several integration projects simultaneously.

Define the processor’s settings

Once the integration is complete, the integrator needs to think how new merchants will be boarded to process through the certification, and, therefore, potentially, develop a user interface or some form of API to configure the accounts. In order to do that, you need to identify all the parameters, assigned by the processor to each merchant for identification purposes (usually MID and TID). Once this information is identified, you can implement the on-boarding logic.

The task of providing the list of fields in the processor’s profile structure is usually reassigned to a responsible developer who will perform the actual coding.

Prepare the necessary documentation

The next and final series of steps basically envisions preparation of all the necessary documentation. It is important to document the entire integration process before putting the project to sleep. Our recommendation is to save all testing information, such as test scenarios, test URLs, test accounts, test card numbers, for the cases when re-certification might be needed or some new problems emerge in production and changes need to be introduced into the existing logic.

Our final general recommendation is to have a special project manager with a list of recommended tasks assigned to the integration project. This manager should closely monitor the overall progress of integration process on the regular basis in order to ensure its fastest completion.

Before you go into production, make sure that you have identified the proper way to get production support or to escalate your request, be it e-mail or a phone number to call in cases of emergency.

Good luck with your payment system integrations!

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

Merchant Funding for PSPs

This article is, primarily, addressed to payment service providers, also known as third-party processors or payment facilitators. Its goal is to familiarize PSPs with the concept of merchant funding (remittance) and challenges associated with it.

One of the issues faced by payment service providers is that of organizing the remittance process in the most efficient and competitive way. The remittance process is the process of sending money back to merchants for transactions they processed. The process of remittance is very closely related to merchant funding process.

There are several challenges faced by PSPs in connection with remittance and funding processes.

  • In many cases it is only possible to send the money after the payment service provider has been funded by the underlying processor.
  • Reconciliation process for a payment service provider and for a merchant, receiving the money, needs to be as simple as possible.
  • Regardless of the pricing structure, it is desirable to keep the process as clean and transparent as possible.

To satisfy the listed criteria, PSPs can choose from among several merchant funding models, incorporating different remittance mechanisms and fee withholding strategies.

Merchant remittance can be organized in several ways.

Cycle-based remittance

The simplest way to fund merchants is based on a time cycle which usually is a calendar month. Under this approach the money is sent once or twice a month (commonly on the1st and the 15th). Each remittance covers all transactions processed from the previous remittance up until now.

The advantage of this approach is that reconciliation (by merchants) tends to be simple and only has to be done once or twice a month.
The disadvantage of this approach is that if the remittance happens on the 1st and the 15th and the merchant processes considerable volume of transactions, for instance, on the 3rd, the money is not available to the merchant for the next twelve days.

The cycle-based approach is more common when some form of follow-up/collections process is performed as an add-on service to the straight processing.

”On-demand” remittance

Under the so-called “on-demand” approach, money is sent to the merchant fixed (agreed upon) number of days (usually, one or two) after the original transaction was processed.

For example, transaction processed on Monday gets funded on Wednesday.

The advantage of the “on-demand” approach is that money is available to the merchant sooner.
The disadvantage of the approach is that the reconciliation becomes more complicated, especially, if a merchant is processing transactions every day, as funding from one day can overlap with funding from another.

There are two ways in which the “on-demand” approach can be implemented.

Remittance based on transactions’ funding date

When this approach is used the funding of a transaction happens after a fixed time period counted off of the date when the transaction is funded by the underlying processor. (The funding date in this case is the date when the PSP actually gets the money from the processor.)

The advantage of remittance based on the funding date is that PSPs don’t have to float any money themselves.
The disadvantage of the approach is that it might become extremely complicated when funding is performed by different institutions (banks, processors of different types) with different time schedules. However, if all underlying funding happens on the same schedule, using this approach is not a problem.

For example, if funding period equals to two business days, transaction processed on Monday will be funded by the processor on Wednesday, and the merchant will receive the funds on Friday.

Funding-date-based approach is, technically, recommended for situations when all of the funds are received by PSPs with the same time delay.

Remittance based on transactions’ response date

When this approach is used, the funding for a transaction happens after a fixed time period counted off of the response date of the transaction. (Response date is the date when the response to the transaction (approval/decline) is received from the underlying processor, and, thus, it is known whether the transaction got approved or declined.)

For example, if funding period equals to two business days, transaction processed on Monday will be funded on Wednesday, regardless of when the PSP receives the funds from the processor.

For PSPs who have multiple underlying funding institutions, which operate on different schedules, the solution is to fund all transactions based on response date. This does make reconciliation more complicated for the payment service provider and potentially requires floating of funds, but it simplifies reconciliation for the merchant (as all of the funds are consolidated into a single deposit) and gives the payment service provider a very important competitive advantage.


A merchant submits a file containing ACH, Visa/MasterCard and Amex transactions. Let us assume that ACH transactions are funded back to PSP the next day, Visa and MasterCard transactions – two days after and Amex – four days after the submission (which is not uncommon in the industry today). For example, the file is processed on Monday. On Tuesday ACH transactions will be funded back to the PSP. On Wednesday the PSP receives the funds for Visa/MasterCard transactions, and on Friday Amex transactions get funded.If funding (remittance to the merchant) is based on response date with a two-day delay period, then on Wednesday the merchant will get all the funds for the transactions processed on Monday, but the PSP will have to float the funds for Amex transactions.

If transactions are funded based on the date of their funding by the underlying processor (with the same two-day delay period), then the merchant will get the money for ACH transactions on Thursday, for Visa and MasterCard transactions – on Friday, and for Amex – next Tuesday. While under this model the PSP never has to float its own funds (send them to the merchant), the reconciliation for the merchant is rather complex, especially if processing happens daily.

In the next article we will continue developing the topic of merchant funding (remittance) process for PSPs. Particularly the article will cover the process of handling merchant fees.