Payments as a Core Product Feature vs. Bolt-On Integration
Embedding payments in your product determines who owns the merchant relationship and the revenue.
Payments as a core product feature and payments as a bolt-on integration create different businesses, even when they serve the same merchants. The choice determines who controls the transaction, earns from it, and retains the relationship afterward. The choice affects revenue per transaction, how long merchants stay, and what the platform is worth. Integration architecture sets the opportunity, while adoption and operational control determine how much of it the platform captures.
Why the payments integration decision is structural, not cosmetic
The payments decision allocates control over a relationship the platform has already helped create. Most platforms own the workflow in which payment becomes necessary, including scheduling, invoicing, job management, membership, or order management. Redirecting the merchant to a third-party processor hands off the payment revenue, transaction data, and user experience at the point where that workflow turns into money.
That handoff changes more than the checkout screen. With a bolt-on, the processor owns the merchant relationship for payments, and the platform provides the software around it. With embedded payments, that relationship is part of the product. As transaction volume grows, the difference compounds because the architecture determines which business benefits from the activity.
What the monetization model actually determines
The monetization model sets the platform’s economic claim on every transaction. With the same gross payment volume, or GPV, different models bring in very different amounts of payment revenue without adding a merchant. Who has control explains more of that gap than pricing alone does. Models range from sending a merchant elsewhere to owning onboarding, pricing, and the payment relationship from then on.
At one end, a referral or ISO arrangement pays a thin residual while leaving the merchant account, pricing, and relationship outside the platform’s control. An integrated fee-on-top markup improves monetization but still does not provide underlying control over the merchant experience or data access. PayFac-as-a-Service, or PFaaS, changes that allocation. The platform controls onboarding, pricing, and the relationship, while the infrastructure partner manages compliance, sponsor bank relationships, and underwriting.
Full PayFac registration has much the same economics as PFaaS, but comes with full liability, high costs both upfront and over time, and a build that takes years. It can make financial sense only when annual processing volume passes a high threshold. The choice depends on whether the platform’s scale justifies assuming obligations that a PFaaS partner would otherwise manage.
Referral can therefore make sense as a test even if it is a poor model for the long term. Testing limits the initial commitment. Staying with it, however, leaves the platform running a lead-generation arrangement for another payments business, with the foregone revenue growing as volume increases. The structural cost is not the decision to experiment, but the failure to distinguish an experiment from the intended business.
What platforms that treated payments as a core product actually look like at scale
Shopify’s revenue profile shows how far the economic balance can shift when financial products sit within the operating workflow. Its merchant solutions business, spanning embedded payments, lending, and banking, accounts for the substantial majority of total revenue, versus roughly a quarter from software subscriptions.
Payments embedded in e-commerce checkout, restaurant orders, or fitness membership are part of an activity the merchant already performs. They do not depend on a separate destination. Their position within the workflow gives the platform a way to earn from business activity as well as from access to software.
That scale comes with a margin trade-off. Payments revenue has lower gross margins than pure software subscription revenue, so a larger top line should not be confused with uniformly better revenue quality. Yet settlement, payouts, and reporting also create switching costs different from those of software alone. A merchant leaving such a platform must move more than an application, which gives the revenue profile a retention dimension as well as a growth dimension.
The attachment rate problem: why embedded architecture underperforms even after launch
A stronger model does not guarantee that merchants use it. Many platforms stall with only 15–20% of eligible merchants actively processing on-platform, leaving most of the available base outside the payment product. Attachment is the next constraint. For many platforms, low activation costs more in lost revenue than the gap between monetization models.
Higher attachment adds GPV from merchants the platform already serves, without having to win a new customer. But a bolt-on experience gives those merchants an easy reason not to move, because they already have a processor and switching requires a separate decision. Native workflows change that comparison. When invoices are paid in-platform, payouts start in the same dashboard, and reconciliation happens automatically, the payment product demonstrates its value through the work.
Pay Ops: why merchant onboarding and risk management are product decisions, not back-office ones
Onboarding and risk controls determine merchant quality, revenue continuity, and network compliance, making them part of the product’s operating structure. They are not merely administrative overhead. A platform cannot meaningfully control the payment experience while treating the systems that admit and monitor merchants as interchangeable back-office services.
A bolt-on puts much of that responsibility elsewhere, but also leaves the data, relationship, and economics elsewhere. PFaaS makes the allocation more consequential because operational ownership and legal exposure are not necessarily identical. Visa’s VAMP program applies across the U.S., Canada, EU, and APAC, giving network compliance implications across those markets. The infrastructure must make those obligations manageable without leaving the platform unclear about its own responsibility.
A unified Pay Ops layer connects onboarding, underwriting, risk controls, billing, reconciliation, and reporting to payment acceptance and accounts payable through a single API. The benefit extends beyond fewer vendor integrations. It makes compliance manageable at scale and helps the platform understand the sub-merchant exposure it is accepting. However, tooling alone cannot establish who bears liability, which depends on whether the provider holds scheme risk or leaves that exposure with the software company.
Pay Out and the full revenue picture: outbound payment flow as a second monetization layer
Acceptance captures only one side of a merchant’s money flow. A platform monetizing inbound payments alone captures roughly half the available payments revenue opportunity, while accounts payable and disbursements provide a second layer. The complete product includes Pay In, Pay Out, and Pay Ops. A payment button typically reaches only a slice of the first.
The outbound opportunity is especially significant for marketplaces, field-service companies, and businesses with vendor or contractor relationships. Their outbound flow can exceed inbound flow in absolute dollar volume, allowing a platform that facilitates both to earn on both sides. Acceptance does not dictate payout design. The network that takes the buyer’s money is rarely the rail that pays the seller, so controlling Pay Out creates a separate product decision.
FedNow and RTP support ISO 20022 messaging with rich remittance data, which supports their use in B2B payables, supplier payouts, insurance disbursements, and merchant settlement. FedNow raised its transaction limit to $10 million on November 12, 2025, so it could handle larger B2B disbursements. Rail selection therefore extends beyond payment speed. A platform owning the outbound layer can select rails by weighing cost and data richness.
Unified inbound and outbound infrastructure also provides a fuller view of merchant cash flow. The platform has the option to use that information to build more financial products, including working capital. Its relevance begins with whether the architecture gives the platform access to both sides of the merchant’s financial activity.
AI and agentic automation as the emerging line between core and bolt-on
Native automation can act within the workflows the platform owns, while a disconnected integration limits the information and authority available to it. Agentic payments are already in early production, although they are not yet a fully mature product category.
The IMF’s 2026 note describes systems increasingly able not only to recommend transactions but also to initiate, coordinate, and manage financial operations under delegated authority. Treasury management and corporate payment routing are among the leading production uses. Delegated authority is the defining change. It moves AI beyond observing a payment toward completing multi-step financial work, with consequences for how the underlying systems are built.
Nearer-term payment operations applications include disputes, reconciliation, and network compliance, where repetitive, rules-based work creates scope to reduce cost and errors. PayTic Intelligent Components, formed through PayTic’s April 2026 acquisition of GUPPY-AI, demonstrated agents handling these workflows at Money20/20 Europe 2026. That demonstration establishes a concrete operational direction. Such systems need the platform’s infrastructure to give them a coherent workflow on which to act.
A bolt-on without control of data, the merchant relationship, or operations cannot meaningfully add that intelligence simply by attaching another tool. The limitation precedes the AI purchase. When platforms choose infrastructure now, they also decide whether automation can later work natively or has to stay outside the payment business.
How the core-versus-bolt-on choice shows up in platform valuation and M&A
Investors and acquirers can read these architectural decisions in a platform’s financial and operating profile. Payments attachment is an explicit multiple driver in vertical SaaS M&A because it signals revenue diversification, customer stickiness, and a defensible data moat. Those signals reduce perceived acquisition risk. High attachment shows that payment infrastructure is an asset the business uses.
Revenue recognition complicates that reading without changing the underlying economics. For the same GPV and merchant fee, net recognition shows less revenue at a high margin, while gross recognition shows a larger top line at a lower margin. Informed buyers adjust for the distinction. A platform that cannot explain its own approach adds unnecessary complexity to due diligence and makes its growth harder to interpret.
Operational leverage adds another valuation dimension. AI-enabled agentic workflows that decouple revenue from headcount command a 20–25% valuation premium in Treasury/AP/AR SaaS, though that figure is not a blanket premium for any platform using AI. Unified operations give the platform a basis for that leverage, rather than merely a claim about technical capability.
A PFaaS platform with high attachment and unified payment operations is therefore a different kind of business from a subscription product that earns referral residuals. Outsiders can see its payment revenue, how much merchants depend on it, and how it runs. Valuation is where those choices become legible. The choices themselves were made much earlier, when the platform selected its model, merchant experience, and infrastructure partner.
What choosing core product over bolt-on actually requires from the infrastructure partner
The first commercial test is whether the arrangement provides a true processing-margin revenue share or a fixed referral fee under a PFaaS label. Pricing authority is equally decisive. A platform needs to know whether it can set merchant pricing above cost and retain the spread, because with that right it controls a payments business and without it receives compensation for introductions.
Liability deserves the closest examination. Some providers hold scheme risk as the registered payment facilitator, while others provide the infrastructure and leave the software company with sub-merchant exposure. Both arrangements can be sold as PFaaS. The platform must establish which obligations the contract assigns to each party.
The technical requirement is unified Pay In, Pay Out, and Pay Ops through a single API, because each layer supports an economic claim established earlier. Acceptance provides transaction revenue, payouts extend monetization, and operations support compliance, reporting, and automation. Human support completes that infrastructure. Pricing strategy, interchange optimization, adoption guidance, and risk framework advice, supported through Slack, email, and phone, help a platform develop competence without treating every decision as an API problem.
Choosing a partner therefore belongs within the structural decision. The platform inherits the partner’s architecture, liability model, AI layer, and support model, including the limits those impose on what the product can become.
