By Adam Atlas
Attorney at Law
Pricing in a merchant services sales agreement is a part of contract negotiations that requires more attention on the part of the party signing the contract than it does of its attorney. The purpose of this article is to highlight a few common misunderstandings related to pricing in merchant agreements that often create disputes between parties.
It is customary for ISOs to pay merchant level salespeople (MLSs) revenue that is the net of certain expenses. In the absence of a clear discussion about what is to be netted out of revenue, fees that the ISO has to pay to its acquiring organization are likely something the ISO may net out of revenue.
However, other expenses that ISOs may have, such as their own internal costs of labor, rent, data et cetera, are less obvious types of expenses to net out of agent income.
The message here for all parties is to have, before signing an agreement, a discussion as to what fees are to be netted out of revenue before or after the split to the agent. Clarity on this point will avoid many disputes and will actually build stronger relationships.
New MLSs in our industry are often paid 50 percent of net revenue on the merchants that they refer to ISOs with whom the MLSs have signed. Much like the discussion over net revenue, ISOs and agents would benefit from understanding the basis of the splits that make the deal.
For example, an MLS may be paid 50 percent of what the ISO receives, before or after netting out certain expenses of the ISO.
There is no prescribed formula for what must be done in these calculations. Instead, the parties should understand their respective intentions regarding these calculations. Once you know the deal, write it into the agreement. If the agreement is already signed, you can always sign an addendum that gives greater clarity to what has already been agreed upon.
In addition, e-mail exchanges over the meaning of certain provisions will be useful documentation in the event that you ever have to dispute the interpretation of the document.
It may come as a shock to know that some very respectable large processors have permitted ISOs or agents to upload certain pricing with respect to a merchant, but then actually charge the merchant something different. When too many fees are collected, this can be embarrassing for the ISO and costly to the relationship with the merchant.
Too many fees collected will also precipitate a dispute over who should reimburse the merchant - the processor or the ISO.
If too few fees are collected, this will also precipitate a dispute between the processor and ISO as to who should make the other whole for fees they believed they would be receiving.
The solution is found in a mixture of action items. First, the ISO and processor should have a regular system for verifying, in each new account, that the merchant is actually being charged what they both think the merchant should be charged.
Second, it is recommended that ISOs take the time to spot-check merchant statements and compare them to the merchant agreements that merchants signed. This is especially relevant to larger merchants, where an error can quickly create problems that exceed an ISO's cash flow.
Again, don't assume that because you uploaded certain pricing into a processor's online boarding system that the merchant is necessarily being charged those amounts.
Take a close look at reserves, both for yourself and merchants. Some merchants end up contributing a never-ending fixed percentage of gross processing into a reserve account without ever levelling off at a percentage of aggregate monthly volume, as would be expected.
For example, if the merchant reserve is set at 5 percent of monthly volume, and monthly volume is $100,000, then when the reserve reaches $5,000, the processor should stop adding to it.
Some processors take a never-ending stream of 5 percent deductions from all monthly settlements. This is a recipe for conflict between all parties.
Similarly, if you are a sales organization that takes liability, your processor may wish to build a reserve for liabilities that are yours. That reserve should also be built in a rational manner, and its balance should form part of the regular reporting to the ISO.
Naturally, the preference is for contractual wording to reflect the agreements between the parties in respect to reserves, like all other matters of pricing.
Pricing under an agreement will inevitably change. The changes must, however, be within customary parameters.
For example, if interchange goes up, then pricing to the ISO can be correspondingly increased. If the processor's phone service goes up in cost, however, that will not likely be grounds for an increase in ISO pricing.
For matters between those two extremes, it is important that the agreement in place reflect some kind of predictable and rational basis on which pricing may be changed.
Regardless of the wording of the agreement, any change in pricing to an ISO, MLS or merchant should always be evidenced by some kind of correspondence; otherwise all parties are exposed to embarrassment, or worse.
Regardless of the legal grounds for a given change in pricing, no change should ever be perceived as arbitrary or purely done for the sake of taking more money.
Again, pricing is that part of a merchant services sales agreement where parties need to pay very close attention so as to be sure that they are getting the deal they think they are getting.
If you are in doubt, run some numbers through a model test account on a spreadsheet and see whether your return is the same as that promised by your processor.
In publishing The Green Sheet, neither the author nor the publisher is engaged in rendering legal, accounting or other professional services. If you require legal advice or other expert assistance, seek the services of a competent professional. For further information on this article, e-mail Adam Atlas, Attorney at Law, at firstname.lastname@example.org or call him at 514-842-0886.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.Prev Next