Run refund logic only after the provider signature passes against the exact raw body.
Lemon Squeezy refund webhook test
Refund handling is a launch gate, not a support afterthought. Before public checkout traffic, prove that a signed refund event revokes or pauses access once, preserves audit evidence, and never exposes API keys, webhook secrets, customer data, or private checkout URLs.
Read the delivery and refund policyDecide the rollback before launch
A refund should trigger a clear entitlement decision. For a downloadable Pro Kit, that can mean marking the private delivery inactive, stopping resend support, recording the refund reason, and preserving checksum evidence for dispute-safe support. Do not erase the history needed to explain what happened.
Refund webhook checks
Use fake fixtures and controlled local replay before production. The same refund event should be safe when delivered once, retried by the provider, or reviewed later by support.
Convert refund, dispute, or manual support events into explicit grant, revoke, hold, or review decisions.
Replay the same event and prove duplicate deliveries skip emails, access changes, and irreversible writes.
Record event name, order reference, action, idempotency key, replay result, and support note without secrets.
Refund test report template
Keep the report small enough to paste into a pull request or release note without leaking sensitive data.
# Lemon Squeezy refund webhook test
- Provider: Lemon Squeezy
- Event: refund or refunded-order fixture
- Environment: production-shaped fake fixture
- Signature gate: pass
- Order reference: fake_order_123
- Entitlement decision: revoke paid download resend support
- Idempotency key: lemon:refund:fake_order_123
- First replay: rollback side effect executed once
- Second replay: duplicate skipped with HTTP 2xx
- Buyer evidence: checksum and delivery policy remain available
- Secrets included: noSupport policy connection
A refund flow is easier to defend when the buyer-facing page already explains delivery, checksum verification, support scope, duplicate purchase handling, broken archive handling, and safe issue reporting. Link refund evidence back to that public policy instead of improvising from private logs.
FAQ
Should a refund webhook immediately delete buyer records?
No. Treat refund handling as an entitlement decision. Revoke paid access or mark delivery inactive, but preserve secret-free audit evidence, checksum records, and support history.
How do I test duplicate refund webhook delivery?
Replay the same signed refund fixture more than once and prove rollback side effects run once. The second delivery should return success without sending duplicate support emails or repeating irreversible writes.
What should a refund evidence report include?
Include provider, event name, order identifier, refund state, entitlement action, idempotency key, replay result, support note, and rollback owner. Do not include API keys, webhook secrets, customer private data, or private checkout URLs.
Turn refund handling into a release gate
Use the free sample to inspect fake Lemon Squeezy fixtures and replay tests. Use the Pro Kit preview when you need copy-ready rollback notes, entitlement decisions, duplicate replay tests, and review reports for paid delivery.