Payment Processors, APIs, SaaS Sales Guys, and Other Things I Now Yell About Professionally

Welcome to the Wild West

 

It has never been easier to accept payments online. The explosion of the online payments industry has opened the door to a flood of new gateways and “payment facilitator” solutions, along with an army of slick sales teams promising seamless, roll-out-ready payment processing.  “No need to deal with banks directly!” they say. “No need to deal with financial institutions ever again! Just plug in our API and go live tomorrow!” 

 

As a former bank employee… trust me, I get the appeal. And as a lawyer who works with high-risk merchants (the kind who are often rejected by traditional Processors), I see why this pitch sounds even more tempting. Which is why I have concerns. And chronic anxiety. And an unrelenting headache. But I digress.

 

“We Found a Great New Payments… Facilitator?”

Over the past two years, I’ve had a recurring experience (waking nightmare) with clients. It starts something like this:

 

“We found a great new Payment Processor! We’ve done our due diligence and just need you to review the contract for any red flags.”

 

Great. Except it’s not a Payment Processor. It’s a Gateway Agreement. (And based on how the arrangements are usually presented, I don’t blame anyone involved for getting confused.)

 

Usually, the agreement is labeled in a way that leaves both the nature of the payment services and the provider open to interpretation: “Payment Facilitators” offering “Payment Integration Services,” or “Fintech Infrastructure Services,” or some other branding exercise. Maybe (this has happened before) the Agreement I am asked to review is literally just a document containing API specs with a link to embedded online legal terms buried in the middle. But format aside, nine times out of ten, it’s not a Payment Processor Agreement. It’s a Gateway paper.

 

Breaking the Bad News

 

At this point in my review, I will usually clarify that the counterparty is a Gateway, and ask if we have any information on the (hopefully) licensed third-party Processor that will be actually handling the funds. The conversation can go in a few directions from here, but generally at this point, someone starts preparing to explain to leadership why a payment solution scheduled to “go live” this week… probably won’t be.

 

This situation isn’t ideal, and it also isn’t unusual. The pace of payments innovation (and frankly, the willingness of tech companies to position themselves as financial service providers) has created real confusion for merchants (and headaches for their lawyers, myself included). In the current payment services landscape, understanding the difference between a Payment Gateway and a Processor isn’t optional for operators. So let’s get into it.

 

What Is a Payment Processor, Exactly?

 

A Payment Processor is the licensed financial institution that actually moves and controls a merchant’s money. Processors authorize transactions, handle settlement, and are legally responsible for chargebacks, fraud claims, and disputed transactions.  To be clear, Processors will absolutely claw back any losses from the Merchant via contract, but Processors are still the ones holding the proverbial bag when things go wrong.

 

A real Payment Processor will be registered as a money services business (MSB), payment institution, or acquiring bank, and subject to financial regulatory compliance requirements and oversight.

 

Critically, in a Merchant-Processor relationship: (i) the Merchant knows who is holding and moving the funds; (ii) the Merchant has a contract with that entity, and (iii) the Merchant has a direct point of contact and legal recourse with the Processor if something goes wrong.

 

That level of visibility and privity is what makes a real Processor agreement fundamentally different from a tech services Gateway contract that seems to be offering similar things. Which we’ll dig into now.

 

What Isn’t a Payment Processor (But Really Wants to Sound Like One)

 

Here is where things can get murky.

 

There’s a growing wave of tech companies that have emerged as the ultimate middlemen in e-commerce. They’re marketed as ‘payment facilitators’, ‘merchant platforms’, ‘global gateways’, and their sales teams love to overuse the word ‘integrated’. These companies are not licensed as financial institutions, they do not touch funds, and critically, they do not assume liability for funds when things go awry.  These companies are not Processors; they just sound like they might be. 

 

What you are actually dealing with here is a Payment Gateway: the industry term for tech-layer-only services that transmit transaction data but do not actually move or hold funds. Even if the company markets itself as a “facilitator,” “platform,” “global payment stack,” or something catchier, if it isn’t licensed and doesn’t settle funds, it’s functionally a Payment Gateway.

 

Gateways process transaction data, not money, and usually offer a sleek interface with onboarding flows, KYC tools, payment routing, dashboards, and other helpful tools. The merchant fund processing, however, is handled externally by a third-party Processor connected to the Gateway. In many cases, the Merchant has no direct relationship with that Processor at all.

 

Nice API. Any Idea Who’s Holding Your Money?

When something goes wrong in payment processing (funds are frozen, a payout doesn’t arrive, reserves get imposed, chargebacks spike), Merchant recourse depends on having a direct legal relationship with the Processor in control of the funds. If that’s not the company the Merchant has signed a contract with, they’re stuck relying on a tech provider to chase answers on their behalf. Best of luck with that.

While Merchant-Processor agreements generally include a certain level of Merchant protection, the same cannot be said for Gateway agreements as a category. Most Gateway agreements include explicit disclaimers that they are not responsible for the actions, delays, or failures of the third-party Processors they connect Merchants with. They do not guarantee payout timelines. They do not guarantee affiliated Processor performance. They usually don’t even provide Merchants with the actual Processor’s terms, which are often “incorporated by reference” but not attached to the agreement and not negotiable.

The result is a one-way relationship: the Gateway can impose reserve terms, delay settlements, or pass along fees, but takes no responsibility if the Processor it connects the Merchant with acts in a way that negatively impacts a Merchant’s business. And if the third-party Processor decides to freeze Merchant funds or terminate a Merchant Account, the Merchant has to escalate indirectly through the Gateway with which it entered into the contract. This isn’t theoretical – it’s standard. And if you can’t tell by the length of this treatise, it keeps me up at night.

If you’re staring down one of these deals and have questions, need a second set of eyes, or simply want someone to scream into the wind with, feel free to reach out to lindsay@gmelawyers.com. I do this for a living, and yes, I’ve probably seen worse.

Next Week…. in Part 2 of this Article, we’ll dig into what Merchants need to know before entering any payment services Agreement… whether you’re dealing with a Processor, a Gateway, or a kid with a laptop on a beanbag chair in the Bahamas.

Recent Posts

Related Posts