A success page should not be the only proof of payment

The customer may never reach the final page

Stripe's fulfilment guidance says a checkout landing page alone is insufficient because a buyer can pay successfully and lose connectivity before it loads. It also requires repeated notifications to be handled safely. For a hypothetical paid workshop recording, that means access should follow verified payment information rather than a browser arriving at a congratulatory page. Give the responsible implementer this requirement explicitly. Do not assume a payment button and a success screen form a complete purchase workflow, even when the happy-path demonstration looks convincing.

• Stripe: fulfill orders ↗

Define one durable purchase record

The owner needs a record connecting the payment, purchased item and customer account or delivery destination. Decide how a customer who closes the browser finds their purchase again. The system should not require the owner to reconstruct the transaction from a screenshot. Keep sensitive payment handling within the appropriate provider and approved integration. For the recording example, the purchase record should explain which recording was bought and whether access was granted. A general account flag such as paid can become ambiguous as the business adds more offers.

Make repeated signals harmless

Payment systems can send updates more than once, and a customer can reload a page. Ask the implementer to demonstrate that these actions do not create duplicate access grants, duplicate fulfilment tasks or repeated customer messages. Write the expected result in business terms: one paid order leads to one fulfilled entitlement. If a later payment state changes, handle that as a separate decision with a traceable history. Avoid a process where every notification blindly repeats the same action. The owner should be able to see whether fulfilment already happened. Include a support lookup by purchase reference, so a customer who never reaches the final page can still receive help with the completed payment.

Test the interruption deliberately

In the provider's suitable test environment, complete a payment without relying on the final browser page, then check the owner record and customer access. Replay the relevant notification through the supported testing method and confirm nothing duplicates. Include a pending or unsuccessful payment so access is not granted too early. Record any parts the current implementation has not demonstrated. The purchase path is ready when it survives these ordinary interruptions and the business can explain the state of an order independently of what one browser happened to display.