The online payments space is chaotic. Companies evolve and expand quickly. Processing chain roles get blurred. The branding is slick, and the legal language rarely keeps up with the pace of financial engineering.
I have seen “processing agreements” from companies that don’t process transactions, “merchant services agreements” from entities that explicitly refuse to assist with chargeback disputes, and “payment partners” that would rather jump off a bridge than answer a compliance department inquiry (and to be fair, same).
If you are a Merchant lawyer, you’ve probably encountered similar contractual nightmares and found that there aren’t a ton of resources on this topic. And if you’re a Merchant, well, you probably just want to get paid before these tariffs kick back in and screw you in new, creatively painful ways.
In this article, I’ll do my best to help at least one of you.
Last week, I broke down the difference between direct payment Processors vs. Gateways, and why understanding this difference is critical for Merchant operators and their lawyers. This week, I’m going to dig into (1) how to spot the difference in the wild, and (2) how to paper your contracts accordingly.
Language That Blurs The Lines
While many Gateways are clear and direct about the scope of their services, it shouldn’t come as a surprise that many tech services (or maybe just their sales reps) lean into the confusion between Gateways and Processors. I routinely see contracts littered with Processor-adjacent language: just enough to pass the smell test for a small business that is eager to go live, and doesn’t have a direct line to a Legal Department.
This lack of role clarity between direct payment Processors and everyone else in the payment space is particularly acute in the high-risk merchant space, where processing partner options are limited, and Merchants, perhaps after being unceremoniously dumped by Stripe, are eager to sign with the first payment service that will have them.
This is not a strategy I would recommend, in life or in payment processing. Instead, having good, clear information about your chosen payment service provider is the key. So, regardless of whether you’re dealing with a Processor, a Gateway, or a kid sleeping on a beanbag chair in the Bahamas (waves at SBF), here are the basic questions every Merchant should have the answer to before letting anyone “process” their funds.
Screening Qs: Who is actually in control of your money?
Who is the licensed entity processing and settling funds for the Merchant?
Not the brand. Not the API layer. You want to be able to identify the actual financial institution responsible for the funds.
Does the Merchant have a direct contract with that entity?
If not, what governs the Merchant’s relationship with that entity?
What is the flow of funds, from transaction initiation to settlement?
Understanding the flow of funds is critical. Who touches the money, in what order, and under what conditions?
Is there a reserve required, and if so, who is holding it?
Don’t assume your counterparty is the one in control of the reserve. Which entity will control it, and who will have a say over how it is released?
Who has the authority to delay, freeze, or claw back funds, and under what circumstances?
If it is anyone other than the counterparty you have contractual privity with, that will affect the terms you can accept.
If something goes wrong, who can the Merchant escalate to, and what are their obligations?
Plan for the worst. And also expect the worst. Welcome to the high-risk Merchant rodeo!
Telltale Contract Language
If you’re not getting direct answers to the questions above, or you still aren’t clear re: who is on the other side of the table, consider looking at the actual contract itself (wild idea, I know) for some language clues.
Here are some phrases to watch for if you are looking for a direct Processor over a middleman:
“We act as a single integration point for all your global acquiring needs.”
“Settlement is conditional upon our receipt of funds.”
“We are a technology company providing financial services infrastructure.”
“Processing services may be provided via third-party service providers.”
“Funds will be settled to you in accordance with our internal policies.”
“We facilitate the movement of funds.”
“You agree that [Company] is not responsible for delays or failures in payment processing.”
“Use of our platform does not create a banking, escrow, or fiduciary relationship.”
“Processor terms are incorporated by reference.” (But they’re not attached, and you can’t negotiate them.)
Any contract that makes generous use of the word “integrated” (shudder).
By now, you should have a sense of what kind of payment service provider you are involved with: Processor or Gateway. And congratulations are in order, you’ve gotten farther than most! Now it’s time to paper the deal.
Using a Gateway Instead of a Processor? Draft Like It!
Not all Gateway deals are bad. Sometimes, a Gateway option is exactly what a Merchant needs, especially in high-risk, cross-border, or fast-moving markets. But if the contracting party isn’t a licensed Processor, the agreement should reflect that.
The Gateway shouldn’t be imposing Processor-level financial risk terms unless it’s also assuming liability. Merchants should know who’s holding the funds, what terms govern that relationship, and what recourse exists if the arrangement breaks down.
Use Schedules. Name the entities. Get access to the underlying Processor terms. If a Gateway is holding reserves or delaying settlement, that authority to do so should be limited and tied to Processor requirements.
Merchants should know who’s licensed, who’s liable, and who to actually call when something goes wrong with processing. They should also know where to buy headache medicine in bulk.
If you’re working on your first Gateway Agreement or dealing with a “Processor” Agreement that seems suspiciously light on actual processing, reach out to lindsay@gmelawyers.com. I’m happy to help, and I’ve absolutely seen worse.
