If you're building a vertical SaaS platform in the creator economy with brands and agencies on one side and creators on the other, you have three credible architecture solutions for payments:

1. Build on Stripe Connect with your own ledger

2. Build on a BaaS provider like Unit for embedded banking and ledgering

3. Build on a merchant of record network like Lumanu that manages vendor onboarding, tax, compliance, and ledgering for you

The payment architecture decision depends on whether payments are your product or a feature of your product, your compliance liability and support appetite, and how much infrastructure your team can build, operate, and maintain. This guide walks through the decision criteria and tradeoffs.

The summary answer

Choose Stripe Connect + build your own ledger if:

• You need to collect money from brands via credit card, ACH debit, or invoicing.

• You have engineering capacity to build and maintain vendor onboarding state management, payments, and ledgering.

• You have support capacity for assisting vendors who have issues onboarding or receiving funds.

• You are willing to take on the merchant of record role, with its tax and compliance obligations, for the payments you make on behalf of customers.

Choose a BaaS provider (e.g. Unit) if:

• Your product needs real FDIC-insured bank accounts to support things like debit cards, interest, and lending (vs. virtual balances).

• You are able to manage a compliance program under a bank partner's requirements.

• Your volume warrants the upfront build and ongoing costs of a BaaS solution.

Choose a merchant of record network (Lumanu) if:

• The money movement is primarily payouts to influencers, creators, and affiliates.

• You want vendor onboarding, KYC, global tax reporting (W-9/W-8, 1099s), payout failures, and creator support handled by a counterparty.

• You are out of the money flow, OR you have a process built to collect funds for creator payouts from your customers.

Most creator-economy platforms are not building a neobank. They're building campaign management, discovery, affiliate tracking and attribution, or workflow software where payments are the last mile. That reframes the classic "Connect vs. BaaS" question into a three-way decision, including a hybrid approach where a merchant of record carries tax and compliance for payouts.

Why these three options? Defining the leaders in each category

Stripe Connect is the leader in DIY marketplace payment infrastructure. Connect is the most widely deployed platform-payments toolkit, with mature APIs for connected accounts, three charge models (direct, destination, and separate charges and transfers), and robust documentation. Its "separate charges and transfers" model is purpose-built for one-to-many splits, supporting one charge with payouts sent to multiple recipients. You customize and manage the full vendor onboarding flow yourself, including the state management that confirms each vendor completes verification and becomes payable. Alternatives: Adyen for Platforms (stronger for global enterprise acquiring, denser API), PayPal/Braintree marketplace tooling, Dwolla (ACH-centric, US-only).

Unit is the leader in US banking-as-a-service. Unit is the default US choice when a software company wants accounts, cards, payments, and lending behind a single API and contract, and it is the most accessible BaaS platform for early-stage vertical SaaS. Companies like Wix and Bill.com embed banking through Unit. Vendor onboarding for creators runs through your application flow: creators submit identity information in your UI, Unit and its bank partner run the verification, and your code manages the application through its states, from submission to approval, document requests, or denial. Alternatives: Synctera (closer to the bank-partner layer), Treasury Prime (multi-bank flexibility), Column (for companies effectively becoming a bank), Stripe Treasury (Stripe's entry into the BaaS space).

Lumanu is the merchant of record and payment & compliance network for the creator economy. Lumanu takes on operational compliance work the other two don't by functioning as a payment network and becoming the legal counterparty to each creator you pay. Lumanu also takes on vendor onboarding itself: creators create a Lumanu account and self-onboard, and Lumanu owns getting them verified and payable. You give up control of that onboarding experience in exchange for someone else guaranteeing creators get set up. Lumanu acts as merchant of record in the US, UK, EU, and Canada and vendor of record for international payouts, paying creators in 180+ countries and 132 currencies, with an API, webhooks, and sandbox for platforms embedding payouts. It has processed over $1.5B in creator payments and partners with Visa for real-time push-to-card payouts. Pricing for platforms is a wholesale variable Funding Fee, so cost scales with payout volume rather than a contract minimum. Alternatives: Trolley, Dots and Tipalti  (payout APIs that move money, collect tax forms, help with filings  but do not act as merchant or payer of record), Gigapay (EU-focused MoR).

The categorical difference: Stripe Connect and Unit are infrastructure you build on. Lumanu is a network you plug into. Trolley, Dots, and Tipalti sit in between: they require less technical infrastructure than Stripe, and compliance, liability, and support stay your responsibility.

The API Payout Provider Evaluation Criteria Checklist

1. Who should be the payor/ merchant of record? This decision determines your liability, your tax obligations, and your ERP/vendor model. With Stripe Connect (separate charges and transfers) and on any payout API (Trolley, Dots), you are the payer of record: 1099 filings, DAC7 exposure, chargebacks, and negative balances live with you. With Lumanu, they act as the merchant of record and your single vendor. Decide whether acting as merchant of record is an asset (control, margin capture) or a cost for your core business.

2. Do you need to be in the money flow? If brands check out by card on your platform and you split funds downstream, you need an acquirer, and Connect (or Adyen) is entrenched. If your customers fund campaigns via invoice, ACH, or wire, and the hard problem is disbursing to hundreds of creators globally, you don't need marketplace acquiring. Staying out of the money flow, with customers funding payout balances at the payments network, removes the AR build, the funds-handling exposure.

3. Do "member wallets" mean virtual balances or bank accounts? A virtual balance (earnings accrued, pending, withdrawable) is a ledger problem: buildable on Postgres, or delegated to a network that maintains wallets for you. A bank account (deposits, cards, interest) is a regulated banking product, which requires BaaS. Teams spec "wallets," then discover mid-build they meant one and architected for the other.

4. What is your compliance surface? Count jurisdictions of where your customers are, the currencies they are funding in, and what countries your customers are making creator payouts to. US-only creator bases keep the problem to W-9s and 1099s. The moment your customers pay creators in 30 countries, you need to plan for W-8 collection and validation, treaty rates, VAT/GST edge cases, and country-level regulations. Building International payment compliance in-house on Stripe Connect is a multi-quarter project with permanent operational cost. Leveraging a merchant of record can offload year end requirements for finance and ongoing compliance and legal costs.

5. What's your engineering and support capacity? The real Stripe Connect build isn't only the ledger (that's a few weeks). It's infrastructure to handle reconciliation, retries, refunds across parties, and the payout-failure support queue for as long as you run payouts. The BaaS build means building out a supporting compliance infrastructure. Understand your capacity for operating and supporting payments beyond building the integration.

6. What's your payout volume trajectory? See the stage guide below; the economics flip at different volumes for each architecture.

7. Compare APIs, pricing, and contract commitments. Rail coverage, webhook quality, sandbox fidelity, contract minimums, FX markups, and per-payout fees matter. API docs are table stakes and each approach will have a different set of core principals and mental models to understand before moving forward. Read more: Top 5 Payment API solutions

What you build and maintain with each option

The standard advice ("use Connect and a Postgres ledger") will work, especially for early stage companies but it oversimplifies the architecture and what it takes to get payouts live for a vertical SaaS company. Here is the full build-and-run surface for a creator platform managing payments between brands/agencies and creators.

Option 1: Stripe Connect + self-built ledger

You build:

• Charge orchestration. For multi-party splits, you use separate charges and transfers: charge the brand on your platform account, then create transfers to each connected account. You write the split logic and the fee math. One charge covers your platform fee, Stripe's processing fees, and the amount each recipient receives, so you decide who absorbs Stripe's cut, calculate each transfer amount from the net, and validate that total transfers never exceed the charge.

• A double-entry Postgres ledger for member wallets: immutable transaction log and balance computation. If some of your customers want to track creator earnings without moving real money through your platform (for example, they pay creators outside your system but want balance visibility, or they accrue earnings over a period before releasing a payout), your ledger also needs entries with no corresponding Stripe transaction. That "ledger-only" mode doubles your test surface, because each flow now exists in a real-money version and a record-only version. If all of your customers only move real money through you you can skip it.

• Reconciliation tooling between your ledger and Stripe's actual money movement. The core problem: money passes through in-flight states (charged but not yet transferred, transferred but not yet paid out) that a balance snapshot can't capture, so you compare event streams rather than balances. Example of a mid-transaction failure: the brand's charge succeeds, transfer one of three succeeds, and transfer two fails because that creator's account has incomplete verification. Your ledger shows three creators credited while Stripe shows one paid. Reconciliation tooling exists to detect and resolve exactly these states.

• Idempotency and retry logic. When one transfer in a multi-party split fails and you retry the batch, the transfers that already succeeded execute a second time and double-pay those creators, unless each transfer operation carries an idempotency key. With keys in place, a retry re-attempts only the failed leg.

• Refund and reversal logic across parties. A brand can dispute a card charge, or an ACH debit can return for insufficient funds days after settlement. If you already transferred that money to three creators, you need transfer reversals from each of them, plus handling for creators whose balances have since been paid out and gone negative.

• Creator onboarding state machine and UX on top of Stripe's connected-account APIs. The lifecycle: create the account (Express, where Stripe hosts the onboarding flow, or Custom, where you build the full UI and submit data via the API), collect the account's requirements (identity details, business type, an external bank account for payouts), and then manage state. Stripe exposes outstanding requirements on the account object as currently_due, eventually_due, and past_due, and signals payability through the payouts_enabled flag. You subscribe to account.updated webhooks, prompt creators when Stripe requests more verification, and handle accounts that become restricted or disabled. The state machine tracks invited to verified to payable. You own the onboarding for all account types.

You maintain and operate:

• Payer-of-record obligations. For payouts, this is first a tax and compliance role: you collect and validate W-9s and W-8s, file 1099s, and run backup withholding when a tax ID fails verification. It also carries a financial backstop. Your Stripe balance is debited for Stripe fees, refunds, and chargebacks, and Stripe expects platforms on this model to cover connected accounts' negative balances. In practice: a reversal pushes a creator's balance below zero, and Stripe recovers the shortfall from you.

• Tax operations: configuring and paying for Stripe's 1099 tooling, handling corrections, B-notices, and creator tax questions, or building this yourself.

• Payout failure support: failed bank verifications, returned transfers, "where's my money" emails. Expect your support queue to grow in proportion with creators paid.

• Cross-border constraints: Stripe transfers require the platform and connected account to be in the same region in most cases, with cross-border transfers supported between the US, Canada, the UK, the EEA, and Switzerland. Creators outside those regions, such as a creator in Brazil or the Philippines, need a separate path: either Stripe's cross-border payouts feature where eligible, or a second payout provider with its own integration and reconciliation.

• Ongoing reconciliation and ledger integrity as an operational discipline.

Strengths: unmatched control, best-in-class money collection (card checkout, ACH debits, invoicing; see the AR section below), no contract minimums, and the most common v1 path for anyone collecting or sending money on the internet. If payments are your product and the creators your customers pay are US/EU-concentrated, Stripe Connect is a strong v1 option.

Option 2: BaaS (Unit)

You build:

• Application-layer flows on Unit's APIs: account opening (KYB requirements), card issuance if needed, payment initiation, and your own split and payment routing logic (BaaS gives you accounts and rails, not payment logic).

• KYB/KYC workflows and account-state handling for anyone who holds an account. You implement compliance workflows, not just payment APIs. One scoping decision matters here: not every recipient needs a deposit account. Unit supports ACH credits to saved counterparties, meaning external bank accounts identified by account and routing number, and Plaid verification is supported and recommended. A platform can pay creators from its own operating account to their external accounts and reserve full bank onboarding for creators who want to hold a balance or a card. This means you can create a pooled account for holding funds and managing payouts. Tax reporting and AML/OFAC screening on those payouts remain your responsibility either way.

• Your product's wallet UX on top of real deposit accounts.

You maintain and operate:

• A compliance program. Under BaaS, compliance work is split: the platform and sponsor bank provide the framework, and you operate your program within their guardrails. The scrutiny is real and recent. The FDIC issued Cross River Bank a consent order in 2023 over fair-lending controls in its fintech partner programs, and the Federal Reserve took enforcement action against Evolve Bank & Trust in 2024 over risk-management and AML deficiencies in its fintech partnerships, shortly before the Synapse collapse froze funds for end users of connected fintechs. Bank partners audit their programs harder as a result.

• Bank-partner relationship management, audits, and reporting obligations.

• A months-not-weeks integration timeline before the first dollar moves, and ongoing engineering to handle account states, disputes, and program changes.

• The money-in side. BaaS gives you accounts and money movement, and nothing upstream of them. Billing customers by invoice into accounts you manage means you build the invoicing, remittance matching, and dunning, and charging brands by card means adding a card processor on top. The AR section below covers this in detail.

Strengths: if creators should hold actual bank accounts on your platform, to earn interest, spend on a branded debit card, receive instant deposits, and use the account more broadly (for example, to collect TikTok Shop of AdSense for YouTube payments), no other option in this set delivers that. This is the right architecture when embedded banking is a revenue line and a moat. Budget for the cost structure: BaaS contracts tend to carry fixed monthly platform fees and minimums, implementation fees, and per-account and per-transaction charges, plus the compliance staffing to run the program. The fixed base means the economics work at volume rather than at launch. Unit is the most accessible BaaS for US-based platforms and marketplaces.

Option 3: Merchant of record network (Lumanu)

You build:

• API integration: trigger creator onboarding, create payouts, and listen to webhooks for onboarding status, payment status, account balances, and fundings.

• Funding flows (how brand/agency money reaches payout wallets) and metadata mapping for your reporting.

• Your own UI elements to control customer workflows. Funding workflows and payout triggers live in your platform.

• Optionally, Lumanu's RBAC (role-based access control) for granular user permissions: fund, create payouts, approve payouts, pay payouts.

• Sandbox-to-production in weeks.

You maintain and operate:

• The integration itself. Lumanu owns creator identity verification (KYC/KYB), W-9/W-8 collection and validation, year-end 1099 filings, international tax and compliance as vendor of record, currency conversion, payout failures, and creator support.

• Your position in the flow of funds, which you choose. Funds sit in dedicated bank accounts on Lumanu's network rather than on your balance sheet.

Limitations: Lumanu is payout-side infrastructure funded over banking rails. It is not a card acquirer for brand-side credit card funding, so if you need card rails for money in, you pair it with a processor (see the funding models below). If you need creator bank accounts you control, that requires committing to BaaS. You also cede control over the creator onboarding and payout experience to Lumanu as a payment network.

How does money come in? The accounts receivable side

Payout architecture discussions focus on money-out, but how money gets in depends on the option chosen. The AR side involves far fewer transactions and compliance considerations, and it still shapes the decision.

Stripe Connect: the strongest money-in option. Collecting money is what Stripe does best. Card checkout is first-class. ACH Direct Debit covers larger invoiced amounts, with two caveats your ledger has to model: slower settlement, and ACH debits that can be clawed back days after you credit a balance. Stripe Invoicing and Billing work as expected. If your platform sits in the money flow while taking a spread on payouts, Connect works well out of the box.

BaaS (Unit): dedicated bank accounts for receiving and holding funds, and no AR solution. BaaS gives you bank accounts that money can land in, and nothing upstream of that. You're building a full AR process that feeds the accounts you manage: invoicing, payment acceptance (you'll likely still add a card processor), remittance matching to figure out which incoming wire or ACH credit belongs to which customer and campaign, dunning, and reconciliation into your account structure. That's a second product surface layered on top of the compliance program you're already operating.

Lumanu: two funding models, depending on whether you're in the money flow.

• Out of the money flow (the simpler path). Lumanu creates an account for each of your platform's customers and manages invoicing: your customers pay Lumanu by ACH or wire to fund their payout balance, and your platform never touches the funds. The trade-off is that your customers need to be able to pay Lumanu, which means setting Lumanu up as a vendor in their AP system. That's a one-time procurement step per customer, small next to the hundreds of per-creator vendor setups it replaces, and still a step your sales and onboarding motion should plan for.

• In the money flow. Platforms that want to receive customer funds themselves can, then move funds into the respective accounts on Lumanu's network for disbursement. You keep control of billing and the customer payment relationship. You also keep the AR build and the funds-handling implications that come with receiving and forwarding money.

With Connect, money-in is a solved product and money-out is your build. With BaaS, you build both directions. With Lumanu, money-out is solved, and money-in is either Lumanu's job (out of flow) or a deliberate business choice you keep (in flow).

How do international creator payouts work with each option?

If your customers pay creators globally, and in the creator economy they will, international reach is where these architectures diverge.

Stripe Connect: two layers of geographic constraint.

1. Connected-account eligibility: in the standard model, your platform and the connected account must be in the same region, and cross-border transfers are supported within a corridor covering the US, Canada, the UK, the EEA, and Switzerland, with an added cross-border fee.

2. Stripe's cross-border payouts feature extends recipient coverage to a longer country list for eligible platforms, with caveats: Stripe enables it based on your platform profile, per-country payout minimums apply, some countries can only receive euros, some are in preview status where Stripe can pause payouts without advance notice, certain fund flows aren't supported, and Stripe doesn't provide direct support to recipient accounts, so you handle international payout support. Creators in unsupported countries can't be onboarded or paid. Map your customers' actual creator geography against Stripe's supported-country lists to ensure coverage and prevent future workarounds.

BaaS (Unit): domestic by design. US BaaS gives you US rails: ACH, wires, real-time payments, cards. Paying a creator in the UK or EU means adding a cross-border payout or FX provider on top, which means a second integration, a second contract, a second compliance review, and a second reconciliation surface between your ledger, your bank accounts, and the international provider.

Lumanu: global payouts are the product. Lumanu pays creators in 180+ countries and 132 currencies over local rails, PayPal, or Visa Direct, acting as vendor of record for international payments and handling local tax and compliance requirements in each market. Lumanu’s wallet architecture is set up to support on account/ wallet per currency so if you are managing multiple currencies for a given customer you will need to potentially pull from multiple wallets to display balances by currency and call different wallets for payouts based on currency. You fund in your currency; creators are paid in theirs, with no fees on standard payouts (including no SWIFT fees if a local rail is not available). International programs run on the same integration as domestic ones.

When to choose each: comparison table

Which architecture at which stage: a payout-volume guide

Pre-launch to ~$1M/year in payouts. The mechanics of any option work at this volume; the question is opportunity cost. Connect plus a Postgres ledger is the right decision if payments are core IP you want to own. If they're not, this is the stage where an MoR network is most attractive, because there's no build: a no-minimum, variable-fee model means you're not paying for infrastructure ahead of volume. Your engineers ship product instead of reconciliation tooling. BaaS is premature and cost prohibitive at this stage. Stripe Treasury's reported minimums alone would exceed many seed-stage budgets.

~$1M–$10M/year. DIY support and operational costs surface at this stage: 1099 volume becomes a January commitment, payout-failure tickets become a real support cost. For Stripe Connect ensure budget for a payments team (engineering, support, and tax ops). On an MoR network the compliance surface stays off your roadmap. Revisit BaaS only if a banking product (cards, deposits) has become a validated revenue line.

~$10M–$50M/year. Decision point: is money movement your moat? If yes, and you're monetizing float, FX, or financial products, the economics of owning infrastructure (Connect at negotiated rates, or BaaS for banking products) can beat network fees. If payments remain a feature, MoR network economics tend to win once you load in the internal costs: engineers, compliance headcount, audit exposure, and support.

$50M+/year. Contracts become negotiable and hybrid architectures are common: Connect or Adyen for acquiring, an MoR network for the long tail of global creator payouts, and BaaS where a banking product exists. At this scale the question shifts from vendor selection to which flows you insource versus route through a network, decided by cost per payout and support and liability appetite.

FAQ

Is Stripe Connect a merchant of record? It depends on charge type. With separate charges and transfers, the model multi-party platforms use, your platform is the merchant of record: your balance absorbs Stripe fees, refunds, and chargebacks, and payer-of-record tax obligations to creators stay with you.

Can I use Lumanu and Stripe together? Yes. Stripe (or another processor) handles money-in from brands at checkout, and Lumanu handles the payout side via API: creator onboarding, global disbursement, tax, and compliance. The two solve different halves of the flow.

Can any creator open a Stripe Connect account? No. Connected accounts are limited to countries Stripe supports, and standard transfers require the platform and the creator's account to be in the same region, with cross-border transfers covering the US, Canada, the UK, the EEA, and Switzerland. Stripe's cross-border payouts feature extends recipient coverage for eligible platforms, subject to per-country minimums, currency restrictions, and preview-status limitations. Map your customers' creator geography against Stripe's supported lists before you commit to the architecture.

What's the middle ground between building my own ledger and full BaaS? Payout APIs (Trolley, Dots) reduce the build for disbursement, and ledger-as-a-service (Modern Treasury) reduces the build for balance tracking, and both leave your platform as payer of record. A merchant of record network is the only option in this set that moves the liability itself, along with the workload.