Staging copies and store moves raise the same three questions: which FedEx environment the copy is talking to, whether test traffic can create real labels, and what needs updating when the domain changes. This page answers all three with what the plugin actually does — no guesswork.

​
Sandbox vs production: the one switch that matters

Every FedEx call the plugin makes goes to one of two FedEx hosts, chosen by the Environment setting on the Account tab (Fedex → Settings → Account):
  • Sandbox — FedEx’s test host. Credentials are free, rates are simulated, and labels are real PDFs that never enter the FedEx network. Nothing you do here costs money or creates a real shipment.
  • Production — your real FedEx account. Labels are billable shipments.
A staging copy of your store has its own database, so it has its own copy of this setting. The safest staging setup is: sandbox credentials + Environment: Sandbox. A staging store on sandbox credentials physically cannot create a billable shipment.
Copying a production site to staging copies its saved credentials too. If you leave production keys on the staging copy, test orders there will create real shipments on your FedEx account. Switch the staging copy to sandbox keys, or at minimum to the Sandbox environment, before letting anyone click around.

​
Staging mode: log FedEx calls without changing checkout (advanced)

For SOAP→REST migrations and risky changes, the plugin has a developer-facing staging mode toggle. When enabled, it records the rate requests the plugin makes into a rolling diagnostic log so you can inspect them; it does not change what customers see at checkout. It has no admin screen — toggle it with WP-CLI:
The log holds the last 100 entries and is stored in the site’s database. Turn the toggle off when you finish diagnosing. See the SOAP migration guide for the migration context this tool was built for.

​
Moving your store to a new domain

The WordPress.org edition of the plugin has no domain locking and no license server — settings live in your site’s database and move with it. After a domain move, three things need attention:
  1. Tracking webhooks point at your old domain. FedEx pushes tracking updates to the webhook URL configured under Fedex → Settings → Tracking (your site’s REST webhook endpoint). After the move, update the webhook subscription on the FedEx developer portal to the new domain’s URL — see Tracking webhooks for the full setup. Until you do, tracking updates stop arriving (everything else keeps working).
  2. Labels already on the server stay put if uploads move with the site. Label PDFs are stored under wp-content/uploads/ and referenced from order records. Copy wp-content/uploads as part of the migration and order pages keep working; leave it behind and old labels will no longer be downloadable.
  3. Re-test after the move. Place one sandbox (or low-value production) order and confirm a label creates and a tracking event arrives — the same two-minute check recommended after every update (see Updating the plugin).

​
Cloning or duplicating a store

Running two live stores from one FedEx account? The plugin does not block entering the same FedEx credentials in two installations — each store keeps its own credentials and its own counters. Whether FedEx’s terms allow sharing one account across stores is a question for FedEx, so confirm with them before relying on it (see the FAQ). For a temporary clone (testing a redesign, debugging an order), follow the staging rules above: sandbox credentials, Sandbox environment, and staging mode if you need the request log.

​
Multisite

The plugin is not advertised for WordPress multisite. It can be installed network-wide and its uninstall routine cleans up every site in the network, but day-to-day multisite behavior (per-site settings, network admin integration) is not something the documentation covers — test it on your own setup before committing.