Configure external members callback URLs
External members areas rely on a callback or integration URL so AtomicPay can tell the external platform when to create access. This is different from link delivery, where buyers manually open URLs, and different from native delivery and member access when that path is available for the product type.
Use callback delivery when the buyer experience lives in MemberKit or another external members platform and access should be created automatically after an approved sale.
When callback delivery fits
| Use callback URLs when | Use another method when |
|---|---|
| Access must be created in an external members platform | Buyers only need static URLs. See link delivery. |
| You already have platform-specific integration docs | The product is a downloadable ebook. See ebook delivery. |
| Manual fulfillment is too slow for launch volume | MemberKit has a dedicated setup path. Start with MemberKit setup. |
| Subscription or one-time access rules are managed externally | You only need sale events in CRM tools via webhooks |
How callback delivery works
- Buyer completes checkout and the sale reaches the expected approved state in Sales.
- AtomicPay sends the access event using the configured callback URL.
- The external platform creates or unlocks the buyer account.
- The buyer signs in on the external platform.
- Support verifies access using both AtomicPay sale data and the external platform user record.
Callback delivery depends on correct product mapping, approved payment status, and a reachable endpoint on the external side.
Setup workflow
- Confirm the correct business workspace.
[Screenshot: App header — correct business workspace selected.]
- Complete external platform setup on the members side first.
[Screenshot: External platform admin — course or area ready before callback setup.]
- Open the product delivery settings.
[Screenshot: Product delivery tab — external members area section visible.]
- Choose external members area as the delivery method.
[Screenshot: Delivery method — External members area selected.]
- Select the external platform when available.
[Screenshot: Platform dropdown — target external platform selected.]
- Paste the callback URL from the external platform exactly as provided.
[Screenshot: Callback URL field — full URL pasted without typos.]
- Save the product and confirm delivery settings persisted.
[Screenshot: Product saved — callback URL stored on product.]
- Create pricing and publish checkout.
[Screenshot: Published checkout — offer linked to product with callback delivery.]
- Run a controlled test purchase through the first-sale workflow.
[Screenshot: Test checkout — payment completed on live link.]
- Confirm access appears in the external system for the test buyer.
[Screenshot: External platform — test buyer account created with correct access.]
- Document support escalation when access is delayed or missing.
[Screenshot: Internal support doc — escalation steps for callback delivery failures.]
Common problems
| Problem | What to check |
|---|---|
| No access created | Callback URL accuracy, sale approval status, external mapping |
| Wrong course or area unlocked | External platform product or offer mapping |
| Delayed access | Incomplete payment treated as approved too early. See incomplete payments. |
| Worked in test but not live | Different offer, product, or external environment mapping |
| Subscription canceled but access remains | External platform rule plus subscription cancellation review |
What to verify before launch
| Check | Why it matters |
|---|---|
| Callback URL matches the external platform docs | Typos break all access creation |
| Product and offer mapping is correct on both sides | Wrong mapping sends buyers to the wrong area |
| Checkout copy tells buyers to sign in externally | Reduces buyer access tickets |
| Test sale is approved, not merely initiated | Callback timing depends on sale status |
| Support knows which platform owns access | Speeds up investigations |
| Webhooks are configured only if external automations also need them | Callbacks and webhooks solve different problems |
Best practices
- Test one real purchase per product and offer path before scaling traffic.
- Keep a mapping table between AtomicPay products and external platform areas.
- Use MemberKit setup when MemberKit is the target platform.
- Monitor first-week support tickets for access delays after launch.
- Review subscription products with overdue handling and cancellation policy.
Common mistakes
- Pasting a staging callback URL into a live product.
- Changing offer or plan without updating external mapping.
- Assuming callback delivery replaces buyer access support workflows.
- Launching before product approval or checkout publish is complete.
- Troubleshooting the external platform before confirming sale approval in Sales.
FAQ
Is callback delivery the same as webhooks?
No. Callback URLs are part of product delivery to create member access. Webhooks send business events to your own endpoints or automation tools.
Where should I start for MemberKit?
Use connect MemberKit for delivery first. Return here when you need the broader callback model explained.
What if access fails for one buyer only?
Compare the buyer's sale in Sales with the external account record, then follow buyer access troubleshooting.
Do refunds remove external access automatically?
Do not assume they do. Review refunds, product policy, and the external platform behavior together.