Problem Handling
The basket transaction cannot be paid by the Payment Service if the basket contains some problematic items, e.g. the customer age must be checked, the amount or quantity limit is exceeded, a rescan is needed, etc.
Problems are handled differently according to the basket clientType (SELF_SCANNING, SCANLESS etc.) and according to the request attribute registerProblematicItem in item registration. In each process, it is defined for each problem if the process can be finished and the problem is stored on the basket or if the process is aborted and the client must repeat the call with improved data. Example: The Item Registration Service receives a request to add an unknown item. If the basket was created by GK GO, the line item is created with a problem, and the basket must be checked by an employee. If the basket was not created by GK GO and registerProblematicItem = false, no line item is created but an error is returned to the client. The client displays an error message to inform the user directly.
The problems are stored on the specific line item or on the transaction level in transaction extensions. The problemLevel attribute on the basket provides the information whether the basket contains any problems and with which importance. The problemLevel attribute can have the following values:
- Empty - no problem
- MEDIUM - at least one medium problem with the basket, no critical problem
- CRITICAL - at least one critical problem with the basket; the problem can be solved by a full rescan only
The Basket Service provides the following endpoint to request the list of problems:
GET /baskets/{basketId}/problems
If the problematic item is removed, the problem is also removed from the basket.
The checkout process checks if the basket contains any problems. If it does, the transaction is suspended and must be finished on a Self Checkout. Additionally, for defined problems with the problemLevel = CRITICAL, a full rescan is required.
The list of potential problems is described in the Basket Service API.