Payfac-as-a-service, compared

Stripe Connect

The incumbent baseline: embedded multi-party payments where Stripe holds the acquiring relationship and a direct agreement with every seller, with a dial for how much responsibility the platform takes on.

Ownership

Stripe, first-party product.

Merchant onboarding

Three onboarding options for connected accounts: Stripe-hosted onboarding, an embedded onboarding component inside your app, or API-only onboarding where you build the UI and must track Stripe's changing requirements at least every six months (Stripe recommends against it unless you commit to that). Verification runs against each account's dynamic requirements; who collects the information, who pays fees, and who eats losses are all configurable via controller properties.

Who holds the registration

Stripe establishes a direct contractual relationship with every connected account that processes payments (the Connected Account Agreement). Payout-only accounts can instead sit under a recipient agreement, which by Stripe's own description creates no direct service relationship with Stripe; those recipients have a relationship only with the platform. For direct charges the connected account is the merchant of record. Stripe's own material states the model plainly: platforms get payfac-like economics without registering as payfacs, with Stripe handling the acquiring relationship, compliance, and fraud liability.

Economics

Monetization levers: application fees on charges, a no-code platform pricing tool for per-account fee markups, and Instant Payout markups. Published platform pricing when you handle your users' pricing: $2 per monthly active account and 0.25% + 25¢ per payout, on top of base processing (2.9% + 30¢ per successful domestic online card charge; ACH 0.8% capped at $5). Both platform fees drop to zero when Stripe handles pricing; the revenue share in that model is not published.

API surface

Accounts API with controller properties (the Standard/Express/Custom types are deprecated vocabulary now), a new Accounts v2 API with role-based configurations still mid-rollout, hosted and embedded onboarding, a catalog of embedded dashboard components, direct and destination charge flows, payouts including Instant Payouts, and embedded-finance add-ons (Treasury, Issuing) gated on the platform taking loss liability.

Published go-live claim

Fully self-serve: register the platform in the dashboard, complete Connect platform onboarding for a recommended configuration, and acknowledge responsibilities in the platform profile if you take on loss liability. Sales is needed only if you want custom pricing.

Choose them when: Choose Stripe Connect if you want the largest ecosystem and a configurable dial from fully Stripe-managed to white-label with platform-owned losses, and you accept its published per-account and per-payout fees (or a negotiated revenue share) as the price of not registering as a payfac.

Worth knowing: Account vocabulary is mid-transition twice over: Standard/Express/Custom types are deprecated in favor of controller properties, and docs steer new integrations to the preview Accounts v2 API, which several features do not yet support.

Sourced from: docs.stripe.com · stripe.com

Finix

End-to-end payments platform for software platforms and marketplaces, with a published path from processing under Finix's payfac registration to holding your own.

Ownership

Independent, venture-backed. Founded 2015; $75M Series C led by Acrew Capital (announced October 2024).

Merchant onboarding

Two published merchant paths: white-labeled hosted onboarding forms (no-code, created in the dashboard or via API, prefillable, US and Canada) that redirect back to your platform, or a full onboarding API where you build the UI. Underwriting is automated with rules, verification checks, and risk signals; Finix's docs say the review often takes just minutes, with approved, rejected, or update-requested outcomes, while the underwriting product page itself avoids time claims. The marketing word is embedded, but the documented form mechanism is a hosted redirect link, not an in-page component.

Who holds the registration

Both models are current and sold as a graduation path. You can process under Finix's payfac registration (Finix is a registered payment facilitator; onboarding collects the seller's consent to both Finix's terms and yours), or register as a payfac yourself and keep using the same API, at which point you hold the merchant agreements and carry Level 1 PCI DSS. Exactly who holds the merchant agreement in the managed model, beyond the dual-consent language: not published.

Economics

Buy-rate model with platform-controlled markup rather than a percentage revenue share. Published platform pricing: flat 2.75% + $0.30 (Visa/Mastercard/Discover) or interchange + card brand fees + 0.3% + $0.30, ACH 0.75% ($0.25 min, $5 max), plus per-merchant fees ($5 onboarding, $2.50/month active merchant, $0.25 per payout, $30 disputes). You set sub-merchant pricing through fee profiles and collect the spread as platform residuals. Platform-level setup or subscription fee for the payments service: not published (the optional fraud-monitoring add-on lists a $1,500 setup fee).

API surface

REST APIs for onboarding, platform payments, payouts, fee profiles and residuals, subscriptions, and in-person payments; Finix.js plus iOS and Android tokenization SDKs; hosted checkout, payment links, virtual terminal, and invoicing as low-code surfaces. Docs at docs.finix.com.

Published go-live claim

Self-serve sandbox; Finix's payfac guide claims payfac-as-a-service platforms can be live in as little as a couple of days depending on business model, and that becoming your own payfac on their infrastructure takes months rather than years. No contractual SLA published.

Choose them when: Choose Finix if you want payments as a product line with published buy rates, you intend to set your own merchant pricing and keep the spread, and you want a credible path to holding your own payfac registration later without switching APIs.

Worth knowing: Positioning is broadening toward direct merchants and no-code alongside the platform business; the payfac-infrastructure story is no longer the sole pitch.

Worth knowing: The Flex/Core model names appear in older guides and may be deprecated in favor of unbranded language.

Sourced from: docs.finix.com · finix.com

Payabli

Pay In, Pay Out, and Pay Ops infrastructure for vertical SaaS, with Payabli holding the payfac registration and underwriting every merchant.

Ownership

Independent, venture-backed (legal entity Centavo, Inc. d/b/a Payabli). $28M Series B led by Fika Ventures and QED Investors (June 2025), $60M total per their release.

Merchant onboarding

Template-driven boarding: hosted boarding links merchants can save and resume, a boarding API for building your own application flow, bulk boarding, and manual management in the PartnerHub dashboard. Pricing packages live inside boarding templates, and Payabli's team creates your root template, so setup is sales-assisted by design. Payabli underwrites each merchant (KYB/KYC including beneficial owners); applications move through twelve published statuses from Not Submitted to Live, including Declined, Manual Review, and Withdrawn. No embedded boarding UI component is published; embedded components are payment-side only.

Who holds the registration

The clearest registration disclosure in this set: Centavo d/b/a Payabli is a registered Payment Facilitator of PNC Bank and a registered ISO/MSP of Merrick Bank, and the published sub-merchant terms are between Payabli's legal entity and the merchant, e-signed during boarding. You register as nothing. Which sponsorship model a given merchant lands under is not published, and the terms bind high-volume merchants (over $1M Visa or $10M Mastercard a year) into a tri-party direct-acquirer variant.

Economics

Revenue-share model on both acceptance and payables: you set merchant pricing per vertical through boarding templates (including surcharge and convenience-fee models), and partners earn a share of virtual-card interchange on the payout side. Every number is negotiated: published rev-share percentages, buy rates, setup fees, and monthly fees are all not published. An illustrative blog example of a roughly 0.5% platform take rate is a strategy illustration, not a rate card.

API surface

REST API across acceptance (card, ACH, check, wallets, hosted pages), payables (virtual card, ACH, check), and operations (boarding, entities, reporting, disputes) with webhooks; eight official server-side SDKs (C#, Go, Java, PHP, Python, Ruby, Rust, TypeScript); embedded pay-in components via component.js for card and ACH collection, express checkout wallets, saved methods, and a virtual terminal. Docs at docs.payabli.com, which also serve .md mirrors for agents.

Published go-live claim

Homepage claims developers get up and running in days, not months. No underwriting-decision SLA is published; once underwriting approves, docs say account setup typically completes within one business day.

Choose them when: Choose Payabli if you are a US vertical SaaS that wants managed payfac operations with monetization on both money-in and money-out, you are comfortable negotiating economics rather than reading a rate card, and a sales-assisted template setup fits how you sell.

Worth knowing: Docs were recently restructured; older docs.payabli.com URL shapes 404. Cite current paths only.

Sourced from: docs.payabli.com · payabli.com

Worldpay for Platforms (Payrix)

Embedded payments for SaaS platforms at three ownership tiers: referral, payfac-as-a-service (Payrix Pro), and full payfac-developer infrastructure.

Ownership

Global Payments, as of January 9, 2026 (Payrix: acquired by FIS 2022, moved to Worldpay, majority-sold to GTCR 2024, then Worldpay acquired by Global Payments). payrix.com now redirects to platforms.worldpay.com.

Merchant onboarding

Sub-merchants board through the Payrix Pro API (POST /entities) or white-labeled hosted merchant signup forms, with bulk upload and a partner portal alongside. The vendor markets real-time underwriting with automated compliance checks and instant risk assessments. The integration itself is wrapped in sales-assisted phases (discovery, implementation, soft launch).

Who holds the registration

On payfac-as-a-service, the vendor assumes the risk and underwriting liabilities as the payfac business, and the published sub-merchant agreement is between the sub-merchant and Payrix with the bank and processor as the channel. The PayFac Developer tier inverts that: you become the payments provider and own end-to-end servicing on their infrastructure; who formally holds the merchant agreement there is not published on the product page.

Economics

You control sub-merchant pricing through configurable fee schedules and documented profit sharing; actual buy rates, revenue-share terms, setup, and monthly fees are all demo-gated, not published. The vendor's own educational blog publishes directional ranges per tier: 0-20 bps of volume at referral, up to 40 bps integrated, 60-100 bps at payfac-as-a-service, 100-120 bps as a full registered payfac, and suggests full registration is hard to justify below roughly $750M in annual volume. Treat those as vendor-published ranges, not quotes.

API surface

The vendor markets three API tiers (referral, Payrix Pro, payfac developer); the Payrix Pro surface is the one fully documented in public. It covers merchant boarding, card-present via triPOS terminals and card-not-present payments, wallets, ACH with a return simulator, tokenization and recurring, funding and payout configuration, fee and profit-sharing configuration, webhooks, and embedded PayFrame components.

Published go-live claim

Vendor blog claims embedded-payments integrations take as little as three weeks and up to three months; an Infinite Campus quote on the site cites merchant boarding falling from a 31-day average to under 3 days. No guaranteed launch timeline is published on product pages.

Choose them when: Choose Worldpay for Platforms if you want one vendor relationship that spans the whole ownership spectrum, from referral economics to full registered-payfac infrastructure at very large volume, and a sales-led enterprise program fits how you buy.

Worth knowing: Dual branding is live right now (Worldpay for Platforms marketing, Payrix Pro product and legal), and the site banner says Worldpay is now part of Global Payments; another rename is plausible.

Sourced from: platforms.worldpay.com · resource.payrix.com · docs.worldpay.com

Rainforest

Payfac-as-a-service purpose-built for vertical SaaS, with published buy-rate pricing, no revenue share, and embedded components for onboarding, payments, and reporting.

Ownership

Independent, venture-backed. $29M Series B co-led by Matrix Partners and Infinity Ventures (September 2025); $60.75M announced across rounds, of which $3.25M was seed venture debt.

Merchant onboarding

Three published paths, led by a low-code embeddable merchant onboarding component that keeps the application inside your product, plus portal entry and a full API. Rainforest underwrites: real-time verifications run during application entry (tax ID against legal name, owner SSN, bank account ownership, expected volume), with document upload and manual review as the fallback.

Who holds the registration

The published processing terms are a three-party contract between Rainforest Pay Inc. (entering as agent of a sponsor bank), the merchant, and the sponsor banks (First Citizens and JPMorgan Chase); your platform is not a party, and the terms subordinate your own agreement with the merchant. Whether the platform registers as anything: not published. Rainforest markets itself as payfac-as-a-service; the literal phrase registered payment facilitator does not appear on the fetched pages.

Economics

Buy-rate interchange-plus with no revenue share, and the rate card is public: card buy rates of 0.30%/0.25%/0.20% by monthly volume tier ($0-5M/$5-15M/$15-25M) plus $0.30/$0.25/$0.20 per transaction by count, ACH at $0.20 per item, payouts $0.20, disputes $15, no PCI fees. Tiers are pick-a-tier: once you qualify, all transactions bill at that tier. You price your merchants above your buy rate and keep the difference. Monthly minimums and rates beyond $25M/month: not published.

API surface

APIs for merchant onboarding and applications, payins (create, capture, void, refund), and deposit reporting, with nine embedded components spanning payment collection, merchant onboarding, receipts, and payment, deposit, and chargeback reporting. Docs publish an OpenAPI spec and an llms.txt index. A platform-initiated payout API and server-side language SDKs: not published.

Published go-live claim

Homepage and product pages claim processing in days, not months, on the strength of the pre-built components. No guaranteed integration timeline is published.

Choose them when: Choose Rainforest if you are a US vertical SaaS that wants to monetize the spread on published, tiered buy rates with no revenue share, and embedded components matter more to you than server-side SDKs. Its contract is US-only, so it is not for global platforms.

Worth knowing: US-only by contract: the processing terms prohibit merchants whose principal place of business is outside the United States.

Sourced from: docs.rainforestpay.com · legal.rainforestpay.com · rainforestpay.com

Stax Connect

Stax's embedded-payments program for vertical SaaS, sold as a managed, people-heavy partnership with revenue share; economics are negotiated, not published.

Ownership

Privately held; Greater Sum Ventures is the control investor per Stax's own releases. New CEO named February 2026; Stax announced completing its move to end-to-end processing in October 2025.

Merchant onboarding

Four published enrollment options: white-glove enrollment run through Stax Connect, a Stax-hosted white-label landing page, hybrid enrollment (the merchant starts in your app and finishes on the Stax-hosted signup), and fully custom in-app flows submitting through the enrollment API. Applications track through Application, In Review, and Configuration states. Stax manages bank sponsorship, disputes, funds movement, and underwriting; the docs publish the underwriting criteria and an initial-review timeline (most applications get a first underwriter review within about 36 to 48 hours of signature), but not an automatic-versus-manual split. A managed program, Stax Connect Plus, staffs payment consultants for selling, enrollment, and activation.

Who holds the registration

Who holds the sub-merchant agreement is not published. Stax markets payfac-as-a-service and a PayFac-like experience, while its own registration disclosures list ISO/MSP relationships (Fifth Third, Pinnacle dba Synovus, and partner/ISO of Elavon) rather than a registered-payment-facilitator disclosure. Its programs page offers referral, reseller, and managed and traditional PayFac options without defining who registers under each.

Economics

Marketed as revenue sharing on processing fees, with platforms designing custom pricing packages for their merchants. Specific revenue-share percentages, buy rates, setup fees, and monthly fees: not published anywhere on Stax properties. Everything is a partnership conversation.

API surface

Published surface: an enrollment API for boarding, Stax.js for card capture and tokenization, partner webhooks for application and transaction events, and a white-labelable payment portal plus a Stax-hosted branded landing page for merchant applications. A dedicated payouts API is not published; docs put ACH funding at four to five business days (card funding schedules are not published for Connect) and expose residual reporting in the dashboard.

Published go-live claim

The developer docs state an average implementation timeline of 45 days; a marketing post claims embedding in as little as 30 days. The flagship product page makes no day-count claim.

Choose them when: Choose Stax Connect if you want a managed, sales-led payments partnership with humans attached (white-glove enrollment, optional staffed selling through Connect Plus) and you are comfortable negotiating economics rather than reading a rate card.

Worth knowing: Recent flux: a CEO change in February 2026 and a 2025 move to in-house end-to-end processing may shift the product.

Sourced from: docs.staxpayments.com · staxpayments.com

Tilled

PayFac-as-a-Service for B2B software companies: white-label payments with revenue-share economics, without registering as a payfac.

Ownership

Independent, venture-backed. Founded 2019 in Boulder; $12.5M round led by Canvas Ventures and UPC Capital Ventures (October 2024), nearly $40M raised total.

Merchant onboarding

Two published paths: a white-label hosted merchant application generated from your dashboard and served on your custom subdomain, or a custom flow on the onboarding API with OnboardingJS. The happy path moves through created, started, submitted, in_review, and active (the docs publish eight statuses, including rejected and withdrawn), with Middesk validation of US business identity. Tilled runs underwriting (OFAC, PEP, bank verification, TIN, background checks) and markets that more than 80% of applications are approved instantly; that figure and a ten-minute onboarding example come from marketing posts, and the documented flow includes an in_review state with no published SLA.

Who holds the registration

Tilled operates the payment facilitation stack in a master-merchant and sub-merchant structure; the partner registers as nothing and Tilled handles underwriting, fraud monitoring, and chargeback management. Worth knowing: Tilled's own site-wide legal disclosure lists ISO/MSP registrations (Pinnacle Bank dba Synovus, Citizens Bank) rather than a card-network registered-payment-facilitator disclosure, and the exact counterparty on the sub-merchant agreement is not published.

Economics

Revenue share over a Schedule A buy rate, with you setting merchant pricing during onboarding. Published tiers: 70% revenue share with a $500 monthly SaaS fee on the plan pitched for platforms under $5M/month of processing; 80% share at $2,500 monthly on the plan above it. Commission is (merchant revenue minus your buy-rate cost) times your share, paid monthly in arrears; if merchant revenue comes in below your cost, the difference is collected from you. Actual buy rates per card type: not published (the pricing calculator's 2.9% + 30¢ merchant and 2.27% + 15¢ cost figures are labeled estimates).

API surface

REST APIs for payments, payouts, onboarding, and reporting with webhooks; Tilled.js and PaymentsJS for collection and OnboardingJS for custom onboarding; no-code white-label modules for onboarding, console, payment links, virtual terminal, and notifications, with custom domains and branded emails at the enterprise tier. Docs at docs.tilled.com.

Published go-live claim

Homepage claims embedding in weeks, not months or years; a Tilled post claims a software company can have the API running in a matter of days. Merchant-level marketing claims onboarding in under ten minutes. No contractual guarantee published.

Choose them when: Choose Tilled if you are an established B2B software platform that wants payfac-style economics with a published revenue-share split and a fully white-label merchant experience, and you can justify the monthly platform fee and absorb negative-commission risk on thin months.

Worth knowing: Paysafe has announced an expanded Tilled partnership for payfac-as-a-service across the US and Canada; a Paysafe-branded docs deployment previously seen at paysafe.docs.tilled.com no longer resolves. Re-verify before relying on it.

Sourced from: docs.tilled.com · tilled.com

Where Flint fits

Flint is the row for platforms whose answer to "should we monetize the spread" is no, or not yet. Each business on your platform becomes its own Flint merchant through an onboarding API and an embedded verification component, pays Flint's published rates directly, and settles to its own bank account; your platform is never in the funds flow and registers as nothing. What embeds is commerce, not only charges: orders, checkout, invoices, and subscriptions arrive with the payments. How that works in practice, including what happens when a merchant fails underwriting, is on the embedded payments page.

Merchant onboarding

Merchant creation is an API call (email and name to start), then a requirements state machine tells you exactly what is outstanding; identity verification runs in an embedded component inside your app, with no hosted redirect. A scoped sandbox API key can be minted before verification finishes. Every merchant is underwritten individually, and a decline is a state your flow is expected to handle, not an exception.

Who holds the registration

Every business on your platform is a Flint merchant with its own underwriting, its own record, and its own payout destination; each merchant agrees to Flint's terms directly. Your platform registers as nothing, is never in the funds flow, and has no platform balance, because there is no platform account for money to sit in.

Economics

The API has no application-fee, revenue-share, or fee-split field; no slice of a transaction can be routed to the platform. Merchants pay Flint's published rates directly (from 3.79% + 30¢ with no monthly fee at the base tier), and the platform charges its merchants for the software. If monetizing the spread is the goal, every other row on this page is a better fit, and the decision essay linked below covers when that goal is even worth having.

API surface

One public REST API spanning orders, checkout, payment links, invoices, subscriptions, catalog, refunds, payouts reporting, and merchant onboarding, so the embedded product is commerce, not only charges. Node SDK, a CLI whose non-interactive commands double as MCP tools for agents, and a public OpenAPI spec.

Published go-live claim

Platform onboarding is API-first: start from an endpoint, mint a sandbox key, and build before any sales conversation. Live processing turns on per merchant once that merchant passes verification; there is no platform-wide go-live gate to schedule.

Choose Flint when: Choose Flint if payments revenue is not your business model: you want commerce embedded in your product with merchant onboarding as an endpoint, your merchants pay published rates, and you monetize your software. If you want a revenue share or your own registration, choose from the rows above.