Broadleaf Microservices
  • v1.0.0-latest-prod

Fulfillment Statuses and Transitions

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.

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:
This status is usually triggered by:

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:
This status is usually triggered by:

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

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