Storefront Settings Reference

This page documents every single setting in Settings → Storefront order edit — the system that lets your customers make limited changes to their own orders from their Shopify customer account, within a window you control. It requires the Growth plan or above and Shopify’s new customer accounts.

If you haven’t read it yet, Customer Experience shows what a shopper actually sees when these settings are turned on — reading that alongside this page will make several of these settings click faster.

The tab is organized as four sub-tabs, and this page is organized to match them exactly, so whatever you’re looking at on screen has a matching section here:

1. Order editing — the master switch, hold mechanism, time window, and what customers may change.
2. Editing restrictions — tag-based and price-based exclusions.
3. Order cancellation — whether and how customers can cancel outright.
4. Refund settings — automatic refund behavior.

Note on saving: every change on this tab is a draft until you click Save settings at the top of the page. Nothing takes effect for customers until you save. There is no separate “publish” step beyond that single Save button.

1. Order editing

Enable Order Editing Flow

Location: Storefront order edit → Order editing sub-tab → Order editing card (the very first card).

What it does: This is the master switch for the entire customer self-service system. It is a single checkbox with no sub-options of its own — every other setting on this page, across all four sub-tabs, only has any effect once this is checked.

Default: Off. A freshly installed app (or a shop that hasn’t touched this tab yet) shows customers nothing extra on their order pages.

When enabled: Every eligible order (see Customer Experience → Eligibility for the full eligibility list — this checkbox is only the first of several conditions) shows a “Manage your order” card with an Edit button on that customer’s order status page.

When disabled: The app renders absolutely nothing on any order page. Every setting described below on this entire page is inert while this is off — you can configure them all in advance and they’ll simply wait, unused, until you flip this on.

Dependencies: None going in — this is the top-level switch everything else depends on.

Customer impact: The difference between seeing a normal Shopify order-status page and seeing one with a “Manage your order” card and an Edit button.

Merchant impact: None until a customer actually uses it — turning this on doesn’t change anything about how your orders are created, taxed, or fulfilled by itself.

Example: A store launching self-service editing for the first time should leave this off while configuring every other setting on this page (time window, what’s editable, restrictions, refunds) exactly the way they want it, and only check this box — and click Save — once, as the final step, so nothing half-configured is ever shown to a real customer.

How to test: Turn it on, save, then open a recent real order’s status page as that customer (or place a fresh test order and open its confirmation/order-status page). You should see the “Manage your order” card if the order is otherwise eligible.

Order hold mechanism

This card controls what happens to an order’s tags — and optionally its fulfillment status — while the editing window is open, so your own fulfillment process (whether that’s you personally, staff, or a Shopify Flow automation) knows not to act on an order that might still change. It has five controls: two checkboxes and three tag lists.

Add order tags

Location: Order editing → Order hold mechanism → first checkbox.

What it does: A single checkbox that turns the app’s entire tag-lifecycle behavior on or off. When it’s on, the app automatically applies your on-hold tags the instant an order is created, swaps to your confirmed tags the instant the editing window closes, and adds your edited tags on top of whichever of those is current, the instant a customer actually saves a change.

Default: On.

When enabled: Every new order gets tagged automatically, in real time, at each of those three moments — you never have to tag anything by hand.

When disabled: The app never applies any tag to any order, at any point, for any reason. The three tag-list fields below still exist in the UI (so your typed-in tag names aren’t lost if you re-enable this later), but nothing happens with them while this checkbox is off. If Put fulfillment status on HOLD (below) is also off, self-service editing then has no visible signal at all on the order itself — you’d only know an order is mid-edit by checking the app’s own Recent activity feed.

Dependencies: Feeds directly into the three tag lists immediately below it, and works alongside (not instead of) Put fulfillment status on HOLD — you can use tags, the fulfillment hold, both, or neither.

Merchant impact: This is the setting that makes tag-based fulfillment automation possible at all — a saved search, a Shopify Flow, or a third-party app that filters on “does NOT have tag X” only works if this is on and something is actually applying tag X.

Example: A store using a Shopify Flow that triggers “when order is tagged CONFIRMED_ORDER, send to the 3PL” relies entirely on this checkbox being on — without it, no order would ever pick up that tag and the automation would never fire.

How to test: Place a test order with a short editing window (e.g. 15 minutes), confirm the on-hold tag appears on the order immediately in Shopify admin, then wait for the window to close and confirm the tag switches to your confirmed tag.

Put fulfillment status on HOLD

Location: Order editing → Order hold mechanism → second checkbox.

What it does: A stronger, independent guarantee than tags. When on, the order’s actual fulfillment status in Shopify is placed on hold — not just tagged — the moment it’s created, and the hold releases automatically the moment the editing window closes.

Default: Off.

When enabled: The order genuinely cannot be fulfilled by anyone or anything — you, staff, an app, a 3PL integration — while the hold is active, regardless of whether they’re paying attention to tags. This is the option to reach for if “someone might fulfill it anyway” is a real risk at your store.

When disabled: Fulfillment status is left completely alone; the order is fulfillable at any time from the moment it’s placed, and only tags (if Add order tags is on) signal that it’s mid-edit.

Dependencies — this is the one genuine conflict on this entire tab: it cannot be combined with an “Until fulfilled” editing window (see Editing window below). A fulfillment hold stops the order from being fulfilled — but an “until fulfilled” window is defined as staying open until the order is fulfilled. Turned on together, the order would be stuck open forever: the hold prevents fulfillment, and only fulfillment would close the window. The Editing window dropdown disables the “Until Fulfilled” option outright while this checkbox is on, with an inline explanation, so you can’t accidentally create this deadlock.

Merchant impact: A genuinely hard stop on fulfillment during the window — useful for small teams without robust tag-filtered fulfillment automation.

Example: A single-person shop fulfilling orders manually from the plain Shopify Orders list (no saved searches or Flow automation set up) turns this on with a 1-hour window, so there is zero chance of physically packing and shipping an order in the same hour a customer might still change it — with no reliance on remembering to check a tag first.

How to test: Turn it on with a short time-based window, place a test order, and confirm in Shopify’s own order page that fulfillment shows as on hold; wait for the window to close and confirm the hold releases automatically. Release can lag the window’s official close by up to about 10 minutes — the release runs on a periodic background check, not the instant the countdown hits zero.

On-hold tags

Location: Order editing → Order hold mechanism, below the two checkboxes.

What it does: The actual tag text applied to an order the moment it’s created, for as long as the editing window stays open — but only if Add order tags above is checked. This is a list, not a single value: add as many tags as you want applied simultaneously at this stage.

Default: One tag, ON_HOLD_ORDER.

How to change it: Type a tag and press Enter (or click Add) to add it to the list; click the × on any existing tag chip to remove it.

Example: Add a second tag like AWAITING_CONFIRMATION alongside the default if a separate reporting or automation workflow already expects that exact text.

How to test: Change or add a tag, save, place a test order, and confirm the new tag text (in addition to or instead of the default) appears on the order.

Confirmed order tags

Location: Order editing → Order hold mechanism, below On-hold tags.

What it does: The tag(s) applied the instant the editing window closes — replacing the on-hold state. This is your “safe to fulfill” signal.

Default: One tag, CONFIRMED_ORDER.

Example: Point your fulfillment automation’s filter at this exact tag text (e.g. “has tag CONFIRMED_ORDER”) rather than “does not have ON_HOLD_ORDER” — the two aren’t guaranteed to be perfect opposites if you’ve also enabled the fulfillment hold or made manual tag changes, so filtering on the positive confirmed signal is the more reliable automation pattern.

How to test: Same as On-hold tags — change it, save, and confirm the new text appears once a short test window closes.

Edited order tags

Location: Order editing → Order hold mechanism, below Confirmed order tags.

What it does: The tag(s) applied the moment a customer actually saves a change to the order (a contact update, an address change, or an item edit — not just opening the editing screen without changing anything). This is added in addition to whichever of the on-hold/confirmed tags is currently applied, not instead of it — an order can carry both ON_HOLD_ORDER and ORDER_EDITED at once if the customer edits it before the window closes.

Default: One tag, ORDER_EDITED.

Merchant impact: Lets you distinguish, at a glance in your Orders list, which orders within the editing window are still exactly as originally placed versus which ones a customer has actually touched.

Warning: never add any of these three tags (on-hold, confirmed, or edited) to the Order tags restriction list on the Editing restrictions sub-tab. Doing so is self-defeating — the app validates this at save time and will refuse to save the settings, with an explanation, because it would make every order the app itself just tagged immediately ineligible for further edits (and, since cancellation also requires the order to be editable, ineligible for cancellation too).

How to test: Edit a test order as the customer, then confirm the edited tag appears on the order in admin immediately afterward.

Edit timeframe

Enable time-based editing window

Location: Order editing → Edit timeframe → first checkbox.

What it does: Decides whether there’s a time limit on editing at all, and switches the rest of this card’s controls on or off accordingly.

Default: On.

When enabled: Reveals the Editing window dropdown (and, depending on your choice there, either a custom-minutes field or a daily-cutoff-time field) so you can choose the actual limit.

When disabled: No time-based window applies at all. The order stays editable indefinitely from the customer’s side — but only as long as it also keeps passing every other eligibility rule (not cancelled, not fulfilled, no restricted tag — see Customer Experience → Eligibility). In practice, this means “editable until it ships,” since fulfillment is checked independently regardless of any time window.

Dependencies: Gates the Editing window dropdown and everything nested under it.

Recommended configuration: Leave this on for almost every store — an unlimited window means a customer could technically edit an order that’s about to be packed. It’s most defensible to turn off only if Put fulfillment status on HOLD is on and you’re deliberately relying on the fulfillment hold itself (released manually or by some other process you control) as your only gate, rather than a clock.

How to test: With it off, confirm an order placed a long time ago is still shown as editable (as long as it isn’t fulfilled or cancelled).

Editing window

Location: Order editing → Edit timeframe (shown once the checkbox above is on).

What it does: A dropdown choosing the actual duration, as a rolling period measured from when the order was placed (not from a fixed clock time): 15 Minute, 30 Minute, 1 Hour, 2 Hour, 4 Hour, 6 Hour, 12 Hour, 1 day, Until Fulfilled, or Custom.

Default: 1 Hour.

“Until Fulfilled”: the order stays editable until you (or your fulfillment process) actually mark it fulfilled — there’s no fixed time cutoff at all. Disabled/greyed out while Put fulfillment status on HOLD is checked, for the deadlock reason explained there.

“Custom”: reveals a Custom window (minutes) number field. Any whole number of minutes is accepted by the settings screen itself — there’s no enforced minimum — but a window under a few minutes leaves a customer very little real time to notice a mistake and act on it.

Recommended configuration: A shorter window (15–60 minutes) still catches most typos and second thoughts without much risk of an edit landing after the order has already started being picked and packed. A longer window (several hours to a day) is more forgiving to customers who don’t check their order confirmation immediately, at the cost of a longer stretch where you shouldn’t treat the order as final.

Example: A print-on-demand or made-to-order shop that starts production almost immediately might choose 15–30 minutes. A shop that batches fulfillment once a day might reasonably choose “1 day” or switch to a daily cutoff instead.

How to test: Set a short window (e.g. 15 minutes), place a test order, confirm the “Manage your order” card shows a live countdown, and confirm the Edit option disappears once the countdown reaches zero.

Use daily time limit instead

Location: Order editing → Edit timeframe.

What it does: Switches from a rolling duration (e.g. “1 hour after this specific order was placed”) to a fixed time of day cutoff shared by every order (e.g. “6 PM every day, no matter when the order came in”). Orders placed before that time on a given day close at that same cutoff the same day; orders placed after it roll forward to the next day’s cutoff — so an evening shopper still gets close to a full day’s window, not five minutes.

Default: Off.

When enabled: Reveals a Daily cutoff time field, entered in 24-hour HH:MM format. The cutoff is evaluated in your store’s own timezone, not the customer’s.

Dependencies: Turning this on makes the Editing window preset dropdown irrelevant for timing purposes — whatever preset was selected there no longer applies; the daily cutoff fully replaces it as the closing rule.

Example: A store that packs and ships everything received “today” in one batch at 6 PM wants every order placed before 6 PM editable only until 6 PM that day, and every order placed after 6 PM (which won’t ship until the next batch anyway) editable until 6 PM the next day.

How to test: Set a cutoff a few minutes in the future, place a test order, and confirm the countdown shown to the customer matches the time remaining until that exact cutoff — not a generic short window.

Order editing settings — what customers can change

This card controls which categories of information a customer may edit at all. Each of the three top-level categories — Contact information, Shipping address, Item/product editing — is independent; you can allow items but not address, for example, in any combination.

Contact information — Mobile number / Email address

Location: Order editing → Order editing settings → Contact information.

What it does: Two separate checkboxes, not one combined toggle — you can allow phone number changes without allowing email changes, or vice versa.

Default: Both on.

When both are off: The entire Contact information card is hidden from the customer’s edit screen — not shown-but-disabled, genuinely absent, so there’s no dead space or confusing greyed-out section.

When only one is on: The Contact information card still appears, but only shows the one field you’ve allowed.

Customer impact: Directly controls which of email/phone fields the customer can see and change at all.

Merchant impact: None beyond what data can change — email and phone updates apply straight to the real order’s contact fields.

Example: A store that relies on email for all customer communication but manages SMS/phone opt-in through a separate dedicated flow might leave Email address on and turn Mobile number off, so customers can’t accidentally opt themselves into or change SMS contact through this screen.

How to test: With both off, confirm no Contact information card appears in the edit screen at all. With only Email address on, confirm the card shows just that one field.

Shipping address

Location: Order editing → Order editing settings → Shipping address.

What it does: A single checkbox controlling whether a customer can edit the order’s shipping address at all — name, both address lines, city, state/province, postal code, country, and phone.

Default: On.

When enabled: A Shipping address card appears with all of those fields editable together as one form — there’s no way to allow editing only some of the address fields.

When disabled: No Shipping address card appears at all.

Customer impact: Shopify validates the new address server-side on save. An invalid combination (most commonly, a postal code format that doesn’t match the selected country) fails the save and shows Shopify’s own specific message — e.g. “Enter a valid postal code for Canada” — so the customer knows exactly what to fix, rather than a generic failure.

Merchant impact: A corrected address applies to the real order immediately; nothing about shipping cost or the shipping method itself changes as a side effect of an address edit.

Example: Almost every store should leave this on — a wrong or incomplete shipping address is one of the single most common reasons a customer would want to self-edit an order at all, and it’s the change most likely to prevent a failed delivery if caught in time.

How to test: Edit the address to an intentionally invalid combination (e.g. a US ZIP code with Canada selected as the country) and confirm you see a specific, readable error rather than a generic failure message.

Item/product editing

Location: Order editing → Order editing settings → Item / products.

What it does: The master switch for the entire Items card — quantity changes, variant swaps, adding new products, and removing items are all gated behind this one checkbox first.

Default: On.

When enabled: Reveals a nested panel with four further controls: Which variants can customers change to?, Add more items to the order, and Remove items from the order — each documented individually below. It also makes an Items card appear on the customer’s edit screen, listing every line with quantity controls (subject to those nested settings).

When disabled: No Items card appears at all, and every setting nested under it becomes moot — you can leave them configured in advance without effect.

Dependencies: Parent to everything in this whole sub-section below.

Example: A store selling exclusively made-to-order or engraved items — where no quantity or variant change is safe to allow after checkout — would turn this whole category off, while still allowing Contact information and Shipping address edits above.

How to test: With it off, confirm the Items card doesn’t appear in the edit screen at all, while Contact/Address cards (if enabled) still do.

Which variants can customers change to?

Only shown when Item/product editing is on. A radio choice — exactly one of the three can be selected — controlling the “Change option” dropdown that appears under each line item, i.e. whether and how a customer can swap a line to a different variant of the same product (a different size or colour, for example — this never lets a customer swap to a completely different product; that’s what Add more items plus Remove items together would achieve instead).

Why it compares against the paid price, not the list price: if the comparison used the pre-discount list price, a customer with a discount code could use “same or higher” to swap into a variant that’s actually cheaper than what they paid — or be unfairly blocked from a swap that’s genuinely fair given what they paid. Comparing against the real, discounted paid price keeps the rule fair in both directions, and matches what automatic refunds also compare against.

Recommended configuration: “Same and higher value variants” (the default) if you never want a self-service swap to reduce what you’re owed on an order without you explicitly deciding that’s fine. “All variants” if you’re comfortable letting price differences net out automatically via automatic refunds. “Same value variants” is the most conservative — useful if your variants (e.g. colours of an identical product) are genuinely meant to always cost the same, and any price difference showing up at all would actually indicate a pricing mistake worth catching.

Example: A clothing store with a plain size/colour matrix at one fixed price per product would likely pick “Same value variants,” since every variant of a given product should be the same price and there’s no reason to allow anything else. A store where higher sizes cost more (e.g. plus sizes with a surcharge) would want “Same and higher value variants” so a customer can size up (paying the difference, refunded/charged accordingly) but not size down and pocket a discount they didn’t ask for.

How to test: With “Same and higher value variants” selected, confirm a lower-priced sibling variant does not appear as an option in the Change option dropdown, while an equal- or higher-priced one does.

Add more items to the order

Location: nested under Item/product editing, once it’s checked.

What it does: A checkbox controlling whether an Add product button appears at all, letting a customer add an entirely new product to their order — not just adjust an existing line — via a picker matching your admin’s own product-search dialog.

Default: Off.

Dependencies: Requires Item/product editing to be on; has no effect otherwise. The picker’s search results are separately filtered by Hide out of stock products under Editing restrictions if that’s turned on.

Customer impact: With it on, clicking Add product turns the edit screen into a full “Select products” picker — search field, checkbox rows with thumbnail/title/SKU/stock/price, a quantity stepper per selected row, and a running selected-count — closely matching what you see in your own admin’s product picker. Selections are added to the order only once the customer clicks Save changes on the main edit screen, not the moment they’re picked.

Merchant impact: A genuinely new line item appears on the real order, priced at that variant’s current live price, with tax calculated on it automatically the same as any other add.

Recommended configuration: Turn this on if you’d rather a customer add a missed item themselves than open a support ticket or place an entirely separate second order (which then needs separate shipping). Leave it off if you specifically don’t want self-service to be able to increase an order’s total at all (only reduce it, if that’s on).

Example: A customer who forgot to add a matching accessory before checkout can add it themselves within the window, rather than emailing to ask if it can be added to the order that hasn’t shipped yet.

How to test: Turn it on, open the edit screen as a customer, click Add product, search for a real product, add it with a quantity, save, and confirm it appears as a genuinely new line item on the real order in your admin, with correct price and tax.

Remove items from the order

Location: nested under Item/product editing, once it’s checked.

What it does: A checkbox controlling how far down the quantity stepper on an existing line can go.

Default: On.

When enabled: The quantity stepper’s minus button can reach 0, which removes that line from the order entirely on save.

When disabled: The minus button stops at 1 — a customer can reduce a line’s quantity but can never fully remove it this way. (They can still remove the entire order via Order cancellation if that’s separately enabled — this setting only concerns removing a single item while keeping the rest of the order.)

Dependencies: An order can never be reduced to zero total items in one save unless the customer is simultaneously adding a replacement item (via Add more items) or swapping a variant — removing the last remaining line with nothing added back is rejected, with a message pointing the customer toward cancelling the order instead.

Merchant impact: A removed line restocks its inventory automatically, and — if automatic refunds are on — refunds the removed value to the customer’s original payment method.

Recommended configuration: On, for most stores — a customer who ordered too many of something (or the wrong thing entirely, in combination with Add more items) benefits from being able to correct it themselves. Turn it off specifically if you want every line-item removal to go through you, while still allowing quantity reductions down to 1 and other item edits.

How to test: With it off, confirm the quantity stepper on an existing item can’t go below 1. With it on, confirm it can reach 0 and the line disappears from the order on save (as long as it isn’t the order’s only remaining item, per the rule above).

2. Editing restrictions

Tag-based restrictions

Control which orders, customers, or products are excluded from self-service editing, using Shopify tags you already have or create specifically for this purpose. This card has three separate tag lists plus one radio choice governing how the product-tag list behaves.

Order tags

Location: Editing restrictions → Tag-based restrictions.

What it does: Any order carrying any one of the tags in this list is never eligible for editing at all — the “Manage your order” card doesn’t appear on that order’s page, full stop, regardless of every other setting on this page.

Default: Empty — no restriction applied.

Customer impact: A customer whose order happens to carry one of these tags sees a completely normal Shopify order page, with no trace that self-service editing exists anywhere else in your store.

Merchant impact: A clean, reliable way to hand-pick specific orders out of self-service editing without touching the global settings — just tag the order.

Example: Tag orders custom-build when they contain a made-to-order item you genuinely can’t accommodate any change to after the fact, and add custom-build here — every other order in the store is still editable normally, only the tagged ones are excluded.

Gotcha: never add any of your own hold/confirmed/edited tags here — see the warning under that section for exactly why, and note the app actively refuses to save if you try.

How to test: Tag one test order with a restricted value and confirm the Manage your order card disappears from that specific order’s page while a similar, untagged order still shows it.

Customer tags

Location: Editing restrictions → Tag-based restrictions.

What it does: Any customer carrying any one of the tags in this list can never self-edit any of their orders — this is a per-customer restriction, not per-order, so it follows that customer across every order they have or will place.

Default: Empty.

Merchant impact: Useful for excluding an entire account’s worth of orders from self-service at once, rather than tagging orders individually.

Example: Tag known problem accounts, or an entire wholesale/B2B customer segment you always want to handle manually rather than through automated self-service, with a tag like no-self-edit, and add that exact tag here.

How to test: Tag a test customer account with a restricted value, place an order under that account, and confirm self-service editing doesn’t appear on that order even though the order itself carries no restricting tag.

Product tags

Location: Editing restrictions → Tag-based restrictions.

What it does: Tags applied to products (not orders, not customers) that trigger a restriction — with the exact behavior of that restriction controlled entirely by the radio choice immediately below it, not by this field itself.

Default: Empty.

Example: Tag pre-order, made-to-order, personalized, or engraved products with something like no-edit, and add that same tag here.

How to test: Continue to the next setting — the two only make sense tested together.

When a tagged product is found in an order

Location: Editing restrictions → Tag-based restrictions, directly below Product tags.

A radio choice — exactly one selected — for what happens when an order contains at least one product carrying any of the Product tags above:

Recommended configuration: “Disable editing for tagged items only” if your orders commonly mix restricted and unrestricted products — you don’t want one engraved item to block a customer from fixing a typo’d address or swapping an unrelated t-shirt’s size on the same order. “Disable complete order editing” (the default) if a restricted product showing up at all is itself a signal that the whole order needs manual, human handling rather than any self-service at all.

Example — “tagged items only” mode: An order containing one engraved (locked) mug and one plain (unlocked) t-shirt lets the customer freely change the t-shirt’s size while the mug’s line shows “(not editable)” with no controls.

Example — “complete order” mode: The same order instead shows no Manage your order card at all — the customer would need to contact support even to fix their shipping address, because the presence of the engraved mug locks the entire order.

How to test: Tag one product, add that tag under Product tags, place a test order containing both that product and an ordinary untagged one, and confirm the behavior matches whichever mode you selected.

Item-based restriction

Hide out of stock products from variant selection

Location: Editing restrictions → Item-based restriction.

What it does: A single checkbox controlling whether an out-of-stock variant can be offered to a customer at all — in both the Change option dropdown on an existing line, and the Add product picker’s search results.

Default: Off (out-of-stock variants are shown normally in both places).

Definition of “out of stock” used here: only applies to products that track inventory in Shopify at all — a variant belonging to a product with inventory tracking off is always treated as available, since Shopify itself has no concept of “out of stock” for it. For a variant that does track inventory, “in stock” means its available quantity is greater than zero, or its inventory policy is set to allow overselling (“Continue selling when out of stock”) in Shopify’s own product settings — either condition is enough to keep it offered.

When enabled: A variant that fails both of those conditions (tracked, zero stock, and set to stop selling when out) is quietly excluded from both the Change-option list and the Add-product search results — the customer never sees it as an option, rather than seeing it and then hitting an error if they pick it.

When disabled: Every variant is offered regardless of stock level; if a customer picks a genuinely out-of-stock one, the request is rejected server-side with a validation message rather than silently succeeding.

Recommended configuration: On, for most stores with real inventory tracking — it’s a strictly better experience to never show an option that would just fail anyway.

How to test: Set a variant’s inventory to 0 with “Continue selling” off in Shopify, turn this setting on, and confirm that variant no longer appears as a Change-option choice or in Add-product search results — then confirm it reappears once you turn the setting back off.

Minimum item price for editing

Location: Editing restrictions → Item-based restriction.

What it does: A price floor, entered in your store’s own currency (the field shows your currency symbol automatically). Any line item priced strictly below this amount — evaluated against what the customer actually paid per unit after discounts, not the pre-discount list price — becomes locked, exactly the same “(not editable)” treatment a product-tag restriction applies under “tagged items only” mode.

Default: Empty — no floor at all; every item is eligible for editing regardless of how cheap it is.

Why it compares against the discounted price, not the list price: comparing against the list price would make this setting trivially bypassable by any discount code — a $50 item discounted down to $2 would still count as “$50” under a list-price comparison and stay fully editable. Comparing against what was actually paid closes that gap, and matches how the variant scope comparison and automatic refunds both work too.

Merchant impact: A locked item can’t be changed, added again, or removed by the customer, but doesn’t affect whether the rest of the order (or its contact/address info) stays editable.

Example: Setting this to 5 (in your currency) prevents self-service editing on near-giveaway promotional items, free-with-purchase samples, or heavily discounted clearance add-ons, while leaving everything else in the order fully editable as normal — useful if those items are handled by a separate process (or simply aren’t worth the operational overhead of letting a customer fuss over a near-zero-value line).

How to test: Set a value above a specific test item’s actual paid price (after any discount you applied), confirm that line shows as not editable, then raise or clear the value and confirm it becomes editable again.

3. Order cancellation

Enable order cancellation

Location: Order cancellation → Order cancellation card, first checkbox.

What it does: The master switch for letting a customer cancel their entire order (not individual items — that’s the separate Remove items feature) from the self-service screen, available within the same eligibility window as editing.

Default: On.

When enabled: A Cancel order section appears on the edit screen (for otherwise-eligible orders) with a reason dropdown and a cancel button.

When disabled: No Cancel order section appears at all — a customer wanting to cancel would need to contact you directly, even if item/contact/address editing is otherwise fully available to them.

Dependencies: Cancellation follows the same eligibility rules as editing (time window, tags, fulfillment status) — there’s no separate time window just for cancellation.

Customer impact: The presence or absence of any self-service way to back out of an order entirely.

How to test: With it off, confirm no Cancel order section appears in the edit screen, while other enabled sections (Items, Contact, Address) still do.

Restrict cancellation to “Cash on Delivery” orders only

Location: Order cancellation → Order cancellation card, second checkbox.

What it does: Narrows self-service cancellation so it’s only offered on orders paid via a Cash on Delivery (COD) gateway — prepaid orders can still be edited (if editing is otherwise on) but the Cancel order option itself won’t appear for them.

Default: Off.

Matching logic (exact): the app checks the order’s payment gateway name and treats it as COD if that name contains both the words “cash” and “delivery” (in either order, case-insensitively), or contains the literal text “COD”. This reliably matches common COD gateway names, but a custom or unusually-named COD gateway that doesn’t match either pattern won’t be recognized — if your store’s COD gateway isn’t being picked up correctly, contact support with your exact gateway name so it can be checked.

Recommended configuration: Turn this on specifically if you want to avoid the refund overhead of self-service cancellations on payments that have already been captured, while still letting COD customers — who haven’t paid anything yet, so a cancellation has no refund to process — cancel freely without contacting you.

Merchant impact: Prepaid-order cancellations then have to come through you directly, where you can decide refund handling case by case; COD-order cancellations are frictionless for the customer and cost-free for you (nothing was collected).

How to test: Place one COD test order and one prepaid test order; with this setting on, confirm cancellation is offered on the COD order and not offered on the prepaid one.

Order cancellation reasons

Location: Order cancellation → Order cancellation reasons card.

What it does: The exact list of reasons shown in the customer’s “Why are you cancelling?” dropdown when they cancel. Purely a list you curate — add as many as you like by typing a reason and clicking Add (or pressing Enter); remove any with the × next to it.

Default: “Changed my mind”, “Selected wrong address”, “Placed by mistake”, “Found better product/price”, “Not happy with the delivery timeline”, “Other reason”.

Merchant impact: These reasons are recorded with the cancellation and visible in your Recent activity / order notes, giving you real signal on why customers are cancelling — useful for spotting a pattern (e.g. a spike in “Selected wrong address” might point to a confusing checkout address field).

Example: Add a store-specific reason like “Item no longer needed for event” if you sell event-timed goods and want that signal captured distinctly from the generic “Changed my mind.”

How to test: Add a custom reason, save, and confirm it appears in the dropdown on the customer-facing cancellation screen.

4. Refund settings

Enable automatic refunds for order edits and order cancellation

Location: Refund settings → Automatic refund processing card.

What it does: A single checkbox controlling whether a refund is issued automatically, with no manual step from you, to the customer’s original payment method, in two distinct situations:

1. Order cancellation — if the order had a real payment collected against it, cancelling refunds that full paid amount automatically as part of the same cancellation action.
2. A value-reducing item edit — reducing a quantity, or swapping to a cheaper variant (only reachable at all if variant scope permits a cheaper option), automatically refunds the exact price difference, to whichever payment method(s) the original charge actually used.

Default: On.

When enabled: Both situations above are handled without you doing anything — the refund transaction is created the moment the customer’s action completes.

When disabled: Neither situation triggers an automatic refund. Cancelling or reducing an order’s value simply leaves it with a balance owed to the customer, which you’d see and process manually from Shopify’s own order page, on your own timeline.

What happens when a refund genuinely can’t be completed automatically (even with this on): some payment states can’t be reversed through the API at all — most notably, an order marked “paid manually” in your admin (as opposed to a charge through a real connected gateway) has no real transaction behind it for Shopify to reverse. When this happens, the app does not fail the customer’s underlying action — their item change or cancellation still goes through normally — it instead logs the refund shortfall to your Recent activity feed so you know exactly what to refund yourself and why the automatic path couldn’t handle it.

Dependencies: Interacts with, but doesn’t require, variant scope — this setting only ever has something to do when an edit or cancellation actually reduces the order’s paid value, which variant scope (among other settings) controls whether a customer can even trigger.

Recommended configuration: Leave this on for stores using a real connected payment gateway (Shopify Payments or similar) — it removes a manual step entirely and matches the ordinary customer expectation that removing an item means getting that money back without having to ask. If your store’s orders are mostly settled through manual/offline payment methods, automatic refunds won’t be able to complete against them regardless of this setting, so it matters less either way — though leaving it on is still harmless and correctly handles any orders that were paid through a real gateway.

Example: A customer reduces a $50 item’s quantity from 3 to 1 on an order paid via Shopify Payments. With this on, a $100 refund (2 × $50) is issued to their card automatically the moment they save. With it off, the order simply shows a $100 balance owed to the customer in your admin until you process a refund yourself.

How to test: Place a real test order through actual storefront checkout (not “mark as paid” in admin — a manually-marked-paid order has nothing for the automatic path to refund against, by design, so it’s not a useful test of this specific setting), then use self-service editing to reduce a quantity. Check the order’s payment/transaction history in Shopify admin for a new refund transaction matching the exact price difference.

Refund method

Location: Refund settings → Refund method card.

Refunds always go back to the original payment method used on the order — there is currently no alternative method to choose (such as store credit or a gift card issued in place of a refund), so this card is informational rather than a setting you configure. If that changes in a future version, this section will be updated to document the choice.

Getting help

• Use the in-app support chat (the button in the corner of any app page) to message our team.
• Email us at support@nvtrends.com.