Guides

Order API

The order API is used to upload historic operations, to allow if needed to link existing historical tickets (sales, returns or mixed tickets) to the customers that are being created.

🚧

This is not always needed as Wapping provides an easier and simpler method to integrate previous customer order information wich doesn't require any integration and is often enough for most business needs.

This API will only be needed when the business wants to upload all the historic to have the detailed order information of the customers previous of having Wapping.

When using the Order API, orders should be sent individually, rather than in bulk, for each customer upon receiving the webhook of the creation of a customer.
This process asumes that an existing Webhook connection is established, as the customerId will be needed to link the customer with the order.

🚧

Note that this process will happen when already launched to production, as it requires the customers to register and validate organically to obtain the correct customerId.
In summary, there will not be a bulk syncronization process while onboarding, but instead an organic upload of the orders from the customers that are being validated.

To achieve this the Order API can be used, specifically the Create Order method. This method must be called once per customer transaction, again only when the customer has been validated and the customerId is provided.


Order Object Structure

The Order object includes several key sections. Below is the recipe describing all the relevant porperties.



Lines

The line array reflects all the lines that are included in the order, containing information of the product with it's properties, external discounts applied if any, quantity and the subsequent line amount (product unit price * quantity = line amount).

This lines are identified by lineCode, which is the identifier Wapping will use in the response to reference the same line to apply discounts if needed.


Product

The product contains the information to identify what is being sold, the important bits are the unitPrice and product code, to identify and link in case it exists, or create it in case it doesn't.


Receipt

The receipt allows to upload the digital representation of the printed ticket.

It is supported both if the ticket is already available online via the url property, if is digitalized (pdf, image, etc) or even if it's just an array of bytes, in wich case Wapping would digitalize and disponibilize it via public URL.


Return Information
For the returns it is not mandatory to reference the original sale transaction as this is a historic operation.
Nevertheless, if the association is needed, it can be achieved ensuring proper linkage using either:

  • traceReturnId: using the Wapping ID of the sale line

    OR the combination of:

  • shopCodeSale, posCodeSale, orderCodeSale, lineCodeSale: using the business codes to allow more flexibility

🚧

Make sure the sale is already loaded as it won't link the return if it's not previously on the system. This is not mandatory.