Payment Gateway Branding

It is more and more common for present-day businesses to use white label payment gateway software. The purpose of this article is to familiarize merchants and PSPs with the concept of payment gateway branding and the role it plays in merchant services industry. It also covers some payment gateway branding solutions commonly implemented by industry players in order to achieve greater flexibility and gain competitive advantage.

Payment gateway branding concept

The concept of payment gateway branding comes into play when a company utilizes the technology of one of its vendors to deliver services to its customers under its own name. The key idea behind payment gateway branding is to make availability of services on sub-contractual basis more transparent and simple, and, thus, allow relatively small businesses to strengthen their image and reputation in the eyes of their customers.

Payment gateway branding levels

Within the payment services industry branding is possible on several levels. Each branding level represents a relationship between three actors:

  • vendor – usually, represented by a merchant service provider (MSP). MSP, in turn, can be either a gateway, PSP, bank or an actual processor
  • business – represented by a merchant, a reseller or a PSP
  • consumer (customer, service user) – represented by a cardholder, a merchant or a reseller

Generally, the components to which branding is applicable, can be divided into two groups:

  • components related to processing and operations (such as gateway URL, e-mail notifications about successful payments, logo on merchant statements etc)
  • support-related components (such as integration specifications, knowledge base, tutorials and support e-mails)

Let us take a look at specific items to which branding can be applied at each of the levels.

Level I: MSP (gateway)-merchant-cardholder

Vendor: MSP or gateway
Business: merchant
Customer: cardholder

Items (or components) to be branded on this level include:

  • Payment pages (or payment portals)
  • Virtual terminal
  • URL, company name and logo for self-service portal
  • various e-mail notifications (account setup, payment notification, chargeback summary)

Example

An example of level-one branding would be a cardholder who opens a payment page, using merchant-specific URL, and sees the merchant’s name and logo on the page, as opposed to generic logo and name of the underlying gateway that provides this page.

Level II: Payment gateway (MSP)-reseller-merchant

Vendor: MSP or payment gateway
Business: reseller
Customer: merchant

There are two common models on which relations between merchants and resellers can be based.

  • A reseller functions as an agent of the larger underlying entity (processor or other) and requires no branding, for the most part.
  • A reseller functions as an ISO or PSP, and in some cases full branding is preferable.

In addition to items that can be branded on Level I, the components at this level include:

  • merchant statements
  • integration specifications
  • tech-support e-mails

Examples

An example of level-two branding would be a merchant statement received by a merchant from a reseller (even if actually generated by the gateway), bearing contact information and logo of the reseller, as opposed to contacts and logo of the underlying PSP or gateway.
A reseller would like to have a support e-mail (for instance, support@reseller.com) for its customers, but does not have technical staff to answer the e-mails. In such cases a gateway owner can supply a branded e-mail, maintained on the domain of the reseller, and have its own technical personnel responding to the e-mails on behalf of the reseller.

Level III: MSP/gateway/processor-PSP-reseller

Vendor: MSP or payment gateway/ processor
Business: PSP
Customer: reseller

In addition to items which can be branded on Levels I and II, the components on this level include:

  • reseller statements
  • management tools (CRM)

Example

An example of level-three branding would be a reseller statement received by a reseller from a PSP (even if actually generated by the gateway), bearing contact information and logo of the PSP, as opposed to contacts and logo of the underlying gateway or processor.

For most payment systems it is still problematic to support level-three branding. There are two approaches that can be used to attain this branding level:

  • Deployment of a separate server instance for every PSP – a separate server with a separate database is set up for each PSP. Merchants (or resellers) of a given PSP are stored in that database. The disadvantage of this approach is that multiple independent instances of an application have to be maintained, and it is extremely difficult to provide single sign-on for the technical personnel of the PSP, that manages the servers
  • Support of a three-level hierarchy architecture within payment gateway software – all PSPs together with their merchants and resellers are stored in one and the same database. A single server cluster is used as opposed to independent servers. This approach allows to have the same code deployed across all PSPs and makes access to data considerably easier for support people, that have to perform cross-PSP support functions and access information of different PSPs at the same time

Conclusion

The payment gateway branding concept is rapidly gaining importance in today’s business environment. Regardless of whether you are a merchant, a reseller or a PSP, when you make your next decision about the payment technology to use, you should take into consideration the branding capabilities of the payment gateway you cooperate with.

It is particularly important for large payment service providers with complex payment systems to use payment gateway software capable of supporting all three levels of branding, without the necessity of maintaining separate service instances.

Merchant Services Reserves

The purpose of this article is to familiarize PSPs with the concepts of merchant services reserves. As mentioned in the previous article, handling of transactions that occur outside the normal processing cycle is an important consideration to bear in mind in the context of merchant funding (remittance). These transactions are refunds, ACH returns and chargebacks.

Chargebacks and ACH returns can come in within 60-day period from the time when the original transaction was processed. Consequently, the money for that transaction may already have been funded, and it is important to ensure that merchant will be able to cover the expenses resulting from these types of transactions.

The most common tool for dealing with refunds, chargebacks and ACH returns is withholding of the reserves.

Merchant services reserve concept

Generally, a merchant services reserve is a pool of money that is maintained to minimize the risk of financial fraud for PSPs (third party processors or payment facilitators). There are three reserves, which are commonly maintained, and can be dynamically adjusted every time a remittance process occurs.

The types of merchant services reserves and models for reserve formation are addressed in the sections below.

Types of reserves

Conceptually there are two reasons why reserves are maintained.

Firstly, reserves are intended to cover expenses resulting from transactions that reverse previously approved payments, and occur after the originally approved payments are already funded. Examples of those are chargebacks and ACH returns. Reserves for ACH returns and chargebacks are held because these transactions can come within 60-day period after the time of the original transaction processing.

Secondly, reserves are intended to cover expenses resulting from transactions that produce negative balance against an account (bank account) that doesn’t belong to the merchant, for example, credits and refunds. Reserves for refunds are often used by wholesale resellers, who use aggregation models (or by PSPs), as refunds for merchant’s products are withdrawn from the PSP’s account.

All merchant services reserves are always withheld by PSPs as deductions from merchant remittances. When a refund needs to be performed, the funds are taken out from the refund reserve. If the reserve is empty, no further refunds can be issues.

Merchant services reserve calculation models

Generally, a reserve can represent either a fixed amount or a percentage of processed transaction volume. These two approaches for merchant services reserve calculation are addressed below.

Reserve as a fixed amount

Under this approach a reserve represents a fixed amount of money. The approach is commonly applied to refund reserves. A certain fixed number (say, $5000) is established, providing the maximum reserve and the maximum possible amount of refunds.

Reserve as percentage

Under this approach a reserve is established as a percentage of the total volume of transactions approved. The option is more frequently used for ACH return and chargeback reserves.

A reserve percentage together with analysis time period (one or two months) is established. Every time a remittance is performed, depending on the time frame, transaction volumes processed during the last 30 or 60 days, are analyzed, respective established percentage is calculated, and the resulting amount becomes the reserve requirement. Reserve is refilled as a deduction from a remittance.

In some cases, if processing volumes increase, larger reserves may need to be withheld, while, if processing volumes decrease, some funds need to be returned back from the reserve. Sometimes, it is recommended to retain a minimum fixed amount in the reserve even if total reserve requirement is dynamically calculated. It is used as insurance against sharp decreases in processing volumes. That is why, beside percentage and time frame, chargeback and ACH reserves are often characterized by a fixed minimum reserve amount. For example, reserve amount may vary from $1000 to 5% of processed transaction volume. In such cases, if a merchant’s processing volume drops, the reserve amount cannot fall below the fixed threshold.

Example

Sliding time window 30 days
Reserve percentage 5%
Minimum reserve amount $500If volume of transactions processed during a month is $20000 then the reserve requirement will amount to $1000.
If volume of transactions processed during a month is $5000 then the reserve requirement will amount to $500 (and not $250 resulting from percentage calculation).

Conclusion

PSPs need to withhold refund, chargeback and ACH return reserves in order to protect themselves from losses induced by the respective types of transactions. Merchant services reserve amounts need to be carefully and flexibly calculated in order to provide the best solutions for both PSPs and merchants.

Handling Merchant Fees

In the previous article we touched upon the topic of merchant funding, which is particularly important for payment service providers. This article is also targeted at PSPs, also known as third-party processors or payment facilitators. In the article we are going to address such important aspects of merchant funding (remittance) as withholding of merchant fees.

As mentioned in the previous article, one of the challenges faced by PSPs in connection with remittance and funding processes is that, regardless of the pricing structure, it is desirable to keep the process of withholding of fees as clean and as transparent as possible.

One of the crucial questions to be addressed in the context of merchant funding is “how” and “when” to take out merchant fees.

How to take out merchant fees?

Deducting fees from subsequent remittance

One way is to take the fees out of the subsequent remittance. For instance, if at some point a merchant owes $100 in fees and has just processed $1000 worth of transactions that merchant will be funded $900 instead of full $1000.

The advantage of this approach is that it is easier to spot\detect the situation when a merchant has no funds to cover the fees.

The disadvantage of the approach is that if a merchant discontinues processing, or if a merchant’s processing volume drops, there may not be enough money to cover the fees already accrued.

Withdrawal of merchant fees as a separate transaction

The second approach involves issuing a withdrawal (usually, as an ACH transaction) either from the same deposit account, or from a separate bank account that was designated by the merchant for withholding of the fees.

The disadvantage of the approach is that this type of withdrawal may result in ACH returns, which might be difficult to track, and, thus, it becomes more problematic to see the outstanding balance of the merchant (in contrast to the first approach).

Under the first approach the actual balance of the merchant is always clear, while under the second approach there is always a risk of arrival of ACH return up to 60 days from the day when fees where taken from the merchant.

When to take out merchant fees?

As mentioned above, another important question to be considered by a PSP is “when” to take out fees. As in case of “how”, there are two options.

Withholding of merchant fees at the time of a deposit

One approach is to take out merchant fees at the time of the deposit.

This approach is often used in conjunction with the on-demand remittance model (when funds are disbursed fixed number of days after transaction processing – see the previous article for details). If a PSP is funding transactions and taking out merchant fees right away, it can have fees deducted taken from the remittance. Such combination is quite a common one.

Example

On Monday a merchant processes a $1000 worth of transactions. If the fees are withheld at the time of the deposit then, and remittance is done based on response date with a two-day delay period, then on Wednesday the merchant gets this sum minus (for instance) $50 of fees ($950).

The advantage of the approach is that the PSP has higher chances of collecting the fees.
The disadvantage of the approach is that it makes daily reconciliation more complicated for the merchant. For instance, if a merchant processed $1000, it will not get the full $1000 (as fees are taken out), so the described approach makes it really difficult for merchants to reconcile, as they always have to consider the fees.

Withholding of merchant fees based on time cycle

Another approach is to take out money at the end of a processing cycle, which is, generally, a calendar month.

Example

If a merchant processes a $1000 worth of transactions on Monday, it gets the full amount on Wednesday and $50 of fees are taken out at the end of the month.

This second approach is often used in combination with withdrawal of merchant fees as a separate transaction discussed above.

The advantage of the approach is that this approach makes reconciliation easier for merchants, as they only have to reconcile the fees part at the end of the month.
The disadvantage of this approach is that it requires the PSP to potentially float its own funds, if PSP is funded net of fees by the underlying processor. Another disadvantage for the PSP is that at the time it attempts to collect the fees, the funds may not be in the account.

In the next article we are going to address the handling of transactions that occur outside the normal processing cycle, namely, ACH returns and chargebacks.

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.

Example

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.