Stripe Eshop integration: Checkout, webhooks and controlled fulfillment

A reliable Stripe integration verifies payment on the server and performs each commercial action only once.

Stripe's Checkout documentation states that automatic fulfillment requires webhooks and cannot rely solely on the return page. Some payment methods also confirm success later. For a store, completing checkout and receiving final payment success are therefore not always the same event. Choose methods suitable for the account and market, then define when goods ship, inventory is reserved and customer notifications are sent. The integration must preserve that distinction in its interface and background jobs, rather than treating every completed checkout session as immediate permission to dispatch.

Create a Checkout Session with correct data and persist its association with the internal order. The server receives relevant events, verifies authenticity and reads payment state before triggering the next action. That operation must remain safe if invoked repeatedly. The customer confirmation screen uses actual status and should not claim completion while a payment result is pending. Digital access and physical dispatch are different fulfillment actions with the same payment gate. Record their individual completion so a later reconciliation can recover an unfinished action without duplicating one already performed.

Events may arrive more than once or be delayed. Use stable references, stored outcomes and a pending-work reconciliation process. If the customer closes a phone immediately after payment, the server still needs to update the order. If a delayed method eventually fails, goods should not already have shipped contrary to the agreed rule. Webhook signatures, amount changes and partial refunds require separate checks. These details protect the connector's operational consistency and provide support with a clear explanation when a transaction is successful but an order-related step remains incomplete.

A Stripe implementation separates payment verification from fulfillment tasks. A shared reference lets the server determine whether digital access has already been granted or goods released to the warehouse. Those actions may finish at different times. Repeated webhooks must not create a second result. For a pending payment method, show appropriate information instead of unverified success. Support should see which commercial step remains outstanding and whether payment needs rechecking or an internal task needs resuming. That distinction is essential when one basket contains different fulfillment types.

A basket contains an item to ship and a digital guide. After payment verification, the application creates two distinct tasks. If digital access succeeds but the warehouse update fails, reconciliation resumes only the second task instead of repeating the same provision. A duplicate webhook sees which actions already completed. For a method with delayed results, apply the agreed waiting rule. Customers receive clear information about their purchase. Support can identify whether the remaining work concerns dispatch, access or payment confirmation, rather than treating the mixed basket as one opaque task.

Test duplicate and delayed events, browser closure and an invalid webhook signature. Unverified notifications must not alter commercial state. Also test failure after an initially pending result and interruption of an internal task after payment success. Recovery preserves completed actions and continues outstanding work without another charge. Staff verify amount, reference and purchased items. Provide reconciliation steps distinguishing payment problems from fulfillment problems. Test concurrent processing of the same Checkout Session as well as sequential duplicates, because a shared completion record must remain reliable under both conditions.