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.

Split Funding Challenges

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

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

PSP-centric split funding model

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

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

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

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

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

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

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

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

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

Merchant-centric split funding model

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

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

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

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

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

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

Remittance issue in split funding

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

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

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

Conclusion

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