Payments infrastructure for vertical SaaS.

A vertical SaaS platform — software written for a specific industry vertical rather than for general business use — wins or loses on how well the product fits the workflow of one industry. Payments inside a vertical platform have to fit that same workflow. Horizontal payment providers ship the same checkout, the same vault, and the same retry logic to every customer regardless of vertical, which is why a fitness-studio platform ends up with the same dunning emails as a B2B SaaS billing $50k invoices: the payment provider has one product and the vertical platform inherits it.

That mismatch shows up most clearly in three places: recurring billing logic, dunning behavior, and merchant onboarding. A fitness platform with $25/month memberships needs aggressive retry windows and customer-friendly grace periods; a B2B services platform with $5,000 monthly retainers needs a slower, more conservative retry schedule and direct-to-billing-contact outreach. A horizontal provider gives both the same defaults. Vertical platforms outgrow those defaults by year two.

Fluid Pay is gateway-and-platform, not a one-size-fits-all SaaS payment vendor. The recurring engine, the dunning logic, the retry schedules, the account-updater participation — all of it is configurable per platform. The vertical SaaS decides what fits its merchants; we provide primitives that compose, not a single canned product.

The single largest payments problem for vertical SaaS platforms with subscription merchants is involuntary churn: subscriptions that fail because a card on file became stale, and customers who never come back to update it. Industry data routinely puts involuntary churn from card failures at 20–40% of total churn — and half of that is recoverable with the right setup.

The "right setup" has three components.

Account updater. Refresh expired or replaced cards from the networks automatically. Our updater runs the standard batched services from Visa, Mastercard, Discover and Amex under one workflow, and charges only when a card actually updates. For monthly, weekly or daily recurring schedules the batched cycle catches credential changes well before the next charge.

Adaptive retry logic. Different failure codes need different retry behavior. A "do not honor" response is retried differently from an "insufficient funds" response, which is retried differently from a stolen-card response. Naïve retry policies do the same thing for all three and either over-retry (annoying customers and triggering fraud flags) or under-retry (losing recoverable transactions).

Dunning that does not feel like dunning. Customer-facing communication is the difference between a card-update completion and a churn event. The vertical SaaS knows their customer better than any horizontal provider does; the platform should control the tone and timing of that outreach.

Account updater is the foundation. Without it, the other two are recovering from a problem that did not have to exist. Our updater is the foundation we recommend turning on first.

Vertical SaaS is, by definition, not one market. The implementation patterns differ enough that "vertical SaaS payments" is too coarse to be useful as a category. The patterns we see most often:

Field service and home services. Mobile-first workforces. Card-present matters from day one because the technician is at the customer location. Tap-to-pay on a phone is often the first hardware. Recurring is common for maintenance plans, but the core flow is per-job invoicing with card-on-file.

Healthcare and practice management. A mix of patient-pay and insurance-eligible transactions. The payment surface needs to support patient statements, recurring payment plans for procedures, HSA/FSA card handling, and clear receipts that match the insurance EOB. Privacy and compliance posture matter more than in other verticals.

Fitness and wellness. High-volume, low-ticket recurring. Aggressive trial-to-paid funnel. Strong account-updater dependency because the membership economics break quickly when retention slips. Card-present matters at the front desk; tap-to-pay matters for guest check-ins.

Education and training. Tuition payment plans, recurring class fees, parent-paying-for-student patterns. The merchant-of-record is often a school or program, not the platform; reporting needs to surface both ends of the relationship cleanly.

B2B SaaS and professional services. Larger ticket sizes, ACH-heavy. Net terms common. Recurring billing with extended dunning windows. Level 3 processing matters for commercial-card payers — see our Level 3 page for the interchange math.

Each of these has different defaults. Each ships on the same gateway primitives, configured to fit the vertical. The product decision for the vertical SaaS is not "which provider" but "which provider lets me configure for my vertical without rebuilding."

Vault portability is the single underrated feature of a payments platform for vertical SaaS. The cost of leaving a payment provider is in the vault, not the API. An API can be re-implemented in two to four weeks; a vault that cannot be exported means asking every active subscriber to re-enter their card.

"Exportable" has a specific meaning. The vault data — platform tokens, customer records, payment-method metadata, and the underlying card data needed to re-instantiate the vault elsewhere — can be exported in a structured format and imported into another PCI-compliant vault at a different provider. The provider performs the export when asked, on a reasonable timeline, without making it a commercial weapon.

This matters for vertical SaaS specifically because the platform may outgrow a payment provider partway through its life cycle — not because the provider failed, but because the platform's economics changed. A platform that starts at $1M in payments volume and scales to $1B has fundamentally different leverage and different alternatives at the second number than the first. The platform that locked into a non-portable vault at $1M does not have that leverage; the platform that retained vault portability has a real choice.

Our vault is exportable by design. Not because we expect partners to leave — and the structural reasons partners choose us tend to keep them — but because non-portable vaults are a lock-in pattern that does not align with how we want to do business.

The vertical SaaS that started online almost always adds card-present. The platform that started card-present almost always adds online. The vertical SaaS that started with one-time payments almost always adds recurring. The patterns converge: vertical platforms eventually need every channel.

Most payment providers are good at one of card-present, online, and recurring; serviceable at a second; weak at the third. The vertical SaaS that picks based on what works today ends up vendor-swapping when the second and third channels are needed at production quality.

Fluid Pay runs all three on the same stack. The same vault stores the card-on-file used in recurring, the card used online, and the card used in person — they are the same customer, the same record, the same reporting. The recurring engine, the hosted-fields SDK, and the EMV-and-tap-to-pay terminal stack share the customer model. The vertical SaaS picks once.

The economic problem with most vertical SaaS payment integrations is that the unit economics get worse as the platform scales — exactly opposite to how a SaaS business is supposed to work. Tier breaks, growth charges, hidden processor margins, and "platform fees" that escalate with merchant count compound until the payments line stops being profit-positive.

Our pricing is the inverse. A flat monthly platform fee, a fixed per-transaction processing margin, no per-merchant license, no growth charge. As you scale, your unit margin improves because your absolute platform-fee spend becomes a smaller fraction of your processing revenue. We make money when you process more — not when you process more and we layer additional charges on top.

For vertical SaaS specifically, this matters because the payments revenue line tends to grow faster than the subscription revenue line once embedded payments is meaningfully turned on. A pricing structure that taxes that growth is a strategic mistake disguised as a vendor decision.

The most common migration we see in vertical SaaS is off Stripe Connect. The pattern is consistent: the platform built on Connect early because the integration was fast and the brand was respected, hit a constraint (Connect Standard's economics, Connect Express's control limits, or the absence of true white-label), and decided to retain merchant ownership rather than continue ceding it to Stripe.

The migration is a project, not a turnkey operation, but it is bounded. Vault data comes across in a structured handoff — the cards on file in Connect can be migrated to our vault without forcing customer re-entry. The API surface is rewritten on top of our REST endpoints in two to four weeks for a typical mid-complexity integration. The recurring schedules, customer records and saved methods survive the migration intact.

The commercial flip is what matters. Where the platform was paying Stripe a per-transaction fee plus the Connect application fee structure, the platform now collects the residual margin between merchant rates and processor cost. For a platform processing meaningful volume, the math turns net-positive in the first quarter of the new arrangement.

The right time to migrate is before the volume is so large that the migration project itself becomes a multi-quarter undertaking. We have run this migration with vertical SaaS partners ranging from low-eight-figures to low-nine-figures in annual processing volume; both ends complete within a single quarter when scoped well.