Stripe is our default payments rail.

Q: Do you build custom Stripe integrations or use Stripe Checkout?

Both, chosen per project. Stripe Checkout is excellent when a hosted payment page fits the flow, and it carries the least PCI scope and maintenance. We build custom flows with Payment Intents and Elements when checkout is part of the product experience: multi-step carts, saved payment methods, or platform splits with Connect. Either way the order state is driven by webhooks, not by the browser.

Q: Can you migrate our billing to Stripe without breaking subscriptions?

Yes. Subscription migrations run as a controlled import: existing customers and payment methods move through Stripe's migration tooling with the issuing processor, renewal dates carry over, and the cutover is sequenced so no customer is billed twice or dropped. We have run the same playbook in the other direction too, off Stripe and onto specialist rails, when underwriting required it.

Q: What if Stripe will not approve our business category?

Then we build on a rail that will. We integrate NMI and Bankful for categories outside mainstream underwriting, with the same checkout quality and the same webhook-driven order state. If there is any chance your category is restricted, we confirm underwriting in writing before a line of payment code is written.

The payments layer behind most of what we ship: checkout, subscriptions, billing, and revenue splits. When a business model fits mainstream underwriting, Stripe is where we start.

stripe.com ↗

How we use Stripe

Stripe handles payments on most of our SaaS and commerce builds. We integrate it server-side behind small, typed modules: Checkout or Payment Intents for one-time purchases, Billing for subscriptions, and Connect when a platform needs to split revenue between parties, the way our creator-platform builds pay out storefront owners automatically. Card data goes straight to Stripe so PCI scope stays inside the payment provider, webhooks drive order state in our applications, and Radar handles fraud scoring before a charge ever settles. On Medusa builds Stripe slots in as the payment provider while the commerce engine orchestrates the order.

The best payments stack is the one that never becomes the reason the business stops.

Why Stripe

Stripe earns the default slot the same way our other defaults do: the developer experience is the best in the category, the API contract is stable, and the vaulting, billing, and payout primitives cover most business models without custom infrastructure. It is also the rail every future hire already knows. The honest limit is underwriting: Stripe is conservative about restricted categories, and a merchant it will not approve, or later offboards, needs a different rail entirely. That is why payments at ComCreate is a portfolio decision, not a single-vendor loyalty. Stripe by default, specialist rails when the category demands them.

Stripe integration for SaaS and commerce

A Stripe integration is an application-architecture problem more than an API problem. The card form is the easy part; the work that decides whether billing is trustworthy is everything around it. We treat webhooks as the source of truth, so a subscription state or an order status changes only when Stripe says it did, never because the browser claimed success. Every event handler is idempotent, because Stripe redelivers, and every payment object carries our own IDs in metadata so support can trace a charge to an order in one lookup. Entitlements live in our database and sync from billing events, which means a failed renewal downgrades access automatically and a recovered payment restores it without a human in the loop. That discipline is identical whether the front of the flow is Stripe Checkout, a custom cart, or a Medusa storefront.

Our application development service How we build on Medusa

Where Stripe ends: restricted categories

Stripe is the right rail for the mainstream, and we recommend it without hesitation there. But its underwriting excludes whole categories: smoke-adjacent products, CBD and hemp, many supplements, and other businesses that are legal, legitimate, and still outside mainstream risk appetite. For those clients we build on rails that underwrite the category on purpose, with NMI as the gateway layer and Bankful on the acquiring side, wired into the same checkout with the same engineering discipline. The deciding question is never which processor has the best API. It is which processor will still be processing for this business in five years.

How we use NMI How we use Bankful The Philter case study

Where we use it