Split Funding Models

Traditionally, when merchants processed their transactions, the processor simply deducted processing fee and funded the merchant the rest. Presently, there is a growing need to split the part into several deposits. One of the main reasons for that is the emergence of online marketplaces.

From conceptual viewpoint, there are two ways to implement split funding mechanism. A company may need to implement one way or another, depending on its business model. Some business models, however, need to accommodate both ways at the same time in order to function effectively.

The purpose of this article is to inform the readers about the two types of split funding platforms, so that they could choose the more suitable platform type.

Customized split: split funding on the submitter’s end

The most common and simple type of split funding mechanism is as follows. When a transaction is processed, the submitter specifies, how the funds are to be split. Say, there are two or three recipients specified at the moment of transaction submission. Recipients are merchants or users, registered within the system, that are going to receive their shares of the total transaction amount.

In other words, the submitting system specifies particular splitting (fund distribution) rules on per-transaction basis.

This approach is more suitable when the distribution of funds depends on the specific context of the transaction, such as the number of affiliates involved, or the number of items purchased.

Example 1

A customer purchases a t-shirt for $25, and the submitting system determines that there is an affiliate, involved in the transaction, who should receive $5. Therefore, the system specifies that the total transaction amount is $25, of which $5 should go to the affiliate.

We should note that, when the next t-shirt is sold, the distribution of funds might, actually, be different.

Pre-defined distribution: split funding on the gateway’s end

Under the second model (the more complex one), the split funding rules are set up in advance in the system itself (on the payment gateway’s end). Some information on merchant services commission sharing is available here {link}.

The second model is more suitable when the distribution rules are the same from transaction to transaction.

Example 2

An online rent payment software vendor partners with some specific payment gateway. The gateway charges a convenience fee. For each transaction the rent payment software charges $4.50 from that convenience fee. The rules can be configured accordingly in the rent payment software and recorded on the gateway’s end.

Example 3

An online store sells t-shirts and hoodies online. T-shirts and hoodies are provided by two different vendor companies. For t-shirt sales the online store marks up 10%, while for sales of hoodies it marks up 8% of net transaction amounts. The rest (90% and 92%) of net transaction amounts, respectively, goes to the vendors. Consequently, after the respective distribution rules are setup, when a transaction happens, it will be sufficient to specify the vendor involved.

Split funding peculiarities

We should note, that in each split funding scenario it should be clear, who is responsible for the payment of fees. In most cases it is easier to make the account, under which the transaction is processed, responsible for the entirety of the fees. In other words, the entire fee is paid by the merchant and not split into parts. However, there might be scenarios, when the fee needs to be split between multiple parties.

Another issue to address is handling of void and refund transactions. As every sale transaction is eventually split into multiple ones, it is necessary to define, how the sub-transactions can be voided or refunded. The simplest option is to allow void/refund of the main transaction and, subsequently, void or refund all sub-transactions. However, more customized scenarios may also be required.

Conclusion

Your choice of split funding platform should depend on particular split funding needs of your business.
If splitting logic is complex and context-dependant, while the software integrator (customer) needs to have full control of the distribution rules, the first (customized split) model is preferable.
If splitting rules are more or less consistent from case to case, the second approach (pre-defined distribution) might be more appropriate.

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.

Conclusion

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.

Dealing With Multiple International Payment Platforms

Introduction

Present-day globalization tendencies push more and more businesses to process payments in multiple geographical zones.

Particularly, such companies include businesses, which start offering their products online internationally, and franchises, which enter international markets.

The purpose of this article is to outline the problems faced by these companies and try to provide structured step-by-step strategy that they could follow.

Problem

Let us say, there is a company, which wants to solve the problem of multi-currency and international transaction processing for itself or for its clients.

Context

The task of entering an international market can be addressed at one of the three “complexity levels”.

  • Level 1: A company wants to process its own transactions (product sales) in different countries.
  • Level 2: A franchisor wants to operate in different countries, but in each country at most one processing partner is sufficient (a franchisor can impose all franchisees to use a single processor).
  • Level 3: A software vendor company wants to service many clients in different geographic zones using several processing options (support more than one platform or acquiring bank in each country).

Strategy in brief

The crucial issues you will definitely have to deal with (if you want to expand your operations to multiple geographical locations) include:

  • Finding a solution for operations with several currencies
  • Prioritization of regions
  • Prioritization of typical transaction types handled by your payment ecosystem
  • Organization of underwriting and on-boarding processes in new geographies
    • Strategy in detail

      In order to organize the process properly, first of all, you have to study the overall situation and then – answer some fundamental questions.

      • Is it going to be possible to settle transactions in one single currency, or settlement currency must always be the same as authorization currency? If a company wants to charge its customers in a local currency and settle the funds from international sales in a single bank account, it can partner with a single acquirer, that supports dynamic currency conversion. If it plans to settle transactions in the local currency, then a local relationship with a specific bank will be required. In the second case a more complicated payment ecosystem will have to be built.
      • What are the high-priority and low-priority regions? What the actual transaction volume is going to be? Evaluation of transaction volumes is necessary for pricing negotiations and related issues. Establishment of the relationship with a payment processor and implementation of the required technical integration is never a simple process. It takes plenty of time, and it becomes even more difficult at the international scale, especially when several projects are under way. Most likely, you will have to proceed in the sequential manner, which is why it is important to prioritize.
      • What are the transaction types you need to process? Are you going to deal only with online card-not-present transactions? Is card-present transaction support required? Will you need EMV support and respective payment terminals? Usually, it is much easier to find a card-not-present solution, because various local regulations exist for use of the chip cards in a particular region. In some cases region-specific specifications are necessary for you to be able to accept cards in the retail environment. The additional challenge is that in some countries it is not possible to certify your existing EMV solution, and you may be required to use whatever is available on the local market. Some of these available solutions might not fit into your existing payment ecosystem.
      • Which banks will handle the underwriting process, and how merchant accounts are going to be issued? How are you going to integrate with these banks? What is the specific connection mechanism? These questions are extremely relevant for many countries. However, in some countries (say, in North America) there are payment gateways, which work with several processors or acquiring banks, and are able to facilitate your relationship with any one of them. On the international arena, the options might be more limited, because some regions have only few acquiring banks, and some gateways might be limited to work with only specific acquiring partners.

      As we can see, all business details (including corruption as well as local regulations and legislative barriers, which might result in cost increases) must be discussed and considered in advance.

      You must find the gateway, providing the best solution in each specific country in view of the listed questions.

      Finally, you will get a list of countries, banks and payment platforms you will have to partner with. After that you will have to analyze the available gateways and check, which of them have either all or most of the necessary bank connections.

      Example

      Let us consider a case when some “optimal” solution is found. Say, there is a gateway, which supports 3 of the 5 necessary bank connections, but is unable to add the missing 2 and all the subsequent ones (or the payment gateway provider is reluctant, because the cost of new connections is too high). This is just the case when you have to consider creating your own payment ecosystem (for some companies this might be the overall goal).

      Next you have to define, in which countries you will have to start from scratch, and in which countries you have some clients (merchants) already using the system. Keep in mind, that in any case if you are going to expand your operations, a strategy will be needed for on-boarding of new merchants.

      Existing clients

      Example

      A franchising company is a vendor of software for fitness centers. It doesn’t have any integrated solutions within the country. Franchisees have to establish a relationship and purchase standalone terminals from it. Every transaction, made at POS, is processed using the standalone terminal, and then – keyed into the main system of record, provided by the franchisor. The franchisor decides that the solution based on usage of standalone terminals is a bit complicated and it is better to offer integrated payment processing functionality. In this case the franchisor has to migrate the already existing merchant accounts.

      In such a situation, you have to analyze, how to migrate these clients from their existing solutions to the company’s main product. Beside that, you need a strategy for the new underwriting process (get new merchant accounts for the already existing merchants and check if processing costs are going to increase). Finally, you have to define, which technical solutions are needed (in terms of additional integrations) in order to allow merchants to be able to send transactions for processing.

      New clients

      If you have no clients (yet) in some region, you have to work out operations for on-boarding process in each particular country.

      Conclusion

      If you are planning to enter foreign markets, handle new currencies, and process transactions internationally, you need to set up priorities and develop a step-by-step expansion strategy.

Handling Bank Account Transfers Worldwide

This article is targeted at those who need to deal with bank accounts in different countries while processing transactions. It explains certain aspects associated with the process in different parts of the world.

Every US based business, dealing with bank accounts internationally, should pay attention at these things and the particularity of the process in each country of operation.

Globally, there are two types of systems, which are most popular today. Systems of the first type, allow for one-phase processing of fund transfers between accounts, while systems of the second type allow for two-phase processing.

One-phase processing of bank account transfers

One-phase processing is used in such countries as the USA and Canada. In these countries inter-bank fund transfers are conducted through a nation-wide clearing house. In the US, for instance, the clearing house is the Federal Reserve. A merchant has to send a file with the list of transactions to be funded (withdrawals) to the clearing house; within one or two days it gets the requested funds from the clearing house. After that the clearing house sends transaction requests to respective banks to verify the availability of funds and complete these transactions. Usually, member banks will then have certain time period (up to sixty days in the US) to either confirm transaction or decline it. If a bank declines a transaction for whatever reason, then the return is sent to the merchant, who originated the transaction, and the funds are forcibly withdrawn from the merchant’s bank account (check our article on ACH returns for details).

Two-phase processing of bank account transfers

Two-phase processing is used in the UK (BACS), EU (SEPA), and Australia. Under this approach clearing houses are also used. However (in contrast to one-phase systems), in such systems as BACS and SEPA all bank accounts must be registered within the system before any financial transactions can be processed through them. A registration file with the list of accounts is sent by a merchant to the respective financial authority (body), which issues payment mandates to merchants. (At the stage of bank account registration invalid bank accounts can be identified). Within a certain period after the registration (generally, about two weeks after the mandates are obtained) the merchant can start processing actual transactions. After that the process, generally, follows the same patterns as during one-phase processing. The clearing house contacts member banks to clear the funds. However, most of two-phase systems, usually, provide most of the responses within three days and do not require the 60-day wait period (as the accounts are already registered in the system). However, some banks may delay payments, while some other banks may dispute them post factum.

The advantage of the first system is its simplicity, while the advantage of the second system (although more complex) is its reliability. I.e. in the second case merchants have better chances of getting their money from valid bank accounts of their customers, however, implementation of a two-phase system requires more efforts.

Conclusion

If you are a payment gateway provider, processing worldwide, and you want to process in the countries, using different banking systems, you need to pay attention at the architecture of the whole process. Your main objective in this context is to make your payment gateway capable of working with both one-phase and two-phase systems, while providing your customers with a unified integration API.

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

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.

Conclusion

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 Gateways II: Credit Card Convenience Fees

The purpose of this article is to familiarize merchants and resellers with the concept of transaction surcharges as an advanced feature to be considered during payment gateway/processor selection.

If this is the first time you are reading our “Payment Gateways II” series, please, start with the Introduction to improve your understanding of this post.

Some businesses require surcharging a fee on top of the original transaction amount. The two most common surcharge examples are credit card convenience fees and taxes.

Credit card convenience fees

Every time a merchant processes a transaction, there is a processing cost associated with it. Traditionally it used to be covered by the merchant. However, there is a practice of applying a credit card convenience fee, functioning as a surcharge on the original transaction, to pass the cost of processing to the cardholder. Historically associations, such as Visa, MasterCard tried to discourage the practice, but under the pressures of businesses they’ve accepted it. As a consequence, many merchants are now able to afford credit card processing, because they are charging convenience fee to cardholders.

Credit card convenience fee implementation

Credit card convenience fee can be processed as part of the original transaction or it can be processed as a separate transaction, resulting in two transactions on the card. The first option is often considered a better one; it is preferred by Visa, and, from cardholder’s viewpoint, it involves just a single transaction. The second option is unpopular with card associations, especially with Visa.

If a merchant business is limited in the capability of doing two transactions, it needs to go with a processor capable of accommodating the surcharge in a single transaction. If a business chooses to use two transactions through two different MIDs then it will need to somehow handle the situation when the second transaction doesn’t go through because of insufficient funds or network communication error.

A mechanism very similar to the one used for credit card convenience fees is also used for surcharging of taxes.

While support for surcharges is not a very critical factor, and the entire decision, whether to go with a processor or not, is not going to be based on it, it should be considered. So merchants should discuss the support for surcharges of credit card convenience fees with their processors.

Let us look at a real-life example of how credit card convenience fees are used.

Example

A bill payment service company has an online payment portal that utility companies can use to collect past due balances from their customers. The bill payment company wants to surcharge a 5 % convenience fee on every transaction processed to cover the costs of processing and its services.
The simplest way for the company is to send a single transaction and then get its 5 % as a rebate back from the processor. The ability to charge a credit card convenience fee as part of the original transaction and receive the money back from the processor as a form of rebate at the end of the month (or simply get its 5 % automatically deposited to its account the day after the transaction is processed) reduces the complexity of integration process for the bill payment company. In either case payment processing logic within the bill payment application becomes considerably easier (as there is no need for logic targeted at processing of credit card convenience fee as a separate transaction).

Conclusion

Businesses that need to charge credit card convenience fees should go with a processor that has native support for that. When evaluating processors’ convenience fee support capabilities, businesses should pay attention to the available mechanism (one transaction vs two transactions); the decision regarding processor selection should be made based on the specific business requirements.

Payment Gateways: Settlement (Capture)

The purpose of this article is to discuss adequate transaction settlement (capture) mechanisms as a criterion to be considered during payment gateway selection.

If this is the first time you are reading our “Selecting a Payment Gateway” mini-series, please, start with the Introduction to improve your understanding of this post.

Credit card payment processing involves two phases. The first one is authorization, when the card is verified (it is checked whether the necessary sum of money is available on the account) and the money is blocked (reserved for subsequent settlement). The second one, usually taking place at the end of the business day, is capture (or settlement), when the reserved amount is withdrawn from the card-holder’s account and transferred to the merchant’s account (the funds are settled). Therefore, to complete transaction processing, settlement has to be performed.

Settlement mechanisms

In general, there are two settlement mechanisms commonly referred to as terminal capture and host capture.
In the case of the host capture most of the work required to settle transactions is actually done by the host system (payment gateway). When host capture is used, payment gateway (the host) keeps track of all the authorizations and takes care of settlement on its own.

Settlement is generally done:

  • once a day at a fixed time
  • multiple times a day within fixed settlement windows
  • on demand when end-of the day settlement message is received.

Generally, no or minimum information is required from a merchant to use host capture. Terminal capture is usually done by sending a settlement message\settlement file with the full information about the transactions that need to be settled. Terminal capture puts all the responsibility for the settlement logic upon the submitter (merchant).

While terminal capture does provide more control over the settlement process, it is easier to deal with host capture whenever it is possible, because it is easier to implement and support.

From the global perspective all types of settlement can be viewed as belonging to one or two groups: merchant-initiated or time-initiated. Terminal capture and on-demand host capture are merchant-initiated. Settlement, performed daily at fixed time, or several times a day within fixed settlement windows, we are talking about time-initiated host capture.

When choosing the settlement approach, every business needs to consider, what the best option is: merchant-initiated versus time-initiated, and host capture versus terminal capture.

Merchant perspective

In each particular case it is important for a merchant to consider all the business needs while making a choice between terminal capture and host capture mechanisms, as host capture may not support certain features needed by the merchant.

Example

A fitness club, that works 24 hours, has three shifts of employees changing during the day. There is a common practice of settling out all of the transactions that were authorized during a shift when a shift is closed. In a situation like this, the scheduled settlement (without end-of-day message) is unacceptable for the merchant, as it has to be performed several times during the day, not necessarily at a specific time. Consequently, dealing with a processor\payment gateway, which supports only scheduled settlement, will be problematic for the fitness club.

Conclusion

While the preference is usually on the host capture side, merchants need to check if it fits their business model, and, at the same time, whether all the necessary features can be accommodated by the host capture system (as some features might be supported by payment gateways only under terminal capture).
If all of the features necessary can be accommodated by the host capture mechanism, it is really the preferred way of settlement.

Reseller perspective

As in the cases of other payment gateway selection criteria, while choosing a settlement mechanism, a reseller must carefully analyze the needs of the merchants it is dealing with.

Example

One of the potential problems to be addressed by a reseller may be that each merchant might need some business specific logic. Particularly, if a payment gateway can perform settlement for a merchant at the same predefined time during the day, and merchants are situated in different time zones, it might be difficult to adjust time settings for each merchant individually to ensure proper settlement time for each timezone. Consequently, in such cases it may be easier for the reseller to delegate control of the settlement process directly to the merchant (terminal capture), than to adjust time settings to every merchant’s time zone (host capture) with the payment gateway.

Conclusion

While making a decision concerning settlement mechanism selection, a reseller should consider all the aspects, which are critical for a merchant. However, if resellers accept some limitations in order to simplify the integration process, they need to understand that any problems resulting from these limitations will be multiplied by the number of the merchants the resellers are dealing with.

Our next post will cover standard credit card features to be considered during payment gateway selection.

Payment Gateways: Processing Costs

The purpose of this article is to discuss credit card transaction processing cost as a criterion to be considered during payment gateway selection.

If this is the first time you are reading our “Selecting a Payment Gateway” mini-series, please, start with the Introduction to improve your understanding of this post.

Although processing cost is not the only factor to consider while selecting a processor, it is nevertheless, extremely important. Understanding the processing cost anatomy is not easy. For more information on credit card processing costs, fees and rates, refer to this article.

Processing cost components and transaction pricing strategies

To put it shortly, processing cost consists of base costs (which include interchange fees and assessments) and markups. Within card processing cost it is mostly markup that is negotiable. The three pricing strategies predominant in the industry include: “cost plus” (also called “interchange plus” or “pass through”), tiered (or bundled) pricing and blended rate. Every other pricing strategy, after closer consideration, usually turns out to be a variation of these three.

Blended rate pricing

Blended rate pricing strategy is the easiest to understand; it does not take the differences in card types and transaction costs into account at all. Under blended rate pricing, the processing fee is usually established as an average processing cost plus some fixed markup.  In other words, regardless of the card type, the same price is charged for every transaction.

So if a business has a good variety of cards it is constantly dealing with, under blended rate pricing these differences don’t matter much. But if a merchant knows that some card types are predominant in the transactions processed (for instance, the  business is dealing mostly with debit cards), then this merchant is going to consistently overpay.

Tiered pricing

Tiered pricing, in essence, is an extension of blended rate pricing model, where transactions are assigned to different tiers. These “tiers” or “levels” are defined by ISOs/processors based on transaction qualifications, card types or other factors. The problem with tiered pricing is that the processor’s scheme of transaction qualification may be really difficult to understand. And without understanding it, a merchant would often be unable to predict the cost of a transaction before it settles. At the same time, even with multiple tiers, some averaging of cost still occurs (similarly to blended rate model) and, consequently, there remains a risk of systematic overpayment by a merchant.

Cost plus

Cost (interchange) plus is the most transparent of credit card processing pricing models, because the processor’s markups do not depend on base interchange.  All markups are charged as a fixed rate fee on top of true cost, which comes from an association (Visa, MasterCard, etc) for every transaction.

Merchant Perspective

Naturally, any merchant will look for a processor offering the most cost-efficient pricing model. While considering the processing cost, it’s important to remember that different transactions cost differently. In general, some transactions (as a group) will cost cheaper to process than others. For example, debit cards would cost considerably less to process than reward cards (or credit cards with cash-back option), and swiped credit cards would qualify for a lower rate than keyed cards. A merchant would want the processing fees to be structured based on true cost. Actually, a merchant would wish the final cost to be as close to the true processing cost as possible, with the above-mentioned differences in transaction costs (interchange qualifications) taken into account.

Beside the price that the merchant gets quoted, the merchant also needs to think about the types of cards it processes (debit or reward, keyed or swiped, etc) and fee structure that is offered. Any merchant would definitely want to go with someone whose pricing model reflects the differences in card types.

Example

The health club chosen as an example is going to be dealing with a variety of cards, but might be heavier on the card-not-present side (all membership dues are collected as card-not-present). To optimize the cost it would be best for it to go with a processor providing “cost plus model.

Conclusion

In general, the advice to a merchant who wants to get a transparent and flexible model reflecting card type differences is: go for “interchange plus” pricing. The recommendation is especially relevant for those who are more on the debit cards side.

Reseller Perspective

Traditional types of resellers (such as ISOs) are generally interested in flexible and affordable pricing structure. Software companies acting as resellers might also be interested in the ability of the processor\payment gateway to combine software fees and processing fees.

Example

Usually, software companies tend to charge separate fees for software usage and separate fees for transactions processing services. For instance, a fitness software company wanting to offer merchant services to its customers could charge a certain amount in dollars per month for software (say, $100 per location) plus optional 2.5 % for processing. However, in today’s environment it might be more beneficial from the marketing standpoint (and more profitable) to offer managed processing at 5 % with software included for free.

Conclusion

In general, a reseller should prefer to partner with the processor\payment gateway offering “cost plus” pricing model, as it makes it easier to price and resell, and seems to be more appealing in today’s market.

Those resellers interested in charging their service fees as part of the processing costs should consider processors\payment gateways capable of accommodating this.

Our next installment will be dedicated to ease of integration with different credit card processors\payment gateways.