I noticed this policy change recently and has completely upended our inventory and marketing systems.
In the past, you could cancel any order - even if it’s paid or fulfilled. It’s been like this for a decade. All of a sudden, we’re now unable to cancel an order. Instead, the terrible support bot says we can only “cancel” an order by going through the return process. Why?
Use case: I create a $0 order to reship items for a customer or to ship a package internally within my company. This order is not considered a real order, so I cancel the order after it’s done. However, now that I’m unable to cancel these types of orders, my total order counts are completely off. More importantly, sales quantities are COMPLETELY off now because I can no longer cancel these orders and remove those quantities from the units sold report and CSV exports. In addition, if I follow what the bot says - to “return” these orders instead, then my ‘return’ statistics will be WAY higher than what they should be!!!
I’d like the cancel feature back. This has been something that worked for like a decade, and why did it get changed without warning? This has so many implications for accounting purposes and marketing and even fundraising, as it greatly impacts the number of orders, average order value reports, inventory numbers, and everything! Please advise a fix.
I forgot to mention - this also means all “test” orders can’t be cancelled. There are plenty of reasons for test orders (i.e. when implementing a new app, when testing out a new product, new promo code, etc…) and all those orders would need to be cancelled. Now that you can’t, all of these orders jam up the system and throws off all of the order statistic and exports.
How do you work around this?
Hi @joshroban
I totally understand your frustration; this change has hit a lot of merchants hard because it affects counts, reporting, and workflows that relied on simple cancellations.
Short version: Shopify’s cancellation behavior now depends on an order’s status (paid/fulfilled/fulfillment flow). When an order is already fulfilled or has fulfillment/return activity tied to it, Shopify often forces a refund/return workflow rather than a simple cancel — that’s to protect payouts, fulfillment pipelines, and reporting integrity. Because of that, the old “cancel anything anytime” shortcut no longer works in every case.
Practical ways to fix or work around it (pick what fits you):
-
Use Draft Orders for internal/test/reship flows
- Create $0 or internal shipments as Draft Orders (not real orders). Drafts can be deleted and won’t pollute sales, units-sold, or AOV reports.
-
Cancel before fulfillment where possible
- If the order hasn’t been fulfilled, canceling in the Admin will usually work and remove it from reports (choose refund/restock options if needed).
-
When the UI blocks cancellation: use programmatic cancel
- Shopify supports a GraphQL
orderCancel mutation that lets you cancel programmatically (refund/restock options) even when the UI is restrictive. It runs as a background job, so you may need to poll for job status.
-
If a fulfillment/return is already in progress
- The practical path is usually to issue a refund/return and then archive the order so it doesn’t appear in Open lists. To prevent reporting pollution going forward, tag internal orders (e.g.,
internal-reship) and exclude those tags when running reports or CSV exports.
-
Automate cleanup
- Use Shopify Flow (if available) or a small custom script to auto-tag and archive orders created for internal use. This prevents manual mistakes and keeps analytics clean.
Quick checklist I recommend right now:
-
Stop creating internal/test orders as normal orders — create them as Draft Orders or tag them clearly.
-
For existing messed-up counts, decide: refund+archive or try orderCancel programmatically for eligible orders.
-
Add a simple team rule: “All reship/internal orders → Draft Orders” to avoid repeat issues.
If you’d like, I can:
-
Provide a short GraphQL mutation example and a Node.js script to run orderCancel for eligible orders, or
-
Write a Shopify Flow recipe that tags and archives internal orders automatically.
Which do you prefer (GraphQL script or Flow recipe)? Also — does your store plan include Shopify Flow, and are you comfortable running a small script with API credentials?
Hi there,
Yes, can you please provide a graphQL mutation example, and include directions on where to input this.
For test orders, draft orders doesn’t work - because real tests are placed directly through the front end shopify website, as if pretending to be a real customer. Please advise how to resolve those.
Thanks
Hi @joshroban,
Great question! If you want to create test orders that mimic real customer checkouts on the storefront (not draft orders), the recommended approach is to use Shopify’s orderCreate GraphQL mutation with the test flag set to true.
Here’s a basic example:
mutation createTestOrder {
orderCreate(
input: {
test: true
lineItems: [
{
variantId: "gid://shopify/ProductVariant/1234567890"
quantity: 1
}
]
customer: { id: "gid://shopify/Customer/9876543210" }
billingAddress: {
firstName: "Test"
lastName: "Buyer"
address1: "123 Test Street"
city: "Toronto"
province: "ON"
zip: "M4B1B3"
country: "CA"
}
shippingAddress: {
firstName: "Test"
lastName: "Buyer"
address1: "123 Test Street"
city: "Toronto"
province: "ON"
zip: "M4B1B3"
country: "CA"
}
email: "test-buyer@example.com"
financialStatus: PAID
fulfillments: [
{
trackingInfo: [{ number: "123456789", company: "Test Carrier" }]
}
]
}
) {
order {
id
name
test
totalPriceSet {
shopMoney {
amount
currencyCode
}
}
}
userErrors {
field
message
}
}
}
Where to Run the Mutation
-
Go to your Shopify Admin → Apps → Develop apps.
-
Open your app and navigate to API clients → API playground (GraphiQL App) or use an API client like Insomnia or Postman with your Admin API access token.
-
Make sure the app has the write_orders scope enabled.
-
Paste the mutation above, adjust your variantId, customerId, and addresses, and execute the request.
Notes
-
The test: true flag marks the order as a test, so it won’t affect analytics or payouts.
-
For test orders via the storefront checkout, Shopify doesn’t support true “front-end” test purchases on live gateways. Instead, you can:
-
Make sure to disable Bogus Gateway after testing to resume normal payments.
This approach will let you create realistic test orders programmatically while keeping your reports clean.
If you find my answer helpful, please like my reply and mark it as the accepted answer.
Hi @joshroban,
I hear your frustration — you’re right, Shopify recently made changes around order cancellations, and many merchants who rely on “test” or “internal” orders have been impacted in the same way you described.
Why the change happened
From what Shopify has shared, this update is tied to making order states more consistent across reports and APIs. Previously, cancelled orders (especially after fulfillment/payment) created inconsistencies in analytics, returns data, and financial exports. The move to encourage returns/adjustments instead of post-facto cancellations is intended to align with accounting standards.
The downside (as you’ve experienced)
-
You lose the ability to keep order counts “clean” if you were using cancellations for internal/test orders.
-
Using the “return” flow artificially inflates return stats.
-
Inventory / sales reporting now looks off if you were relying on cancellations to zero-out units.
Possible workarounds today
-
Test/internal orders → Instead of creating real orders, you can:
-
Use Shopify’s “Bogus Gateway” or a 100% off discount code for test orders in a development store.
-
In a live store, mark internal movements using a draft order and avoid converting it to a finalized order.
-
Adjusting reporting → You can filter reports by tags (e.g., tag your internal/test orders as “internal”) so they can be excluded in analytics/exports.
-
Inventory corrections → If the order inflated sales units, you can use inventory adjustments to correct the stock manually without touching the return stats.
Longer-term
There’s quite a bit of merchant pushback on this (you’re not alone), so it may help to also submit feedback directly via the “Give feedback” link in your admin. Shopify does monitor these threads, but direct merchant pressure has the most impact.
Quick question for you: do you mainly use these “$0 reship/internal orders” for inventory movement or for customer reshipments? The answer changes which workaround will be least disruptive for you.
Hey @joshroban,
Yes Shopify did quietly tighten up order cancellation. Once an order has been marked as fulfilled or partially fulfilled, it can’t be outright cancelled anymore. The reasoning is mostly about payment capture + tax/reporting compliance, but you’re right it’s a big change if you relied on cancel-anytime as part of your workflow. A couple of workarounds merchants use:
-
For internal or $0 reship orders, instead of creating a “real” order, you can use draft orders or even a separate POS location tagged for internal shipments. That way they don’t bloat your sales/marketing data in the first place
-
If you still need to cancel after creation, your best bet is to void before fulfillment. After fulfillment, your only option is return/refund, which (as you said) skews return stats.
-
Some merchants sidestep this with automation apps (like auto-tagging “internal” orders and excluding them from reports)
As for reporting and customer comms, tools like ParcelPanel Order Tracking can help reduce the knock-on pain especially if your concern is customers seeing “phantom” orders or getting confused by return vs. cancel. With a branded tracking page + automated notifications, you can filter what the customer actually sees, even if Shopify’s back-end reporting is clunky.
It’s frustrating that Shopify didn’t flag this change better, but for now the safest play is adjusting workflows (drafts/internal locations) so you’re not relying on cancel-anytime.
Hope this helps a bit! If it does, feel free to mark it as a solution so others can find it too 