Replace WooCommerce Payments with DashCommerce

The “who owns the Stripe account” question

WooCommerce Payments looks like a native payment processor inside WooCommerce. It is actually Stripe, routed through Automattic’s Stripe Connect platform. When a customer pays on a WooPayments store, the charge goes to a Stripe account Automattic created on your behalf; payouts settle through Automattic’s platform arrangement; disputes flow through Automattic’s support channels before reaching Stripe.

This is a reasonable design — it means merchants never have to think about Stripe. Onboarding is a single flow inside the WooCommerce admin. Dispute UI, payout reporting, and refund flows all live in one place. For a non-technical merchant running a WooCommerce store, this reduction in surface area is the product’s entire value proposition.

DashCommerce makes the opposite bet. The whole architecture assumes you have your own Stripe account, created directly at stripe.com, and that Stripe is the only thing touching your money. There is no DashCommerce platform account. There is no Automattic-equivalent intermediary. You paste your publishable key and secret key into environment variables, webhooks point at your DashCommerce deployment, and that’s the entire integration.

The tradeoff is real and worth naming: you now have to think about Stripe. You log into stripe.com to handle disputes. You read payout reports in Stripe’s dashboard. You configure Radar rules directly on your Stripe account. DashCommerce doesn’t hide any of that — it exposes it.

What DashCommerce gives you

The payment feature set maps closely to WooPayments:

• Stripe Payment Element at checkout, supporting cards, Apple Pay, Google Pay, Link, and saved payment methods. The same component WooPayments renders, because it’s literally the same Stripe SDK.
• Hosted Checkout mode for merchants who want Stripe to own the full checkout page (useful for PCI scope reduction), plus embedded Payment Element mode for merchants who want the payment form inline with their own cart UI.
• 3DS 2 / SCA handled automatically by Stripe Payment Intents — no merchant-side configuration needed, same as WooPayments.
• Idempotent webhooks: DashCommerce persists Stripe event IDs with a unique index, so if Stripe retries a webhook (which it regularly does), the second delivery is a no-op. Duplicate charges, duplicate subscription activations, duplicate refund records all stopped at the database layer.
• Stripe Subscriptions natively, with trials, proration, upgrade/downgrade, dunning emails, and cancellation flows. No add-on required.
• Stripe Connect marketplace payouts for multi-vendor stores — platform fee, transfer_data splits, Express-account onboarding.
• Multi-currency — eight currencies built in, per-product pricing, storefront renders in the visitor’s currency and Stripe handles the conversion at settlement.
• Buy-now-pay-later methods (Klarna, Affirm, Afterpay/Clearpay) available the moment you enable them in your Stripe dashboard. DashCommerce doesn’t need to know about them individually — the Payment Element renders whatever Stripe returns.

Install is a single command: npm create @dashcommerce@latest scaffolds a full storefront with checkout, admin, and Stripe integration ready to connect. The npm package is @dashcommerce/core at v0.1.3 as of April 2026, MIT-licensed, published publicly.

Where WooPayments still wins

Being honest about this: WooPayments has UX advantages that come from being deeply integrated into the WooCommerce admin.

Dispute management in-admin. WooPayments surfaces the full dispute queue inside WP-Admin: open disputes, evidence upload, status timeline, win/loss outcomes. DashCommerce sends you to Stripe’s Dashboard for all of this. For stores with meaningful chargeback volume, the context-switch is a real productivity cost.

Payout reporting in-admin. WooPayments shows upcoming payouts, payout history, and balance directly inside WooCommerce. DashCommerce doesn’t — you check Stripe. Merchants used to seeing their payout schedule in the same place as their orders will notice this.

Fraud analytics dashboards. Radar decisions and blocklists live on Stripe’s side regardless, but WooPayments gives you a rollup view inside WooCommerce of flagged transactions with in-context approve/reject. DashCommerce surfaces Radar’s decision in order metadata but doesn’t replicate the dashboards.

Maturity. WooPayments launched in 2020 and has had five+ years of production hardening, billions in GMV processed, a large support team, and integration with Automattic’s broader merchant tooling (Capital, WooCommerce Shipping, WooCommerce Tax). DashCommerce is v0.1.3 — every payment feature works, but the payment-admin polish is genuinely thinner.

If these are important to your operations, WooPayments is still the better fit. DashCommerce is not trying to rebuild those surfaces — Stripe already has them on stripe.com, and we’d rather point you there than build a thin wrapper.

The Stripe-first architectural bet

The reason DashCommerce doesn’t build dispute UI or payout reporting or Radar dashboards inside its own admin is that Stripe has spent a decade building those surfaces, and a wrapper is always worse than the real thing. WooPayments works around this by being deeply integrated with Automattic’s Stripe Connect platform so the wrapper gets privileged access to the underlying data. DashCommerce works around it by not being a wrapper — we just use Stripe’s public APIs and let Stripe’s dashboard remain the source of truth.

What you get from the Stripe-first model:

• Portability. If you ever uninstall DashCommerce, your Stripe account keeps working. Subscriptions renew. Customers’ saved payment methods continue to charge. The only thing you lose is the DashCommerce storefront and admin — the payment relationship with Stripe is yours.
• Direct support. When something breaks in a charge or webhook, you file the ticket with Stripe directly. There’s no Automattic support queue to go through first. For technical teams, this is usually faster.
• No intermediary risk. If Automattic changes WooPayments pricing, sunsets features, or renegotiates their Stripe platform terms, WooPayments merchants inherit those changes. With direct Stripe, your contract is between you and Stripe, and nobody can insert themselves.
• Full Stripe API access. Anything Stripe can do — Issuing, Terminal, Treasury, Climate, Tax — is available to you directly. WooPayments exposes what Automattic chooses to integrate; direct Stripe exposes everything.

This is an architectural bet, not a universal win. Teams that value the integrated admin experience will feel the loss of the in-Woo UI. Teams that value direct control over the payment processor will feel the opposite.

Migration approach

Moving a live WooPayments store to DashCommerce + direct Stripe:

1. Create a direct Stripe account at stripe.com. This is new — WooPayments used a platform-created account, not a direct one.
2. Scaffold DashCommerce: npm create @dashcommerce@latest, configure environment variables with your direct Stripe keys, deploy.
3. Export catalog and customers from WooCommerce — CSVs work. Import via dashcommerce-merge-seed into the typed products collection.
4. Order history imports read-only for support lookup. No need to re-process historical charges.
5. Subscriptions are the hard part. Active WooPayments subscriptions are tokenized against Automattic’s platform Stripe account, not your new direct account. Options:
   • Request Stripe’s account transfer process (works in some cases — talk to Stripe directly).
   • Accept that customers re-authorize payment methods on first renewal after cutover. Plan for a retention dip and communicate clearly before the switch.
   • Run both systems in parallel during the transition window, new signups on DashCommerce, legacy renewals still on WooPayments, until the legacy cohort naturally ages out.
6. Disputes and payouts switch over the moment your first DashCommerce charge lands. The WooPayments dispute queue ages out as open disputes close; the Stripe Dashboard becomes the source of truth going forward.
7. Webhooks — DashCommerce sets up Stripe webhook endpoints at install time. Make sure the old WooPayments webhook endpoint stays live only long enough to finish processing in-flight legacy charges, then disable it.

Timeline: expect two to six weeks depending on catalog size and subscription volume. The catalog and customer parts are fast; the subscription cutover is where planning matters.

Honest recommendation

If you are staying on WooCommerce and WooPayments is working, stay on WooPayments. The integrated admin UI is real value, and the processing rates are identical to direct Stripe — there’s no cost win to moving for cost’s sake. This page is not trying to convince you to leave.

If you are leaving WooCommerce because your team has outgrown it, WooPayments comes along as baggage — you can’t keep it without keeping Woo. In that case, DashCommerce’s Stripe-first model is the natural replacement: direct Stripe account, your webhooks, your Dashboard, no intermediary. You give up the in-admin dispute UI and payout reporting, and you gain full control over the payment relationship.

The decision is architectural, not financial. Pick the integration model that matches how your team actually wants to operate.