Baskets
| Associated Terms |
|---|
| Transaction, Receipt, Cart, Order, Return |
| Parameter Names Used |
|---|
basket_id, retailer_basket_code, receipt_id, supplementary_basket_code |
Contents
Overview
In the Spaaza data model, a ‘basket’ represents an end-user or customer transaction stored in the backend. Each basket is associated with a Spaaza retailer or customer organisation and is sent to Spaaza either via Spaaza’s add-basket API endpoint or imported in bulk by Spaaza using one of our operations import scripts.
It is also possible to send the contents of a provisional basket to Spaaza via our get-basket-priceAPI endpoint and Spaaza will respond with any adjustments to that basket without storing the basket in the backend. See the ‘Provisional or adjusted Basket’ section below.
When purchased items are returned, this is not seen by Spaaza as an adjustment to a confirmed basket (see below for the distinction between confirmed and provisional baskets), but as a new basket containing returned items which are linked to an original purchase basket. For more information, please see our documentation on ‘Processing a return inline’.
Please see the documentation below for more information about types of basket in the Spaaza model, and some of the important properties and concepts associated with baskets.
Types of basket
Spaaza has two types of basket. These are explained below.
1. Provisional or adjusted basket
Spaaza’s data model has the concept of an adjusted or provisional basket. This is not a basket which is stored in the Spaaza backend (see the confirmed basket section below for ones which are), but is designed to return adjustments to a basket which apply to an individual end-user, and which can be applied to the confirmed basket or transaction when it is sent by the API client. It’s possible to request an adjusted basket multiple times and receive a different response each time.
Spaaza’s provisional basket API endpoint, get-basket-price, is used to request adjustments to the supplied basket, which may include vouchers the end-user (customer) is entitled to use, and discounts at the item or basket level.
A good example of how a provisional basket works is as follows:
- Customer logs into e-commerce site and is opted into the site’s loyalty programme
- Customer adds items to cart in e-commerce site
- E-commerce site makes a request to Spaaza’s get-basket-price API endpoint, including information about the customer, items in the basket, prices and total order value
- Spaaza responds with an adjusted basket, including vouchers the customer has indicated they would like to spend and an adjusted total order amount
- E-commerce site adjusts total amount the customer pays based on the response received from Spaaza
- Customer pays for the order in the e-commerce site
- E-commerce site sends confirmed basket with adjusted values
2. Confirmed basket
When a basket is sent to Spaaza using our add-basket API endpoint, it is stored in the Spaaza database. Unlike in some e-commerce systems, a confirmed basket stored in Spaaza is immutable and cannot be updated once it has been transmitted - this includes payment and tax details.
Spaaza retailers and customer organisations also make use of the facility to import large numbers of transactions in bulk. This is performed on a custom basis by Spaaza using our internally-available bulk import scripts and is usually carried out to import large numbers of historical baskets.