An abandoned checkout is created when:

• A customer begins an eCommerce Checkout process but doesn't complete it (for example, after closing their browser tab before putting in their payment details and making a payment).

• A customer who is also a site member creates a cart and closes their browser tab before proceeding to the checkout page. (Wix eCommerce creates an abandoned checkout entity with the cart details).

The Abandoned Checkouts API allows an app developer to help a customer recover their abandoned checkout. When a customer completes their checkout and makes a purchase, the checkout becomes an order.

An abandoned checkout contains buyer details, prices, reference to the initial cart or checkout, a URL for accessing the abandoned checkout, and more.

The eCommerce Abandoned Checkouts API provides functionality for getting information about an abandoned checkout and retrieving a list of abandoned checkouts. You can also listen for events when an abandoned checkout is created and recovered.

To assist in migration from the Stores to eCommerce APIs, please refer to the Stores Cart to eCommerce Checkout Conversion Table.

• Recovered: When a customer returns to their abandoned checkout and completes the checkout.

• Activities: This property is only relevant if the site owner set up automations in the Dashboard. The activities property is a list of all automation activities performed by Wix Automations regarding the abandoned checkout. Wix Automations updates the activities field for each actvity in the automation flow. For example, if a site owner set up an automation to send a notification to a site visitor an hour after their abandoned checkout is created, Wix automations does the following:

  • Updates the activities field to SCHEDULED when the abandoned checkout is created.
  • Updates the activities field to NOTIFICATION_SENT after an hour, when the notification is sent to the site visitor.

  Other actvities include:

  • EMAIL_SENT
  • EMAIL_NOT_SENT
  • TASK_CREATED

This article shares some possible use cases your app could support, as well as an example flow that could support each use case. You're certainly not limited to these use cases, but they can be a helpful jumping off point as you plan your app's implementation.

If a site visitor starts a checkout but doesn't complete it, you can redirect them to their checkout page. You can also check whether the site visitor has recovered their abandoned checkout and completed the purchase.

To redirect the site visitor to their checkout page:

1. Using the Abandoned Checkout Created Webhook, listen for an event when an abandoned checkout is created (a checkout was not completed).

2. Save the newly created abandoned checkout's ID (entityId field) and checkoutUrl from the above webhook's payload. Then send a marketing campaign with the checkoutURL to your site visitor, redirecting them to their checkout page.

3. After the marketing campaign, call Get Abandoned Checkout with the abandoned checkout's ID. Then check the status field in the response to see if the abandoned checkout has been recovered.

The table below shows field support for filters and sorting for the base set of abandoned checkout properties.

Field	Supported Filters	Sortable
id	$eq, $ne, $in, $exists
createdDate	$eq, $ne, $gt, $lt, $gte, $lte	Sortable
updatedDate	$eq, $ne, $gt, $lt, $gte, $lte	Sortable
status	$eq	Sortable
buyerInfo.email	$eq
totalPrice.amount	$eq, $gt, $lt, $gte, $lte	Sortable
totalPrice.convertedAmount	$eq, $gt, $lt, $gte, $lte	Sortable