Should a download link ever expire

What this step is

Step 40 (Part VI) is marked moderate difficulty, often skipped. Most digital-product checkouts either never expire the link (and it gets forwarded) or make expiry so tight it generates support tickets from legitimate buyers.

Why the webhook, not the thank-you page

Delivery triggers from the payment system telling the server the money arrived, never from a browser reaching a thank-you page. Browsers close mid-transaction, and a round trip the business depends on will eventually fail someone who genuinely paid. The handler has to be idempotent against a retried webhook event, so a duplicate notification doesn't duplicate delivery or double-charge a downstream action.

Token expiry in practice

A permanent link gets forwarded until a paid product is effectively free with extra steps. Gate it behind a signed link expiring after a few days, long enough that a phone-then-laptop buyer is never caught by it, and reissue on request without interrogation.

Deliver on two channels: the confirmation screen immediately, and email within about a minute, so a closed tab never strands a genuine buyer.

What done looks like

Every settled purchase produces a download or open event within a day. A gap wider than a few percent between payments and that event is treated as a standing alert, not an occasional glance, because it usually means the webhook-to-delivery chain is broken somewhere.

This is a narrower claim than a general delivery system: the token and its expiry window are specifically about preventing a paid asset being forwarded freely, not about tracking (that's step 43 onward) or about the follow-up sequence that runs after delivery (step 41).

Where it breaks

Triggering delivery from the thank-you page instead of the webhook, which loses anyone whose browser closes before the page renders. A handler that isn't idempotent, so a retried webhook event sends the file (or the follow-up sequence) twice.