Hi Jamessimm,

Thanks for sharing your setup and the challenges you’re facing. You’re dealing with a pretty typical asynchronous-payment scenario, and I think the approach you’ve taken is sound. Below are some thoughts, confirmations of what works, and a few suggestions to strengthen the flow and avoid edge-cases.

1. You’re treating the payment as finalized only after the gateway’s webhook confirms authorization, which is correct for payment methods that redirect the user or rely on delayed confirmation. That follows standard async-payment best practices: the initial client-side finish (drop-in / redirect) only signals "payment started/authorised - pending confirmation."
2. By refactoring so the webhook - not the frontend callback - converts the cart into an order, you avoid problems where the user never returns (e.g. they close the browser on bank-redirect), but the system still needs to act when payment is confirmed. That is robust and reliable.
3. Redirecting the user to a “pending” confirmation screen after payment initiation is also a good UX compromise: the user gets immediate feedback, and backend continues to wait for definitive confirmation.

So far - this matches recommended practices for asynchronous payment flows + external gateway + webhooks.

Recommended enhancements & safeguards:

• Flag or lock the cart when payment is initiated (e.g. set a PaymentPending = true flag, prevent further changes to line items or shipping after payment call)
• Initiate payment → mark cart as “pending payment” and lock it.
• Redirect user to “pending order page / payment in progress” - no edits allowed.

• Wait for webhook.

  • On success → convert cart to order, unlock order, send downstream events.

  • On failure or timeout → revert cart lock, notify user, allow retry or alternative payment.

• Expire the lock after a timeout (e.g. 30–60 minutes) if webhook never arrives - release cart so user can continue checkout or retry
• Treat the pending-state screen as “readonly” / informational, not editable
• On webhook callback, perform idempotent checks (e.g. verify payment reference, ensure webhook not processed already) before creating order
• Persist metadata about payment method, attempt timestamp, webhook status, etc. on cart / order - for auditing, reconciliation, and support
• Gracefully handle failures: payment rejected / timeout / webhook not received - show appropriate UI to user, perhaps allow retry or cancel flow

Hope this will helps you!

Thanks,

Hi Sunil,

Thanks for the reply, this was posted a while ago and we've solved the issues since then.

We ended up with a flow that:

• Converts the cart to an order immediately on clicking "Pay", but in a "pending" state.
• If there's an immediate failure, or a webhook is received indicating non-success, we update the order to "Payment Failed", which also gives the customer the ability to retry payment.
• If a webhook is received indicating success, the order is transitioned to the next state.

A lot of your suggestions are exactly what we implemented, so good to have that validated.

Thanks.

Great to hear that, and thanks for the update!

Your final flow sounds solid - converting the cart to an order in a “pending” state is a reliable pattern, and handling both webhook outcomes (success/failure) via state transitions is exactly how most async-payment platforms operate.

Glad to know the suggestions aligned with what you implemented.