Set up link delivery products
Link delivery sends buyers to one or more URLs after payment. Use it for software access, communities, onboarding pages, bonus resources, or any post-purchase destination that does not require a file upload like ebook delivery.
Configure links before sending traffic to checkout. Support issues often start when payment succeeds but the buyer does not understand which link to open.
When link delivery fits
| Use link delivery when | Consider another method when |
|---|---|
| Buyers need one or more labeled access URLs | The product is a downloadable ebook. See ebook delivery. |
| Access lives on external pages you control | Access must be created automatically in MemberKit or similar. See external members callback URLs. |
| Delivery is mostly instructional or onboarding | Ongoing membership billing needs subscription pricing and access policy |
| Checkout can clearly explain each link label | Delivery depends on manual fulfillment outside AtomicPay |
What link delivery affects
| Area | Impact |
|---|---|
| Product setup | Labels and URLs become the buyer-facing delivery promise |
| Checkout | Copy should explain what each link opens |
| Sales | Support verifies approved sale before blaming links |
| Refunds | Access may need review after refund |
| Webhooks | External systems may still need sale events even when links are manual |
| Support load | Unclear labels create repeat tickets |
Setup workflow
- Confirm the correct business workspace.
[Screenshot: App header showing the active business name and workspace switcher.]
- Open Products and start a New product.
[Screenshot: Products list page with New product button visible.]
- On What will you sell?, select Link Delivery.
[Screenshot: Product type selector — Link Delivery tile selected; subtitle reads "Access links after purchase."]
- Create the product or open a link delivery product.
[Screenshot: Link delivery product opened — product type Link Delivery confirmed.]
- Complete product approval details and sales page information.
[Screenshot: Link delivery product details and approval fields.]
- Open the delivery links area.
[Screenshot: Delivery links section — add link action visible on product.]
- Add each link with a clear, buyer-friendly label.
- Use complete, valid URLs including
https://when required.
[Screenshot: Delivery links editor — multiple labeled URLs saved on the product.]
- Remove empty, outdated, or duplicate links.
[Screenshot: Delivery links list — empty or duplicate rows removed before save.]
- Save the product and confirm the link list persisted.
- Create pricing and publish checkout.
[Screenshot: Published checkout preview explaining each delivery link label.]
- Run a test purchase through the first-sale workflow.
[Screenshot: Test checkout — link delivery purchase payment submitted.]
- Confirm each link appears or is reachable after approval.
[Screenshot: Post-purchase screen listing labeled delivery links for the test buyer.]
- Document support steps for buyers who cannot find the right link.
[Screenshot: Support playbook — how to verify delivery links for a buyer purchase.]
Link labeling examples
| Label style | Why it helps |
|---|---|
Main software login | Buyer knows which URL is primary |
Community access | Separates bonus destinations from core access |
Implementation checklist | Makes supporting material obvious |
Mobile app download | Reduces confusion on phone support calls |
Avoid vague labels like Link 1 unless support scripts explain them clearly.
What to verify before launch
| Check | Why it matters |
|---|---|
| Labels tell buyers what each link opens | Reduces support confusion |
| URLs work on mobile and desktop | Many buyers open links on phones |
| Links match checkout promise | Prevents refund and dispute pressure |
| No placeholder or staging URLs remain | Common launch mistake |
| Product is active | See inactive products and link impact |
| Support can verify expected links per product | Helps buyer access troubleshooting |
Best practices
- Keep the number of links manageable on checkout and in support docs.
- Test every URL after changing pricing or product copy.
- Use UTM conventions on marketing pages, not on private delivery URLs unless analytics truly need them.
- Pair link delivery with clear refund policy and support escalation rules.
- If access later moves to a members platform, plan a migration to MemberKit or callback delivery instead of patching links forever.
Common mistakes
- Leaving old onboarding URLs in a live product.
- Promising one link on the sales page and configuring another in the product.
- Using link delivery when access should be automated through external members callback URLs.
- Launching before checkout publish or product approval is complete.
- Sending buyers to login pages that require a separate account creation step without explaining it on checkout.
FAQ
How many links can one product include?
Use as many as the offer truly needs, but keep the buyer experience simple. Too many links increase support load.
What if one link breaks after launch?
Fix the URL in the product, update support scripts, and review whether existing buyers need communication. Check buyer access troubleshooting for ticket handling.
Can link delivery work with subscriptions?
Yes, but define whether links remain available during overdue or canceled subscription states before launch.
Should I use webhooks with link delivery?
Use webhooks when external systems also need sale events. Links alone do not replace webhook-based automations.