Order creation edge cases

Ask about this Page
Copy for LLM
View as Markdown
When you implement a checkout flow, one key decision is whether to create the Order before or after a successful payment. Each approach affects customer experience, stock management, and revenue tracking differently. Creating an Order after payment is often preferred because it simplifies operational flow and edge case handling. Creating an Order before payment lets you reserve inventory immediately, but introduces risks around unpaid Orders.

This guide covers edge cases for both approaches and strategies for generating unique order numbers.

For a comprehensive guide to each checkout stage, including guest checkout, shipping, payment integration, and Cart integrity, see the Implement a custom checkout learning module.

Create an Order after successful payment

Creating an Order after a successful payment simplifies operational flow because no cleanup is needed if payment fails. However, redirect-based payment methods introduce scenarios where payment succeeds but Order creation doesn't happen automatically.

Unreachable redirect URL

The order-success redirect URL of the web store can become inaccessible due to network issues, or the customer might close the browser tab. In both cases, payment succeeds but the corresponding Order is not created.

A viable method to address an unreachable redirect URL is to asynchronously create an order based on payment transaction changes. These changes are guaranteed through asynchronous notifications from the PSP. You can query for Messages of type PaymentTransactionAdded or PaymentTransactionStateChanged, or subscribe to them. These Messages link to the Payment through the resource field. Every Payment correlates with a Cart, giving you the information to decide if a Cart should become an Order.

Multiple successful payments

Multiple successful payments on a single Cart can occur when a customer opens two browser tabs for the same Cart. If both payments use a redirect type (for example, credit card and PayPal), they complete independently, resulting in double payment.

To address duplicate payments, refund one of the successful payments. You can use the Payment Message to determine if a Cart has too many successful Payments and subsequently initiate a refund.

Mismatched payment and cart amounts

During checkout, a customer might navigate with two browser tabs, one displaying the cart and the other showing a redirected payment with a fixed amount. If the customer adds more items to the cart, the cart value and the paid amount can differ.

As a solution, validate the cart post-payment to ensure the cart amount aligns with the paid amount. If there's a discrepancy, cancel the payment and request the customer to pay again. Refunds can also be executed asynchronously through the PSP notifications.

Create an Order before successful payment

Creating an Order before payment lets you reserve inventory immediately through the Order's inventoryMode. However, unpaid Orders can affect stock, revenue data, and Cart modifications.

Unfinished payments and stock issues

If a customer doesn't complete the checkout process or cancels a payment, the reserved stock within an Order won't automatically release. This poses a risk, as automation or high user activity can deplete the web store's stock. To mitigate this, consider using a continuously updated external Inventory Management System (IMS) or a real-time inventory check before initiating payment.

False revenue display

Orders that remain unpaid might still display in the Merchant Center dashboard (or a similar monitoring tool) as revenue, providing an inaccurate representation of actual earnings.

Bestsellers misrepresentation

Unpaid Orders inflate sales metrics in the Merchant Center and any connected analytics tools. Products linked to unpaid Orders appear as best-sellers, skewing inventory planning and merchandising decisions.

Order modification restrictions

Once an Order is created, the original Cart can no longer be modified. If a customer wants to adjust items after payment was initiated but before it completes, you must cancel the Order and create a new Cart.

Voucher limitations

One-time vouchers are consumed when the Order is created. If a customer doesn't finalize payment after a redirect and wants to modify the Cart instead, the voucher is already spent. Creating a new Cart based on the previous one compounds this problem, especially if a product has limited stock and is already linked to the unpaid Order.

Generate a unique order number

Regardless of when you create the Order, you need a unique and human-readable order number. The order number typically links the payment provider to Composable Commerce and serves as a reference for customers.

To generate such order numbers, you have several options:

  • Alphanumeric Order Numbers of a certain length that your BFF pre-calculates:
    1. Generate a random order number.
    2. Set orderNumber on the OrderFromCartDraft and call CreateOrderFromCart to create a new Order, or perform the Set Order Number update action on an existing Order.
      If the Create or Update method fails with a DuplicateField error on the orderNumber field, an Order with that order number already exists. Go back to step 1.

    The longer the order number (8 characters allows for 2.8 trillion variations), the less likely it is to conflict with an existing order number. Using prefixes, such as a date, may be another way to achieve uniqueness for your order numbers.

  • Third-party service: use your BFF to call a third-party service to produce the order number or generate it directly within the BFF.
  • Generating numbers asynchronously: generate order numbers during post-order processes, such as exporting to an order management system (OMS) or importing from an external system.