We run automated refunds with the following flow:
Cron picks a payment_id
Backend calls POST /refunds
Dodo processes the refund and returns a refund_id
We persist the refund_id in our database
Problem Scenario
If the server crashes, times out, or the DB write fails after step 3 but before step 4 completes, the refund is successfully created on Dodo’s side, but we permanently lose the refund_id.
When the cron retries:
Dodo correctly prevents duplicate refunds
API returns PAYMENT_ALREADY_REFUNDED
But the response does not include the original refund_id
As a result:
our DB remains inconsistent
we cannot reconcile the refund automatically
manual investigation becomes necessary
Expected Behavior
For idempotent refund requests, it would help if the API returned either:
the original refund_id, OR
a way to fetch the existing refund by idempotency key/payment reference
This would allow safe retry + reconciliation after partial failures.
Any Workaround for this?