# What happens to the payment gateway when migrating a store? > When you migrate a store, your payment gateway account stays yours, because the gateway is a separate service that holds your merchant relationship, so you do not lose it; you reconnect it to the new platform. That means adding your gateway API keys to the new store, reconfiguring the webhooks that tell your store when a payment succeeds or fails, and then testing checkout thoroughly before launch, because a store that cannot take payment is worse than one with a few broken links. Keeping the same gateway is the smooth path: the merchant account, payout setup, and any stored payment methods stay in place, and you are simply pointing a new storefront at the same processor. The one thing you never skip is testing a real transaction end to end before customers rely on it. WPBuildAI reconnects your gateway to the new store, reconfigures the webhooks, and tests checkout end to end before cutover, so payments keep flowing without interruption. Source: https://wpbuildai.com/what-happens-to-payment-gateway-when-migrating-a-store/ By lawrence-arya ยท 2026-06-29 --- When you migrate a store, your payment gateway account stays yours, because the gateway is a separate service that holds your merchant relationship, so you do not lose it; you reconnect it to the new platform. That means adding your gateway API keys to the new store, reconfiguring the webhooks that tell your store when a payment succeeds or fails, and then testing checkout thoroughly before launch, because a store that cannot take payment is worse than one with a few broken links. Keeping the same gateway is the smooth path: the merchant account, payout setup, and any stored payment methods stay in place, and you are simply pointing a new storefront at the same processor. The one thing you never skip is testing a real transaction end to end before customers rely on it. WPBuildAI reconnects your gateway to the new store, reconfigures the webhooks, and tests checkout end to end before cutover, so payments keep flowing without interruption. ## The gateway is a separate service you keep The reassuring foundation is that the payment gateway is not part of your website. It is an external service, your card processor, that holds your merchant account, your payout relationship, and often your stored payment methods, and your site simply talks to it through an integration. So when you change website platforms, the gateway account does not go anywhere; you are only changing which storefront connects to it. This is why keeping the same gateway is the smooth path: everything the gateway holds, the merchant relationship, the payout schedule, the compliance status, stays exactly where it was, and the migration becomes a matter of reconnecting rather than rebuilding. Understanding that the gateway is separate is what turns a scary-sounding topic into a manageable reconnection task. ## Reconnecting means keys and webhooks The mechanics of reconnection are specific and worth doing carefully. You add your gateway API keys to the new platform's payment settings, which is what lets the new store initiate charges through your account, following the gateway's own integration guidance, such as the [payments documentation](https://stripe.com/docs/payments) for a processor like Stripe. Then you reconfigure the webhooks, the messages the gateway sends back to tell your store that a payment succeeded, failed, or was refunded, so orders update correctly. Confirm that currencies, enabled payment methods, and any fraud or 3D Secure settings match how you ran before. Keys initiate the charge and webhooks report the result, so both halves have to be right, or you get charges with no order updates, or orders that never confirm. ## Testing checkout is non-negotiable If there is one rule for a store migration, it is that you test checkout before launch, because a broken checkout is the worst outcome there is. A store with a cosmetic glitch still sells; a store that cannot take money does not, and the failure can be silent, an order that looks placed but never charged, or a charge that never becomes an order. Payment has several moving parts that all must align, so a real end-to-end test, placing an actual transaction, confirming the charge in the gateway, seeing the order created, and watching the webhook update its status, is the only proof that money flows. This is the highest-stakes case of the general rule that you [test a migration before going live](/how-to-test-a-migration-before-going-live), and it is why checkout gets tested last and most thoroughly, right before cutover. ## Keep the same gateway, especially with subscriptions Changing gateways during a migration is where stores get into trouble, and the advice is simple: do not, unless you have a deliberate plan. Reconnecting your existing gateway keeps stored payment methods and, crucially, any recurring billing intact, whereas switching gateways forces the hard problem of moving payment tokens between merchant accounts. That problem is acute for [subscriptions](/what-happens-to-woocommerce-subscriptions-after-migration), whose renewals depend on those tokens, so bundling a gateway switch into a platform move risks breaking recurring revenue on top of everything else. If a gateway change is genuinely necessary, treat it as its own project with the providers' involvement, separate from the platform migration. One change at a time keeps the money side stable while you move the storefront. ## Security and going live cleanly A couple of final points keep the launch clean. Payment security is largely the gateway's job, which is part of why you keep it: the gateway handles card data under [PCI standards](https://www.pcisecuritystandards.org/), so your new storefront should continue to hand off payment to the gateway rather than touching card details directly. And sequence the go-live so the gateway is fully connected and tested before real traffic hits the new store, which ties into doing the [staging-to-live cutover cleanly](/does-pushing-staging-to-live-affect-seo). The platform change itself carries no ranking penalty, as the [Backlinko analysis](https://backlinko.com/search-engine-ranking) shows and any [careful site move](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) confirms, so the commercial risk in a store migration is concentrated in checkout, not SEO, which is exactly why checkout deserves the most testing. ## Steps to handle the payment gateway in a migration 1. **Keep the same gateway account**, since it is separate from your platform. 2. **Add your API keys** to the new store's payment settings. 3. **Reconfigure webhooks** so payment status flows back to orders. 4. **Match currencies, methods, and fraud or 3D Secure settings** to your old setup. 5. **Test a real transaction end to end**, including the order and the webhook. 6. **Sequence go-live** so the gateway is connected and tested before real traffic. ## Worked example: a checkout that just kept working Consider a store that processed all payments through one gateway and worried the migration would jeopardize its ability to take money. In practice the gateway account was untouched; the team simply added the API keys to the new platform, reconfigured the webhooks so orders would update on payment, and matched the currency and fraud settings. Before launch they placed a real test order, watched the charge appear in the gateway dashboard, confirmed the order was created, and saw the webhook mark it paid. Only then did they cut over to the new store. Customers noticed nothing except a faster site, payments flowed exactly as before, and because checkout had been proven end to end, the highest-risk part of the migration was also the most boring. ## Limitation: gateway-specific steps and gateway changes vary It is honest to bound this. Reconnecting a gateway is straightforward in principle, but the exact steps, where keys live, how webhooks are registered, which settings exist, vary by gateway and by the new platform, so follow your specific provider's integration guidance rather than a generic recipe. And if you must switch gateways, that is a materially harder change, particularly for stored methods and subscriptions, and should be planned as its own project with the providers. Some fraud, tax, or region settings may also need reconfiguring rather than transferring. So treat gateway reconnection as reliable but detail-driven, lean on your provider's docs, and never let a gateway switch ride along casually with a platform move. ## Key points When you migrate a store, the payment gateway account stays yours, because the gateway is a separate service holding your merchant relationship, so you reconnect it to the new platform rather than losing it. Reconnecting means adding your API keys, reconfiguring the webhooks that report payment status, and matching currencies, methods, and fraud settings to your old setup. Then test a real transaction end to end, since a broken checkout is the worst thing a store migration can do and its failures can be silent. Keep the same gateway, especially with subscriptions whose recurring tokens are hard to move, and treat any gateway change as a separate, planned project. The commercial risk sits in checkout, not SEO, so checkout earns the most testing, and gateway-specific steps mean following your provider's own guidance. WPBuildAI reconnects your gateway to the new store, reconfigures the webhooks, and tests checkout end to end before cutover, so payments keep flowing without interruption. Send your web address for a free analysis. Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.