When someone withdraws from a purchase, returnEasier sends the acknowledgement of receipt within seconds: unique identifier, order summary, deadlines and the PDF with its timestamp and hash. From today, if that send fails, the system recovers it by itself instead of waiting for someone to notice.
Your customer no longer sees an error when confirming
Until now, if the sending queue was down at the exact moment of confirming, Step 2 of the portal ended on an error page — even though the request had already been recorded. That was the worst possible moment for an error: the success screen is the customer's immediate proof, the one that gives them their identifier.
Now that screen always shows. It is the consistent reading of the law: a withdrawal takes effect the moment the consumer communicates the decision, not when the email arrives. And it removes the other side effect: customers starting over and creating a duplicate request.
An automatic check every 15 minutes
Four times an hour, an automatic check looks for withdrawal requests with no acknowledgement sent so it can queue them again. It leaves a 5-minute margin — so it never steps on a send already under way — and covers the last 30 days, enough to ride out any realistic provider incident. Each check retries a limited batch of pending acknowledgements, so during a long incident, with many pending at once, some may wait more than one round.
No duplicate emails: before sending, it checks whether the acknowledgement already went out, and each request is processed only once, even if the original send and the retry overlap. The only gap is the one above —provider accepts, note never saved— and it is accepted on purpose: when in doubt, a duplicate beats a customer with no acknowledgement.
And if it never even gets queued, you see it in the timeline
A silent failure was the real problem: with no acknowledgement there was no trace at all, and the merchant notification travels in that same send. Now the request records the event «Acknowledgement not sent (resend it from this screen)» in its timeline, inside the request detail in your Shopify admin, with the «Resend confirmation» button right next to it. That event covers a failure to QUEUE the send. If the job queues fine and fails afterwards —rendering the PDF or handing it to the provider— you will not see that notice in the timeline: the automatic 30-day retry takes care of that case, and the «Resend confirmation» button is there all the same.
Like every returnEasier event, it enters the audit log and shows up in your auditable export: there is a record that the acknowledgement needed a resend, and of when it happened. The audit log is append-only —entries are only ever added— and hash-chained, so you can check its hashes against those in your earlier exports; the acknowledgement PDF also carries the hash of its request.
The legal screen only opens legal requests
One precision fix: the identifier of a commercial return — a voluntary return under your own policy — can no longer open the legal flow's success screen. It used to open it and reframe it with the statutory withdrawal wording, which does not apply to that case. Each flow now shows its own screen.
The auditable record, reinforced in the database
In the same batch we hardened the hash chains behind your history, and it is worth saying how far each one goes. The events chain —the one your auditable export recomputes— is protected by the database itself: it admits neither two links hanging off the same parent nor a second starting point, and if one ever appeared, reading stops instead of carrying on as if nothing were wrong. The requests chain has half that net: the database stops two rows sharing the same previous link, and any other anomaly is logged and passed over on purpose —blocking it would leave your store unable to record a single further withdrawal, which is worse than the problem.
What you need to do
Nothing. It is live on every plan and in all 7 languages. If you want to review which emails returnEasier sends and when, we cover it in the help center; and if you would rather see where a request's timeline lives, read how to handle a request.