Replace Stripe for WooCommerce with DashCommerce

What the Stripe plugin for WooCommerce does

The “Stripe” plugin on WooCommerce — the free one published by Stripe Inc., sometimes listed as “WooCommerce Stripe Payment Gateway” — adds Stripe as a payment method on Woo’s checkout. You connect your Stripe account, set keys, and Woo’s checkout renders Stripe’s Payment Element. It handles SCA, 3DS 2, Apple Pay, Google Pay, saved cards, and the Payment Intents flow. Webhooks sync charge status back into Woo orders. Disputes and payouts live in the Stripe dashboard.

It’s good software. It’s free. It’s Stripe’s own code. For a WooCommerce merchant who wants Stripe as their processor and doesn’t want Automattic sitting in the middle (which is what WooCommerce Payments / WooPayments gives you), the Stripe plugin is the correct choice.

It is also, by design, a payment gateway. The Woo data model — orders, line items, customer records, subscriptions via Woo Subscriptions — wraps around it. Stripe is one leg of the stack. WordPress, WooCommerce, and the add-on ecosystem are the other three.

The architectural difference with DashCommerce

DashCommerce is not a gateway. It’s a commerce plugin for EmDash CMS where Stripe primitives are the commerce primitives. Orders wrap Stripe Payment Intents. Subscriptions wrap Stripe Subscriptions. Customers wrap Stripe Customers. Payouts are Stripe payouts. Webhooks are idempotent against Stripe event IDs.

In the Woo + Stripe-plugin world, you have Woo’s notion of an order, and the plugin bridges it to a Payment Intent. That bridge is mostly reliable — Stripe’s team maintains it — but it is still a translation layer between two data models. Subscription renewals go through Woo Subscriptions’ hook system, which calls the Stripe plugin’s Payment Intent code, which calls Stripe. Refunds from Stripe’s dashboard have to be reconciled back into Woo’s order status via webhook handlers. Multi-currency support requires a Woo extension that talks to both Woo and Stripe.

In DashCommerce, the translation layer doesn’t exist because there’s nothing to translate between. An order is a Payment Intent reference. A subscription is a Stripe Subscription reference. Refunding from Stripe’s dashboard and refunding through DashCommerce’s admin are the same operation — one is just a different UI for the same Stripe call. Multi-currency works because Stripe supports it and DashCommerce doesn’t fight Stripe’s model.

Neither approach is objectively better. “Gateway inside a larger platform” and “platform shaped around the gateway” are both legitimate designs. They fit different stacks.

When the Stripe plugin is fine

If any of the following describe you, stay on the Stripe plugin:

• You run WordPress and plan to keep running it. The content side of your site is built on WordPress, your team edits in the WP admin, and your writers would revolt if you moved them to something else. Don’t move commerce just to match architecture — stay.
• Your Woo stack works. You have subscriptions via Woo Subscriptions, membership gating via Woo Memberships, shipping via a 3PL extension, tax via TaxJar for WooCommerce. The whole thing is wired up. Ripping it out to swap gateways is negative-value work.
• Your team is WordPress-native. You hire WordPress developers, use Advanced Custom Fields, and your processes depend on the WP plugin ecosystem. DashCommerce is an Astro + TypeScript world — wrong shape for you.
• You want Stripe’s own plugin specifically so Automattic isn’t in the middle. The Stripe plugin (direct Stripe account, you own it) is better than WooPayments (Automattic’s Connect platform) for teams that want nothing between them and Stripe. Keep it.

This is most merchants using the Stripe plugin, and that’s fine. The software does what it says.

When DashCommerce makes sense

The situations where replacing the Stripe plugin with DashCommerce is actually correct are narrower:

• You’re leaving WordPress anyway. This is the only case that really matters. If the broader migration — content to EmDash or another modern CMS, hosting to Cloudflare or Vercel, templates to Astro — is already happening, DashCommerce is the commerce layer shaped for that world. Moving commerce at the same time is cheaper than two separate migrations.
• You want Stripe primitives surfaced directly. If your team is building with Stripe’s API anyway — custom checkout flows, embedded Payment Elements in non-standard places, Stripe Connect marketplace payouts with complex transfer logic — fighting Woo’s abstraction over Stripe stops being worth it. DashCommerce exposes Stripe with less translation.
• You want TypeScript end-to-end. Woo + Stripe-plugin is PHP. DashCommerce is TypeScript. If your team would rather extend a typed plugin than read PHP hooks, this is a real ergonomic win.
• You want edge-native deployment. DashCommerce runs on Cloudflare Workers. WordPress does not, practically speaking. If your stack is already edge-first and WordPress is the outlier, commerce should move with it.

Outside those cases, the Stripe plugin is already solving your problem. Don’t over-engineer it.

Migration steps

If the CMS move is happening and you want the gateway to come with it:

1. Keep the same Stripe account. The publishable and secret keys you use on Woo go straight into DashCommerce settings. No Stripe-side change. Payouts, dashboard, and history continue on the same account.
2. Re-link active subscriptions. Stripe Subscriptions keep billing — they live in Stripe, not in WordPress. DashCommerce reads them back into its own subscription records via the Stripe API. No customer re-tokenization required (unlike migrating off a managed platform that holds its own Stripe Connect tokens).
3. Export Woo orders as reference data. Historical orders import into DashCommerce read-only, mostly for customer support lookup. You don’t need to re-process them.
4. Point webhooks at the new endpoint. Update the webhook URL in the Stripe dashboard from your Woo webhook endpoint to DashCommerce’s. DashCommerce uses idempotent handlers keyed on Stripe event IDs — duplicate events from a transition window are safe.
5. Run both in parallel briefly if needed. Since both clients use the same Stripe account, you can technically run Woo and DashCommerce against the same Stripe while cutting over. Most teams won’t, but the option exists.

The CMS migration itself (WordPress to EmDash, Woo templates to Astro) is the hard part. The gateway swap is mechanical.

Honest recommendation

The official Stripe plugin for WooCommerce is fine. If that’s the only thing you were planning to change, don’t. It works, it’s Stripe’s own software, it’s free, and it will keep working.

DashCommerce is the right answer when the architecture underneath is wrong — you’re leaving WordPress, you want TypeScript commerce, you’re running at the edge, or you want Stripe primitives surfaced instead of wrapped in Woo’s data model. In that context DashCommerce is the version of the Stripe-native idea that assumes you’ve already walked away from the WordPress substrate.

If WordPress is staying, stay. If it’s going, DashCommerce is shaped for the other side.