Automatic Digital Delivery: Sending Files and Keys After Payment
Set up automatic digital delivery after payment with webhooks, expiring links and license keys, and keep delivery logs that help you fight chargebacks.

Photo: Pixabay
On this page 9 sections
- How Automatic Digital Delivery After Payment Works
- Why You Should Deliver on a Confirmed Payment, Not on Form Submit
- Using Payment Webhook Fulfillment to Trigger Delivery
- Expiring, Single-Use, and IP-Logged Secure Download Links
- Issuing and Revoking Keys With a License Key Delivery System
- Holding Delivery for Orders Flagged as High Risk
- Building a Delivery Log You Can Submit as Dispute Evidence
- Setup Checklist
- Next Steps
Key takeaways
- Trigger fulfillment from a verified payment confirmation (a webhook or server-side check), never from a thank-you page or form submit.
- Use expiring, limited-use download links and log every access instead of sending permanent file URLs.
- Tie each license key or account to an order ID so you can suspend or revoke it on refunds and chargebacks.
- A timestamped delivery log does double duty: it supports customer service and serves as evidence in disputes.
If you sell software, templates, ebooks, courses or other downloads, buyers expect their purchase within seconds. Automatic digital delivery after payment makes that possible, but only if it is wired correctly. Done carelessly, it hands files and keys to fraudsters and leaves you with no proof when a customer claims they never received anything. This guide covers several practical points: tying delivery to a confirmed payment, triggering fulfillment with webhooks, protecting files with expiring links, managing license keys through refunds and chargebacks, holding risky orders, and keeping a delivery log you can use as dispute evidence.
How Automatic Digital Delivery After Payment Works
Every reliable setup follows the same basic chain of events. A gap anywhere in that chain shows up later as a lost file, a leaked key or a dispute you can't answer.
| Step | What Happens | What You Record |
|---|---|---|
| 1. Checkout | Buyer submits payment details and accepts your terms | Order ID, terms version, timestamp |
| 2. Authorization | Processor approves or declines the charge | Transaction ID, result |
| 3. Confirmation | Your server receives a verified payment event | Event ID, time received |
| 4. Fulfillment | System generates a link, key or account | Asset ID, key, expiry |
| 5. Notification | Buyer gets an email and an on-screen confirmation | Email sent, delivery status |
| 6. Access | Buyer downloads, activates or logs in | IP address, device, timestamp |
The rest of this article goes through steps 3 to 6 in detail. If you are still choosing a processor and checkout stack, start with our ecommerce payment processing setup guide. If you're weighing creator platforms against your own checkout, see our Patreon vs. Ko-fi vs. Buy Me a Coffee fee comparison. Course creators can also compare Kajabi, Teachable and Thinkific payment fees. Download sellers can compare Gumroad, Lemon Squeezy and Payhip creator fees. If you sell low-priced downloads, see our guide to micropayment fees on $0.99 downloads. If you sell to buyers outside the U.S., see our U.S. seller's guide to VAT on digital products. If you sell game currency or virtual items, see our guide to payment rules and risks for selling in-game currency.
Why You Should Deliver on a Confirmed Payment, Not on Form Submit
A common shortcut is to send the file when the buyer reaches the "thank you" page or clicks "Place Order." That approach is unreliable for several reasons:
- The browser is not a trustworthy source. Someone can load your success URL directly, refresh it or modify the request.
- Submission isn't the same as payment. A card can be declined, fail authentication or be sent for review after the form goes through.
- Some payments settle later. Bank transfers, ACH and certain wallet payments can show a pending status before they succeed or fail.
- Buyers close tabs. When delivery depends on the page loading, a buyer who closes the window early may get nothing, which leads to a support ticket or a dispute.
The rule is simple: fulfill only after your server has confirmed the payment directly with your processor. The success page can display a "your files are on the way" message, but it should never generate the actual asset.
Using Payment Webhook Fulfillment to Trigger Delivery
A webhook is a message your processor or gateway sends to your server when something happens, such as a successful payment, a refund or a dispute. Payment webhook fulfillment means your delivery system responds to those events rather than to browser activity.
Verify, Then Act
Most processors sign webhook messages so you can confirm the message came from them. Check the signature on every event before doing anything. Then, for extra safety, query the payment status through the processor's API before you release high-value items.
Make Your Handler Idempotent
Processors often resend webhooks when they don't get a quick acknowledgment, so your server may receive the same event more than once. Store each event ID. If you have already processed it, acknowledge it and skip it. Without this check, a single purchase can produce two license keys or a duplicate account.
A good pattern:
- Receive the event and verify the signature.
- Save it to a queue or database table.
- Return a success response right away.
- Process fulfillment in a background job.
- Mark the event complete and record the result.
If You Deliver a Digital Product After Stripe Payment
The same principles apply whatever platform you use. To deliver a digital product after Stripe payment, or after payment through any gateway such as Authorize.net or NMI, subscribe to the event that indicates a completed or successful payment. Make sure delayed payment methods only fulfill on final success. Event names, retry behavior and signature methods differ between providers, so confirm the details in your provider's current developer documentation. MannyPay offers online payment gateways and ecommerce payment processing for merchants who want to compare options.
Have a Backup When Webhooks Fail
Webhooks can be delayed or missed when your server goes down. Run a scheduled reconciliation job that compares recent successful payments with fulfilled orders and flags any payment that has no matching delivery. This step catches the "I paid and got nothing" problem before the customer contacts you.
Expiring, Single-Use, and IP-Logged Secure Download Links
Never email a permanent public URL to a file. Once that link is shared on a forum, anyone can download your product.
Secure download links are generated per order and usually include a cryptographic signature that your server or storage provider checks. Most cloud storage services can generate signed, time-limited URLs. You can also route downloads through a small endpoint on your own server that validates the order before serving the file.
How to Set Expiring Download Link Rules
Choose limits that stop casual sharing without frustrating legitimate buyers. The values below are illustrative. Adjust them based on your file sizes and how often you get support requests.
| Setting | Illustrative Starting Point | Why |
|---|---|---|
| Link expiry | 24 to 72 hours | Limits sharing while giving buyers time to download |
| Download limit | 3 to 5 attempts | Allows for failed downloads and a second device |
| Reissue | Self-serve from account page | Avoids support tickets when a link expires |
| IP and device | Log, don't block | Mobile and home IPs change frequently |
A few practical notes:
- Strict single-use links cause support headaches. If a large download fails partway through, the buyer is stuck. Allowing a small number of attempts is usually a better balance.
- Log IP addresses rather than locking to them. If you see many different IPs on one link within a short window, flag the link for review instead of blocking it automatically.
- Track completed downloads where you can, not only link clicks. A logged completed download is stronger evidence than "the link was opened."
- Disclose your logging. Recording IPs and device data is personal information. State it in your privacy policy, and check with a qualified professional which state privacy laws apply to you.
Issuing and Revoking Keys With a License Key Delivery System
A license key delivery system creates or assigns a key when a payment is confirmed, links it to the order, and tracks what happens to that key afterward. You can draw keys from a pre-generated pool or create them on demand. In either case, each key record should include:
- Order ID and transaction ID
- Customer email and account ID
- Issue timestamp
- Status (active, suspended, revoked)
- Activation history: timestamps, device identifiers and IP addresses
The same structure works for account delivery such as SaaS logins, course access or membership areas. The "key" is the account entitlement, and the activation history is the record of logins and content accessed. If you sell usage-based access, see our guide to prepaid credits billing for AI and SaaS tools. If you bill for usage after the fact, see our guide to usage-based billing for SaaS: metering, invoices and card limits.
What to Do on Refunds
When you issue a refund, your refund webhook should automatically deactivate the key or remove access. Manual revocation tends to get forgotten, and a refunded buyer who keeps a working key costs you twice. For help writing the policy itself, see our guide to building a digital product refund policy that holds up.
What to Do on Chargebacks
When a dispute webhook arrives, set the entitlement to suspended rather than deleting it. That keeps the activation history intact for your evidence package. If you win the dispute, you can decide whether to restore access based on your terms. Your terms of service and checkout disclosures should say plainly that access may be suspended when a payment is reversed. Have a professional review that language.
Keys are a frequent target for stolen cards because they can be resold quickly. For more on that pattern, see our guide to stopping stolen-card fraud on license keys.
Holding Delivery for Orders Flagged as High Risk
Instant delivery is the default, but you don't have to deliver every order instantly. A short review queue for a small share of suspicious orders costs far less than handing a fraudster a resellable asset.
Common signals that justify a hold:
- Billing country, IP location and email domain that don't match
- Multiple failed card attempts before a successful one
- One buyer ordering many keys or seats at once
- A new account placing a high-value order within minutes of signing up
- Disposable email addresses or emails that look randomly generated
- Several cards used from the same device or IP
When you hold an order:
- Show the buyer an honest status message, such as "Your order is being verified and will be delivered shortly."
- Set an internal deadline for review so legitimate buyers aren't left waiting.
- Approve or cancel the order. If you cancel, refund it promptly rather than leaving it in limbo.
- Record the decision and the reason in the order log.
Authentication can reduce the number of orders you need to hold. 3-D Secure authentication adds an issuer verification step for card-not-present payments and can shift fraud liability for authenticated transactions in many cases. Confirm how this applies to your account with your processor.
If your digital business keeps getting flagged by processors, our article on why digital products merchant accounts get flagged explains what underwriters look for. Sellers with elevated dispute exposure may also want to review high-risk merchant account options. If you sell coaching programs, see our guide on why processors hold high-ticket coaching sales. To check how your category code affects approvals and monitoring, see our guide to MCC 5815–5818 digital goods codes and how they change your fees.
Building a Delivery Log You Can Submit as Dispute Evidence
This is where fast delivery and dispute protection support each other. Your fulfillment system already produces timestamps at every step, so keep them in a single record per order.
What to Log
| Data Point | Why It Matters in a Dispute |
|---|---|
| Terms and refund policy version accepted, with timestamp | Shows the buyer agreed to your policies |
| Transaction ID and authentication result | Ties the delivery to the disputed charge |
| Delivery email sent and delivery status | Shows you fulfilled promptly |
| Download completions with IP, device and time | Shows the buyer received the file |
| Key activations or account logins | Shows the product was used |
| Prior undisputed orders from the same customer | Can support a claim that the buyer recognizes your business |
| Support conversations | Shows whether the buyer raised a problem before disputing |
Turning the Log Into a Dispute Response
Card networks and issuers apply specific evidence standards to digital goods disputes. Typical requests include proof of access or download, device and IP data, and a history of the customer's relationship with you. Exact requirements change over time and differ by dispute reason, so ask your processor what they currently accept.
Build a one-page export template for each order that presents the log as a clear timeline with timestamps and identifiers. Avoid unedited database dumps. Reviewers respond to evidence they can read quickly.
An illustrative timeline might read: order placed and terms accepted, payment confirmed by webhook, delivery email sent, file downloaded twice from the same device, license activated on one machine, and the account logged in again the following week. A buyer claiming "I never received it" is difficult to believe against that record.
Logs are especially valuable against friendly fraud, where a real customer disputes a legitimate purchase. Our guide to spotting and fighting friendly fraud covers how to respond without damaging customer relationships.
Setup Checklist
- Fulfillment is triggered only by verified server-side payment events
- Webhook signatures are verified, and event IDs are deduplicated
- A reconciliation job catches payments that have no delivery
- Download links are signed, expiring and limited to a few attempts
- Downloads, activations and logins are logged with timestamps
- Refund events revoke access, and dispute events suspend it
- A review queue exists for high-risk orders, with a target turnaround
- Terms, refund policy and data collection are disclosed at checkout
- A one-page evidence export is ready for disputes
Next Steps
Start by auditing your current flow. Find the point where delivery is actually triggered and what you record afterward. Most sellers can fix the biggest gaps, such as delivering on form submit, using permanent links and keeping no access logs, without rebuilding everything.
If you want to review your payment setup for digital goods, including gateways, authentication and payment processing for ecommerce businesses, you can request a free quote from MannyPay. A specialist responds within one business day.
This article is general information, not legal or technical compliance advice. Confirm privacy, consumer protection and card network requirements with qualified professionals and your processor.
This article is for general educational purposes and is not legal, tax or financial advice. Card network rules and state laws change; confirm current requirements for your business.


