Why Vertical SaaS Companies Are Rethinking Embedded Payments

A vertical software company can build an excellent product and still lose a customer’s confidence at the payments handoff. The merchant expects the software to understand its business. A confusing application, repeated document requests or an unexplained processing restriction feels like a failure of that experience, even when a separate provider makes the decision.

That is why the embedded-payments discussion deserves a place in product strategy, not just the integration backlog. Based on Jeff Shea’s interview insights, the useful question is how to build a payments business that fits the merchants you serve—and how much of the operation your team should own.

Start with the merchant experience you need to protect

Software founders often think about payments as an extension of an existing workflow: finish a job, send an invoice, collect a deposit or renew a service agreement. The customer experiences one product. Behind it, however, several organizations may control the application, merchant review, gateway, processing and support.

Friction appears when those responsibilities are unclear. A merchant may submit information without knowing who will request missing documents. A software support team may receive a funding question it cannot answer. Neither problem is solved simply by placing the application inside the product.

Map the whole journey before selecting an interface. Identify the person responsible for an incomplete application, a declined merchant, a changed business model and a processing question after activation. Give the merchant a clear next step at each point. That operational design is part of the product experience.

Choose the operating model before the integration

“Embedded payments” describes an experience; it does not establish who bears risk. Three broad approaches are worth separating.

• Referral: introduce merchants to a provider and agree the commercial arrangement. This can limit development work, although the platform has less control over the payment journey.
• Partner-led embedded payments: connect supported onboarding or payment functions to the software while a payments partner coordinates merchant processing. Product ownership, support handoffs and revenue participation need explicit terms.
• Payment facilitation: build or operate a more substantial payments program within an acquiring relationship. This requires dedicated attention to acceptance, monitoring, disputes and the responsibilities assigned to the program.

There are variations within each approach. A hosted interface does not automatically remove contractual obligations, and an API does not automatically transfer underwriting liability to the software company. Compare the proposed configuration, not the category name. The guide to embedded payments without becoming a PayFac explores those responsibility boundaries in more detail.

Payline’s partner approach is designed for software companies that want payments functionality and revenue participation without building their own merchant-underwriting operation. Structures can avoid direct merchant-processing loss liability, subject to agreement. Partners still need to understand their own compliance, data-security and contractual duties.

Design onboarding around review, not just activation

Speed matters, but activation is only one moment in a merchant relationship. Some payment models allow an initial start while risk reviews continue afterward. Other processes request substantial documentation before approval. Ongoing monitoring can still occur after upfront underwriting; no onboarding model eliminates later review.

The trade-off is not simply fast versus slow. Founders should ask when important requirements become visible, how merchants learn what is missing and whether the review fits the business being assessed. A short form that conceals the next steps can be harder to support than a clear process that explains them.

Payline’s approach combines technology-driven upfront underwriting and documentation collection with multiple processing relationships. The aim is to understand a merchant’s profile and coordinate a suitable processing path. The applicable provider determines acceptance and terms; additional relationships do not guarantee approval, unrestricted funding or the absence of reserves.

Software companies can choose between API-integrated and hosted merchant onboarding. In an integrated approach, the platform builds the application experience around supported endpoints, information requirements and agreement steps. In a hosted approach, merchants complete the application through the selected Payline workflow, reducing the custom application work needed to begin.

Start hosted if that is the right way to learn your merchants’ needs. Integrate more deeply when the benefits justify maintaining authentication, field mappings, secure document handling and status updates. Before committing engineering time, use the merchant onboarding overview to frame the discussion and obtain the actual onboarding API documentation. Gateway transaction documentation is not proof of onboarding API access.

Test the model against your vertical’s exceptions

Consider an HVAC platform. Its merchants may collect payment after a repair, request a deposit for equipment or bill a maintenance plan. Those are different payment patterns within one software category. A useful review looks at transaction size, service completion, recurring authorization and how a technician collects payment in the field.

A furniture or interior-design platform presents another pattern. Custom orders can separate the deposit from delivery by a substantial period. The conversation needs to include fulfillment timelines, cancellations, refunds and final payment. A generic retail description may leave the most important underwriting questions unanswered.

These are illustrative scenarios, not customer results. The lesson is to bring representative profiles—including the difficult ones—to the partner discussion. Ask what information each provider needs and what happens when a merchant does not fit the first available path.

Multiple processing relationships can support merchant-specific placement. They do not establish a universal integration or automatic failover. Token portability, devices, reporting and approval requirements may differ. The multi-processor payments guide distinguishes merchant placement from integration coverage and transaction routing.

Model revenue from active merchants and defined costs

Payments can become a meaningful recurring revenue stream, but a forecast should begin with merchants actually processing eligible volume. Total software accounts, signed applications and activated processing accounts are different populations. Keep them separate in your model.

For illustration, assume 100 active merchants each process $50,000 monthly. Annual processed volume is $60 million. At an illustrative effective platform earnings rate of 10 basis points—0.10%—annual partner revenue is $60,000, or $5,000 monthly. This rate is after the negotiated revenue-sharing arrangement.

The effective earnings rate is an example assumption, not standard Payline pricing or a guaranteed return. No additional revenue-share percentage is applied to this calculation. The resulting partner revenue also is not the software company’s profit: integration, support and other operating expenses may remain.

Illustrative estimates only. Actual revenue depends on merchant activity, processing costs, eligible volume, pricing, and negotiated partner terms. This is not a quote or earnings guarantee.

Payline partners can discuss cost-based arrangements and negotiated revenue sharing. Ask which costs reduce the revenue basis, which transactions qualify, how adjustments appear and when commissions are paid. Then test lower adoption and volume. At half the illustrative active merchants, with other inputs unchanged, the example partner revenue falls to $30,000 annually.

Use the Payline Connect revenue calculator to explore assumptions. For a fuller analysis of operating costs and participation, read the software payments monetization guide.

A practical decision framework for software founders

1. Define your merchant mix. Document industries, locations, sales channels, transaction sizes and delivery timing. Include a realistic exception, not only your easiest merchant.
2. Assign operational ownership. Name who follows up on applications, communicates decisions, handles payment questions and escalates funding or dispute issues. Confirm the scope of Payline’s full-service merchant-processing support.
3. Select a launch boundary. Decide whether hosted onboarding is sufficient initially or whether integrated onboarding solves a specific product problem. Separate required launch features from later enhancements.
4. Verify the payment lifecycle. Test the online, recurring, invoicing and gateway capabilities you need. For in-person use, confirm eligible hardware and POS integrations. Confirm reporting access rather than assuming every report is available through an API.
5. Review the agreement and statement together. Walk through merchant pricing, the revenue basis, partner share, obligations and loss allocation. Use the same merchant scenario across proposals.
6. Define a pilot and review point. Track completed onboarding, merchant questions, eligible processing activity and support effort. Decide what evidence would justify expanding the program.

Payline can provide reporting tools, with supported reporting integrations available for appropriate programs. Decide which information belongs inside the software and which can remain in a partner tool. The goal is useful visibility with a maintenance burden your team can sustain.

Frequently asked questions

Can we earn payments revenue without becoming a PayFac?

Yes, revenue participation can be negotiated through a partner model. The agreement defines the eligible revenue, costs, share and obligations. Offering payments inside software does not by itself make the platform a payment facilitator.

Does upfront underwriting prevent later reviews?

No. Upfront review helps establish the merchant’s profile and initial requirements. Providers may continue monitoring activity and request additional information as circumstances change.

Should we begin with hosted or integrated onboarding?

Choose based on product needs and engineering capacity. Hosted onboarding can reduce initial custom development. API integration can offer more control over supported steps, with added implementation and data-protection responsibilities.

Will every merchant use the same processor and hardware?

Not necessarily. Merchant eligibility and technical compatibility shape the available options. Confirm each proposed path’s features, devices and reporting rather than assuming universal coverage.

Bring your merchant mix to the conversation

The most useful starting point is a concrete portfolio, a desired customer experience and a clear view of what your team can operate. Discuss your software payments program with Payline to evaluate onboarding, processing options and partner economics together.