Why: the goal or problem

Imagine selling access to a digital course. Learners choose a course, pay through a checkout page, and expect access to open only after a confirmed payment.

A digital-course buyer can land on a thank-you page while payment is still pending. A customer reaches a success page but never receives access, or repeated notifications grant the same purchase twice. A checkout screen alone cannot establish a trustworthy sale. You need to connect an order, verified payment evidence and exactly the entitlement promised, while making sales and support responsibilities explicit.

How: work toward a solution

  1. Define the sale before integrating a button: product, price, currency, customer identity, access duration and refund behavior. Decide who is the contractual seller and who answers support requests. A payment processor and an outsourced seller do not take on identical responsibilities; examine the actual agreement.
  2. Create an order on the trusted server using the agreed catalog price. Associate it with the provider’s checkout or payment identifier. Browser-provided amounts and a visit to a success URL are not sufficient proof that the expected order was paid.
  3. Receive the provider’s verified event or query its trusted payment record. Check the order, currency, amount and relevant completion state. Some methods finish later, so show pending rather than granting access merely because the checkout flow returned. Follow the provider’s authentication and event-verification procedure.
  4. Make processing safe to repeat. Store which payment has produced which entitlement, and ensure concurrent or retried processing cannot grant it again. If recording access fails after payment, retain a recoverable state and retry that operation. Starting another charge is not a substitute for recovering fulfillment.
  5. Exercise the difficult paths in a test environment: duplicate event, delayed success, failure, interrupted browser return and refund. Confirm both the payment record and the product’s access record. A successful redirect test does not cover missed notifications, and a payment refund does not automatically implement your application’s access policy.

Keep a support trail linking order, provider reference and entitlement state without exposing secrets. Define how an operator can identify a paid-but-unfulfilled order and recover it. Before release, verify supported products, countries and distribution channels against current agreements and platform rules. Do not infer obligations from the provider’s marketing category alone.

Agree how long an order may stay pending and what support message customers see while an unresolved payment is investigated.

Verified payment before access

Digital course · one purchase

Verify before granting access

A success page alone cannot prove that payment completed.

  1. 1CustomerStarts checkout for one purchase
  2. 2Payment providerSends a payment event to the server
  3. 3Application serverVerifies event and payment state
  4. 4Access recordGrants access once for the purchase

Duplicate event Same purchase stays at one access grant.

Failed payment No access grant; show a recoverable status.

Provider events can be delayed or repeated. Define the exact verified event and fulfillment rule for the provider you use.

Pending payment: wait for trusted completion. Paid but access not recorded: retry fulfillment without charging again. Refund: apply the agreed access policy; payment and entitlement are separate records.

What: the concept

A payment channel is a route, a processor handles payment, and a merchant of record is the seller for covered transactions. Stripe’s fulfillment guidance separates payment evidence from access delivery. Lemon Squeezy describes its seller role; retained duties depend on the agreement. Sources checked 2026-09-23. These implementation checks do not replace a review of the actual sales arrangement.