Version History
This section describes changes made in subsequent releases and the new features in this API. If not otherwise stated, changes are implemented in the Public API Cloud and Public API Edge.
| Release | Enhancements | API Version |
|---|---|---|
| 2025.2 | To improve resiliency and maintainability along with the performance ; internal orchestration changed to point new CPaaS services. The orchestration logic doesn't involve contract change, making it non-breaking change ideally. But it does constitute a breaking change with respect to Multiversion. Hence a new version is introduced to public API, v2. For backward compatibility, the deprecated version (v1) remains functional until further notice (max 12 months), but we recommend that you use the new option instead. | v2 |
| 2025.2 | API client is enabled to verify the Health Check status for the newly added backend services: Mapping Service and Restrictions Service along with the other dependent backend services. | v1 |
| 2025.2 and Patch in API 2024.2 | We improved the POS flow by allowing it to override some basket restriction violations with appropriate approval by the store manager. This ensures that the transaction will not be terminated with an exception when a sale restriction validation returns false. CPaaS now returns information on what restriction failed, why it failed, and if it is allowed to bypass. To support this implementation, request and response contracts are extended for the following endpoints: - POST /transactions/basket/total - POST /transactions/basket/payment - POST /transactions/basket/item The optional string field below has been added to the request contract. - info.TransactionType The array properties below have been added to the response contract. - failedGeneralRestrictios - failedSaleRestrictions The below string field is deprecated from the request contract. - info.type Orchestration changed for a few endpoints. POST /transactions/basket/total - To validate sales restrictions and collect required customer data during sales validation failure with a bypass condition, the endpoint now calls the new CPaaS Restriction Service endpoint. - To populate missing tax and product groups, PAG is calling the CPaaS Mapping Service. Orchestration change for POST /transactions/basket/payment - Added the additional call to the Restriction Service. - The backend call to /calculatetaxesWithPayments is removed. Orchestration change for POST /transactions/basket/item - Additional calls to Restriction Service and Mapping Service were added. | v1 |
| 2024.2 | Depending on regional requirements, a fiscal session for a miscellaneous transaction (for instance, Store Receipt, Archive Receipt, Reprint Receipt, No Sale, Sign Off) can be optional. To support regions that do not require fiscal session for miscellaneous transactions, we extended the following endpoints: POST /transactions/miscellaneous/start and POST /transactions/miscellaneous/finish with the optional request field: fiscal.externalLocationId, indicating business unit Id. For regions that do not require fiscal session for miscellaneous transactions (fiscalSessionId is not present), required data can be retrieved using externalLocationId. | v1 |
| 2024.2 | To enhance the customer corrections handling, we extended the POST /transactions/basket/finish endpoint with the following optional request fields, representing a document chain: info.documentChain [] - info.documentChain.documentCode - info.documentChain.documentType - info.documentChain.additionalInfo - info.documentChain.additionalInfo - info.documentChain.additionalInfo.attribute - info.documentChain.additionalInfo.value - info.documentChain.linkedDocuments [] - info.documentChain.linkedDocuments.linkedTypeId - info.documentChain.linkedDocuments.linkedDocumentCode This extension enables CPaaS to apply region-specific validation rules on a structure of the full document chain without calling CTR. The POS system stores the customer correction data in the Electronic Journal. Only after successful validation, VRx saves the document in CTR. | v1 |
| 2024.2 | To improve the system performance and resiliency we changed System APIs and backend calls sequence, reflecting changes in Backend services: - new backend calls sequence in the POST /transactions/basket/payment endpoint: POST /api/v1/restrictions/validate (Basket Service) > POST /api/v1/restrictions/validate (new endpoint in the Basket Service, combining the payments/validate and payment-rounding/calculate logic) > POST /api/v1/taxes/recalculateWithPayment (new endpoint in the Tax Service) - new backend calls sequence in the POST /transactions/basket/total endpoint: POST /api/restrictions/validate (Basket Service) > POST /api/transactions/basket/validate (Fiscal Service) > POST /api/taxes/calculate (Tax Service, logic extended to include rounding) > POST /api/payments/suggestedPayments (new endpoint in the Basket Service) | v1 |
| 2023.3 | In particular countries (like Norway or Portugal), to prevent manipulations in cash register systems, all sales transactions must be digitally signed sequentially, using an encrypted hash of the previous transaction. The use of signatures from the previous receipt ensures a chain of signed data that should not be broken. To directly support the implementation of signing process we have added the new optional request array info.previousFiscalData [] to the following endpoints: POST /transactions/basket/start, POST /transactions/cashflow/start, POST /transactions/miscellaneous/start, and POST /transactions/basket/finish. This allows the POS to load fiscal data from previous response and apply it to the next sequential request to CPaaS finish transaction. To maintain consistency with private CPaaS API: - we deleted optional request objects: header.* and details.* from the endpoint POST /transactions/basket/start - we deleted optional request object header.* from endpoints: POST /transactions/cashflow/start and POST /transactions/miscellaneous/start | 1.5.0 |
| 2023.3 | In some countries, such as Norway, there is requirement to include additional information for each tax calculation (on item level) in SAF-T report. To enable holding additional tax related metadata, we have added additional fields to the following endpoints: POST /transactions/basket/total (in response) and POST /transactions/basket/finish (in request): details.items[i].taxes[ii].attributes, details.items[i].taxes[ii].attributes[iii].id, details.items[i].taxes[ii].attributes[iii].description, details.items[i].taxes[ii].attributes[iii].value | 1.5.0 |
| 2023.3 | To support primary document numbering by the POS when integrating with CPaaS, we extended request for endpoint POST /transactions/basket/finish with the following new fields: info.attributes [], info.attributes.key, info.attributes.value, info.attributes.order. The POS system uses the new Info.attributes property to send all parts of the document number (key-value pair with order property) to CPaaS. | 1.5.0 |
| 2023.2 | To POST /transactions/basket/total, POST /transactions/basket/payment, and POST /transactions/basket/finish endpoints we have added the following new fields, in requests and responses: - details.items[i].taxes[ii].isReturn, details.items[i].originalTaxes[ii].isReturn, details.taxes[i].isReturn, details.originalTaxes[i].isReturn, details.total.isReturn. | 1.3.16 |
| 2023.2 | To the following endpoints: - Basket APIs: POST /transactions/basket/finish; POST /transactions/basket/abort - Cash Flow APIs: POST /transactions/cashflow/finish; POST /transactions/cashflow/abort - Miscellaneous APIs: POST /transactions/miscellaneous/finish; POST /transactions/miscellaneous/abort we have added events array to request and response. New fields added in request: details.events, details.events[i].id, details.events[i].eventType, details.events[i].externalEventType, details.events[i].timestamp New fields added in response: basketSummary.events, basketSummary.event[i].id, basketSummary.event[i].fiscalData, basketSummary.event[i].fiscalData[ii].key, basketSummary.event[i].fiscalData[ii].value, basketSummary.event[i].fiscalData[ii].mustArchive. | 1.3.16 |