{if ftt_dorm_120 == true}
Quick favor: Our records indicate that you aren’t opening this email. But records can be wrong. Please click here if you’d like to remain subscribed to Fintech Takes. |
|
|
{/if}Happy Thursday, Fintech Takers!
February is almost over, and that means it’s time for a sponsored deep dive essay!
Sponsored deep dive essays are opportunities for me to collaborate with specific companies on topics that interest them, me, and (hopefully) you. The sponsor provides invaluable input, but each essay is researched, written, and edited by me and is an honest reflection of my thoughts on the topic. And ohh boy, do I have thoughts on this topic!
Today’s essay is about the evolution of the embedded payments ecosystem and why what's past is not necessarily prologue.
I’m grateful to today’s sponsor — WEX — for pushing my thinking forward on this topic.
- Alex |
Was this email forwarded to you? |
|
|
Embedded Payments: From Product Feature to Infrastructure |
For most of modern business history, payments sat outside the product.
You sold something, then you figured out how to get paid. Invoices were mailed. Checks were cut. Credit cards were swiped on separate terminals. Even when commerce moved online, payments often remained something you were redirected to: a separate page, a separate provider, a separate moment entirely. What changed — and what we now call “embedded payments” — was not simply that businesses found new ways to move money. Businesses have always needed to pay and get paid. What changed was that software became the product. Once the product experience became fully digital, payments (just ones and zeros!) could be woven directly into the workflow itself.
Embedded payments, in the modern sense, is not about accepting cards or processing transactions. It’s about integrating money movement directly into a software product’s user experience, so that paying, getting paid, or moving funds becomes a native part of how the product works rather than a separate step layered on top. No redirects. No handoffs.
That distinction matters because it ties embedded payments specifically to software and SaaS. A restaurant has always needed a way to accept payment. What’s new is a restaurant management platform that controls ordering, inventory, payroll, supplier payments, and settlement inside a single interface, and captures value every time money moves through it. In other words, embedded payments aren’t just payments inside software. They’re software turning money movement into a product. Early on, this didn’t feel especially strategic. As SaaS exploded in the 2000s and early 2010s, payments were treated as a feature you added once you’d nailed everything else. Subscription revenue came first. Growth came second. Payments came later, usually via an API that promised to make the complexity disappear.
This mindset made sense at the time. Payments were regulated, operationally messy, and full of edge cases. If you were building software, the smart move was to outsource all of that risk to a third party. Integrate an API, let a processor handle the hard parts, and focus on shipping product. For a while, that approach worked. Payments felt lightweight, interchangeable, almost invisible. They were plumbing; necessary, but not strategic.
But abstraction has a way of breaking down once enough money starts flowing through the pipes. |
When Payments Stopped Being Plumbing |
The first real shift didn’t come from payments companies. It came from software companies accidentally discovering that money movement was more valuable than they’d been treating it.
Marketplaces were some of the earliest companies to feel this. When buyers and sellers transact inside a platform, payments aren’t just a backend function. They’re the mechanism that makes the entire marketplace work. Taking a small percentage of each transaction felt natural, even inevitable. At first, those take rates looked incremental. Over time, they became foundational. (You can see an early template in eBay and PayPal: the “checkout workaround” that started as a trust and conversion tool eventually became the economic engine — and the piece of the stack with the most leverage.)
Vertical SaaS has followed a similar path, though often more quietly. Software built for restaurants, contractors, or healthcare providers didn’t just help companies in those verticals run their businesses. It sat directly in the middle of how money flowed through them. Invoices were generated inside the product. Payments were accepted inside the product. Payouts were initiated inside the product. Once that happened, it became obvious that payments weren’t just enabling the workflow. They were the workflow.
What surprised many founders was how quickly payments revenue could rival (or exceed) subscription revenue. A platform charging $99 per month could suddenly find itself moving millions of dollars a year on behalf of its customers. Even a modest take rate could generate more revenue than the core SaaS license, with the added benefit of being directly tied to customer activity. The more the customer used the product, the more valuable the platform would become.
This is where the mental model began to shift. Payments were no longer a cost center or a necessary evil. They were a growth lever. They drove retention. They generated data. They aligned the platform’s incentives with its customers’ success.
Matt Brown, a venture capital investor at Matrix and a close student of embedded payments, uses the analogy of an iceberg: it looks like an integration problem, but that’s just the tip. Beneath the surface is where the real value — revenue expansion, tighter customer lock-in, higher LTV — is hiding. However, as Matt warns, that’s also where the more difficult problems are hiding: Many companies think that a few lines of code and hours of work will yield a whole new monetization model. However, integrating payments is just the tip of the iceberg, and real success requires more than product and engineering work. |
Early on, platforms approach payments with a feature mindset. It lives with product or engineering. Decisions are optimized for speed and UX. Compliance, fraud, settlement timing, and regulatory exposure are treated as things someone else — usually a processor or sponsor bank — will handle. That approach is viable when payments are small. It becomes fragile once payments are material. |
Before software platforms started embedding payments into their products, a different form of embedded finance was playing out in plain sight: co-brand credit cards.
These were financial products sold under the joint banner of a recognizable brand and a bank, blending loyalty incentives, everyday spending, and money movement into a single customer touchpoint.
Early on, these products mostly functioned as simple marketing tools — extra points on airline miles, a discount at checkout, a nicer-looking card in your wallet. However, over time, co-brand programs became strategic engines of revenue and customer engagement.
By the 2000s and 2010s, co-brand card programs had grown well beyond marketing gimmicks. Airlines, retailers, and other consumer-facing brands increasingly leaned on co-branded cards to deepen customer loyalty and drive recurring revenue, especially through rewards that tied everyday spending back to the brand’s core business. What was once a feature of a loyalty program increasingly became a financial product with material economic impact.
(For example, Delta reported roughly $8.2 billion in revenue from its American Express co-brand card program in 2025 — more than 13% of its roughly $63.4 billion in total revenue that year.)
That economic weight created a new structural reality: issuing co-brand cards wasn’t something every bank could do, and partnering with every brand wasn’t something every bank wanted to do. The Consumer Financial Protection Bureau’s analysis of the U.S. credit card market underscores this dynamic. In its review of retail and co-brand credit cards, the CFPB observed:
Four large banks issue over 80 percent of retail credit cards. A few specialized banks issue the majority of private-label and retail co-brand credit cards with the largest merchants. Big brands didn’t just look for any bank partner; they needed partners with the scale, infrastructure, compliance capabilities, and risk controls necessary to manage enormous transaction volume and the associated credit, fraud, and regulatory obligations.
Co-brand cards also illustrate something embedded payments people often learn late: embedding finance isn’t a one-off engineering project. It’s a long-term operating commitment. Banks that issue these cards are responsible for underwriting, credit risk, fraud monitoring, settlement, compliance reporting, dispute handling, and consumer servicing — areas that require deep expertise and specialized systems.
As the economic impact of co-brand credit cards grew, those behind-the-scenes requirements became mission-critical. Financial features that once seemed commoditized become strategic, and the partners capable of running them sustainably become more specialized — and fewer in number. Payments embedded in software are now approaching that same turning point. |
The Inflection Point in Embedded Payments |
For most software platforms, the early wins come easily. Embedded payments improves the user experience. It removes friction. It shortens sales cycles. It makes the product stickier. And it creates a new and unexpected source of revenue.
However, once meaningful volume starts flowing through a platform, payments stop behaving like a feature and start behaving like its own business. Customers expect reliability. Regulators expect accountability. And the platform itself becomes exposed to risks it didn’t originally set out to manage. The shift is subtle at first.
Platforms don’t wake up one day and declare themselves financial institutions. Instead, they find themselves fielding fraud disputes, managing payout delays, responding to compliance questions, and negotiating with banking partners. What once felt like a clean integration turns into a larger (and messier) operational surface area. This is also the point where differences between embedded payments providers begin to matter. Early on, most providers look similar: developer-friendly tools, fast onboarding, abstracted complexity. At scale, the questions change. Who ultimately holds the funds? Who is responsible for compliance? What happens when something breaks? What happens when regulators come knocking? What happens when the platform expands into new geographies or new verticals? These aren’t product feature questions. They’re partnership ones.
And that brings us to the part of the embedded payments story that’s still underappreciated. |
The thing about embedded payments is that it doesn’t usually fail fast. It works. It grows. It generates revenue. And for a long time, it feels deceptively manageable. Volume increases, customers are happy, and the payments line item on the P&L looks better every quarter. From the outside, it can appear as though the hard part is over. In reality, that’s often when the hard part begins.
The complexity cliff isn’t a single event. It’s a slow accumulation of responsibility that only becomes visible once a platform reaches real scale. Fraud rates that were once negligible become meaningful. Chargebacks turn into an operational distraction. Payout timing, which used to be an implementation detail, suddenly affects customer trust and cash flow. Regulatory questions that once felt abstract become immediate and specific.
What makes this cliff challenging is that much of this complexity lives outside the traditional comfort zone of software companies. Product and engineering organizations are designed to ship quickly, iterate often, and abstract away messiness. Financial operations are the opposite. They require controls, reconciliation, documentation, audits, and long feedback loops. They reward consistency and predictability more than speed.
Fraud is often where this shift becomes material.
When payments are small, fraud losses feel manageable. At scale, they become line items. Someone has to absorb chargebacks. Someone has to monitor suspicious activity and file reports. Someone has to decide when to freeze funds — and answer for it later.
This is where partnership boundaries matter. Who ultimately eats the loss? Who carries regulatory accountability? Where does the platform’s responsibility end and the payments partner’s begin? In theory, those lines are defined in contracts. In practice, customers and regulators tend to see the platform first. As embedded payments mature, software platforms find themselves absorbing responsibilities they never explicitly signed up for. Know-your-customer (KYC) and know-your-business (KYB) requirements expand. Anti–money laundering obligations grow more demanding. Cross-border
transactions introduce new regulatory regimes and settlement risk.
At a certain scale, regulators stop seeing a platform as “just software.” They see it as an intermediary in the flow of funds — because that’s what it is. Even if the platform doesn’t hold a bank charter or money transmission licenses itself (but rather works with regulated partners), it is still the most visible part of the stack to customers, merchants, and regulators alike.
Recent regulatory history helps explain why this perception is important. Under Rohit Chopra, the CFPB took an intentionally expansive view of its consumer protection mandate. Rather than focusing narrowly on traditional categories of financial institutions or specific financial products, the bureau increasingly emphasized financial behavior at scale — how money moved, how quickly it moved, and who ultimately controlled those flows.
That approach brought a wide range of unexpected companies into regulatory focus. Large technology firms offering payment tools. Airlines. Even video game companies! The common thread wasn’t a bank charter or a balance sheet. It was volume, velocity, and control.
For folks in the embedded payments space, this is a crucial reminder. As software platforms process more transactions and sit more directly between end users and their money, regulatory interest becomes less about what those platforms call themselves and more about what they do. The question shifts from “Are you a bank?” to “How much financial activity runs through you, and what happens when something goes wrong?”
This is where the early abstraction around payments begins to break down. The idea that compliance, risk, and funds flow can be easily outsourced across starts to feel naïve. Platforms realize that while they may not legally be banks, they are operationally performing many bank-like functions. Those responsibilities don’t disappear just because they’re inconvenient or because a partner sits elsewhere in the stack.
The co-brand card market went through a similar reckoning. As card programs scaled, brands and issuers learned that loyalty economics came bundled with credit risk, regulatory oversight, and operational burden. Managing that complexity required specialization, institutional knowledge, and systems built for scaled financial operations rather than one-off growth experiments.
Embedded payments platforms are now confronting the same reality, only faster. Software scales quickly. Money, once embedded, follows. And once a platform reaches this stage, payments are no longer something it can afford to treat as a side project or a growth experiment. They become a core operational function; one that touches trust, reputation, and long-term viability.
Crossing this complexity cliff forces a choice. Software platforms can continue treating payments as a thin layer on top of their product, or they can invest in the infrastructure, expertise, and control required to run payments as a durable business. Increasingly, that choice is shaping not just how embedded payments are delivered, but who is positioned to deliver them at all. |
No one is asking if software platforms should offer payments. That question was settled years ago. The question today is how much of the stack they (or their payments providers) need to control to operate safely, reliably, and at scale.
This is where vertical integration enters the story.
In the early days of embedded payments, abstraction was the selling point. Payments providers promised to hide the messy parts: banking relationships, compliance obligations, settlement mechanics, and regulatory nuance. Platforms could focus on product while someone else handled the financial infrastructure underneath.
As platforms scale, every dependency in the stack becomes a potential point of failure. Sponsor banks impose constraints. Third-party processors introduce latency and opacity. Regulatory responsibility becomes diffuse. When something goes wrong, it’s often unclear who is ultimately accountable — and from the perspective of customers and regulators, that ambiguity is itself a problem (as the failure of Synapse dramatically illustrated).
The response from the most mature players in embedded payments has been to reduce that ambiguity by owning more of the system.
In some cases, that has meant pursuing bank charters or banking licenses. WEX, for example, has long operated with a bank at the center of its model, giving it direct control over funds flow, compliance, and regulatory relationships rather than relying entirely on external partners.
Vertical integration is not a shortcut to scale; it’s a response to having already scaled.
This mirrors what happened in other forms of embedded finance. In co-brand card issuance, the market ultimately selected for large institutions that could handle underwriting, compliance, servicing, and regulatory oversight at scale.
Over time, issuance concentrated among specialized players not because consolidation was inevitable, but because complexity demanded it. Embedded payments are now following a similar path, even if the mechanisms look more modern.
Importantly, vertical integration doesn’t mean that the software platforms embedding payments for their customers need to become banks. Most shouldn’t, and won’t.
What it does mean is that the embedded payments providers that those software platforms rely on increasingly need to look and behave like financial infrastructure providers, not just vendors with elegant APIs and developer docs. They need the ability to manage risk directly, engage regulators confidently, and operate across geographies and verticals without reinventing the stack each time.
This is another way embedded payments is quietly growing up. The conversation shifts from features and flows to governance and resilience. From “how fast can we launch?” to “how does this hold up over a decade?” From optimizing for developer experience to optimizing for trust.
Seen in that light, the recent wave of licenses, charters, and infrastructure investments isn’t really a surprise. It’s a signal that the rest of the embedded payments ecosystem is realizing what a few early innovators like WEX realized a long time ago: durability matters more than novelty, and owning the hard parts of the system is no longer optional.
That, ultimately, is what it looks like when a product feature becomes infrastructure. |
If the early promise of embedded payments was about better user experience, the endgame is about something less visible but far more durable: trust.
As embedded payments becomes more common, it becomes less visible. Users don’t think about how money moves through a platform any more than they think about how data is stored, or messages are delivered. Payments become an expectation rather than a feature; a background capability that simply works. But that invisibility is deceptive. Under the surface, payments become more consequential, not less.
When payments are embedded deeply into workflows, they touch more of the business. They affect cash flow. They shape customer relationships. They create regulatory exposure. The smoother the experience feels on the front end, the more robust the operations need to be on the back end to support it. This is why the future of embedded payments is unlikely to be defined by flashy product launches or elegant APIs. It will be defined by resilience. By systems that can handle volume without friction, complexity without chaos, and regulation without disruption. By providers that treat payments not as a growth experiment, but as long-term infrastructure.
In many ways, embedded payments are coming full circle. They started as something bolted on, became something designed into products, and are now becoming something so fundamental that they disappear from view again. The difference is that this time, the disappearance is earned. It’s the result of operational maturity rather than abstraction.
For software platforms, this shift changes how success is measured. The question is no longer just whether payments increase revenue or improve retention (we know that they frequently do). The question becomes whether payments infrastructure can be relied on under stress. Whether it can scale across markets and verticals. Whether it can hold up when regulators scrutinize it, when fraud spikes, or when economic conditions shift.
The companies best positioned for this phase are not necessarily the ones that moved fastest at the beginning. They are the ones that understand money as a system rather than a feature, and regulation as a constraint to be managed rather than avoided. Experience compounds in this environment. Institutional knowledge matters. So does control.
The quiet winners will be those built for the long run: the operators that can sit invisibly beneath the user experience while confidently carrying the weight of money, risk, and regulation. Those are the companies shaping the next phase of embedded payments — not by making it faster, but by making it last. |
|
|
ABOUT SPONSORED DEEP DIVES |
Sponsored Deep Dives are essays sponsored by a very-carefully-curated list of companies (selected by me), in which I write about topics of mutual interest to me, the sponsoring company, and (most importantly) you, the audience. If you have any questions or feedback on these sponsored deep dives, please DM me on Twitter or LinkedIn.
Today’s Sponsored Deep Dive was brought to you by WEX.
|
|
|
WEX’s corporate payments line, often referred to as Corporate Payments or Business Payments, provides global B2B solutions designed to automate and simplify complex accounts payable processes. Utilizing a cloud-based platform and virtual card technology, WEX enables businesses to streamline supplier payments, reduce manual reconciliation, and mitigate fraud. These digital solutions help companies replace paper checks, gain real-time visibility into spending, and generate new revenue streams through volume-based rebates across various industries.
|
|
|
Thanks for the read! Let me know what you thought by replying back to this email.
— Alex |
| | {if !profile.vars.fintech_takes_user_fitness && profile.vars.fintech_takes_user_fitness != false}Join 2,444 other finance and fintech leaders in the Fintech Takes Network
|
|
| {/if}{if profile.vars.fintech_takes_user_fitness == true}The conversation doesn't have to stop here
Keep learning and connecting in the Fintech Takes Network
EVENTS | FEED | LIBRARY | DIRECTORY
|
|
| {/if}Get your brand in front of 58,000+ fintech and banking executives. |
Workweek Media Inc. 1023 Springdale Road, STE 9E Austin, TX 78721
Want to ruin my day? Unsubscribe. |
|
|
|