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"
}
Q: I received a 500 error when performing connectivity testing and I do not see the error in the lambda logs
A: This error could be happening due to a mis-configuration on the API GW Integration request. The best option to confirm the root cause is to check the API GW log for errors. In some cases the error could be due to missing permission and you might see an error such as Execution failed due to configuration error: Invalid permissions on Lambda function
To resolve this issue follow the steps documented here
Q: I received this error while calling the Amazon API?
{
"statusCode": 403,
"headers": {
"Access-Control-Allow-Origin": "*",
"Content-Type": "application/json"
},
"body": "{\"Message\":\"User: arn:aws:sts::xxxxxxxxxxxx:assumed-role/role/operation is not authorized to perform: execute-api:Invoke on resource: arn:aws:execute-api:eu-west-1:************:abcdefd/prod/POST/v1/operation/charge because no resource-based policy allows the execute-api:Invoke action\"}",
}
A: The Error Explained:
- A Lambda function with role role/operation is trying to invoke another API
- The attempt is failing because the executing role doesn't have permission to invoke the target API endpoint at v1/operation/charge
- Confirm the API in the error message is the API you have in your account and not the Amazon API
- Specifically, it's missing the execute-api:Invoe permission for this API resource
To fix this, you need to add Resource Policy to API Gateway:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::xxxxxxxxxxxx:role/operation"
},
"Action": "execute-api:Invoke",
"Resource": "arn:aws:execute-api:eu-west-1:************:abcdefd/prod/POST/v1/operation/charge"
}
]
}
Q: I received the following error when trying connectivity testing for payment service
Test error in payments
Our validation process has not received a response from your integration application to the running test within an acceptable wait time. Please consult our troubleshooting documentation to identify resolution to failed tests
A: This error message appears if you do not call the mock payment service within the allow 2 minute window. When the run test button is clicked on a valid SKU , the Amazon service will stage a test basket for 2 minutes to allow the running test to execute successfully. If the test service does not receive a call then you will see this error. You can click the Run test button again to stage a new test basket.
Q: What is the invoke URL for the fraud and abuse feedback service
A: See below for the region specific URL
| Region | Invocation URL |
|---|---|
| US East (N. Virginia) | http://us-east-1.feedback.amazonphysicalstores.com/ |
| US West 2 (Oregon) | http://us-west-2.feedback.amazonphysicalstores.com/ |
| EU (Ireland) | http://eu-west-1.feedback.amazonphysicalstores.com/ |
| AP Southeast (Singapore) | http://ap-southeast-1.feedback.amazonphysicalstores.com/ |
Q: What is a sample payload to the fraud and abuse feedback service? A:
{
"storeId": "<REPLACE_WITH_STORE_ID>",
"shoppingTripId": "<REPLACE_WITH_SHOPPING_TRIP_ID>",
"totalAmount": {
"amount": 14.75,
"code": "GBP"
},
"settledAmount": {
"amount": 10.0,
"code": "GBP"
},
"paymentStatusTime": 1770342660000
}
Q: How do I know if the cart is from an App session or a CC session?
A: This can be determined by examining the cart JSON where
- shoppingTrip.authEvents[FINANCIAL] is a Credit Card entry cart
- shoppingTrip.authEvents[SCAN_CODE] is an app entry cart
Q: How does the cart payload look like when it is an app entry cart
A:
{
"requestId": "2997e9d1-3111-4971-9bff-b3903a0e7c87",
"idempotentShoppingTripId": "41bc23b6-c9a8-41f4-8898-54120ddff5d9",
"storeId": "<INSERT_STORE_ID>",
"shoppingTrip": {
"startTime": "2022-11-29T16:13:26Z",
"endTime": "2022-11-29T16:13:28Z",
"authEvents": [
{
"id": "b49bee24-ae68-4bfd-bbbf-1793c4b6f40b",
"eventTimestamp": 1741302201,
"authLocation": "ENTRY",
"payloadType": "SCAN_CODE"
}
]
},
"cartItems": [
{
"id": "<TEST_SKU>",
"type": "SKU",
"quantity": {
"value": "1.0",
"unit": "unit"
}
}
],
"shopperIdentity": {
"id": "543b9872-2c75-4dcc-83ba-7d1a8c736279"
},
"shopperDeviceId": "829ffe9d8d4d02fb767bee3a190f7d7e"
}
Q: How does the cart payload look like when it is an credit card entry cart
A:
{
"requestId": "2997e9d1-3111-4971-9bff-b3903a0e7c87",
"idempotentShoppingTripId": "41bc23b6-c9a8-41f4-8898-54120ddff5d9",
"storeId": "<INSERT_STORE_ID>",
"shoppingTrip": {
"startTime": "2022-11-29T16:13:26Z",
"endTime": "2022-11-29T16:13:28Z",
"authEvents": [
{
"id": "b49bee24-ae68-4bfd-bbbf-1793c4b6f40b",
"eventTimestamp": 1741302201,
"authLocation": "ENTRY",
"payloadType": "FINANCIAL"
}
]
},
"cartItems": [
{
"id": "<SAMPLE_SKU>",
"type": "SKU",
"quantity": {
"value": "1.0",
"unit": "unit"
}
}
],
"shopperIdentity": {
"id": "543b9872-2c75-4dcc-83ba-7d1a8c736279"
},
"shopperDeviceId": "829ffe9d8d4d02fb767bee3a190f7d7e"
}
Q: How does the cart payload look like when it is an credit card entry cart with loyalty
A:
{
"requestId": "2997e9d1-3111-4971-9bff-b3903a0e7c87",
"idempotentShoppingTripId": "41bc23b6-c9a8-41f4-8898-54120ddff5d9",
"storeId": "<INSERT_STORE_ID>",
"shoppingTrip": {
"startTime": "2022-11-29T16:13:26Z",
"endTime": "2022-11-29T16:13:28Z",
"authEvents": [
{
"id": "b49bee24-ae68-4bfd-bbbf-1793c4b6f40b",
"eventTimestamp": 1741302201,
"authLocation": "ENTRY",
"payloadType": "FINANCIAL"
},
{
"id": "e3a3ccdb-bdf0-4ca1-a164-02a9c3aa7045",
"eventTimestamp": 1741302579,
"authLocation": "MANUAL_IN_STORE",
"payloadType": "SCAN_CODE",
"scanResult": {
"id": "<INSERT_LOYALTY>",
"type": "LOYALTY"
}
}
]
},
"cartItems": [
{
"id": "<SAMPLE_SKU>",
"type": "SKU",
"quantity": {
"value": "1.0",
"unit": "unit"
}
}
],
"shopperIdentity": {
"id": "543b9872-2c75-4dcc-83ba-7d1a8c736279"
},
"shopperDeviceId": "829ffe9d8d4d02fb767bee3a190f7d7e"
}
Q: How do I setup alerts on AWS API Gateway for 400 errors
A: To set up an alert on AWS API Gateway when a 400 error is triggered by a model validation failure, you'll need to create a CloudWatch alarm that monitors the 4XXError metric. Here's how to do it:
Step 1: Enable Request Validation in API Gateway
- Ensure request validation is enabled for your API Gateway REST API
- API Gateway can perform basic validation to ensure required request parameters are present
- Verify that the request payload conforms to your specified JSON schema
Step 2: Create a CloudWatch Alarm for 4XX Errors
Using the AWS Console:
- Navigate to CloudWatch Console
- Go to AWS Management Console → CloudWatch → Alarms → Create Alarm
- Select the Metric
- Choose "Select Metric" -> Navigate to: API Gateway → By API Name (or By Stage)
- Select the 4XXError metric for your specific API and stage[1][3]
- Configure Alarm Conditions
- Metric: 4XXError, Namespace: AWS/ApiGateway, Statistic: SUM, Period: 60 seconds (1 minute)
- Threshold: Set based on your needs (e.g., ≥ 1 for any error, or a higher number for sustained errors)
- Datapoints to Alarm: 1 out of 1 (or adjust for your tolerance), Treat Missing Data: "notBreaching"
- Set Up Notifications
- Add an SNS topic to receive notifications when the alarm triggers
- Configure email, Slack, or other notification channels
Step 3: Enable CloudWatch Logs for Detailed Diagnostics
To identify model validation failures specifically, enable API Gateway execution logs and access logs by referring to the AWS documentation. Sample AccessLogSetting Format strings can be found in the cloudformation templates available on the "CloudFormation templates for Just Walk Out onboarding" page.
Step 4: Filter for Validation Errors
Use CloudWatch Logs Insights to query for validation-specific 400 errors:
fields @timestamp, @message, status, path
| filter status = "400"
| sort @timestamp desc
| limit 20
Q: How do I contact support if I still have a question?
A: You can reach Amazon Just Walk Out support by one of the following options. To raise an issue, please email us at JWOsupport@amazon.com. If this is an issue impacting major functionality within a store, please call us for faster assistance at:+1 855-218-4421 (USA), +44 0808 134 2828 (UK), +611800270944 (Australia), +1 833-505-2944 (Canada), +33 801 31 18 08 (France)
Q: I received the following error while running connectivity testing "We are unable to process your request due to a system error. Please try again. If you continue to experience this issue, contact the Amazon team for help."
A: This error can be a result of a temporary issue and we recommend re-trying the operation after a short wait. If the issue persists then please contact the Just Walk Out support team.
Q: How do I route an API call in AWS API GW to an http endpoint?
A: You can follow the steps in AWS documentation to setup the integration request to an HTTP endpoint. This option is can help when routing API calls to an HTTP endpoints in backend systems or in different environments. Below are the summarized steps and you can consult AWS documentation for more details on how to configure integration request.
- Sign in to the Amazon API Gateway console.
- Select the API you wish to route the call for
- Select the root resource (/) in the Resources pane.
- Select the method you wish to change
- Configure the Integration Request.
- For Integration type, select HTTP.
- For HTTP method, choose the method that most closely matches the backend endpoint's method.
- For Endpoint URL, enter the full URL of your backend HTTP endpoint (e.g., https://api.example.com/data).
- For simpler pass-through of the entire request and response, you can enable HTTP proxy integration. If you need to transform parameters or the body, disable proxy integration (custom integration) and configure mapping templates.
- Deploy the API.
- From the Actions dropdown, choose Deploy API.
- Select a Deployment stage (or create a new one).
- Choose Deploy
