FAQs
What should I do if I receive an INVALID_SIGNATURE result code in the API response?
An INVALID_SIGNATURE error indicates a mismatch between the provided signature and the one expected by the server. The error commonly arises for the following two reasons:
- Incorrect syntax of
Content_To_Be_Signed: The content intended for signing must follow the syntax in the following sample Java code:
String.format("%s %s\n%s.%s.%s", "POST", "/v2/pos/syncProduct", "375Y93*******P00050", "2023-08-28T22:16:07+08:00", bodyJsonStr)- Improper signature algorithm: Ensure that the digital signature is generated using RSA with SHA256 and that the signing key is a 2048-bit RSA key.
Why do the products not appear in the store after syncing them via the syncProduct API?
Products synced via the syncProduct API must be included in the store menu before they can be displayed in a store. For a live store, the menu setup is completed by merchants in D-Store Console. However, in a testing environment, you need to contact your Solution Architect to set up the menu and publish it to the store.
How can I test the inquireOrderDetail API after integration?
The inquireOrderDetail API is designed to verify the status of orders that encounter exceptions. During testing, you can trigger this API by simulating exceptions via either of the following two methods:
- Simulate a createOrder request timeout: Place an order on the provided test store website to initiate a createOrder request from D-Store. Then intentionally delay your response to the request until it times out in eight seconds.
- Simulate an order acceptance timeout: Place an order on the provided test store website to initiate a createOrder request from D-Store. In your response to this request, set autoAccept to
FALSE. This indicates the order is awaiting the merchant's manual acceptance. Ensure that you do not provide any order updates until the order acceptance window passes. To expedite the testing process, you can request your Solution Architect to set a shorter timeframe for the acceptance window.
Why do some modifiers or modifier groups disappear from a previously functioning store?
Modifiers or modifier groups (both known as subproducts) might disappear after the POS provider performs a full product synchronization via the syncProduct API for another store under the same merchant. The issue often arises if the later synchronization assigns different subproducts (identified by their unique posProductId) to an existing top-level product. The new synchronization request overwrites the subproducts for the same top-level product in all stores. Consequently, stores that completed the product synchronization earlier will encounter missing subproduct issues if the updated subproducts are not included in their product list. Refer to the following example and sample codes for a better understanding of this scenario:
- Prior full product synchronization for Store A
The following sample code shows that Store A synchronizes a top-level product, Lemon Tea (s001), and includes the Honey Level modifier group (g001) with the Less Honey modifier (m001):
{
"products": [
{
"posProductId": "s001",
"type": "SINGLE",
"status": "AVAILABLE",
"name": "Lemon Tea",
"price": {"currency": "SGD", "value": 1000},
"subProducts": ["g001"]
},
{
"posProductId": "g001",
"type": "GROUP",
"status": "AVAILABLE",
"name": "Honey Level",
"quantityRule": {"min": 1,"max": 1},
"subProducts": ["m001"]
},
{
"posProductId": "m001",
"type": "MODIFIER",
"status": "AVAILABLE",
"name": "Less Honey",
"price": {"currency": "SGD","value": 0},
"quantityRule": {"min": 1,"max": 1}
}
]
}- Later full product synchronization for Store B
The following sample code shows that Store B synchronizes the same top-level product, Lemon Tea (s001), with the Honey Level modifier group (g001), but a different Less Honey modifier (m002, a different modifier with the same name):
{
"products": [
{
"posProductId": "s001",
"type": "SINGLE",
"status": "AVAILABLE",
"name": "Lemon Tea",
"price": {"currency": "SGD", "value": 1000},
"subProducts": ["g001"]
},
{
"posProductId": "g001",
"type": "GROUP",
"status": "AVAILABLE",
"name": "Honey Level",
"quantityRule": {"min": 1,"max": 1},
"subProducts": ["m002"]
},
{
"posProductId": "m002", //A different ID indicates a different product despite the same name
"type": "MODIFIER",
"status": "AVAILABLE",
"name": "Less Honey",
"price": {"currency": "SGD","value": 0},
"quantityRule": {"min": 1,"max": 1}
}
]
}- Impact on Store A's product list
The following sample code shows Store A's updated product list following the full product synchronization for Store B. In this list, the modifier in the Honey Level modifier group (g001) becomes m002. However, this new modifier is not added to the list:
{
"products": [
{
"posProductId": "s001",
"type": "SINGLE",
"status": "AVAILABLE",
"name": "Lemon Tea",
"price": {"currency": "SGD", "value": 1000},
"subProducts": ["g001"]
},
{
"posProductId": "g001",
"type": "GROUP",
"status": "AVAILABLE",
"name": "Honey Level",
"quantityRule": {"min": 1,"max": 1},
"subProducts": ["m002"] //The associated modifier is updated
},
{
"posProductId": "m001", //The available modifier is still the original one
"type": "MODIFIER",
"status": "AVAILABLE",
"name": "Less Honey",
"price": {"currency": "SGD","value": 0},
"quantityRule": {"min": 1,"max": 1}
}
]
}To address the issue, the POS provider needs to perform full product synchronization again and adjust product IDs with either of the following two choices:
- (Recommended) Use consistent IDs across stores: Apply identical posProductIds for equivalent top-level products and subproducts across all stores. This method is recommended because it simplifies product management for the merchant.
- Use distinct IDs in different stores: In cases where it is impossible to maintain consistent posProductIds, or the merchant desires diverse subproducts for equivalent top-level products in different stores, the POS provider can use distinct posProductIds for all products in each store. This ensures no product overlaps and that the product discrepancies in one store do not affect other stores.