Stripe webhooks after a host or domain move

Why webhooks are the part of a migration members notice

For a membership or course site, Stripe webhooks are how renewals, failed payments, refunds and cancellations reach WordPress. Stripe describes webhooks as the way to respond to asynchronous events, such as when a recurring payment succeeds or a customer disputes a charge. If those deliveries fail after a move, the payment still happens in Stripe, but the member's access in WordPress may not be extended, or a cancelled member may keep access.

Stripe requires registered webhook endpoints to be publicly accessible HTTPS URLs, and you can register up to 16 event destinations. Each endpoint has its own signing secret beginning with whsec_. Stripe says it generates a unique secret key for each endpoint, and if you use the same endpoint for both test and live API keys, the secret is different for each one. A migration that copies the database usually carries the plugin's stored secret along, which is what you want when the URL is unchanged.

Host move, same domain

When the domain stays the same, Stripe keeps sending to the same URL and DNS decides which server receives it. Three things can still break deliveries. First, TLS: Stripe says it requires TLS v1.2 or higher and a valid certificate, and a TLS error is listed as a delivery failure. Second, access rules: a 4xx response, which Stripe says can come from access restrictions (401, 403, 405) or a missing URL (404), often means a firewall, security plugin or basic-auth staging lock on the new host is rejecting the POST. Third, timing: Stripe says your endpoint must quickly return a 2xx status before any complex logic that could cause a timeout.

The subtler risk is the DNS transition window. During that time some deliveries may reach the old host, which will return 200 and record the renewal in a database you are about to abandon. Stripe will consider those delivered and will not retry them. Freeze or disable payment processing on the old site at cutover, and afterwards reconcile events created during the window against the new site.

Domain change: the endpoint must move

Stripe's delivery table lists 302 and other 3xx statuses as errors and states that redirect responses to webhook requests are treated as failures; its fix is to set the webhook endpoint destination to the URL resolved by the redirect. A sitewide 301 from the old domain therefore does not keep webhooks working. Update the endpoint, then confirm deliveries show as Delivered in the Event deliveries tab in Workbench.

MemberPress documents a specific sequence for moving to a new domain. Its Stripe documentation says to disconnect the Stripe payment gateway rather than delete it, and then reconnect it, noting that reconnecting will update your webhooks to use the new domain. It also warns, in capitals, Do NOT delete your Stripe gateway and recreate it, and cautions that disconnecting Stripe on a cloned staging site can remove the live webhook. MemberPress webhook URLs follow the form https://yoursite.com/mepr/notify/xxxxxx-xxx/whk.

WooCommerce's Stripe extension only uses webhook endpoints in the format https://www.example.com/?wc-api=wc_stripe. WooCommerce says webhooks are automatically set up when you connect to Stripe from version 8.6.1, and its Reconfigure webhooks option will recreate the correct webhooks in your Stripe account and remove any old ones that were pointing to your site. Check that both live mode and test mode webhooks show as configured.

Retries, resends and recovering missed events

Stripe says it attempts to deliver events for up to three days with exponential back off in live mode, and retries sandbox deliveries three times over the course of a few hours. If the destination is disabled or deleted when a retry is due, future retries of that event stop. In the Dashboard you can click Resend on an event for up to 15 days after creation, and the Stripe CLI can resend for up to 30 days.

For a larger recovery, Stripe documents calling the List Events API with delivery_success set to false to return only events that failed delivery, and notes that it only returns events created in the last 30 days. Because Stripe does not guarantee delivery order and endpoints might occasionally receive the same event more than once, your handler should skip events it has already processed. Before replaying events manually, confirm whether your membership plugin skips events it has already processed, and check member records afterwards.

Webhook checklist for cutover day

• Before: list every Stripe endpoint in Workbench, the plugin that owns it, and whether it is live or test mode.
• Before: confirm the new host serves a valid certificate for the domain and that security rules allow POST requests to the webhook path.
• At cutover: stop payment processing on the old site so it cannot acknowledge events into the old database.
• Domain change: reconnect the gateway (MemberPress) or reconfigure webhooks (WooCommerce) after the new domain is live.
• After: trigger a test event in a sandbox and check the Event deliveries tab shows Delivered.
• After: review failed events with delivery_success=false and resend or replay within the retry and resend windows.

Sources & verification

Product details and prices can change. Check the linked provider before buying.

1. Stripe Docs: Receive Stripe events in your webhook endpoint Accessed 13 Oct 2026
2. Stripe Docs: Manage webhook endpoints (process undelivered events) Accessed 13 Oct 2026
3. MemberPress Docs: Stripe Accessed 13 Oct 2026
4. WooCommerce Docs: Stripe webhooks Accessed 13 Oct 2026