How Software Companies Can Monetize Payments Without Becoming a PayFac
A practical framework for revenue participation, merchant placement and the responsibilities behind an embedded payments program.
A software company can monetize payments without becoming a payment facilitator by partnering with a payments provider and negotiating participation in the processing revenue generated by eligible merchants. The software team builds the product experience and distribution; the applicable provider program handles merchant underwriting and processing. Revenue depends on adoption, merchant activity, costs and the agreement—not simply on adding a payment button.
There are three broad paths: refer merchants to a processor, integrate an embedded-payments partner with revenue participation, or operate a PayFac program with greater underwriting and operational responsibility. The middle model can let a platform make payments part of its product and earn recurring revenue without building its own merchant-underwriting operation.
Payline supports a partner model in which its provider relationships handle underwriting and placement under the applicable program. That does not remove every platform obligation. Separate underwriting authority, day-to-day work and contractual loss liability before comparing offers.
Three ways software companies can participate in payments
Agent/ISO/Referral model
Introduce merchants to a provider. Compensation may be one-time or recurring, depending on the agreement. This can be a practical starting point when integration is not yet a priority.
Evaluate: attribution of referrals, qualifying activity and ongoing compensation rights.
Embedded-payments partner
Connect the application and payment experience to your software while a provider program reviews merchants. Negotiate participation in defined processing economics.
Evaluate: net revenue basis, merchant fit, integration work and the division of support responsibilities.
Payment facilitator
Build and operate a program within an acquiring relationship, with greater control and responsibility for merchant acceptance, monitoring and payment operations.
Evaluate: scale, sponsor requirements, staffing, compliance infrastructure and loss exposure.
Why payment economics matter to a software business
An installed merchant base gives a software company an existing distribution channel. If payments solve a real workflow problem—collecting a booking deposit, billing a membership or reconciling a field-service invoice—merchants have a reason to adopt them. Eligible ongoing processing can then create recurring payments revenue alongside subscriptions.
That can increase revenue per customer and diversify the business beyond subscription fees. It is not automatically higher-margin revenue: implementation, merchant activation, support and reconciliation all cost money. Measure active processing merchants and retained volume, not just the number of software accounts or submitted applications.
How the revenue model works
Begin with the merchant processing revenue generated under the proposed pricing. Interchange, network fees, processor and gateway costs, adjustments and other contractual deductions affect the amount available for participation. The software partner receives compensation according to the agreement’s defined formula.
- Merchant processing revenueEligible activity under merchant pricing
- Provider and processing economicsCosts, deductions and adjustments
- Software partner participationAgreed share of the defined revenue basis
The result depends on merchant mix, processed volume, average ticket, pricing, interchange and other costs, as well as the partner agreement. Two offers with the same headline percentage can produce different outcomes if one shares gross revenue and the other shares a narrower net amount. Ask for a worked statement using your actual merchant profiles.
A bundled Stripe- or Braintree-style offering may combine payment capabilities, pricing and operational services differently. Compare the actual configuration and commercial terms; do not assume an integrated provider offers no monetization options or that every partner model produces better returns.
Build the forecast from activation, not ambition
Start with eligible merchants, estimate how many will activate, use evidence for their processing volume, apply the proposed revenue formula, then deduct your own operating costs. Model slower adoption and merchant attrition as well as expected performance.
Request the definition of qualifying revenue, excluded fees, adjustments, payment timing, reporting access and what happens when a merchant or the partnership leaves. Commercial terms need review before a forecast becomes a commitment.
What becoming a PayFac actually involves
A PayFac model is an operating choice within an acquiring relationship, not just a checkout design. Merchant acceptance and underwriting, compliance processes, ongoing monitoring, disputes and chargebacks, funding operations and sponsor/acquirer requirements need defined owners and working infrastructure.
Some functions can be supported by vendors, but the program still needs governance, trained people and the ability to respond when a merchant’s activity changes. Financial exposure depends on the acquiring arrangement and agreements. A platform should assess the responsibilities it is accepting rather than relying on the label alone.
For a deeper discussion of role ownership, see embedded payments without becoming a PayFac. Here, the key economic question is whether the extra control is worth the cost of operating that model.
The partner model: product ownership and provider responsibilities
With Payline Connect, a software business can discuss an integrated payment experience and commercial participation alongside merchant placement. The intended division of work should be documented before implementation.
Product and distribution
Customer experience, integration, distribution and the merchant relationship where the agreement provides for it.
Application and payment integration
Review and processing
Application workflow, identity and business verification, merchant underwriting, provider placement and processing infrastructure under the selected program.
Collecting business information is different from deciding whether to approve a merchant. Likewise, provider-led underwriting does not eliminate obligations concerning accurate information, integration security, customer communication or the platform’s own conduct. Review indemnities, reserves, termination rights and responsibility for losses in the actual agreement.
Why merchant placement flexibility affects revenue
One platform can serve merchants with different industries, processing histories, ticket sizes, delivery timelines and business models. A provider suited to immediate-delivery retail may evaluate advance-paid events or subscription services differently. A merchant outside one provider’s accepted profile may fit another provider’s criteria.
Payline works with multiple processor/provider relationships and can evaluate traditional low-risk and specialized placement paths. Every merchant remains subject to underwriting and eligibility; additional paths do not guarantee approval or allow an account restriction to be bypassed.
Placement breadth also does not mean every provider uses the same API or that transactions automatically fail over. The multi-processor software guide separates placement from integration and transaction routing. For specialized profiles, review the high-risk merchant account process before including those merchants in a revenue forecast.
Onboarding is part of the commercial model
A merchant produces no processing revenue while an application sits incomplete. Design the journey from application to review, requests for information, approval and payment activation. Establish who follows up and what your software can show at each step.
Payline’s digital merchant onboarding options include discussion of hosted applications and API-based workflows. An embedded experience can bring supported steps into the product, but its exact form, branding and access depend on the selected onboarding service and program.
- Application: confirm required business and ownership fields and whether the merchant uses a hosted flow or supported API integration.
- Verification: identify which identity and business checks the provider requires and how exceptions are handled.
- Documents: confirm accepted document types, collection methods, access controls and follow-up ownership.
- Status: obtain the available states and update mechanism; do not promise real-time application webhooks without confirming that service.
Digital application, verification, document collection and status workflows are part of the existing Payline/Under offering, with feature access dependent on configuration. Confirm the endpoints and provider coverage for your program before estimating engineering effort. Gateway transaction webhooks are separate from merchant-application status events.
The gateway must support the payment lifecycle
Merchant referrals alone do not deliver embedded payments. Map the actions your software needs after approval against the selected gateway, processor and merchant configuration.
- Take and manage payments: the Payline gateway documentation covers sales/charges, authorization, capture, voids and refunds. Eligible electronic-check/ACH processing requires the appropriate setup.
- Serve repeat customers: recurring billing and Customer Vault support stored payment methods. Tokenization reduces exposure to raw payment data; it does not remove every security obligation.
- Request payment: invoicing and hosted checkout/payment links can support collection outside a fully custom checkout.
- Reconcile and respond: the Query API supports reporting, and gateway webhooks report supported transaction and recurring-payment events.
Review the Payline gateway integration reference for the functions your product needs. Availability depends on processor support, enabled services and merchant eligibility. A documented gateway function is not a promise that every proposed merchant can use it.
Where the partner model can fit
Potential use cases include vertical SaaS, booking and scheduling platforms, field-service software, membership systems, education/coaching platforms and event software. These products often have a natural moment to request payment and an ongoing relationship with the merchant.
Marketplaces and software serving diverse merchant profiles may also evaluate a partner model, but their funds flow, merchant-of-record structure, settlement needs and geography need particular review. These examples describe discovery opportunities, not approved industries or automatic eligibility. Start with representative merchants and actual workflows.
When becoming a PayFac may make sense
A large platform may decide that greater control over its payments program justifies building the necessary infrastructure. It needs sufficient scale, a willing acquiring relationship and the appetite to staff and govern underwriting, compliance, monitoring and operations.
The decision should compare the value of that control with ongoing costs and exposure. A partner model can suit a business that wants to focus on software; a more directly operated program may suit one for which payments operations are themselves a strategic capability. Neither choice is universally better.
What if we already use Stripe or Braintree?
Start with the gap you are trying to solve: payment economics, merchant approval coverage, onboarding control or support. A provider change is useful only if the proposed arrangement improves the relevant tradeoffs after implementation and operating costs.
Compare revenue calculations, accepted merchant profiles, API coverage, reporting, onboarding and support ownership. Stripe’s Connect risk documentation describes different allocations of connected-account loss responsibility; a provider name alone does not establish who bears risk. Evaluate your specific Braintree arrangement on its own terms as well.
Inventory stored credentials, subscriptions, disputes, reconciliation and active merchant accounts before planning migration. Token portability, reapproval and supported migration procedures require confirmation with the relevant providers. Our software-platform alternatives guide expands the comparison; Payline for software companies is the next step for discussing your own stack.
Frequently asked questions
Can a SaaS company make money from payments without becoming a PayFac?
Yes. An eligible referral or integrated partner arrangement can provide compensation tied to merchant processing. The agreement defines qualifying activity and the calculation. Revenue is not guaranteed and must be evaluated alongside implementation and support costs.
Who underwrites the merchants?
In the partner model discussed here, the applicable provider program makes underwriting and acceptance decisions, with Payline coordinating the placement process. Confirm the specific provider, information requirements and decision ownership for each processing path.
Can the software company control the onboarding experience?
It can design the product journey and integrate supported onboarding functions. Hosted, embedded and API options, branding, required disclosures and status visibility depend on the selected service and agreement. Product control does not imply authority to approve merchants.
Can different merchants use different processors?
Potentially, where Payline’s available relationships, eligibility and integrations support the required paths. Confirm technical and reporting differences. Multiple placement options do not mean automatic transaction routing or guaranteed acceptance.
Can Payline replace Stripe or Braintree?
Payline can be evaluated as an alternative for an eligible platform and merchant population. Establish gateway feature fit, onboarding, commercial terms and migration feasibility first. There is no universal replacement or promise that existing tokens and subscriptions transfer automatically.
Does the software company take chargeback liability?
Do not infer loss liability solely from who performs underwriting. The merchant, platform and provider agreements determine obligations, including any loss allocation or indemnities. The partner model avoids requiring the software company to operate as the merchant underwriter; it is not a zero-liability claim.
How are revenue-share economics structured?
The agreement defines which revenue qualifies, the partner’s participation, deductions, adjustments, reporting and payment timing. Merchant mix, processing volume, pricing and underlying costs affect the outcome. Request a worked example rather than comparing headline percentages alone.
Evaluate the economics around your actual merchants
Bring your merchant mix, current provider, processing patterns and required payment features. A useful conversation starts with a workable operating model and a transparent revenue calculation.
A worked net-revenue example
| Illustrative monthly input | Calculation or amount |
|---|---|
| Active eligible merchants | 40; use active processing merchants, not all software users |
| Eligible payment volume | 40 × $25,000 = $1,000,000 |
| Defined revenue basis after provider costs | $4,000 assumed for illustration; obtain the actual definition and statement |
| Partner participation | 25% of $4,000 = $1,000 |
| Your ongoing operating costs | $350 support + $150 integration operations = $500 |
| Contribution before implementation recovery | $1,000 − $500 = $500 |
| Implementation recovery | $6,000 spread over 12 months = $500/month; resulting contribution $0 |
These invented round numbers illustrate arithmetic only. They are not Payline pricing, a revenue-share offer, expected merchant volume or a forecast. The example is before tax and excludes any additional overhead or contractual adjustments not shown.
Avoid double-counting: if provider fees have already reduced the defined revenue basis, do not deduct them again from the partner payout. Separately identify gateway, account, dispute and other charges, credits, exclusions and clawbacks in the proposed agreement.
Stress-test adoption and retention. At half the assumed activity and the same illustrative effective economics, participation falls to $500; unchanged $500 operating costs and $500 implementation recovery would produce a $500 monthly shortfall. Real costs and revenue may not scale linearly.
Ask Payline to work through representative merchant profiles and an actual proposed statement. Keep earned revenue, payment timing and cash received separate, and confirm which party carries each loss obligation.