By Adam Atlas
Attorney at Law
You thought you were selling countertop POS equipment and merchant accounts; then you found yourself selling software platforms for merchants to manage payments, loyalty, personnel and inventory. What started as a simple payment business has become a merchant business consulting boutique.
This is a good thing because ISOs that sell more than just payments stand a better chance of developing better ties to their merchants and keeping them longer. Knowing this, ISOs should also know a thing or two about the legal packaging of applications and systems that are the backbone of contemporary business.
When installing a new app on your phone or other device, most of us do not bother to read the terms and conditions that apply to the app. Believe it or not, lawyers spend a lot of time thinking about and drafting what usually constitutes an end-user license agreement (EULA).
But the EULA not only defines the rights of the user; it also allocates risk, defines information sharing rights and sets out the cost of use to the user. From the viewpoint of app developers, the EULA needs to protect their intellectual property rights and limit their liability. From the standpoint of a typical user, a EULA should actually provide the unfettered right to use the application.
ISOs navigate an already confusing marketplace. So when ISOs add a new service beyond basic processing to the mix, such as a loyalty program, they should examine the offering and see who, exactly, is the provider of the service to the merchant.
There are two possible outcomes in this example. First, the loyalty program has a direct contract with each of the merchants and is the provider – and party to the EULA with the merchant. Second, the program may be set up so that the EULA entered into by the merchant is directly with the ISO and not the loyalty provider.
I am regularly amazed by how many payment startups have not made this distinction clear; they have not taken the time to clarify exactly who the parties are to the various agreements by which their businesses operate. Naturally, we want to know, because the party to the EULA with the merchant is more likely to be in the front row for a legal claim.
On the other hand, having an agreement with the merchant to supply the service, while exposing the provider to risk, also gives the provider greater title or ownership of the merchant account, and ownership means value. ISOs therefore have to learn exactly what the matrix of contracts will be and decide how they want to fit into it.
Once ISOs have sorted out whether they are party to the EULA, they should also pause to consider the contents of the EULA. Ironically, the more useful an app, the more likely it is to result in a claim. For example, a personnel and inventory tracking application that works well and integrates with other platforms that the merchant is using, will likely result in merchants using it and relying on it.
What happens, then, if the system loses all the data of the merchant and a business is stuck not knowing its personnel schedule, inventory status or loyalty card balances? Class-action, perhaps. ISOs should care about limitation of liability in apps that they promote for their merchants because the ISOs may be in the unfortunate position of having to defend a claim related to the app.
When an ISO sells an app to a merchant (whether or not the ISO is party to the EULA for the app), the ISO will want to know about the charges applied to merchants by app providers, for a number of reasons. First, the ISO's revenue on the app is likely a function of the payments made by the merchant under the app. Therefore, knowing about in-game payments, for example, is important for the ISO to track its entitlement to revenue on the app.
Second, the ISO wants to know that the merchant has actually consented to the charges being applied to the merchant. Nothing could be worse for an ISO than overcharging a merchant for a simple add-on that results in termination of the merchant account.
App developers are constantly pushing the boundaries on what kind of equipment can be used to collect, store and transmit cardholder data. Meanwhile, ISOs have been educating merchants on Payment Card Industry (PCI) security standards and compliance for years. These are divergent and competing interests. Before actively promoting an app, ISOs should enquire as to what data is being collected by the app and how it is used and stored.
For example, some loyalty programs are based on cardholder data. That means that the loyalty program has to be PCI compliant – and exposes the merchant, and by extension the ISO, to potential claims. The ISO should also review the interplay between the app and conventional POS functionality of the device where it is installed.
A significant number of app developers go out of business. Some of them peter out without ever gaining traction; others shut down with a large customer base. If this happens, merchants will want to know there is a way to get support even if the provider is no longer around. The best assurance of this is to obtain access to a copy of the software's source code.
Source code is closely guarded by developers because it is raw content and can be easily copied. Most of the time, source code is simply never released. However, serious developers with serious customers will agree to set aside a copy of the source code for merchants to access in the event the developer goes out of business.
ISOs that are now aggressively selling various add-on services should look under the hood to see that the legal context of those additional services are solid and compatible with their core offerings.
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, email 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