DEV Community: Keisha Singleton

Payment decisions every marketplace has to make (and where to automate them)

Keisha Singleton — Mon, 17 Aug 2026 06:03:35 +0000

Building a two-sided marketplace? Payments are not "add Stripe and ship it."

The moment you have sellers who need to get paid, not just a store taking one payment from one buyer, you're making five architectural decisions whether you realize it or not:

How sellers get verified and onboarded (connected accounts)
How money comes in (pay-ins)
What you charge (take rate)
How it splits between parties (split payments)
How money goes back out (payouts)

Get any one of these wrong and you're either shipping a bad seller experience or writing a lot of infrastructure code you didn't budget for.
Here's what each decision actually involves at the API/architecture level, and where a payments platform can take the work off your plate.

1. Connected accounts: verify now or verify later?

Every seller needs KYC/KYB before they can hold or move money. The question is when.

Front-load it at signup and you're protected from day one, but you add friction before a seller has listed anything. 74% of users already find marketplace onboarding unnecessarily complicated — that's before you've asked them for a tax ID.

Defer it to first payout and signup is frictionless, but you're carrying unverified sellers on your platform until they cash out.

There's also an account-tier decision hiding underneath this:

Full connected accounts — seller gets their own balance, multi-currency holding, control over withdrawal timing. Right model for high-earning, repeat sellers (Etsy, Fiverr-style).
Ledger-style accounts — lighter KYC, cheaper and faster onboarding, no seller autonomy over funds. Right model for high-volume, low-earning sellers (Uber, DoorDash-style gig payouts), where full account infrastructure per seller would cost more than the seller earns.

Building this yourself means maintaining KYC/KYB integration, sanctions screening, two separate account infrastructures, and the migration logic to move a seller from one tier to the other as they grow. That's before you've moved a single dollar.

2. Pay-ins: getting money in the door

Once a seller exists, you need to decide how the buyer's money actually lands.

Capture timing is a cash-flow-vs-refund-risk tradeoff. Capture instantly and you lock in revenue immediately, but a cancelled order means a refund, not a released hold — and refund processing averages $15–25 per transaction once you count interchange and processor fees. Delay capture until fulfillment and you dodge that, but debit holds can release in 1–2 business days, well inside a typical shipping window. Ship late, and the hold's already gone.

Fund custody matters more than most teams think about up front. Some providers hold funds in their own regulated account until the split happens — your bank account never touches the buyer's money. Others route the full pay-in through your account first, which puts you in legal possession of buyer and seller funds simultaneously. In the US, holding customer funds even briefly can trigger money transmitter licensing requirements state by state (New York alone wants a $500K surety bond).

Currency conversion is a build-vs-bolt-on call. Native conversion inside your payment provider runs in the background at ~1%. Bolt on a separate FX provider and you've added a second system with its own handoff — mismatched transaction IDs, delayed conversion, markup stacking to 3-5%.

Method coverage is table stakes for anything cross-border: iDEAL in the Netherlands, BLIK in Poland, Pix in Brazil. Build this yourself and you're managing individual FX relationships and integrating local rails one at a time.

3. Take rate: fixed, variable, or compound

Three shapes, and most marketplaces get this wrong on the first attempt:

Fixed — flat fee per transaction. Predictable, but disproportionately punishes low-value orders.
Variable — a percentage that scales with order size. Most common, flexible by category/tier, can double as a growth lever (lower rate for new sellers).
Compound — fixed + variable. Guarantees a revenue floor while still capturing upside on larger orders. This is where Etsy and eBay both landed — neither started there.

The engineering cost isn't in picking one — it's in what happens when you need to change it. If your take rate is hardcoded percentages scattered through your checkout logic, every pricing change (new tier, new category, switching variable → compound) is an engineer picking up a ticket and shipping to prod. If your payment platform exposes splits and commissions as configurable API objects instead, that same change is a config update, not a deploy.

4. Split payments: the part that actually breaks

Single-seller checkout is trivial: buyer pays $100, you take $10, seller gets $90. No infrastructure required.

Multi-seller orders are where it gets real. Amazon-style carts — one checkout, products from three different sellers — need that $100 split three ways ($60/$30/$10) from a single transaction. Now add a partial refund on that order: you need to reverse one seller's cut without touching the others, while keeping your own commission math correct on what's left.

This is the actual engineering cost center. Split-payment logic alone can eat 20-30% of a marketplace's total engineering effort if you're building it in-house — refund edge cases, rounding, partial reversals, reconciliation. If your platform handles splits, commissions, and refunds natively through the API, all of that collapses into a single call instead of a subsystem you maintain.

5. Payouts: getting money back out

Three models, each with a different tradeoff:

Scheduled (daily/weekly/monthly) — predictable, easy to reconcile, but funds sit in limbo for the seller. 44% of gig workers say they'd quit a platform that added fees or friction to fast payouts — payout speed is a retention lever, not a back-office detail.
Instant — money moves in minutes. Sellers want this, but instant rails charge a percentage + flat fee versus a low flat ACH rate. Someone eats that cost — you, or the seller as an opt-in paid upgrade.
Manual — triggered on demand by either party. Most control, least automation.

There's also a UX decision underneath all three: is payout management (balance, withdrawal, status) embedded in your product, or does it hand the seller off to some other hosted page mid-flow? A jarring redirect after they've spent the whole session in your app is its own churn risk.

Building this yourself means maintaining multiple payout rails, the fee-absorption logic for who pays for speed, and your own embedded UI for balance/withdrawal — on top of everything above.

Build vs. buy

A few marketplaces run the full build — Amazon and Airbnb operate their own licensed payment subsidiaries — but that's years of infrastructure and compliance work, not a decision most teams get to make. Most marketplaces build on top of a payments platform instead of becoming a licensed financial institution themselves.

When you're evaluating one, the questions that actually matter:

Coverage — buyer-side coverage and seller-side coverage are not the same number. Check both against where your users actually are.
Compliance — KYC/KYB gets you onboarding. Ongoing sanctions screening and tax reporting (1099-K in the US, DAC7 in the EU) don't stop there. Some platforms handle this for you; others hand you a checklist. (Temu paid a $2M DOJ/FTC penalty in 2025 for exactly this gap.)
Take rate flexibility — can you change fee structure by tier/category/volume without a full re-integration?
Merchant of record — who's the name on the buyer's bank statement, and who eats the chargeback? US chargeback volume is projected to hit 146 million disputes worth $15.3B in 2026 — this isn't a hypothetical line item.

Where this leaves you

None of these five decisions are optional — every marketplace payment runs through all of them, whether you've deliberately chosen an answer or defaulted into one. The API-level question is really: do you want to own connected accounts, split logic, take-rate config, and payout rails as code you maintain, or as calls into a platform that maintains them for you?

Want to know more? Read the full blog here

Stripe vs Airwallex: quick guide to platform payments

Keisha Singleton — Wed, 12 Aug 2026 05:34:05 +0000

Building a platform that pays out sellers, contractors, or creators and trying to decide between Stripe Connect and Airwallex's Payments for Platforms?

Here's the tl;dr rundown you need:

Accepting payments

Stripe Connect — pick a charge type per transaction: direct (connected account is merchant of record), destination (you are, then you transfer their cut), or separate charges and transfers (split one charge across multiple accounts, on your own schedule).

Airwallex Payments for Platforms — pick a setup instead: SaaS (your customers are merchant of record), marketplace (you are, via Airwallex as acquirer), or PSP-agnostic (you are, but keep your own processor for pay-in, no Stripe equivalent for this one).

_Catch: Airwallex's full accounts (the only tier that can accept payments) are only available in ~55-60 countries. Outside that, you're on ledger accounts or PSP-agnostic.
_

Payouts

Stripe splits payouts across three products by recipient type: Connect payouts (onboarded accounts, limited cross-border corridors), Global Payouts (anyone, via email, no account needed), and Treasury for platforms (FDIC-insured balances, US-only).

Airwallex runs it all through one Transfers API, connected account or arbitrary beneficiary, same endpoint.

Pricing and risk

Stripe's real pricing lever is who sets pricing (you vs. Stripe), not account type. Airwallex's rates look simpler but Payments for Platforms itself is contact-sales-only.

Stripe's Managed Risk will absorb bad debt on connected accounts, if you qualify for it. Airwallex has no equivalent, that risk stays with you.

This is the short version.

I wrote up the full comparison, including exact fees, country restrictions, account-tier tradeoffs, and tax/1099 handling, over on the Whop blog:

Stripe vs Airwallex: two different approaches to platform payments

Virtual card issuing started as a spend control tool — now it's a revenue stream too

Keisha Singleton — Fri, 07 Aug 2026 05:15:24 +0000

Most devs who've touched payments know virtual cards as a way to control spend, like issuing a company card for SaaS subscriptions, a dedicated card per vendor, that kind of thing.

That's still true. The global virtual cards market was worth $22 billion in 2025 and is projected to nearly triple to $60 billion by 2030, with B2B use making up the majority of it.

But your platform can also make money with virtual card issuing: every time a virtual card gets used, a small fee gets generated, and someone on the other end collects it.

If you're building a platform with users who hold a balance (creators, sellers, gig workers, whatever) that someone could be you.

This post walks through how that actually works, and how to wire it into a product.

How virtual cards actually work

A virtual card is exactly what it sounds like: a card number, expiration date, and CVV, with no physical card attached. It can be debit, credit, or prepaid underneath — "virtual" just describes the form factor.

Everything else works like a normal card. Authorize, settle, show up on a statement. The only thing missing is the plastic.

One thing worth clarifying if you're integrating this into a product: a virtual card is not the same thing as a digital wallet (Apple Pay, Google Wallet). A wallet is a container — it's empty until you put a card into it. A virtual card is the actual card. You can add either a virtual or physical card to a wallet; the wallet just tokenizes it so the real card number is never exposed in transit.

Once a virtual card is sitting in a wallet, it works anywhere contactless does — online and in person. "Virtual" doesn't mean "online only."

Where the revenue actually comes from

Picture a $100 transaction. That $100 doesn't go straight to the merchant:
The merchant's bank skims a fee off the top — typically 1–3% of the transaction
Most of that fee (on a $100 purchase with a $2 fee, roughly $1.60) goes to whoever issued the card being used
A smaller slice goes to the card network (Visa/Mastercard) for running the rails
The merchant's bank keeps the rest for processing

That $1.60 is called interchange. Normally, it goes to a bank — specifically, whoever issued the card. If your users are spending from their own personal debit cards, that fee goes to their bank, not you.

_The numbers are bigger than you'd think. The Federal Reserve's most recent data puts total US interchange fees on debit and prepaid transactions at $34.12 billion, across 100.7 billion transactions worth $4.7 trillion.
_
Issue the card yourself, and a share of that fee routes back to you instead, through whichever issuing provider you're integrated with (they take their own cut before passing the rest along).

_FYI: Interchange isn't a flat rate. It moves with card type, transaction location, and online vs. in-person, typically landing between 0.2% and 2.5%. Two regulatory notes worth knowing if you're scoping this out:
_
The good news for anyone reading this as an engineer: you don't need a banking license. You need an integration.

How to start issuing virtual cards

Pick an issuing provider

Going direct means becoming a licensed bank yourself, or standing up the full compliance/risk stack that comes with a direct sponsor-bank relationship — KYC, AML, fraud liability, PCI compliance, scheme membership negotiated with Visa or Mastercard directly.

Providers like Whop Cards, Stripe Issuing, and Marqeta have already absorbed that cost once and resell access to it. You build on top instead of underneath.

Wire it up via API

Card issuance happens through the provider's API. In practice: trigger a new card on user signup, on balance threshold, or wherever it fits your product flow. No manual application step for you or your users.

Decide what the card is linked to

Most platforms link the card to a balance the user already has (earnings, pending payouts, wallet funds) rather than a credit line — simpler, lower risk, no underwriting required. Whop Cards works this way by default. Credit-linked cards are the more complex alternative most platforms don't start with.

Configure the card

Spending limits, merchant restrictions, single-user vs. reissued, virtual-only vs. physical fallback — these are typically exposed as configuration on the provider's side, not something you build from scratch.

Ship it

Once issued, a card is usable immediately: online right away, in-person the moment it's added to Apple Wallet or Google Wallet.

Let it run

Every transaction after that generates interchange, the provider processes the split, your share lands automatically. Nothing to run per-transaction. It scales with usage, not with your engineering effort.

A real example: Poke Human
Poke is an AI assistant living in iMessage, WhatsApp, and Telegram. Poke Human is the layer of real virtual assistants that step in when a task needs a human, for things like booking a car, ordering food, handling something the AI can't.

Those VAs need to actually spend money on a user's behalf. Poke issues each VA their own Whop-issued virtual Visa card, funded by Poke, so they can complete the task without any shared-card chaos or manual reimbursement.

No card infrastructure was built in-house. Individual cards are issued via API, with authorization and tracking handled in the background. And every time a VA taps that card, a slice of the interchange comes back to Poke.

That's the general idea: whether the balance behind the card is money a user earned (creator marketplace) or money the platform loaded for an agent to spend (Poke Human), the mechanic is identical — balance, card, spend, interchange back to whoever issued it.

_Read the full guide on Whop's blog, which also covers building this specifically with Whop Cards.
_

How a 19-year-old with $250k in revenue almost dropped out (and why he didn't)

Keisha Singleton — Fri, 24 Apr 2026 04:00:41 +0000

Griffin Kubicki had already built two businesses before he ever set foot on a college campus.

By the time he enrolled at the University of New Hampshire, he'd generated more than $250,000 in client revenue through paid ads and conversion funnels — working as a media buyer, head of operations, and founder of his own agency, Kube Marketing. He wasn't arriving at UNH to figure out what he wanted to do with his life. He already knew.

So why bother with a marketing degree?

He wanted the credential, sure. But more than that, he wanted to meet other young founders — people who understood the particular hunger of building something before most of their peers had held a real job.

He figured college was where he'd find his people.

The loneliness problem no one talks about

UNH has a lot to offer. For most students, its tight-knit Greek community is exactly what they're looking for. But Griffin was wired differently.

"I want people who want to wake up early in the morning and go get s*** done."

Opportunities kept coming in — founder events, clients, deals. He'd return to his dorm excited to share the news, and find his roommate gone. Everyone was out socialising. It wasn't the kind of connection he was after.

He became a regular at UNH's award-winning ECenter, treating it like a second home. His businesses were growing. His social circle wasn't.

"I was just so lost. You almost feel like you're missing out if you don't find your people."

The trip that almost ended his degree

Then came Miami.

Griffin was flown out to meet other young founders — exactly the kind of trip that should have felt like validation. Instead, he spent the weekend being told to quit college. That it was a waste of time.

He came home half-convinced they had a point.

"I was pretty set after that, like, okay, I'm going to drop out. Dude, I'm going to go buy a Porsche."

But a few days later, an admin at the ECenter who'd watched Griffin practically live there saw a LinkedIn post from Whop's John Hill: "Tag a university student entrepreneurship leader. I'll choose one to visit our offices in NYC."

She tagged Griffin. He applied and tried not to think too much about it.

Two days later, an email landed in his inbox: "Are you game?"

What changed his mind

He walked into Whop HQ and found college students who were enrolled, building, and setting goals. Not telling him to quit anything.

"Holy crap. There are college students doing business who have goals like mine, and it's a real thing."

It reframed everything. He wasn't the odd one out, he'd just been in the wrong room.

"It gave me clarity of like, okay, I have goals, I'm going to go get those goals."

Griffin flew home with direction he hadn't had before. He was staying in school, keeping his businesses running, and for the first time since arriving at UNH, he wasn't searching for his community. He knew where to find it.

Building it for others

In the weeks after his visit, Griffin was contracted to create Whop communities for both Harvard and Yale. Then he turned closer to home, becoming the administrator of the UNH whop and helping fellow students build their own.

One of the first people he brought in was Colby Chase, a digital marketer who films car content and teaches creators how to go viral. He then hired a freshman to work alongside him — someone he still works with today.

The community he'd spent his first year searching for, he was now creating for others.

"If people want to go start their businesses, they can go on the whop at the University of New Hampshire and I'm the admin of it. There's an ecosystem built, slowly but surely, it's getting populated."

The bigger picture

Griffin's story isn't an isolated one. According to a 2025 Quizlet survey of 2,000 US college students, more than half of Gen Z students maintain a job or business alongside their studies.

The ambition has never been the problem. What's been missing is infrastructure that doesn't require a co-founder with connections or a family friend with capital — and a community that gets it.

Whop's Higher Ed program has now reached more than 100 universities, with almost 4,000 student businesses launched. The goal for 2026: 1,000 universities and 100,000 students.

At Michigan State, Professor Ken Szymusiak rebuilt his entrepreneurship curriculum around a five-week sprint — and more than 350 students have since built real businesses through it:

"What has become very clear is that my students now have the ability to build at superhuman speed. What used to take weeks now takes hours. Entrepreneurship education has to be about experimenting, not case studies of the past."

Business as community

When Facebook launched from a Harvard dorm room in 2004, it connected people who already knew each other. Whop is doing something different: connecting people through what they create.

Students in New Hampshire are building alongside students in South Carolina, Michigan, and California. A freshman at UNH is learning from a sophomore at Yale.

For builders like Griffin, the business isn't separate from the community. It is the community.

Why your payment integration is leaking revenue (and how the architecture is to blame)

Keisha Singleton — Fri, 20 Mar 2026 07:53:36 +0000

Most payment integrations start the same way. You pick a PSP, follow the docs, get to a working checkout, and ship. It's the default for a reason — the integration is well-documented, the SDK handles the complexity, and payments work.

Now, single-PSP architecture isn't wrong, but it's coupled in ways that only become visible when something breaks, and by then, the cost is already running.

What single-PSP dependency actually looks like in a codebase

When you integrate directly with a single processor, payment logic tends to get distributed across your application. Checkout flows, retry handling, webhook processing, subscription billing: each of these ends up with processor-specific logic baked in.

There's no abstraction layer. Your application talks directly to the PSP. Which means:

Routing decisions live in application code, not in a dedicated layer
Adding a second processor isn't a config change, it's a new integration
Your card vault is owned by the PSP, not by you, and migrating it later is painful
A processor outage has no programmatic fallback

None of this feels like a problem when you're building it, but it becomes a problem when you're scaling.

The failure modes you don't anticipate

Processor outages with no fallback

A single-PSP architecture has one response to processor downtime:sit and wait. There's no routing layer to detect degradation and shift volume. For a merchant processing at meaningful volume, even a short outage represents significant lost revenue, and there's nothing in the stack to catch it.

Suboptimal cross-border routing

Without a routing layer, every transaction goes to the same processor regardless of where the customer is. International transactions routed through a non-local acquirer carry structurally higher failure rates and cross-border fees. The authorization rate difference between domestic and cross-border routing is measurable: but only recoverable if your architecture supports routing decisions.

Silent card-on-file failures

For subscription businesses, card-on-file transactions fail when credentials become stale: expiration, reissuance, account changes. Without network tokenization (tokens issued by the card networks that auto-update), these failures are silent. The charge just fails. By the time it surfaces as churn, the customer is already gone. Up to 12% of card-on-file transactions fail for exactly this reason.

The fraud filter problem

Every PSP has its own fraud rules. A transaction flagged by one processor might sail through another. When your stack has no routing layer, there's no mechanism to recover from a false decline — the transaction fails, the customer leaves, and you have actually paid an acquisition cost to then lose them.

The cost that doesn't show up in your monitoring

Authorization fees are charged on failed transactions as well as successful ones. Every declined transaction carries a direct processing cost on top of the lost sale. At scale, you're paying to lose customers.

The engineering cost compounds this. Adding a second PSP without an abstraction layer means rebuilding routing logic, webhook handling, reconciliation, and vault management for a new provider. That's months of engineering time: and it has to repeat for every new market or payment method.

PCI DSS scope also tends to expand with every direct integration. Without a centralized vault abstracting card data, each new processor potentially increases your compliance surface.

What an abstraction layer actually buys you

Payment orchestration introduces a layer between your application and your processors. Your integration point is the orchestration layer, not the PSPs directly.

What this changes architecturally:

Routing logic lives outside application code. Rules can be updated without deploys. New processors can be added without new integrations.
Vault portability. Credentials are stored once and usable across all connected processors. Retries through a secondary processor don't require re-authentication.
Programmatic fallback. When a primary processor degrades or goes down, the orchestration layer detects it and reroutes — before the customer sees a failure.
A single observability surface. Authorization rates, decline reason codes, and cost-per-transaction across all processors in one place, segmented by BIN range, region, and card type.

The architectural shift is from tight coupling to an abstraction layer with defined interfaces. It's the same principle you'd apply anywhere else in a distributed system.

When to think about this

The earlier the better, but the inflection points that tend to force the conversation are:

Expanding into international markets where local acquiring matters
Adding subscription billing where card-on-file failure rates compound
Reaching a transaction volume where authorization rate improvements have measurable revenue impact
A processor outage that surfaces the single point of failure

By the time most engineering teams are asked to retrofit orchestration, the vault migration alone is a significant project. Building toward an abstraction layer earlier is the lower-cost path.

For the full business case — including the cost of false declines, the vendor comparison, and what to look for when evaluating platforms — the complete guide is here: Why Payment Orchestration Is the Infrastructure Fix Most Merchants Are Overdue For

I looked into every Stripe Connect alternative worth knowing about: here's what I found

Keisha Singleton — Thu, 19 Mar 2026 01:57:44 +0000

I've been deep in research on this one. If you're building a platform or marketplace and Stripe Connect is starting to show its cracks, this is for you.

Why people leave Stripe Connect

Stripe Connect is a genuinely good default. The docs are thorough, the developer experience is polished, and most platforms can get up and running without a dedicated payments team.

The problems tend to come later, with processing fees, Connect account fees, instant payout fees, FX conversion fees, and dispute fees all layering on top of each other. And, geographic gaps in the payout network show up exactly where you're trying to expand.

On top of that, single-provider dependency creates concentration risk that's easy to underestimate until something goes wrong (like it did with Flipcause: when the nonprofit platform filed for Chapter 11 in December 2025, Stripe had frozen ~$2.2M in funds, becoming a central obstacle in creditors' recovery. Legally defensible, but a vivid illustration of what single-PSP dependency can look like at a critical moment).

The alternatives, by category

I broke these into three tiers: full replacements, payout specialists, and merchant of record platforms.

Full Stripe Connect replacements

Whop Payments Network — full-stack infrastructure with multi-provider orchestration, automatic retry on decline, 100+ payment methods, 135+ currencies, 195 countries, and a connected accounts model for platforms. Payout options include next-day ACH, Instant RTP, crypto, Venmo, and international bank transfers. Transparent pricing, 24/7 support, 99.999% uptime. The one I'd look at first if vendor dependency is the core concern.

Adyen for Platforms — best-in-class acquiring infrastructure used by eBay, Wix, and Lightspeed. Interchange++ pricing is cost-efficient at volume, but it's enterprise-only and not self-serve. Assumes a dedicated payments engineering team.

Checkout.com Integrated Platforms — standout feature is split payment configuration at any stage of the transaction lifecycle (authorization, capture, or refund). Strong in Europe, MENA, and APAC. Enterprise-only, sales-led.

Mollie Connect — best option for European platforms. 35+ local payment methods including iDEAL, Bancontact, and Klarna. Pay-per-transaction pricing. Note: the pending GoCardless acquisition (expected mid-2026) adds bank debit to the stack but introduces near-term roadmap uncertainty.

Rainforest — purpose-built for vertical SaaS replacing Stripe Connect. Vertical-specific underwriting improves approval rates in healthcare, logistics, and professional services. Buy-rate interchange++ pricing, no monthly fees, no revenue split. US-focused for now.

Payout specialists

These sit downstream of your PSP and handle disbursements only — useful if your core issue is the payout side, not pay-ins.

Payoneer — strong emerging market coverage (190+ countries, 70 currencies), recognizable brand among freelancers and international sellers. The 2025 fee changes matter: transfers under $400 now carry a flat $4 fee, and FX markups run 0.5–3.5%.

PayPal / Hyperwallet — 400M+ active PayPal accounts means near-instant payouts for payees already in the network. 200+ markets. No published rate card — all pricing is negotiated.

Trolley — purpose-built for mass disbursements. 210+ countries, 135+ currencies, DAC7 compliance automation, white-label payee onboarding. API-first. Disbursement only.

Routable — sits between payout specialist and AP automation tool. Four ACH speed tiers, 220+ countries, strong ERP integrations. Good fit if you're managing both AP and seller payouts.

Tipalti — enterprise standard for global payables. 196 countries, 120 currencies, KPMG-approved tax engine, SOC-compliant audit trails. Finance-team-led, not developer-first. Implementation takes weeks to months.

GoCardless — not a payout tool. It collects recurring payments from buyers via bank debit across 30+ countries at lower cost than card. Worth considering if your specific pain point is the cost of recurring payment collection, particularly in Europe or Australia. Being acquired by Mollie (mid-2026).

Merchant of Record alternatives

MoR platforms become the legal seller of your products, absorbing tax, compliance, fraud, and chargeback liability. Built primarily for SaaS and digital product businesses — not for routing funds between sellers. If you're running a marketplace with third-party sellers, this tier isn't for you.

Paddle — category leader, 13 years as MoR, 6,000+ customers. Handles tax across 100+ jurisdictions, subscription management, fraud, chargebacks. Stripe Managed Payments is now a direct competitor, though Paddle's compliance infrastructure is considerably more mature.

Lemon Squeezy — acquired by Stripe in July 2024. The team is building Stripe Managed Payments. Still works, still simple, but the long-term direction is Stripe-native.

How to choose

Most switching decisions come down to one of three things: cost at volume, geographic gaps, or compliance overhead. Identify which one is actually your problem before evaluating alternatives — it cuts the shortlist fast.

The most important decision in the evaluation is your compliance model. MoR platforms absorb liability in exchange for a higher fee. PSPs and payout specialists hand that responsibility back to you. There's no right answer — only the right fit for your team's capacity.

And don't underestimate connected account migration. Moving active sub-merchants with saved payment methods or live subscriptions is the hardest part of any infrastructure switch. Get explicit written confirmation from any vendor on how they handle it before entering a sales process.

Read the full Stripe Connect alternatives comparison here.