Frequently Asked Questions
Frequently Asked Questions
Q: When calling the adjust charge, capture, refund charge and get transactional data endpoints, will the authentication be the same as it is for the catalog upload endpoint?
A yes, it is the same AWS IAM based auth
Q: Will there be an indicator in the order/purchases request that it is a card present transaction and JWO is doing the charging?
A: If the authEvents payloadType is FINANCIAL then the entry is credit cart otherwise if the value is SCAN_CODE then the entry type is app entry.
{
"authEvents": [
{
"id": "string",
"timestamp": "2025-05-02T00:05:18Z",
"location": "ENTRY",
"payloadType": "FINANCIAL",
"scanResult": {
"id": "string",
"type": "SHOPPER"
}
}
]
}
Q: Will card data such as the card type and last 4 be sent in the order/purchases request for card present transactions? We will need this data to tie it together with the shopping trip id for the transactional data request
A: No, you will need to tie the data together in your solution. When the cart is delivered to you and you calculate the charge then you will call the payment service and record the payment for the cart which will include this data.
Q: For delegated orders, when Just Walkout sends cart to /order/purchases endpoint at 3P connector, what would we send in the shoppingTrip.authEvents.scanResult.id value? Is anything base64 encoded?
A: Amazon sends the customer a loyalty scan to the customer in /v1/identity/scan
the payload scanEvent.id will have a base64 encoded value for the scanned QR in the store.
The customer is expected to decode that id and resolve it and return an id back to us.
Example of an incoming to customer endpoint:
{
"requestId": "string",
"storeId": "string",
"scanEvent": {
"id": "MTExMS0yMjIyLTMzMzMtNDQ0NC01NTU1LTY2NjY= ",
"timestamp": "2024-04-25T13:03:14Z",
"location": "ENTRY",
"value": "string",
"channel": "OPTICAL"
}
}
Customer for example will decode that string “MTExMS0yMjIyLTMzMzMtNDQ0NC01NTU1LTY2NjY=” and do their operation against the id then return a response with an id like this for example
{
"id": "1111-2222-3333-4444-5555-6666",
"type": "SHOPPER",
"action": "ACCEPT"
}
When we send the cart to the customer ,they should expect 1111-2222-3333-4444-5555-6666 in the cart payload in authEvents.scanResult.id
{
"authEvents": [
{
"id": "string",
"timestamp": "2025-05-02T00:05:18Z",
"location": "ENTRY",
"payloadType": "FINANCIAL",
"scanResult": {
"id": "1111-2222-3333-4444-5555-6666",
"type": "SHOPPER"
}
}
]
}
Q: What should my AWS IAM policy look like to allow invoking JWO APIs?
A: This is a sample policy and you should follow your company best practices, you can get the value for the AWS resource ARN by working with the Amazon team
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "PaymentsAPIAccess",
"Effect": "Allow",
"Action": "execute-api:Invoke",
"Resource": "<AMAZON_RESOUCE_ARN>"
}
]
}
Q: What should I do if any of the items in the cart cannot be recognized in my catalog? A: Amazon Just Walk Out expects a successful response when an API payload contains the required fields as specified in the developer documentation.
While validating the payload, you should focus only on verifying the presence and format of the required fields - do not reject carts based on content validation errors (such as mismatched cart items).
If you need implementation examples, refer to sample code here
Q: What is the invoke URL for the payment service
A: See below for the region specific URL
| Region | Invocation URL |
|---|---|
| US East (N. Virginia) | https://us-east-1.payments.amazonphysicalstores.com/ |
| US West 2 (Oregon) | https://us-west-2.payments.amazonphysicalstores.com/ |
| EU (Ireland) | https://eu-west-1.payments.amazonphysicalstores.com/ |
| AP Southeast (Singapore) | https://ap-southeast-1.payments.amazonphysicalstores.com/ |
Q: What is the invoke URL for the checkout service
A: See below for the region specific URL
| Region | Invocation URL |
|---|---|
| US East (N. Virginia) | https://us-east-1.checkout.amazonphysicalstores.com/ |
| US West 2 (Oregon) | https://us-west-2.checkout.amazonphysicalstores.com/ |
Q: Does Amazon provide test environments to validate the integration?
A: Amazon offers testing capabilities for integrating customers to validate the Just WalkOut integration. The list of capabilities include:
1- Access to connectivity testing in the merchant portal for identity, ordering, loyalty and fraud and abuse 2- Access to mock testing services for payment and checkout service
For efficient and flexible API interaction, it is recommended to utilize environment variables to store API endpoints and credentials. This approach allows for easy switching between development, testing, and production environments without code redeployment, significantly reducing overhead and simplifying the testing process.
Developers are encouraged to follow best practices including proper error handling, implementing retry logic, and logging API interactions for effective monitoring and debugging.
Q: I received a 500 Internal server error while doing connectivity testing for the Ordering connector that reads (Service: OrderingConnector, Status Code: 500, Request ID: 6a477d11-e05f-4af0-984d-21a504cdfac3) (SDK Attempt Count: 3)
A: 500 error can be a result of an exception thrown by the processing function on the API. This can be a result of an un-handled exception. Another possible reason is a missing permission on the API GW to Lambda. This could be addressed by following the steps here
Q: I received a 404 error when doing connectivity testing for ordering connector. No method found matching route v1/order/purchases for http method POST.
A: The error is generated if the URL onboarded to the Amazon system has the correct URI structure. Please ensure the value provided matches the correct URI.
Q: I received the following error when executing a call to the Amazon Catalog API. An error occurred: AccessDenied: User: arn:aws:sts::xxxxxxxx:assumed-role/Role-A/upload_catalog is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::xxxxxxxx:role/Role-B
A: This error is generated when the role used to call the API, Role-A is assuming another role, Role-B and Role-B does not have the trust policy to allow Role-A to assume Role-B. To fix this issue you will need to update the trust policy for Role-B to allow Role-A to assue is. For full AWS documentation see here
Q: I am seeing a 400 error on the identity connector connectivity testing. HttpStatus Code: 400 Connector Response: invalid store ID ( Service: IdentityConnector, Status Code:400
A: This error is due to a response generated by the function responding to the API and likely performing a store id validation before responding to the API and the store id in the payload not matching expected value. Consult the external id value to confirm the value you will receive for the store id available in the merchant portal under store details.
Q: I am receiving a 401 when trying to perform loyalty connectivity testing. HttpStatus Code: 401. Connector Response: internal error ( Service: IdentityConnector, Status Code:401
A: The 401 error is generally returned by the processing application if no loyalty program has been matched to the token passed in the test. The correct response needs to have status code 200 and with the following json
{
"id": "string",
"type": "SHOPPER",
"action": "REJECT"
}
