The Difference Between a Payments Vendor and a Payments Partner - Forward
The Difference Between a Payments Vendor and a Payments Partner
BYJordan Greenberg_
partner-vs-vendor-v5.html
Who Gets You Home - Forward
Payments 101
Embedded Payments for Vertical SaaS
Partner vs. Vendor
Most platforms have a payments vendor. Very few have a payments partner. Almost nobody knows which one they have.
Taking payments and building a payments business are not the same product. Whether you have the second one isn't determined by how hard you work. It's determined by who you're working with.
Access vs. Ownership
A vendor gets you live. A partner gets you home.
There are two things a software company can have when it comes to payments. The first is access: credentials, an API, a sandbox, a merchant application flow. The second is ownership: pricing authority, economic participation, a risk relationship, and a clear path to doubling revenue.
Almost every vendor delivers access. Very few deliver ownership. And the gap between the two is not something you can close through effort or iteration. It's structural. It was determined the day you signed.
The vendor isn't doing anything wrong. They delivered what they sold. The problem is that enabling transactions and building a payments business were never the same scope of work, and not everyone was clear about that during the sales process.
Vendor relationship
Partner relationship
Pricing authority
Vendor sets rates. You mark up within a fixed ceiling.
✓You see buy rate. You price to your market.
Economics
Rev share on a base you don't control.
✓100% above buy-rate. You keep the spread.
Underwriting
Generic model across all verticals.
✓Built for your vertical. Shared risk.
GTM support
Docs and a sandbox. Activation is your problem.
✓GTM playbook, merchant sales support, ongoing optimization.
Settlement timing
Fixed schedule. One cadence for all merchants.
✓Configurable per merchant. T+1 or T+2.
Growth path
No incentive to tell you what's next.
✓Clear path to registered PayFac when you scale.
Portability
Tokens and data live with the processor.
✓Your merchants, your data. Full migration rights.
"A vendor gets you live on day one. A partner is still working on your program on day 400."
The distinction matters more as you scale. Early on, the difference between access and ownership feels academic. It starts to matter when you try to price competitively, when a large merchant asks a question you can't answer, when your attach rate has plateaued and nobody on your vendor's side has any reason to help you move it.
Pricing Authority
If your vendor sets merchant pricing, you're not owning payments. You're reselling them.
Pricing is the clearest expression of ownership. A platform that owns its payments program decides what merchants pay: the rate model, the structure, the margin. A platform working through a vendor inherits whatever pricing the vendor offers, marked up within whatever band the contract allows.
With a real partner and a transparent buy-rate model, you see the floor. Everything above it is yours to decide. Flat rate for merchants who want simplicity. Interchange-plus for high-volume merchants where it saves them real money and wins you the account. Tiered structures where the vertical demands it. The economics are yours to architect.
Settlement timing belongs here too. The ability to move money faster for a specific merchant, a contractor waiting on a large job payment, a studio with payroll due, is a relationship lever that vendors don't give you. With a partner, that's configurable per merchant. It costs you nothing to offer and it can be the reason someone stays.
Scenario: A merchant asks for a better rate
Merchant: "Can you do anything on the rate?"
A question every payments platform hears.
Vendor relationship
"Let me check what my contract allows."
Fixed ceiling. One model. No room to move.
Merchant takes it or goes elsewhere. You had nothing to offer.
Partner relationship
"What does your volume look like? Let's build you the right structure."
Flat rate
Predictable
IC+
Cost-efficient
Merchant gets a structure built for them. Deal closes.
The Economics Question
You're getting a revenue share. A revenue share of what, exactly?
The rev share conversation almost always goes the same way. A vendor quotes a split, platform gets 70, vendor gets 30. Maybe 80/20 if you push hard. You model it out, it looks fine, you move on. What nobody explains is that the percentage applies to a base the vendor controls, and they've already taken their cut before that line is drawn.
By the time your 70% applies, the vendor has extracted their processing spread. On top of that, they're billing your merchants directly for PCI non-compliance fees, statement fees, batch fees, and monthly minimums. That revenue never flows to your share. It was taken before the calculation started, and it doesn't show up anywhere in your reporting.
The result: a merchant on your platform might be running an effective rate of 6 or 7 percent once every fee is counted. They don't blame the vendor. They've never heard of the vendor. They blame you. And you didn't even know it was happening.
Where the money goes: vendor rev share vs. above buy-rate
Same transaction. Different structure.
Vendor rev share — "Platform gets 70%, vendor gets 30%"
Interchange
Vendor spread
Junk fees
Your 70%
Interchange (pass-through)
Vendor spread (extracted before your split applies)
PCI fees, statement fees, batch fees (charged to merchants, not in your base)
Your "70%", of what remains. Effective split often closer to 40/60.
Above buy-rate — you set the price
Interchange
Everything above buy-rate is yours to price
Interchange (pass-through)
You see the floor. You price to your market. You keep the spread.
The question that cuts through it: Ask your vendor to show you buy rate. If they can't give you a straight answer, you have your answer.
Above buy-rate flips the whole model. The floor is transparent and fixed. You price to your market, you know exactly what every merchant pays, and there are no fees appearing below the line that you didn't authorize. You can stand behind your pricing in any merchant conversation because you built it.
Risk and Underwriting
A vendor transfers risk to you. A partner sits on the same side of the table.
Vendors apply one risk model across every vertical they serve. It's built around the average merchant, which means it's calibrated for none of them. A fitness studio, a field service contractor, a veterinary practice, and a nonprofit have fundamentally different seasonal patterns, chargeback profiles, and average ticket structures. Generic underwriting treats them identically.
The result: approval rates lower than they should be, reserves sized for someone else's risk profile, and friction at exactly the moment you need it smooth. Every merchant your payments program doesn't activate is a merchant still running a card reader from someone else.
A partner underwrites for your vertical because they share in the outcome when it works. They know what seasonality looks like in your market. They right-size reserves to actual portfolio risk. And because they're participating in the economics, they have a real incentive to approve merchants you should be onboarding, not just protect their own downside.
Same merchant. Two outcomes.
How the application gets read depends entirely on who's reading it.
Merchant profile
Fitness Studio
Business type
$45
Avg. ticket
Jan spike
Volume pattern
0.4%
Chargeback rate
18 months
In business
Generic underwriting
Volume variance
Flagged
Approval
Conditional
Processing limit
$15K/mo cap
Outcome
Friction. Delay. Churn risk.
Vertical-specific underwriting
Volume variance
Expected (seasonal)
Approval
Clean
Processing limit
Scaled to history
Outcome
Activated. Processing day one.
Reserve structures are reviewed as portfolios mature. A partner has reason to reduce them over time. A vendor does not.
What shared risk looks like in practice
When a partner underwrites for your vertical, the conversation around a borderline application is different. A vendor's answer comes from a generic matrix. A partner's answer starts with: what does this merchant type look like in your portfolio, and what does the data say?
Reserve structures get reviewed as your portfolio matures. Approval criteria evolve as you demonstrate performance. The program improves over time because both sides have skin in making it work.
The Contract Is the Business
Ownership isn't a feeling. It's written into the paper, or it isn't.
Everything above, pricing authority, economic participation, risk alignment, has to be reflected in the contract. If it isn't there, it isn't real. Vendor agreements are written to protect the vendor. That's not a criticism; it's how contracts work. But understanding what those protections mean for you is a different conversation than the one that happened during the sales process.
No volume minimums
Minimum volume clauses with fee penalties aren't a commitment to mutual success. They're risk transfer. A slow quarter shouldn't cost you money on top of the slow quarter.
No non-solicit
Non-solicit clauses don't just prevent your vendor from poaching merchants. They prevent you from migrating your own merchants when you're ready to launch a real embedded payments program with a partner. Read this clause carefully. It can lock your existing customer base out of your own payments product.
Full merchant and token portability
If you ever change infrastructure, your merchants come with you. Token migration, merchant data, processing history, those belong to your platform. This is the single clause most platforms don't read carefully enough going in.
A clear path to registered PayFac status
If you grow to the point where full PayFac registration makes economic sense, a partner maps that path and helps you get there. A vendor has no incentive to tell you that conversation exists. Look for explicit graduation language, or the absence of it.
Bilateral rate adjustment
Watch for clauses allowing the provider to modify rates or fees with 30 days' notice and no approval required. The economics you signed on for should be locked, not subject to unilateral revision once you're dependent on the infrastructure.
None of these are unreasonable asks. A partner who is genuinely aligned with your success will put all of them in writing without a fight. The ones who push back are telling you something about the relationship before it starts.
Forward is designed to get you home. We've spent more than 20 years building software and payments companies as founders, CEOs, CTOs, and GMs of Payments. We understand how difficult it can be to cut through the noise, navigate complexity, and make the right payments decisions for your business.
Our mission is simple: help you move with clarity and confidence to achieve the results your business deserves.
Zoom in and out
More
Create with Canva
Enter full screen
📱 For the best view on mobile, try rotating your phone to landscape.
Subscribe to Forward
Share article
## Build payments into your product
Want to learn more or apply this specifically to your business? Speak to a payments expert today.