Order Management at Groupon

Written by Nitin Patel & Sweta Choudhary

An order management system is the heart of any e-commerce marketplace. It is responsible for creating orders and initiating the order fulfillment process. It interacts with other systems such as payments processing, inventory, messaging to track the status of order payments and manages the order lifecycle. The Order Management System is the hub of most e-commerce businesses and it is no different at Groupon.

This article aims to provide an overview of Groupon’s order management system (henceforth referred to as “The Orders System”). It will cover the use cases that the Orders System supports, workflows, data model, and life cycle.

Thanks to the way e-commerce is thriving in the current times, most folks already have an external view of how the order processing might work. But every system is unique, and what makes Groupon’s Order Management System unique is the kind of use cases it supports.

Use cases

Purchase & Post-purchase

Groupon customers can buy a wide variety of deals on Groupon’s website, such as vouchers, products that require shipment (commonly referred to as Goods), hotels, movie and event tickets, 3rd party deals, etc. These deals belong to different types of inventories and each inventory has a different life cycle requirement. There are different inventory services to manage different types of inventories. The Orders System supports the purchase of all types of inventories and orchestrates the order processing. It supports various post-purchase actions such as order lookup, update, cancellation, etc.

Shopping Cart

The Orders System also enables a shopping cart experience by allowing customers to purchase different types of inventories in a single order. For instance, customers can buy a Yoga mat and a voucher for Yoga classes at a local yoga center in the same order.

Order Lifecycle Customisation

It also allows the inventory services to customize the order lifecycle as per their needs. For instance, for the Goods orders placed by customers in North America, the payment should be captured only once the product is ready to be shipped. As another example, orders for live events should be created within a payment collection deadline so that the customers are charged before the event, in which case the payment processing is prioritized for live event orders over others. Also, given the fact that Groupon operates in many countries in North America, EMEA, and APAC, the customer location and local laws and regulations play a role in the way an order is processed.

Voucher Trade-In & Exchange

It supports ‘Voucher Trade-In’, where a voucher can be swapped out for purchasing some other deal. Customers can also exchange certain types of deal purchases. For instance, exchange a pair of shoes for a smaller or bigger size.

Groupon Bucks

The Orders System also manages “Groupon Bucks,” which are wallet equivalent for Groupon. It enables customers to pay for an order using their Groupon Bucks. During order cancellation, customers can choose to get the refunds in the form of Groupon Bucks, which can be used to make purchases within Groupon later.

The Orders System is a highly available system with an uptime of 100% in 2020. It serves more than 50 million requests per day.

Order Workflow

Let’s talk about the set of actions that are involved at a very high-level when a Groupon customer places an order. Fig-1 shows a checkout page on Groupon’s website, where customers place an order by clicking the ‘Place Order’ CTA.

Fig-1 Checkout Page

This triggers the order creation and processing flow which is handled by the Groupon API (henceforth referred to as “GAPI”) platform. GAPI has an aggregator layer that serves client requests by calling multiple backend services (20+) such as the Deals Platform, Inventory Services, and the Orders System. The order creation flow that is orchestrated by the GAPI involves a few notable steps such as “Inventory reservation” followed by “Order creation”. Once the order is successfully created, the rest of the order lifecycle is managed by the Orders system. Fig-2 shows a simplified version of the checkout process.

Fig-2 Checkout process

• Inventory reservation is handled by the appropriate inventory service, where one or more Inventory Units are allocated for the order.
• Order creation is handled within the Orders System where an order record is created and persisted.
• Once the order creation is successful, the customer will be redirected to the order confirmation/receipt page.
• In the background, the Orders System initiates the order collection/processing flow which involves steps such as Fraud prevention checks, preparing payment transactions and triggering payments, publishing the order state change events, and performing post-payment actions.

FIS aka “Federated Inventory Spec”

The GAPI and the Orders System integrate with various inventory services, each with varying lifecycle requirements, and provide a consistent purchase experience to the customers. Also, the overall system is extensible in nature, making it very easy even to onboard a new inventory service. This is made possible by the Federated Inventory Specification.

FIS defines a standard API contract that all inventory services must implement, for actions such as checking inventory availability or reserving an inventory, which GAPI calls during the purchase flow.

FIS also defines the contract for the inventory lifecycle based on the state changes in the Orders System. Let’s look at the orders data model now.

Order Data Model

The Orders data model until a few years ago supported purchasing only a single deal within an order. But it has evolved over time, and it now supports a shopping cart experience, where an order can contain multiple types of deals having different quantities. It supports varying lifecycle and payment processing requirements for different deals within a single order.

Let’s start with a broad overview of various entities that comprise the orders data model and understand the order lifecycle and possible state transitions. Fig-3 shows an ER diagram depicting a simplified version of the orders’ data model.

Fig-3 Orders data model

Entities meant for the Order state

• Consumer/User: Consumer entity refers to a Groupon customer and is not a part of the Orders system. An order is always associated with a consumer.
• Parent Order: The key entity of the Orders system, represents a shopping cart. It holds details that apply to the whole order, such as the reference to the consumer who placed the order.
• Line Item: This can be mapped to an item in the shopping cart. A Parent Order can have multiple LineItems. It holds information about the line item, such as the price (per unit) and the quantity being purchased.
• Order Item Unit (OIU): OIU is the smallest/fine-grained entity of an order, and maps to an instance of the line item it belongs to. A LineItem can have multiple OIUs — the number of OIUs is equal to the quantity set at the line item level during order creation. The state of an OIU (unit_status) depends on the payment action performed on the unit. An OIU is mapped 1:1 with the Inventory system’s entity called “Inventory Unit”. In an upcoming section, we will cover how OIU state changes influence the Inventory Unit lifecycle.

Entities meant for Payment processing

Before explaining the entities that enable payment processing, let us briefly talk about payment processing itself.

The Orders System relies on the Global Payments Platform(GPP) for processing payments using standard payment methods (such as credit cards, Paypal, etc.), and on the “Groupon Bucks Provider” for payments using Groupon Bucks. The Orders System has defined a common contract that helps integration with both the GPP and the Groupon Bucks Provider.

Most of the payment transactions at Groupon go through the 2 step payment process, i.e, authorize and capture. For the sake of simplicity, think of these two actions as a two-phase commit for payments. These steps are orchestrated by the Orders System by default. The inventory services can also override the default behavior and trigger these steps when an Inventory Unit is ready for payment.

There are other payment actions that are possible on an order viz., refund, cancel, and chargeback. Refund and cancel actions are meant to allow order cancellations. Whereas chargeback action is applicable in the case where the customer disputes the transaction with his bank.

Let’s now look at the entities that enable payment processing:

• Order Event: Represents an event that occurs in an order's lifecycle. Each type of event is mapped to a payment action (action field), which could be, authorize, capture, refund, cancel, or chargeback. An event is triggered so that a payment action can be performed on the OIUs of an order. An order can have multiple order event records, each created to perform the payment action that the event maps to. There are certain rules that govern when an event can be triggered for an OIU in a particular state and the sequence in which the event can be triggered. The Orders System defines a state-machine that encompasses all these rules. These rules are covered in the upcoming section.
• Order Payment Transaction (OPT): Represents a payment transaction that executes the payment action corresponding to an order event. It holds a reference (external_reference_id) to the payment transaction on the payment provider side (could be GPP or the Groupon Bucks Provider) depending on the payment method. In most cases, there will be one OPT record mapped to an order event. There could also be multiple OPTs associated with an order event as well — for instance when an order is paid with a combination of credit card and Groupon Bucks.

State Transitions

An order can have one or more OIUs each having a different status. What it means is that there is no such thing as “state” for a Parent Order. Rather the OIUs are the entities that have states and they have state transitions. Fig-4 shows the possible OIU states and transitions that are allowed between states. The states again are based on the payment actions that are allowed on the unit, viz., authorize, capture, refund, cancel, or chargeback.

Fig-4 OIU state transitions

Let’s look at what each state (the ones in the order processing flow) means, and the typical sequence in which the state transition happens:

1. pending: This is the initial state of the OIU which is set at the time of order creation.
2. authorize_requested: An OIU goes from pending state to authorize_requested state when the Inventory Unit is ready for payment authorization.
3. authorize_succeeded: An OIU goes from authorize_requested to authorize_succeeded state upon successful payment authorization.
4. authorize_failed: An OIU goes from authorize_requested to authorize_failed state after an unsuccessful payment authorization. Note that the OIU is moved back to authorize_requested by the orders if the payment can be auto-retried, and if the inventory service wants orders to auto-retry payment failures.
5. capture_requested: An OIU reaches this state after successful payment authorization when the Inventory Unit is ready for payment capture.
6. capture_succeeded: An OIU goes from capture_requested to capture_succeeded state upon successful payment capture.
7. capture_failed: An OIU goes from capture_requested to capture_failed state after an unsuccessful payment capture. Note that the OIU is moved back to capture_requested by the orders if the payment can be auto-retried, and if the inventory service wants orders to auto-retry payment failures.

Note that capture_succeeded may not be the terminal state in case if the customer requests a refund. If the request is accepted, the OIU goes from capture_succeeded to refund_requested, and then to either refund_succeeded or refund_failed state depending on whether the payment was successfully refunded or not.

Inventory Fulfilment

Inventory Unit state transition, in general, is dependent on the payment processing status of the corresponding OIU. The Order Management System emits status change events for every OIU state transition. These events are consumed by the corresponding Inventory Service, which then transitions the Inventory Unit to an appropriate state within its system.

The meaning of inventory fulfillment is different for different Inventory Services. It could mean allocating voucher barcodes for voucher deals, instructing a warehouse to ship items for Goods deals, or booking a previously reserved event ticket for an events deal. So, the inventory system decides when the fulfillment process should be initiated. In most cases, it is triggered after the OIU moves to authorize_succeeded state.

Conclusion

We hope that this article has provided some insights into Groupon’s Order Management System. The system is ever-evolving as we continue to support new use cases and innovations. Stay tuned for other interesting topics which will be covered in future posts in this series!