Fulfillment Statuses and Transitions

Table of Contents

Overview
Default Statuses

Overview

Here is a list of all the default statuses available for Order Fulfillments, as well as how the transitions to each occur.

See Changing Status for the implementation details of changing between these statuses.

Default Statuses

New

NEW

The status a fulfillment starts in when it is newly generated in the CartOrderFulfillmentGenerationService.

Capturing Payment

CAPTURING_PAYMENT

Indicates that payment is currently being captured for the fulfillment.

Note: Capturing payment for the fulfillment potentially involves claiming amounts that were previously captured during the checkout process.

See OMS Payment Capture

Status change is handled by:

CapturingPaymentStatusChangeHandler

Fulfillments can flow to this status from:

NEW

This status is usually triggered by:

API call to status change
AutoCaptureVirtualOrderCreatedListener when a virtual fulfillment is generated during order creation (see Auto-capture After Order is Created)
FulfillmentCaptureWebhookListener when a payment transaction results are received via a webhook, the transaction was successful, and all the captures are completed.

Moving to this status initiates:

FulfillmentCapturingPaymentListener to capture the entire fulfillment
- By default, this is used to capture payments which were only authorized on checkout. However, if checkout is configured to capture already, this capturing flow can be skipped and go straight to FULFILLING or FULFILLED instead (see Intermediate Fulfilling Step).

Capture Awaiting Result

CAPTURE_AWAITING_RESULT

Indicates that one or more capture transactions have been attempted for the fulfillment amount but the system is awaiting asynchronous transaction results. Note: if one of the captures is awaiting result in a multiple-payment scenario, then the order fulfillment will still have the awaiting result status.

Note	Most projects will not use this status. This status will only be used if support for asynchronous transaction results is enabled. Please refer to the following configuration section for more details.

Status change is handled by:

CaptureAwaitingResultPaymentStatusChangeHandler

Fulfillments can flow to this status from:

CAPTURING_PAYMENT

This status is usually triggered by:

API call to status change
FulfillmentCapturingPaymentListener when one or more for payment capture transaction is awaiting results.

Payment Capture Failed

PAYMENT_CAPTURE_FAILED

Indicates that the fulfillment payment was unable to be captured.

Status change is handled by:

PaymentCaptureFailedStatusChangeHandler

Fulfillments can flow to this status from:

CAPTURING_PAYMENT
CAPTURE_AWAITING_RESULT

This status is usually triggered by:

FulfillmentCapturingPaymentListener when any transaction for payment capture failed

Payment Captured

PAYMENT_CAPTURED

Indicates that the fulfillment payment was successfully captured.

Status change is handled by:

PaymentCapturedStatusChangeHandler

Fulfillments can flow to this status from:

CAPTURING_PAYMENT
CAPTURE_AWAITING_RESULT
PAYMENT_CAPTURE_FAILED (see Handling Failures)

This status is usually triggered by:

FulfillmentCapturingPaymentListener when all transactions for payment capture succeeded
API call to status change (see Handling Failures)

Fulfilling

FULFILLING

Indicates that the fulfillment is currently in the process of being fulfilled.

This status should be used when there is a system which can process virtual fulfillments. To use this status, the system responsible for virtual fulfillments must listen for this status change to FULFILLING, attempt to perform the fulfillment, and then trigger Broadleaf to update this status to FULFILLED or FULFILL_FAILED.

This intermediate status is not enabled by default (see Intermediate Fulfilling Step).

Status change is handled by:

FulfillingStatusChangeHandler

Fulfillments can flow to this status from:

NEW (if skipping payment capture; see Order Services Configuration)
PAYMENT_CAPTURED

This status is usually triggered by:

API call to status change
AutoFulfillPaymentCapturedListener after payment is captured, if configured to auto-fulfill (see Auto-fulfill After Payment is Captured)
AutoFulfillVirtualOrderCreatedListener after order is created, if configured to auto-fulfill (see Auto-fulfill After Order is Created)

Fulfill Failed

FULFILL_FAILED

Indicates that the fulfillment failed to be fulfilled.

Only used if FULFILLING is being used. This status is not enabled by default (see Intermediate Fulfilling Step).

Status change is handled by:

FulfillFailedStatusChangeHandler

Fulfillments can flow to this status from:

FULFILLING

This status is usually triggered by:

API call to status change
Custom message listener

Fulfilled

FULFILLED

Indicates that the fulfillment has been fulfilled.

Status change is handled by:

FulfilledStatusChangeHandler

Fulfillments can flow to this status from:

NEW (if skipping payment capture; see Order Services Configuration)
PAYMENT_CAPTURED

This status is usually triggered by:

API call to status change
AutoFulfillPaymentCapturedListener after payment is captured, if configured to auto-fulfill (see Auto-fulfill After Payment is Captured)
AutoFulfillVirtualOrderCreatedListener after order is created, if configured to auto-fulfill (see Auto-fulfill After Order is Created)

Cancelled

CANCELLED

Indicates that the fulfillment has been cancelled.

Status change is handled by:

CancelledStatusChangeHandler

Fulfillments can flow to this status from:

NEW
PAYMENT_CAPTURED
PAYMENT_CAPTURE_FAILED
FULFILL_FAILED

This status is usually triggered by:

API call to status change

Moving to this status initiates:

PaymentReversalFulfillmentCancelledListener to reverse authorize or refund payments, if applicable

Figure 1. Typical fulfillment flows for physical and digital (virtual) goods