Order Cancel Job Result
Requires access scope or
access scope. Also: The user requires
access scope.
A job to determine the result of an order cancellation request.
Anchor to FieldsFields
- Anchor to donedone•Boolean!non-null
This indicates if the job is still queued or has been run.
- Anchor to errorserrors•[Order
Cancel User Error!]! non-null Returns any error that occurred during order cancellation.
- •ID!non-null
A globally-unique ID that's returned when running an asynchronous mutation.
- Anchor to orderorder•Order
The order associated with the cancellation request.
- Anchor to statusstatus•Order
Cancel Status! non-null The current status of the order cancellation request.
Anchor to MutationsMutations
- •mutation
Cancels an order, with options for refunding, restocking inventory, and customer notification.
CautionOrder cancellation is irreversible. An order that has been cancelled can't be restored to its original state.
Use the
mutation to programmatically cancel orders in scenarios such as:
- Customer-requested cancellations due to size, color, or other preference changes
- Payment processing failures or declined transactions
- Fraud detection and prevention
- Insufficient inventory availability
- Staff errors in order processing
- Wholesale or B2B order management workflows
The
mutation provides flexible refund options including refunding to original payment methods or issuing store credit. If a payment was only authorized (temporarily held) but not yet charged, that hold will be automatically released when the order is cancelled, even if you choose not to refund other payments.
The mutation supports different cancellation reasons: customer requests, payment declines, fraud, inventory issues, staff errors, or other unspecified reasons. Each cancellation can include optional staff notes for internal documentation (notes aren't visible to customers).
An order can only be cancelled if it meets the following criteria:
- The order hasn't already been cancelled.
- The order has no pending payment authorizations.
- The order has no active returns in progress.
- The order has no outstanding fulfillments that can't be cancelled.
Orders might be assigned to locations that become deactivated after the order was created. When cancelling such orders, inventory behavior depends on payment status:
- Paid orders: Cancellation will fail with an error if restocking is enabled, since inventory can't be returned to deactivated locations.
- Unpaid orders: Cancellation succeeds but inventory is not restocked anywhere, even when the restock option is enabled. The committed inventory effectively becomes unavailable rather than being returned to stock at the deactivated location.
After you cancel an order, you can still make limited updates to certain fields (like notes and tags) using the
.
For partial refunds or more complex refund scenarios on active orders, such as refunding only specific line items while keeping the rest of the order fulfilled, consider using the
mutation instead of full order cancellation.
Learn how to build apps that integrate with order management and fulfillment processes.