You've just migrated your WooCommerce store to a new host. The site looks identical. Products are there, the checkout loads — but payments aren't going through. Customers are abandoning at the payment step, or worse, being charged while orders stay stuck on pending.
This is one of the most consistent patterns we see: a technically successful migration that silently breaks payment processing. The store owner assumes everything carried over. The payment gateway assumes it's still talking to the old server. Neither is correct — and customers pay the price.
This guide covers every reason WooCommerce payments fail after a migration, in the order you should check them, with specific fixes for Stripe, PayPal, and WooPayments.
Why migration breaks payments specifically
A site migration changes more than just the server. Depending on how it was done, it may have changed the domain, the SSL certificate, the server IP address, the PHP version, the database credentials, and the URL structure — any one of which can silently break payment processing.
Payment gateways are particularly sensitive to these changes because they rely on precise, verified communication between their servers and yours. Here's what a migration touches that gateways care about:
The two most common causes by a significant margin are webhook URL mismatch and SSL certificate issues. Start there.
The webhook problem — the most common cause
When a customer completes a payment, the gateway (Stripe, PayPal, etc.) sends a small HTTP request — called a webhook — to your WooCommerce store confirming the payment succeeded. WooCommerce receives this, moves the order to Processing, and fires the confirmation email.
Webhooks are sent to a specific URL — the one registered in your gateway account when the plugin was first set up. If your domain changed during the migration, that URL now points to a server that no longer exists. The webhook fires, fails silently, and every order stays stuck on pending.
How to check if webhooks are failing
Check your gateway's webhook log
In Stripe: go to Developers → Webhooks → your endpoint → Recent deliveries. Failed deliveries show the HTTP status code returned — a 301, 404, or 0 (connection refused) confirms the webhook URL is wrong or unreachable.
In PayPal: go to Account Settings → Notifications → Webhooks and check the event log.
Check what URL is registered
In Stripe, the webhook endpoint URL is shown in the Webhooks section. Compare it to your current domain. If it shows the old domain or an HTTP URL instead of HTTPS, that's your problem.
Check WooCommerce for the endpoint URL
In WordPress, go to WooCommerce → Settings → Payments → [your gateway] → Manage. Look for a webhook URL field. Copy it and compare to what's registered in your gateway account.
Fixing a broken webhook URL
The fix depends on which gateway you're using. In all cases the principle is the same: update the webhook endpoint in your gateway account to match your current domain.
Go to Stripe Dashboard → Developers → Webhooks. Delete the old endpoint and create a new one pointing to your current domain. The correct URL format is https://yourdomain.com/?wc-api=WC_Stripe or whatever WP Admin shows.
After creating the new endpoint, Stripe generates a new Signing Secret. Copy it and paste it into WooCommerce → Settings → Payments → Stripe → Webhook Secret. Without this update, Stripe's webhook signature verification will fail even with the correct URL.
PayPal uses IPN (Instant Payment Notification) rather than webhooks. Go to PayPal Account → Account Settings → Notifications → Instant Payment Notifications. Update the notification URL to your new domain.
Also check WooCommerce → Settings → Payments → PayPal → IPN Email Notifications — ensure the email matches your PayPal account email exactly.
WooPayments registers webhooks automatically when connected. After a migration, the connection may be stale. Go to WooCommerce → Settings → Payments → WooPayments and check the connection status. If it shows as disconnected or erroring, disconnect and reconnect — this re-registers the webhook with the correct URL automatically.
SSL certificate — the second most common cause
Payment gateways require a valid SSL certificate on your store's domain before they'll send webhooks or process payments. A new host means a new SSL certificate — and until that certificate is properly provisioned and verified, gateways may refuse to communicate with your store.
Signs of an SSL problem
- Stripe webhook deliveries show status
0or a connection error - Customers see a browser warning at checkout
- WooCommerce → Status shows an SSL error
- Your site URL still shows HTTP rather than HTTPS
How to fix it
Verify the certificate is installed
Visit SSL Labs and run a test against your domain. It will confirm whether the certificate is valid, who issued it, and when it expires. An A or A+ rating means SSL is fine — look elsewhere for the payment fault.
Check your WordPress URL settings
Go to Settings → General. Both the WordPress Address and Site Address should begin with https://. If either shows http://, update them — but be careful, this can lock you out if SSL isn't actually working yet.
Force HTTPS if needed
If the certificate is valid but some pages still load over HTTP, add this to your .htaccess file to force HTTPS site-wide:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]API keys — verify they carried over correctly
Your gateway API keys live in the WordPress database and should transfer intact during a clean migration. However, there are a few scenarios where they can become invalid post-migration.
Scenarios where API keys break after migration
- The migration was done by an agency or developer who used their own Stripe/PayPal test account during development. Their test keys transferred — not your live keys.
- You're in test mode. The plugin carried over test API keys and the live/test toggle wasn't switched back. Test mode accepts test card numbers only.
- The keys were stored encrypted and the encryption salt changed on the new host — rare but possible with some security plugins.
How to verify your API keys
Go to WooCommerce → Settings → Payments → [your gateway] → Manage. Check whether you're in live or test mode. Copy the publishable key and verify it against what's shown in your gateway dashboard under API Keys. A live key starts with pk_live_ for Stripe — if you see pk_test_, you're in test mode on a live store.
23 orders charged but never completed — Stripe webhook broken after domain change
A UK health supplements retailer migrated to a new host and immediately saw customers emailing to say they'd been charged but had no order. Their WooCommerce dashboard showed 23 orders stuck on Pending Payment.
→ WooCommerce orders all pending
→ Stripe webhook log delivery failures on all recent events
→ Webhook endpoint URL pointing to old domain (HTTP redirect)
→ Root cause: webhook URL not updated after domain change — Stripe receiving HTTP 301
Stripe was sending webhooks to the old domain, which now redirected to the new one. Stripe doesn't follow redirects — it treats a 301 as a failure. Every webhook failed, every order stayed pending.
We updated the webhook endpoint in Stripe, regenerated the signing secret, updated it in WooCommerce, and replayed all 23 failed webhook events. Every order completed automatically — no refunds, no repeat charges, no customer impact.
Recovering orders that are already stuck
If you have orders that went stuck on pending during the period when payments were broken, don't immediately refund them. Most are recoverable.
Stripe — replay failed webhooks
Stripe retains webhook events for 72 hours and allows manual replay. Once you've fixed the webhook endpoint and signing secret, go to Stripe → Developers → Webhooks → your endpoint → Recent deliveries. Find the failed events and click Resend on each one. WooCommerce will receive the confirmation and complete the order automatically.
For events older than 72 hours, you can manually complete orders using the payment intent ID. In Stripe, find the payment, copy the Payment Intent ID, then in WooCommerce manually update the order status to Processing and add the payment intent ID to the order notes for your records.
PayPal — manual IPN resend
PayPal's IPN History tool (in your PayPal account under Notifications) allows you to resend IPN messages for transactions. Find the affected transactions and resend the IPN — WooCommerce will process them and complete the orders.
WooPayments — contact support
WooPayments doesn't have a self-service webhook replay tool. Contact WooPayments support with the affected order IDs — they can trigger the payment confirmations from their side.
Gateway-specific migration issues
Beyond webhooks and SSL, each gateway has its own migration-specific gotchas worth knowing.
Stripe
3D Secure / SCA configuration — Stripe's SCA settings are domain-specific. After a domain change, verify that your Stripe account's authorised domains include your new domain. Go to Stripe → Settings → Payment methods → Card → Domain registration.
Stripe Radar rules — if you had custom fraud rules in Stripe Radar, verify they're still configured correctly. Rules that block specific countries or card types can create apparent payment failures that are actually intentional fraud blocks.
PayPal
Return URL — after a PayPal payment, customers are redirected back to your store. This URL is configured in PayPal's settings and must match your new domain. Go to PayPal Account → Account Settings → Website payments → Website preferences and update the Auto Return URL.
PayPal Express Checkout credentials — if using PayPal Express, the API credentials (API Username, Password, Signature) are account-specific and should have transferred intact. Verify them against your PayPal account under Account → API Access.
WooPayments
WordPress.com connection — WooPayments requires a connection to WordPress.com (Jetpack). After migration, this connection may be stale or broken. Check Jetpack → Dashboard — if it shows as disconnected, reconnect it. WooPayments will re-establish its connection automatically once Jetpack is connected.
Account verification — if your store's domain changed, WooPayments may require re-verification of the domain as part of Stripe's fraud prevention. This can temporarily pause payouts while verification completes.
The pre-migration payments checklist
If you're planning a migration — rather than fixing one that's already happened — this checklist covers every payment-related step that's commonly missed.
Quick reference — migration payment failures
| Symptom | Cause | Where to fix |
|---|---|---|
| Orders stuck on pending, customers charged | Webhook URL still points to old domain | Update endpoint in gateway dashboard, update signing secret in WooCommerce |
| Stripe webhook shows HTTP 301 | Old domain redirecting — Stripe doesn't follow redirects | Update webhook to new domain directly, not via redirect |
| Gateway refuses to connect | SSL certificate not provisioned on new host | Enable SSL in hosting control panel, force HTTPS in .htaccess |
| Payments failing with "invalid key" error | Test keys transferred instead of live keys, or test mode active | Switch to live mode in WooCommerce payment settings, verify keys against gateway dashboard |
| WooPayments shows disconnected | WordPress.com / Jetpack connection stale after migration | Reconnect Jetpack, WooPayments reconnects automatically |
| PayPal customers not returning to store | Return URL still set to old domain in PayPal | Update Auto Return URL in PayPal account settings |
| Payments working but webhook signature failing | Old signing secret in WooCommerce after new endpoint created | Regenerate signing secret in Stripe, paste into WooCommerce settings |
Preventing this on future migrations
Payment failures after migration are almost entirely preventable. The core principle is to treat payment gateway configuration as a separate step — not something that automatically carries over with the rest of the site.
- Always test payments before reopening the store. Place a £1 real order, verify end-to-end, then refund it. This catches webhook and SSL failures before customers do.
- Use a staging environment. Migrate to staging first, run a full payment test with test credentials, then go live. Most hosts offer staging environments.
- Keep a record of all gateway configuration. Webhook URLs, API key types (live vs test), and which email addresses are associated with gateway accounts. This makes post-migration verification much faster.
- Don't accept payments during the migration window. Put the store in maintenance mode. An order that starts on the old server and completes on the new one is a support problem waiting to happen.
- Verify webhook delivery immediately after go-live. In Stripe, send a test webhook from the Dashboard after updating the endpoint. Confirm it shows as delivered before you reopen for orders.
Migration done and payments still broken?
If you've worked through this guide and payments still aren't processing — or if you have stuck orders that need recovering — we fix migration payment failures daily. Same-day response, flat rate, no fix no fee.
Summary
WooCommerce payment failures after a migration almost always come from one of two places: the webhook endpoint URL wasn't updated in the gateway account, or the SSL certificate wasn't provisioned on the new host. Both are fixable in under an hour once identified.
The pattern is consistent enough that if your migration broke payments, checking the Stripe webhook log first will tell you in under two minutes whether you have a webhook URL problem. That single check resolves the majority of post-migration payment failures.
If you have orders that are already stuck on pending, check whether recovery is possible before refunding — Stripe's webhook replay covers events from the past 72 hours and can complete stuck orders without any customer impact.