@softobotics/storefront-checkout

Headless checkout: shipping/billing/payment mutations, Stripe and Razorpay payment-intent creation, and order-confirmation lookup, built on @softobotics/storefront-vendure-client, @softobotics/storefront-account, and @softobotics/storefront-cart.

Two different settlement models

• Stripe: fully async. createStripePaymentIntentAction only creates a PaymentIntent for the client to confirm with Stripe.js — addPaymentToOrder is never called from here. The order settles later via webhook (admin context); order confirmation polls/waits for orderPlacedAt.
• Razorpay: settles synchronously. createRazorpayOrderAction creates the order, openRazorpayCheckout opens Checkout.js (script must already be loaded on the page — this package doesn't load it), and placeRazorpayOrder calls addPaymentToOrder directly with the signed checkout response. The webhook is only a reconciliation backstop.

Treat these as genuinely different flows, not two implementations of the same thing — a fix to one's test coverage says nothing about the other's.

fetchOrderByCode

Vendure only grants anonymous access to orderByCode once the order has actually been placed. Until then (e.g. right after a Stripe redirect, before its webhook has settled) the query is denied with an auth error — fetchOrderByCode treats that as "still processing" (returns null) rather than throwing, so the caller can show a processing state instead of an error.

Peer dependencies

@softobotics/storefront-account (for CreateCustomerAddressMutation) and @softobotics/storefront-cart (for TransitionOrderToStateMutation and dispatchCartChanged) — both one-directional; neither package depends back on checkout. See their own READMEs for why those specific exports live where they do.