The decision
A refund changes both entitlement and economics. Decide whether partial refunds preserve access and whether full refunds revoke it, then implement that policy consistently in the download route and fulfillment worker. Revenue reporting should record the new refunded amount, not repeatedly subtract a cumulative total.
A worked example
An illustrative $19 order receives a $5 refund and later the remaining $14. The charge may report cumulative refunded totals of $5 and $19. Analytics should record negative $5 and negative $14, not negative $5 and negative $19. A stale event reporting $5 after the full refund must not reduce the stored refunded state.
How to put it into practice
- Persist the highest known cumulative refunded amount for the order.
- Calculate the delta inside a transaction that locks the order row.
- Use unique event/job identifiers and ignore duplicate or non-increasing refund totals.
- Check current provider state before serving paid files so delayed webhooks do not leave fully refunded access open.
A failure to plan for
A purchase event can arrive after a refund event. Establish the order and then reconcile canonical refund state so access and tracking do not depend on event arrival order.
Try it on your project
Test partial refund, full refund, duplicate full refund, and stale partial refund in that order. Verify the stored total is monotonic, analytics deltas add to the actual refund, and fully refunded downloads are denied.
Keep the next step small
Use the free demand scorecard or planning tools to make your assumptions explicit. The $19 launch kit brings the blueprint and seven editable worksheets together.