I’m using the OrderCancel mutation with the option set to notify the customer, problem is, the email the customer receives is invalid, because the email goes out before the order is updated, meaning the customer receives an email stating the financial status is ‘authorized’ and not ‘voided’
Hi @Blake_Anderson,
I’ve looked into this a bit and I have not been able to replicate this on my own store.
When cancelling an order with an authorized payment, with the orderCancel mutation, passing notifyCustomer: true, and refunding the order to the original payment method, did indicate that the payment was voided in the email that was sent.
Here’s an example of the mutation I ran:
mutation OrderCancel($orderId: ID!, $notifyCustomer: Boolean, $refundMethod: OrderCancelRefundMethodInput!, $restock: Boolean!, $reason: OrderCancelReason!, $staffNote: String) {
orderCancel(orderId: $orderId, notifyCustomer: $notifyCustomer, refundMethod: $refundMethod, restock: $restock, reason: $reason, staffNote: $staffNote) {
job {
id
done
}
orderCancelUserErrors {
field
message
code
}
userErrors {
field
message
}
}
}
Variables:
{
"orderId": "gid://shopify/Order/12345678910",
"notifyCustomer": true,
"refundMethod": {
"originalPaymentMethodsRefund": true
},
"restock": true,
"reason": "CUSTOMER",
"staffNote": "Wrong size. Customer reached out saying they already re-purchased the correct size."
}
And here’s the default Order Cancellation email I received, indicating the payment was voided and refunded.
If you have any specific examples where you’ve seen otherwise, I would recommend reaching out to our Shopify Support team via the Shopify Help Center, so we can look at and discuss with you the details of specific orders and emails in a fully authenticated support interaction. Please also have the information of the orderCancel mutation that experienced the unexpected behaviour ready, including the full HTTP details:
- The full plain text HTTP Request, including URL, Body, and Headers (no access tokens)
- The full plain text HTTP Response, including Body and Headers
Thanks for checking it out - unfortunately the payment_status is still coming through as ‘authorized’ on the cancellation email for me.
adding this to the email template
<ul>
<li>{{ cancel_reason }}</li>
<li>{{ financial_status }}</li>
</ul>
gives this in my inbox
even though the status was changed to ‘voided’ if i check immediately after receiving the email
I suspect the issue is the payment info is updated asynchronously, and isn’t complete at the time the email fires (at least, not all the time)? Since i’m seeing similar issues with the webhooks - at the time the server receives the order cancelled webhook, the gql API is still returning data from the pre-cancellation state. Similarly back in october I had to put sleep commands in my code after capturing order payment because the data I would fetch back after the capture would not reflect an actual captured payment until 2-5 seconds afterwards
I can try support ¯\_(ツ)_/¯
Thank you for sharing that additional context on the liquid variables you’re using that is leading to this behaviour.
I believe you may be correct that the order’s financial status is updated asynchronously, and could possibly not be updated before the email is sent. If so then this would be expected behaviour.
I’m currently discussing this with our developers further to confirm the expected behaviour here, and if they do follow up saying this is not expected behaviour, then we should get you to contact Shopify Support directly with specific examples and we can look into it further with you in an authenticated support interaction.
Hi @Blake_Anderson,
I’ve discussed this further with our developers internally, and we can confirm this is known behaviour due to a race condition when the order is cancelled, between the payment being voided, and the email being triggered, and we can confirm that this is not necessarily expected behaviour as this time either.
Our developers will be looking into this behaviour further, however we are unable to provide any estimated timeframes for that, as they do have higher priority issues they are working on at this time.
That all said, I would recommend reaching out to our Support Team as mentioned, with specific examples. That way we can provide your examples to our developers internally to help their investigation, and we can then keep you updated via the Support Ticket on any updates to the matter.
Additionally, in case this helps you as well, we do see this race condition occurring more often if you are using the REST Admin API for order cancellation, though it can still happen with other methods such as the GQL Admin API or via the store’s admin.

