App entry store test plan

• Summary
• Test Plan Overview
• Test Environment Setup
• 1. Identity Verification Test Cases
  • 1.1 Successful Identity Verification
  • 1.2 Invalid Identity Key
  • 1.3 Associate Entry
  • 1.4 Exit Processing
• 2. Charge Calculation Test Cases
  • 2.1 Simple Cart Calculation
  • 2.2 Promotional Pricing
  • 2.3 Complex Cart with Multiple Items
  • 2.4 Cart Handoff with Unidentifiable Item SKU
  • 2.5 Empty Cart Handoff - App Entry
• 3. Integration Flow Test Cases
  • 3.1 Complete Shopping Journey
  • 3.2 Failed Entry Recovery
  • 3.3 System Error Handling
  • 3.4 Cart Received But Not Charged Before Pre-Auth Expiration
  • 3.5 Retry Failed Verify Identity Keys API Call
  • 3.6 Retry Failed Charge Calculation Call
• 4. Performance Test Cases
  • 4.1 Peak Load Testing
  • 4.2 Rate Limiting Validation
• 5. Security Test Cases
  • 5.1 Identity Key Security
  • 5.2 Data Validation
• 6. Store Reporting Test Cases
  • 6.1 Merchant Portal Reporting
  • 6.2 Merchant Portal Dashboard
  • 6.3 Intra-Day Report File Delivery
  • 6.4 Intra-Day Report De-Duplication
  • 6.5 Intra-Day Report Order Spanning Multiple Files
  • 6.6 Event Feed — Cart Event Delivery
  • 6.7 Event Feed — Payment Event Delivery
  • 6.8 Event Feed — Payment Decline Events
  • 6.9 Event Feed — Test Event Validation
  • 6.10 Event Feed — Failed Event Processing
  • 6.11 Reporting Data Reconciliation
• 7. Post-Purchase Test Cases
  • 7.1 Receipt Generation — Amazon-Managed
  • 7.2 Receipt Generation — Retailer-Managed
  • 7.3 Receipt Lookup — Amazon Website
  • 7.4 Receipt Lookup — Retailer-Managed
  • 7.5 Receipt Delivery Failure
  • 7.6 Refund — Successful via Refund API
  • 7.7 Refund — All Reason Codes
  • 7.8 Refund — Idempotency
  • 7.9 Refund — 30-Day Window Expiration
  • 7.10 Refund — Unknown Shopping Trip
  • 7.11 Refund — Rate Limiting
  • 7.12 Refund — Server Error and Retry
  • 7.13 Bad Debt — Declined Adjustment
  • 7.14 Bad Debt — Expired Pre-Auth with Uncharged Cart
  • 7.15 Bad Debt — Repeat Offender Flagging
  • 7.16 Bad Debt — Reporting and Metrics
• 8. Test Data Requirements
  • Identity Keys
  • Product Catalog
  • Store Configuration

Disclaimer: This document contains sample content for illustrative purposes only. Organizations should follow their own established best practices, security requirements, and compliance standards to ensure solutions are production-ready.

Summary

The test plan serves as a sample guidance document for testing a Just Walk Out application that integrates with customer systems to handle entry validation and charge calculations.

The shopper authorization process and store entry transactions are performed through the customer's existing systems rather than the Just Walk Out infrastructure. While this plan outlines key testing scenarios, it should be supplemented with your organization's established testing best practices to ensure comprehensive coverage of any use cases not explicitly included in this test plan.

Test Plan Overview

APIs Under Test:

• Verify Identity Keys API (/v1/identity/identity-keys) — Test Cases
• Charge Calculation API (Order Delegation) — Test Cases

Test Environment Setup

• Test Store ID: TEST_STORE_001
• Valid Identity Keys: Base64 encoded test keys
• Test Payment Sources: Mock payment instruments
• Test Products: Catalog with known SKUs and prices

1. Identity Verification Test Cases

1.1 Successful Identity Verification

Test Case ID: IV-001 Objective: Verify successful shopper entry authorization

Test Data:

{
  "requestId": "550e8400-e29b-41d4-a716-446655440000",
  "identityKey": "dGVzdC1pZGVudGl0eS1rZXk=",
  "storeId": "TEST_STORE_001",
  "authEvent": {
    "id": "123e4567-e89b-12d3-a456-426614174000",
    "timestamp": "2024-10-31T10:00:00Z",
    "location": "ENTRY"
  },
  "keyChannel": "OPTICAL"
}

Expected Result:

• HTTP 200 response
• Gate opens for shopper
• Valid visitor details returned

1.2 Invalid Identity Key

Test Case ID: IV-002 Objective: Test rejection of invalid identity key

Test Data:

{
  "requestId": "550e8400-e29b-41d4-a716-446655440001",
  "identityKey": "aW52YWxpZC1rZXk=",
  "storeId": "TEST_STORE_001",
  "authEvent": {
    "id": "123e4567-e89b-12d3-a456-426614174001",
    "timestamp": "2024-10-31T10:00:00Z",
    "location": "ENTRY"
  }
}

Expected Result:

• HTTP 401 response
• Gate remains closed
• Error message returned

1.3 Associate Entry

Test Case ID: IV-003 Objective: Test store associate entry

Expected Result:

• Visitor type: "ASSOCIATE"
• Special handling for employee access

1.4 Exit Processing

Test Case ID: IV-004 Objective: Test shopper exit verification

Test Data: Same as IV-001 but with "location": "EXIT"

Expected Result:

• Successful exit processing
• Triggers charge calculation workflow

2. Charge Calculation Test Cases

2.1 Simple Cart Calculation

Test Case ID: CC-001 Objective: Calculate charges for basic cart

Test Scenario:

• Shopper selects 2 items
• No promotions applied
• Standard tax calculation

Expected Result:

• Accurate price calculation
• Proper tax application
• Order created successfully

2.2 Promotional Pricing

Test Case ID: CC-002 Objective: Test promotional discount application

Test Scenario:

• Cart qualifies for promotion
• Discount should be applied
• Final price reflects promotion

Expected Result:

• Promotion correctly applied
• Discounted total calculated
• Promotion details in order

2.3 Complex Cart with Multiple Items

Test Case ID: CC-003 Objective: Test calculation with varied items

Test Scenario:

• Multiple quantities of different items
• Mixed promotional and regular pricing
• Different tax categories

Expected Result:

• All items calculated correctly
• Promotions applied appropriately
• Tax calculated per category

2.4 Cart Handoff with Unidentifiable Item SKU

Test Case ID: CC-004 Objective: Verify that a cart handoff containing an item SKU that cannot be identified is accepted and routed to the internal bad cart handling process

Test Scenario:

• Cart contains one or more items with SKUs not present in the product catalog
• Cart is submitted through the standard charge calculation flow

Test Data:

• Cart with item productId: UNKNOWN-SKU-99999 (not in catalog)
• Standard store and shopping trip identifiers

Expected Result:

• Cart is accepted (not rejected)
• Cart is routed to internal bad cart handling process
• No error returned to the caller
• Unidentifiable SKU is flagged for internal review

2.5 Empty Cart Handoff - App Entry

Test Case ID: CC-005 Objective: Verify that an empty cart is not priced and a process is kicked off to cancel the pre-auth on the shopper's payment instrument for app entry stores

Test Scenario:

• Shopper enters store via app-based authentication
• Shopper exits without selecting any items
• Empty cart is handed off for charge calculation

Test Data:

• Empty cart with no line items
• Valid shopping trip ID with app entry authentication

Expected Result:

• Cart is not priced
• A process is kicked off to cancel the pre-auth on the shopper's payment instrument
• No charge is created for the shopping trip

3. Integration Flow Test Cases

3.1 Complete Shopping Journey

Test Case ID: IF-001 Objective: End-to-end shopping experience

Test Flow:

1. Shopper scans identity key at entry
2. Identity verification succeeds
3. Gate opens, shopper enters
4. Shopper selects items
5. Shopper exits store
6. Exit verification triggers charge calculation
7. Order processed and payment charged

Expected Result:

• Seamless flow from entry to payment
• All APIs respond correctly
• Order matches actual cart contents

3.2 Failed Entry Recovery

Test Case ID: IF-002 Objective: Handle failed identity verification

Test Flow:

1. Invalid identity key scanned
2. Verification fails (401 response)
3. Gate remains closed
4. Shopper tries valid key
5. Verification succeeds
6. Normal shopping flow continues

Expected Result:

• System recovers from failure
• No duplicate processing
• Audit trail maintained

3.3 System Error Handling

Test Case ID: IF-003 Objective: Test error recovery mechanisms

Test Scenarios:

• Network timeout during verification
• Charge calculation service unavailable
• Malformed API responses

Expected Result:

• Graceful error handling
• Appropriate fallback behavior
• User-friendly error messages

3.4 Cart Received But Not Charged Before Pre-Auth Expiration

Test Case ID: IF-004 Objective: Verify that an alert is generated when a cart has been received but not charged before the pre-auth on the shopper's payment instrument expires

Test Scenario:

• Shopper enters store via app-based authentication and a pre-auth is placed on their payment instrument
• Shopper completes shopping trip and exits
• Cart is received from JWO
• Charge calculation or payment processing is delayed
• Pre-auth window expires before the charge is captured

Expected Result:

• System detects that the pre-auth has expired before the cart was charged
• An alert is generated to notify operations of the uncharged cart
• Cart is flagged for manual review or reprocessing
• No silent loss of revenue occurs

3.5 Retry Failed Verify Identity Keys API Call

Test Case ID: IF-005 Objective: Verify that a failed Verify Identity Keys API (/v1/identity/identity-keys) call is retried successfully

Test Scenario:

• Shopper scans identity key at entry
• Verify Identity Keys API returns a transient error (e.g., HTTP 500 or timeout)
• System retries the API call

Expected Result:

• Failed call is retried with appropriate backoff
• Successful retry returns correct identity verification
• Maximum retry attempts are enforced
• Alert is raised if all retries are exhausted
• Gate remains closed until a definitive response is received

3.6 Retry Failed Charge Calculation Call

Test Case ID: IF-006 Objective: Verify that a failed Charge Calculation (Order Delegation) call is retried successfully

Test Scenario:

• Cart is received and charge calculation is invoked
• Charge Calculation API returns a transient error
• System retries the API call

Expected Result:

• Failed call is retried with appropriate backoff
• Successful retry returns correct charge calculation
• Maximum retry attempts are enforced
• Alert is raised if all retries are exhausted

4. Performance Test Cases

4.1 Peak Load Testing

Test Case ID: PF-001 Objective: Test system under peak load

Test Parameters:

• 100 concurrent identity verifications
• 50 simultaneous charge calculations
• Sustained load for 10 minutes

Expected Result:

• Response times < 2 seconds
• No failed transactions
• System remains stable

4.2 Rate Limiting Validation

Test Case ID: PF-002 Objective: Verify rate limiting behavior

Test Method:

• Exceed API rate limits
• Verify 429 responses
• Test retry mechanisms

Expected Result:

• Rate limits enforced
• Proper retry-after headers
• System protects against abuse

5. Security Test Cases

5.1 Identity Key Security

Test Case ID: SEC-001 Objective: Validate identity key handling

Test Scenarios:

• Malformed identity keys
• Replay attack attempts
• Key tampering detection

Expected Result:

• Invalid keys rejected
• Replay attacks prevented
• Tampering detected

5.2 Data Validation

Test Case ID: SEC-002 Objective: Test input validation

Test Data:

• Oversized payloads
• Invalid data types
• SQL injection attempts

Expected Result:

• Invalid input rejected
• No system compromise
• Proper error responses

6. Store Reporting Test Cases

6.1 Merchant Portal Reporting

Test Case ID: RPT-001 Objective: Verify daily reports are available and accurate in the Merchant Portal

Test Steps:

1. Complete several shopping trips in the test store
2. Wait for the next daily report generation (typically by 5 AM PST)
3. Download Orders, Catalog, and Payments reports from the Merchant Portal
4. Verify transaction data matches the completed shopping trips

Expected Result:

• Reports are available by expected delivery time
• Order details (items, quantities, prices, promotions) match actual shopping trips
• Payment details match charge calculations

6.2 Merchant Portal Dashboard

Test Case ID: RPT-002 Objective: Verify the dashboard refreshes and displays accurate data

Test Steps:

1. Complete a shopping trip in the test store
2. Wait up to 30 minutes for dashboard refresh
3. Verify sales details and item details reflect the completed trip
4. Export data and validate against expected values

Expected Result:

• Dashboard data refreshes within 30 minutes
• Sales and item details are accurate and exportable

6.3 Intra-Day Report File Delivery

Test Case ID: RPT-003 Objective: Verify Intra-day report files are received via SNS/SQS and processed correctly

Test Steps:

1. Complete a shopping trip in the test store
2. Monitor the SQS queue for incoming SNS notifications
3. Verify Lambda function triggers and processes the notification
4. Confirm the report file is copied from the Amazon S3 bucket to your destination bucket
5. Open the CSV file and validate order data

Expected Result:

• SNS notification received within the 15-minute reporting window
• Lambda function processes the message and copies the file
• CSV file contains accurate order data matching the shopping trip

6.4 Intra-Day Report De-Duplication

Test Case ID: RPT-004 Objective: Verify duplicate report files are detected and not processed twice

Test Steps:

1. Process an Intra-day report file
2. Re-send or re-process the same file
3. Verify de-duplication logic prevents duplicate records

Expected Result:

• Duplicate file is detected
• No duplicate order records are created in the destination

6.5 Intra-Day Report Order Spanning Multiple Files

Test Case ID: RPT-005 Objective: Verify orders split across multiple 15-minute files are handled with upsert logic

Test Steps:

1. Identify an order that appears in two consecutive report files
2. Process both files sequentially
3. Verify the order record is updated (not duplicated) with the latest data

Expected Result:

• Upsert logic correctly updates existing order records
• No duplicate entries for the same order

6.6 Event Feed — Cart Event Delivery

Test Case ID: RPT-006 Objective: Verify CART events are received via EventBridge after a shopping trip

Test Steps:

1. Complete a shopping trip with multiple items
2. Monitor EventBridge for incoming CART events matching the rule {"source": ["AmazonEventsService"], "detail-type": ["CART"]}
3. Verify the event is routed to the configured target (S3, database, or API)
4. Validate cart event payload fields: merchantSku, quantityValue, priceValue, taxValue, listPriceValue, promotionInfos

Expected Result:

• CART event received shortly after shopping trip ends
• Event payload matches actual cart contents (SKUs, quantities, prices, promotions)

6.7 Event Feed — Payment Event Delivery

Test Case ID: RPT-007 Objective: Verify PAYMENT events are received for each payment lifecycle stage

Test Steps:

1. Complete a shopping trip that triggers a payment
2. Monitor EventBridge for PAYMENT events
3. Verify events are received for applicable stages: AuthorizationApproved, CaptureApproved
4. Validate payment event payload fields: amount, brand, cardLastFourDigits, reconciliationId, status

Expected Result:

• PAYMENT events received for each lifecycle stage
• Event payloads contain accurate payment details

6.8 Event Feed — Payment Decline Events

Test Case ID: RPT-008 Objective: Verify PAYMENT decline events are received and can be filtered

Test Steps:

1. Trigger a payment decline scenario (e.g., insufficient funds)
2. Monitor EventBridge for PAYMENT events with eventName AuthorizationDeclined or CaptureDeclined
3. Verify the decline event is routed to the configured target

Expected Result:

• Decline events are received with correct status
• Events can be filtered using EventBridge rules for alerting

6.9 Event Feed — Test Event Validation

Test Case ID: RPT-009 Objective: Verify EventBridge rules and targets are correctly configured using test events

Test Steps:

1. Navigate to EventBridge in the AWS console
2. Select the event bus and click "Send events"
3. Send a test CART event with detail-type "CART" and a sample payload
4. Send a test PAYMENT event with detail-type "PAYMENT" and a sample payload
5. Verify both events are delivered to the configured targets

Expected Result:

• Test events are matched by EventBridge rules
• Events are delivered to the correct targets (S3, database, API)

6.10 Event Feed — Failed Event Processing

Test Case ID: RPT-010 Objective: Verify failed event processing is handled with dead-letter queue or retry logic

Test Steps:

1. Configure the event target to simulate a processing failure (e.g., unavailable API endpoint)
2. Send an event to the event bus
3. Verify the failed event is captured in a dead-letter queue or retried

Expected Result:

• Failed events are not silently lost
• Dead-letter queue captures failed events for reprocessing

6.11 Reporting Data Reconciliation

Test Case ID: RPT-011 Objective: Verify reporting data can be reconciled against charge calculation and payment records

Test Steps:

1. Complete 10 shopping trips with known items and prices
2. Collect data from all reporting sources (Merchant Portal, Intra-day files, Event feed)
3. Compare reporting data against your POS charge calculation records
4. Verify totals, item counts, and promotion values match

Expected Result:

• All reporting sources contain consistent data
• No discrepancies between reporting data and charge calculation records

7. Post-Purchase Test Cases

7.1 Receipt Generation — Amazon-Managed

Test Case ID: PP-001 Objective: Verify Amazon-generated receipts are delivered to shoppers after a shopping trip

Test Steps:

1. Complete a shopping trip with multiple items
2. Verify the shopper receives an itemized receipt via email (credit card entry) or in-app (app entry)
3. Validate receipt contains correct items, quantities, prices, promotions, taxes, and payment total
4. Verify store logo and contact information are displayed correctly

Expected Result:

• Receipt delivered within expected timeframe
• All line items match the shopping cart
• Store branding is correct

7.2 Receipt Generation — Retailer-Managed

Test Case ID: PP-002 Objective: Verify retailer-generated receipts are built from Amazon API data and delivered to shoppers

Test Steps:

1. Complete a shopping trip
2. Consume cart and payment data from Amazon APIs
3. Generate an itemized receipt using your receipt system
4. Deliver the receipt to the shopper
5. Validate receipt accuracy against the Create Purchases API response

Expected Result:

• Receipt generated from API data is accurate
• Delivery channel (email, app, SMS) works correctly

7.3 Receipt Lookup — Amazon Website

Test Case ID: PP-003 Objective: Verify shoppers can look up historical receipts on the Amazon receipt lookup website

Test Steps:

1. Complete multiple shopping trips using the same payment card
2. Navigate to the Amazon receipt lookup website
3. Search for receipts by payment card
4. Verify all shopping trips are listed with correct details

Expected Result:

• All historical trips are retrievable
• Receipt details match original transactions

7.4 Receipt Lookup — Retailer-Managed

Test Case ID: PP-004 Objective: Verify retailer receipt lookup returns accurate historical records

Test Steps:

1. Complete multiple shopping trips
2. Use the retailer receipt lookup system to search for past trips
3. Verify results for both app entry and credit card entry shoppers

Expected Result:

• All trips are indexed and retrievable
• Receipt details are accurate

7.5 Receipt Delivery Failure

Test Case ID: PP-005 Objective: Verify the system handles receipt delivery failures gracefully

Test Steps:

1. Complete a shopping trip with an invalid email address or unreachable notification endpoint
2. Verify the system detects the delivery failure
3. Confirm the receipt is available via receipt lookup as a fallback

Expected Result:

• Delivery failure is logged
• Shopper can still retrieve the receipt via lookup

7.6 Refund — Successful via Refund API

Test Case ID: PP-006 Objective: Verify a successful refund using the Refund API (POST /v1/refund)

Test Data:

{
  "storeId": "TEST_STORE_001",
  "shoppingTripId": "550e8400-e29b-41d4-a716-446655440000",
  "amount": {
    "amount": 9.99,
    "code": "USD"
  },
  "refundRequestId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "refundReasonCode": "DAMAGED_ITEM"
}

Expected Result:

• HTTP 200 response with reconciliationId
• Refund reflected in payment processor records

7.7 Refund — All Reason Codes

Test Case ID: PP-007 Objective: Verify refunds succeed for each refundReasonCode

Test Steps:

1. Submit a refund with reason code DAMAGED_ITEM
2. Submit a refund with reason code EXPIRED_ITEM
3. Submit a refund with reason code UNWANTED_ITEM
4. Submit a refund with reason code JWO_TECH_ERROR
5. Submit a refund with reason code OTHER

Expected Result:

• All five reason codes are accepted and processed successfully
• Each returns a valid reconciliationId

7.8 Refund — Idempotency

Test Case ID: PP-008 Objective: Verify duplicate refund requests with the same refundRequestId do not create duplicate refunds

Test Steps:

1. Submit a refund with refundRequestId aaaa-bbbb-cccc-dddd
2. Submit the same refund again with the same refundRequestId
3. Verify only one refund is processed

Expected Result:

• Second request does not create a duplicate refund
• Same reconciliationId returned

7.9 Refund — 30-Day Window Expiration

Test Case ID: PP-009 Objective: Verify refunds are rejected after the 30-day window

Test Steps:

1. Identify a shopping trip older than 30 days
2. Attempt to submit a refund for that trip

Expected Result:

• Refund is rejected
• Appropriate error message returned

7.10 Refund — Unknown Shopping Trip

Test Case ID: PP-010 Objective: Verify 400 error when refunding an invalid shoppingTripId

Test Data: Use a non-existent shoppingTripId

Expected Result:

• HTTP 400 UnknownShoppingTrip error

7.11 Refund — Rate Limiting

Test Case ID: PP-011 Objective: Verify 429 response and retry-after behavior for the Refund API

Test Method: Send rapid concurrent refund requests exceeding the rate limit

Expected Result:

• HTTP 429 with Retry-After header (600 seconds)
• Retry with backoff succeeds

7.12 Refund — Server Error and Retry

Test Case ID: PP-012 Objective: Verify retry with exponential backoff on 500 and 503 errors

Test Steps:

1. Simulate a 500 or 503 response from the Refund API
2. Verify the system retries with exponential backoff
3. Confirm the refund succeeds on retry

Expected Result:

• Retry logic handles transient errors
• Refund eventually succeeds

7.13 Bad Debt — Declined Adjustment

Test Case ID: PP-013 Objective: Verify bad debt is recorded when a charge adjustment is declined

Test Steps:

1. Complete a shopping trip
2. Simulate a declined Adjust Charge response (status: DECLINED)
3. Verify the system records a bad debt incident with shoppingTripId, amount, and failure reason
4. Verify an alert is generated

Expected Result:

• Bad debt incident recorded
• Alert triggered for operations team

7.14 Bad Debt — Expired Pre-Auth with Uncharged Cart

Test Case ID: PP-014 Objective: Verify bad debt is recorded when a pre-auth expires before the cart is charged

Test Steps:

1. Complete a shopping trip via app entry (pre-auth placed)
2. Delay charge calculation beyond the pre-auth expiration window
3. Verify the system detects the expired pre-auth
4. Verify a bad debt incident is recorded

Expected Result:

• Expired pre-auth detected
• Bad debt incident recorded with root cause "pre-auth expiration"
• Alert generated

7.15 Bad Debt — Repeat Offender Flagging

Test Case ID: PP-015 Objective: Verify shoppers with multiple bad debt incidents are flagged

Test Steps:

1. Simulate 3 bad debt incidents for the same shopper identity
2. Verify the shopper account is flagged in your risk system
3. Verify the flag is considered during future identity verification (Verify Identity Keys API)

Expected Result:

• Shopper flagged after threshold is reached
• Future entry authorization considers the flag

7.16 Bad Debt — Reporting and Metrics

Test Case ID: PP-016 Objective: Verify bad debt metrics are tracked and reportable

Test Steps:

1. Generate several bad debt incidents with different root causes
2. Run bad debt reports
3. Verify reports show total amount, frequency, root cause breakdown, and recovery rate

Expected Result:

• Bad debt metrics are accurate and categorized by root cause
• Reports support business monitoring and decision-making

8. Test Data Requirements

Identity Keys

• 10 valid encoded keys for different shopper types
• 5 invalid keys for negative testing
• 3 associate keys for employee testing

Product Catalog

• 20 test products with various prices
• 5 promotional items
• Different tax categories

Store Configuration

• Test store with proper API endpoints
• Rate limiting configured
• Error handling enabled