A successful WooCommerce Blueprint import does not mean the new store is ready to accept payments. Treat gateway setup as a separate, verified step rather than assuming payment credentials were copied with the store configuration.
Why the export differs
WooCommerce 11.2 removes payment settings from Blueprint exports; the old payment-gateway export step no longer provides them. The official advisory calls for gateway setup after import. This is different from an import failing because the user lacks permissions, covered in the multisite import guide.
Before importing, write a target-store checklist: destination URL, expected merchant account, currency, test or live mode, enabled methods and the person authorized to connect each account. Do not put secret keys into the checklist or commit them with a reusable Blueprint.
Separate configuration from authorization
Install the intended gateway extension from its trusted source. Then connect the destination store using the vendor's supported flow and an appropriately authorized account. Copying another store's option rows can silently connect the wrong business or leave callbacks pointing at the old domain.
Check visible account identifiers and operating mode without exposing credentials in screenshots. Two stores can have identical gateway names while using different merchant accounts. Conversely, the same account can have distinct webhook endpoints and signing secrets for each environment.
Account: Correct merchant and mode. Callback: Target environment only. Order: Expected status exactly once. Secrets: Never store in the Blueprint. Explanatory checklist, not a customer test result.
Test the complete payment lifecycle
Use the provider's sandbox on staging. Do not move a test store into live mode just to make the payment button appear.
- Confirm a guest can see the intended method with the expected currency and address conditions.
- Submit one supported test payment and retain its order ID and provider transaction reference.
- Check the destination of the return URL and the webhook delivery. They should belong to the target environment.
- Verify that the WooCommerce order reaches the expected state once. A payment-provider success page alone does not prove the order updated.
- Exercise a sandbox decline and a supported refund case. Confirm no genuine customer email or fulfillment job is triggered.
Diagnose missing methods narrowly
| Symptom |
Check first |
| Gateway absent from settings |
Extension installed and active |
| Enabled method absent at checkout |
Currency, location, checkout type and eligibility |
| Payment succeeds but order stays pending |
Callback destination, authentication and delivery |
| Wrong merchant sees the transaction |
Account connection and environment configuration |
Do not regenerate every webhook secret while investigating a display issue. A broad reset can break a working production callback even when the imported store is the only one under test.
Production handoff
Require an explicit review of account identity, mode, live callback URL and the approved production payment-test procedure. Remove test-only fulfillment settings deliberately; do not assume an import or a mode toggle restores them.
Record which settings were imported and which were configured afterward, with a responsible owner for each. That record makes the next store launch repeatable without turning payment credentials into shared template data. For a store that accepts payment but fails to update orders, HandL WP can investigate the gateway handoff.
References reviewed October 16, 2026. Examples are explanatory, not customer test results.