Merchant Onboarding for SaaS Platforms: What to Require From Your Payments Partner

An embedded payments partner should make it clear which merchants you can serve, how they apply, who handles underwriting questions, and what happens between approval and the first usable payment. Evaluate that complete workflow before committing to a provider. A fast application demo alone does not show whether your team can launch and operate a payments program.

For a software company, onboarding connects the commercial promise to actual merchant use. An application that needs another document, an approved account with incomplete setup, or an unresolved funding question can leave your customer waiting and your team carrying the work.

Swipesum Connect brings embedded payments infrastructure together with a payments team supporting implementation, provider operations, economics, reporting and ongoing support. This guide explains what to require from any proposed partner, including Swipesum, before choosing the operating model.

What the competing platforms reveal about the decision

Stax, Finix, Infinicept, Forward, Rainforest and Tilled publish different combinations of enrollment tools, operating support and commercial options. Their documentation is useful for building a shortlist. The next step is to verify which configuration and responsibilities appear in your own proposal.

Stax Connect

• What its public material establishes: Its enrollment documentation describes hosted, hybrid, assisted and custom approaches.
• What to verify for your program: Which flow you are buying, how status returns to your software, and who handles follow-up.

Finix

• What its public material establishes: Its onboarding forms documentation separates a completed form from merchant approval and describes requests for additional information.
• What to verify for your program: How your product distinguishes submission, review, approval and updates, with an owner for each action.

Infinicept Launchpay

• What its public material establishes: Its product page describes white-labeled applications, underwriting visibility and a self-service merchant portal.
• What to verify for your program: Which controls and services are included in your agreement, and what responsibility remains with the platform.

Forward

• What its public material establishes: Its application guide describes API-created branded hosted links and an alternative partner-portal flow.
• What to verify for your program: How account creation, pricing-plan selection, conditional status and funding readiness fit your rollout.

Rainforest

• What its public material establishes: Its onboarding guide distinguishes merchant and application records, verification, additional-information requests and decisioning.
• What to verify for your program: Which merchants are eligible, which statuses your team receives, and who resolves additional review.

Tilled

• What its public material establishes: Its documentation describes dashboard and API onboarding; its pricing page distinguishes service features by plan.
• What to verify for your program: Which merchant-support and white-label services are included, and the work your team retains.

Sources: Stax enrollment, Finix onboarding forms, Infinicept Launchpay, Forward applications, Rainforest onboarding, and Tilled onboarding and pricing. Public materials reviewed October 27, 2026. This is a comparison of disclosed workflow details, not a tested performance ranking or a statement that every feature is included in every offer.

Choose the enrollment experience your team can operate

There are several practical patterns to evaluate. Providers use different names and may offer a mixture.

A hosted application sends the merchant to a provider-managed flow. Check branding, prefilled information, return navigation and the process for resuming an unfinished application.

A hybrid flow starts inside your product and hands the merchant to a hosted application for the remaining steps. Demonstrate that handoff on mobile as well as desktop, including the return to your software and the way your team sees progress.

A custom API flow gives your product team more work to define and maintain. Ask which fields, disclosures, signatures, uploads, errors and later updates your implementation must handle. Establish how changes to provider requirements reach engineering.

An assisted flow allows a platform or provider team to help prepare applications. Identify what staff may enter, what the merchant must personally review or accept, and how sensitive information is collected through an approved process.

Choose the combination that fits your development capacity and merchant experience. Do not buy a custom flow simply because it looks better in a demonstration, or assume a hosted flow includes every operational service your business needs.

Test eligibility before promising onboarding speed

Give each provider the same representative merchant profiles: business activity, geography, entity structure, payment methods, average and larger transaction sizes, fulfillment pattern, and required software workflow. Ask which profiles are supported, restricted, subject to additional review, or outside the proposed program.

Include both new customers and established merchants in the exercise. A business already processing elsewhere may need a different commercial conversation and transition plan from one accepting its first payment.

Ask what happens when a merchant changes bank details, expands its activity or processes differently from the original application. Onboarding is the beginning of an account relationship, so the operating plan must cover later changes too.

Use a responsibility checklist with named owners

Keep the original onboarding question simple: who takes the next action? Use this worksheet before implementation begins.

Application

• Responsibility to assign: Collect required information and explain missing items.
• Evidence to request: Current requirements and a demonstrated application flow.

Underwriting review

• Responsibility to assign: Make decisions and handle additional review.
• Evidence to request: Written division of responsibility and actual status definitions.

Merchant communication

• Responsibility to assign: Tell the merchant what is needed and how to respond.
• Evidence to request: Example messages, contact channels and escalation rules.

Configuration

• Responsibility to assign: Prepare account settings, payment flows and devices where required.
• Evidence to request: Setup checklist with completion criteria.

First use and funding

• Responsibility to assign: Investigate the first payment, reporting or funding issue.
• Evidence to request: Acceptance tests and the responsible support teams.

Ongoing changes

• Responsibility to assign: Handle account updates, restrictions and provider escalations.
• Evidence to request: Operating procedure and merchant contact route.

Separate the team that communicates with the merchant from the party authorized to make a risk decision. Operational assistance does not transfer underwriting authority or remove contractual obligations. Confirm the actual arrangement in the written scope.

Require a live walkthrough of the difficult cases

Ask each shortlisted partner to demonstrate the same scenarios, using its approved test environment:

1. A merchant starts an application, leaves, and returns later. Show what is saved and how the merchant resumes.
2. The provider requests another document or correction. Show the merchant's message, the platform's view, the submission route and the next status.
3. A form is submitted but the account is not approved. Show how the software prevents a misleading ready-to-process message.
4. An approved merchant cannot complete the required payment flow. Identify the configuration owner and the first support action.
5. A merchant asks why a payment and a deposit do not appear to match. Trace the records and identify who investigates.
6. A merchant changes account information after launch. Show the supported update and verification process.

These scenarios expose handoffs that a clean happy-path demo can hide. Record whether each result was demonstrated, documented, conditional or unanswered. A verbal promise should not receive the same status as a working test.

Compare the economics of getting merchants active

Ask for the complete commercial schedule: setup and recurring platform charges, per-application or onboarding charges where applicable, active-account fees, support options, devices and other program costs. Identify which charges apply to incomplete, rejected or inactive accounts if the proposal uses those categories.

Then define the internal work. Who chases missing information, configures the account, trains the merchant and handles the first support request? A provider can offer an attractive processing spread while leaving substantial work with your team.

For internal planning, you can calculate onboarding cost per activated merchant by dividing the defined onboarding costs by the number of merchants reaching an agreed activation milestone in the same cohort. State what costs and milestone you included. This is a planning metric, not a market benchmark or a forecast of payments revenue.

Keep application completion, approval, first successful payment and ongoing activity separate. Our embedded payments adoption guide explains how to diagnose that broader funnel.

Resolve merchant ownership and exit questions before signing

Ask who contracts with the merchant, who controls the merchant's pricing, which information your platform can access, and what happens if the provider relationship ends. Get the actual terms for data access, account transitions and any proposed path to another operating model.

Distinguish merchant information from saved payer credentials, payment tokens and subscription schedules. Rights to an account export do not by themselves establish that every record or credential can move or work in another system. Request provider-specific confirmation for the items your program depends on.

For an existing portfolio, use the embedded payments migration guide to plan the broader transition. This onboarding checklist covers how merchants enter and become ready within the selected program; it does not replace that migration plan.

Where Swipesum Connect fits

Swipesum Connect supports software platforms that need payments infrastructure and a team helping operate the program. The starting point is your customer base, payment flows, existing arrangement, economics and internal capacity. From there, the discussion should establish the implementation and ongoing responsibilities your program needs.

Ask Swipesum to complete the same checklist: supported merchant profiles, enrollment path, operating owners, reporting requirements, commercial terms and rollout acceptance. Confirm the specific scope rather than assuming that every arrangement includes every service.

Discuss your embedded payments program with Swipesum. Bring your merchant types, current payment setup, onboarding bottlenecks and the work you want the payments partner to own.

Compare the operating structure with our PayFac model guide, then evaluate the commercial schedule using the embedded payments pricing framework.

Common buyer questions

Is a completed application the same as an approved merchant account?

No. Submission, review, approval and configuration can be separate states. Use the provider's documented account status to determine what the merchant is allowed to do, and test how your software displays it.

Does PayFac-as-a-Service mean the software company has no payments responsibilities?

The label alone does not define the division of work or liability. Review the actual agreement and operating scope, including merchant communication, support, risk decisions, reporting and account changes.

Can merchants keep an existing processor or move without applying again?

That depends on the proposed program and providers. Obtain written confirmation of the supported processing arrangement, account requirements and transfer process. An existing account or saved token does not establish eligibility for another program.

Which embedded payments provider is best for merchant onboarding?

Choose the provider that can demonstrate the required merchant journey, support your merchant population, assign the operational work clearly and meet your commercial requirements. Use the same scenarios and evidence standards across the shortlist; a universal speed claim is not a substitute for that evaluation.