How Vortex compares
PayFac vs PSP vs merchant of record — honestly, including when we are the wrong answer.
How Vortex compares
Three models dominate taking payments online. Knowing which one you are buying matters more than any feature table.
The three models
| PSP (e.g. Stripe) | PayFac — Vortex | Merchant of record (e.g. Polar, Paddle) | |
|---|---|---|---|
| Who holds the merchant account | You, directly with the PSP | You, as a sub-merchant under our facilitation | Them — they are the seller |
| Whose name is on the customer’s statement | Yours | Yours | Theirs |
| Who owns tax (sales tax / VAT) liability | You | You (we give you calculation rails) | Them |
| Onboarding speed | Fast | Fast — self-serve signup, activation gates real money | Fast |
| Control over funds flow, fees, payout timing | High | High — per-merchant rates and payout visibility down to settlement math | Low — you get their standard terms |
| Best for | Companies wanting a direct processor relationship at scale | Platforms and products embedding payments for their users | Selling software globally without wanting a finance function |
What being a PayFac means for you, concretely
- Sub-merchants are first-class. Merchant onboarding, KYC readiness, capability state, and payout readiness are API objects you can build product on — not a support ticket.
- The money math is inspectable. Every settlement exposes gross, fees, refunds, adjustments, and net; payouts reconcile against settlements. If our numbers ever disagree with your provider statement, that is a bug we treat as severity-one.
- Rates are per-merchant and explicit. Your fee schedule is set on your agreement and applied per transaction — visible in the settlement records, not discovered on a monthly statement. No seat fees, no charge for the API itself.
- Provider abstraction is real. Your integration speaks Vortex — the card element, the API, the webhooks. The processing partner behind it can change without your checkout changing. We prove this in CI, in a real browser.
When we are the wrong answer
Candidly:
- You want global merchant-of-record tax handling. If the reason you are shopping is “I never want to think about VAT”, buy an MoR. We give you tax calculation rails; the liability stays yours.
- You want the largest possible processor feature catalog today. Stripe has two decades of surface area — terminal hardware in fifty countries, every local payment method, treasury products. If you need that breadth now, go with Stripe; it is the better answer and pretending otherwise would waste your integration.
- You are not in our processing footprint. We serve US-domiciled merchants today. If your entity is elsewhere, we are not yet for you.
When we are the right answer
You are building a product whose users take payments — a platform, a vertical SaaS, a marketplace-shaped thing — and you want the payments layer to be an API-first system you can embed, inspect, and if it ever comes to it, leave without hostage negotiations.