Combo Store Test Plan (App Entry + Credit Card Entry)
- Combo Store Test Plan (App Entry + Credit Card Entry)
- Overview
- Test Phases
- Test Environment Requirements
- Test Data Management
- Success Criteria & Exit Criteria
- Risk Mitigation
- Test Schedule
- Deliverables
- Appendix
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.
Combo Store Test Plan (App Entry + Credit Card Entry)
Overview
This test plan covers the comprehensive testing strategy for a Just Walk Out store supporting both app-based entry and credit card entry methods. The retailer manages the full payment lifecycle through Amazon's Payment Service APIs, while maintaining control over identity verification (app entry), charge calculation, and post-purchase experiences.
Store Configuration
| Attribute | Value |
|---|---|
| Entry Methods | Mobile app QR code scan AND credit card tap |
| Identity Verification | Retailer-managed (app entry) + Amazon-managed (credit card entry) |
| Charge Calculation | Order Delegation via Create Purchases API |
| Payment Processing | Retailer-managed via Payment Service APIs |
| Receipt Generation | Retailer-managed using retrieved data |
| Self-Service Portal | Required for receipts, refunds, and debt resolution |
| Catalog Management | Catalog API |
APIs in Scope
| API | Endpoint | Purpose |
|---|---|---|
| Upload Catalog | POST /v1/catalog/upload |
Upload product catalog |
| Get Catalog Upload Status | POST /v1/catalog/getCatalogUploadStatus |
Check upload status |
| Verify Identity Keys | POST /v1/identity/identity-keys |
Authorize app entry shoppers |
| Create Purchases | POST /v1/order/purchases |
Receive cart and calculate pricing |
| Adjust Charge | POST /v1/adjust/charge |
Adjust pre-auth to cart total |
| Capture Charge | POST /v1/capture/charge |
Capture adjusted amount |
| Cancel Charge | POST /v1/cancel/charge |
Cancel pre-auth (empty carts) |
| Refund | POST /v1/refund |
Process refunds |
| Report Payment Status | POST /v1/feedback/payment-status |
Report debt payoff |
| Get Transactional Data | POST /v1/payment/transactional-data |
Retrieve EMV data |
| Get Shopper Identity | POST /v1/identity/shopper |
Retrieve shopper email |
Test Phases
Phase 1: Component Testing
1.1 Catalog Management Testing
Duration: 4-6 days
Prerequisites: AWS account configured, Catalog API access granted
Test Objectives:
- Validate catalog upload functionality
- Test catalog status monitoring
- Verify SNS/SQS notification handling
- Test catalog maintenance operations
Key Test Cases:
- Upload valid catalog (< 10,000 items)
- Upload oversized catalog (> 10,000 items)
- Upload malformed catalog data
- Check upload status via API and SNS notifications
- Download and process upload result reports
- Test catalog update and versioning
- Validate rate limiting (10 requests/second)
Success Criteria:
- Valid catalogs upload successfully within 15 minutes
- Invalid catalogs rejected with clear error messages
- Status notifications received within 5 minutes
- Upload result reports accessible and accurate
- Rate limiting enforced correctly
1.2 App Entry - Identity Verification Testing
Duration: 5-7 days
Prerequisites: Mobile app QR generation, Identity Connector deployed
Test Objectives:
- Validate QR code generation and scanning
- Test identity verification logic
- Verify gate authorization decisions
- Test response time requirements (< 2 seconds)
Key Test Cases:
- Valid shopper QR code scan
- Invalid/expired QR code handling
- Associate entry with ASSOCIATE type
- Cash shopper entry with CASH_SHOPPER type
- Loyalty shopper entry with LOYALTY type
- Identity verification timeout scenarios
- Malformed identity key handling
- Idempotency with authEvent.id
Success Criteria:
- Valid identity keys authorize gate opening (200 response)
- Invalid keys keep gate closed (400/401 response)
- All responses return within 2 seconds
- Gate behavior matches response codes correctly
- Idempotency maintained across duplicate requests
1.3 Credit Card Entry Testing
Duration: 3-4 days
Prerequisites: Credit card readers configured, payment processor integration
Test Objectives:
- Validate credit card tap functionality
- Test pre-authorization placement
- Verify Amazon-managed gate decisions
Key Test Cases:
- Valid credit card tap and gate opening
- Invalid/expired card rejection
- Pre-authorization placement verification
- Multiple card types (Visa, MasterCard, Amex)
- Contactless vs. chip card scenarios
- Card reader failure handling
Success Criteria:
- Valid cards trigger gate opening and pre-auth
- Invalid cards keep gate closed
- Pre-auth amounts appropriate for store type
- All card types supported correctly
- Reader failures handled gracefully
1.4 Charge Calculation Testing
Duration: 5-7 days
Prerequisites: Ordering Connector deployed, POS integration complete
Test Objectives:
- Validate pricing calculations for both entry methods
- Test promotion and tax logic
- Verify entry method differentiation
- Test empty cart handling
Key Test Cases:
- App entry cart (payloadType: SCAN_CODE)
- Credit card entry cart (payloadType: FINANCIAL)
- Single item pricing calculations
- Multi-item cart with promotions
- Weight-based item calculations
- Tax calculation accuracy
- Empty cart returns empty purchaseId
- Unrecognized SKU routing
- Mixed entry method group shopping
Success Criteria:
- Pricing calculations accurate within 0.01 tolerance
- Entry method correctly identified from payloadType
- Promotions and taxes applied correctly
- Empty carts handled consistently
- Group shopping scenarios processed correctly
1.5 Payment Lifecycle Testing
Duration: 7-10 days
Prerequisites: Payment Service APIs configured, payment processor integration
Test Objectives:
- Validate full payment lifecycle for both entry methods
- Test adjust, capture, cancel, refund operations
- Verify bad debt tracking and enforcement
Key Test Cases:
- Successful adjust → capture flow
- Adjust decline → bad debt recording
- Empty cart → cancel pre-auth
- Refund processing (within 30 days)
- Refund rejection (outside 30-day window)
- Payment processor timeout handling
- Concurrent payment operations
- Bad debt enforcement at next entry
Success Criteria:
- Payment lifecycle completes successfully for valid transactions
- Bad debt properly tracked and enforced
- Empty carts trigger pre-auth cancellation
- Refunds processed within SLA
- Error handling robust for all failure scenarios
Phase 2: Integration Testing
2.1 Dual Entry Method Integration
Duration: 8-10 days
Prerequisites: All component tests passed
Test Scenarios:
Scenario 1: App Entry Shopping Journey
- Shopper opens mobile app and generates QR code
- Shopper scans QR at gate
- Amazon calls Verify Identity Keys API
- Retailer verifies identity and returns 200 (gate opens)
- Pre-auth placed on payment instrument
- Shopper picks up items
- Shopper exits store
- Amazon calls Create Purchases API (payloadType: SCAN_CODE)
- Retailer calculates pricing and returns purchaseId
- Retailer calls Adjust Charge API
- Retailer calls Capture Charge API
- Retailer retrieves transactional data and generates receipt
Scenario 2: Credit Card Entry Shopping Journey
- Shopper taps credit card at gate
- Amazon verifies payment instrument and places pre-auth
- Gate opens (no retailer F&A callback)
- Shopper picks up items
- Shopper exits store
- Amazon calls Create Purchases API (payloadType: FINANCIAL)
- Retailer calculates pricing and returns purchaseId
- Retailer calls Adjust Charge API
- Retailer calls Capture Charge API
- Retailer retrieves transactional data and generates receipt
Scenario 3: Mixed Entry Group Shopping
- Shopper A enters via app (SCAN_CODE)
- Shopper B enters via credit card (FINANCIAL)
- Both shoppers shop together (group trip)
- Group exits together
- Amazon sends cart with multiple authEvents
- Retailer processes group cart and charges primary payment method
Scenario 4: Empty Cart Scenarios
- App entry shopper exits without items
- Credit card entry shopper exits without items
- Verify pre-auth cancellation for both methods
Success Criteria:
- Both entry methods work independently and together
- Entry method correctly identified in Create Purchases payload
- Payment processing identical regardless of entry method
- Group shopping handled correctly
- Empty carts processed consistently
2.2 Self-Service Portal Integration
Duration: 6-8 days
Prerequisites: Portal deployed, payment processor integration
Test Objectives:
- Validate portal functionality for both entry methods
- Test receipt lookup and generation
- Verify refund request processing
- Test debt payoff workflows
Test Cases:
- Receipt lookup by credit card (both entry methods)
- Receipt lookup by date range
- Receipt download and email delivery
- Refund request submission and processing
- Outstanding balance display and payoff
- Debt resolution and store access restoration
- Portal authentication and security
Success Criteria:
- Portal serves shoppers from both entry methods
- Receipt data accurate and complete
- Refund processing functional
- Debt payoff restores store access
- Security and authentication robust
2.3 Catalog Integration Testing
Duration: 4-5 days
Prerequisites: Catalog uploaded, both entry methods functional
Test Objectives:
- Validate catalog consistency across entry methods
- Test catalog updates and synchronization
- Verify SKU recognition accuracy
Test Cases:
- Same SKU recognition for both entry methods
- Catalog update propagation
- Price changes reflected in both flows
- New item addition handling
- Discontinued item removal
Success Criteria:
- Catalog data consistent across entry methods
- Updates propagate within acceptable timeframes
- SKU recognition accuracy > 99%
- Price changes reflected immediately
Phase 3: Performance & Load Testing
3.1 Dual Entry Method Load Testing
Duration: 6-8 days
Prerequisites: Integration testing completed
Load Scenarios:
Mixed Entry Load Test:
- 25 concurrent app entry shoppers
- 25 concurrent credit card entry shoppers
- 2-hour sustained test
- Realistic shopping patterns
Peak Load Test:
- 50 app entry + 50 credit card entry shoppers
- 1-hour sustained test
- High transaction volume
Burst Load Test:
- 100 concurrent identity verifications (app entry)
- 100 concurrent credit card taps
- 5-minute burst test
Performance Targets:
- Verify Identity Keys API: < 2 seconds (95th percentile)
- Create Purchases API: < 3 seconds (95th percentile)
- Payment Service APIs: < 5 seconds (95th percentile)
- Gate response time: < 1 second for both entry methods
- System availability: > 99.9%
3.2 Scalability Testing
Duration: 4-5 days
Prerequisites: Performance baselines established
Test Objectives:
- Determine maximum concurrent capacity for each entry method
- Identify bottlenecks and failure points
- Validate auto-scaling behavior
Test Method:
- Gradually increase load from 20 to 200 concurrent users (mixed entry)
- Monitor response times and error rates by entry method
- Identify breaking points for each component
Success Criteria:
- System handles target load without degradation
- Both entry methods scale proportionally
- Auto-scaling triggers appropriately
- Graceful degradation under extreme load
Phase 4: Security & Compliance Testing
4.1 Multi-Entry Security Testing
Duration: 5-7 days
Prerequisites: All APIs configured with security
Test Objectives:
- Validate security for both entry methods
- Test authentication and authorization
- Verify data protection across all flows
Test Cases:
- App entry: QR code security and encryption
- Credit card entry: PCI DSS compliance
- API authentication for all endpoints
- Rate limiting enforcement
- Data encryption in transit and at rest
- Audit logging completeness
Success Criteria:
- Both entry methods meet security requirements
- PCI DSS compliance maintained
- All API calls properly authenticated
- Complete audit trail maintained
- No sensitive data exposed
4.2 Bad Debt Security Testing
Duration: 3-4 days
Prerequisites: Payment lifecycle functional
Test Objectives:
- Validate bad debt tracking security
- Test debt enforcement mechanisms
- Verify payment status reporting security
Test Cases:
- Bad debt data encryption and protection
- Unauthorized debt modification prevention
- Payment status reporting authentication
- Debt payoff verification and validation
Success Criteria:
- Bad debt data properly secured
- Unauthorized access prevented
- Payment status updates authenticated
- Debt resolution audit trail complete
Phase 5: Operational Readiness Testing
5.1 Monitoring & Alerting
Duration: 5-6 days
Prerequisites: Monitoring infrastructure deployed
Test Objectives:
- Validate monitoring coverage for both entry methods
- Test alerting for all failure scenarios
- Verify business metrics tracking
Test Cases:
- Entry method performance monitoring
- Payment lifecycle alerting
- Catalog sync monitoring
- Self-service portal health checks
- Business metrics by entry method
- Error rate alerting by API and entry method
Success Criteria:
- All critical metrics monitored by entry method
- Alerts trigger within SLA (< 5 minutes)
- Business metrics accurate and actionable
- Dashboards provide clear operational insights
5.2 Disaster Recovery Testing
Duration: 4-5 days
Prerequisites: DR procedures documented
Test Scenarios:
- Identity Connector failure (app entry impact)
- Payment Service API failure
- Catalog API unavailability
- Self-service portal outage
- Database connectivity loss
- Network partition scenarios
Success Criteria:
- Failures isolated to affected entry method when possible
- Recovery procedures effective for both entry methods
- Data integrity maintained across all systems
- RTO/RPO targets met for critical components
5.3 Operational Procedures Testing
Duration: 3-4 days
Prerequisites: Operations team trained
Test Objectives:
- Validate incident response procedures
- Test manual override capabilities
- Verify staff training effectiveness
Test Cases:
- Gate manual override procedures
- Payment failure resolution workflows
- Catalog emergency update procedures
- Customer service escalation paths
- Bad debt resolution processes
Success Criteria:
- All procedures documented and tested
- Staff can execute procedures correctly
- Manual overrides function properly
- Escalation paths clear and effective
Test Environment Requirements
Infrastructure
- Dual Entry Gates: Both QR scanners and credit card readers
- Mobile App: QR code generation capability
- API Gateway: Rate limiting and authentication for all APIs
- Payment Processor: Integration for both entry methods
- Self-Service Portal: Web application with payment processing
- Monitoring: Comprehensive observability stack
Test Data
- Catalog Data: Diverse SKUs with various pricing models
- Test Shoppers: Profiles for both entry methods
- Payment Instruments: Valid and invalid cards for testing
- Mobile Devices: Various phones/tablets for app testing
- QR Codes: Valid and invalid codes for testing
Tools & Frameworks
- API Testing: Postman, Newman for API validation
- Mobile Testing: Appium, Espresso for app testing
- Load Testing: JMeter, k6 for performance testing
- Security Testing: OWASP ZAP, Burp Suite
- Monitoring: CloudWatch, Datadog, New Relic
Test Data Management
Catalog Requirements
{
"comboCatalog": {
"regularItems": [
{"sku": "COMBO-001", "price": 9.99, "name": "Regular Item 1"},
{"sku": "COMBO-002", "price": 15.50, "name": "Regular Item 2"}
],
"promotionalItems": [
{"sku": "PROMO-001", "price": 12.99, "promotion": "Buy 2 Get 1 Free"},
{"sku": "PROMO-002", "price": 8.99, "promotion": "20% off"}
],
"weightBasedItems": [
{"sku": "WEIGHT-001", "pricePerLb": 3.99, "name": "Produce Item"}
],
"loyaltyItems": [
{"sku": "LOYALTY-001", "price": 19.99, "loyaltyPrice": 15.99}
]
}
}
Shopper Profiles
- App Users: Shoppers with mobile app installed
- Credit Card Users: Shoppers without app, using cards only
- Mixed Users: Shoppers who use both entry methods
- Loyalty Members: Shoppers with loyalty program benefits
- Associates: Store employees with special access
- Bad Debt Shoppers: Shoppers with outstanding balances
Success Criteria & Exit Criteria
Phase Exit Criteria
Component Testing:
- All individual APIs function correctly
- Both entry methods work independently
- Payment lifecycle complete for both methods
- Catalog management functional
Integration Testing:
- End-to-end scenarios successful for both entry methods
- Mixed entry scenarios work correctly
- Self-service portal functional
- Cross-system data consistency maintained
Performance Testing:
- Both entry methods meet performance targets
- System scales appropriately under load
- No performance degradation between entry methods
Security Testing:
- Both entry methods meet security requirements
- PCI DSS compliance maintained
- Bad debt security validated
- Audit requirements met
Operational Readiness:
- Monitoring covers both entry methods
- Disaster recovery procedures validated
- Operations team trained and ready
- Documentation complete
Overall Success Criteria
- Both entry methods fully functional
- Seamless shopper experience regardless of entry method
- Payment processing robust and secure
- Self-service portal operational
- System ready for production launch
Risk Mitigation
High-Risk Areas
- Entry Method Coordination: Ensuring consistent behavior across entry methods
- Payment Lifecycle Complexity: Managing full payment lifecycle for both methods
- Self-Service Portal Integration: Complex integration with multiple backend systems
- Bad Debt Management: Tracking and enforcing debt across entry methods
- Performance Under Mixed Load: Handling concurrent load from both entry methods
Mitigation Strategies
- Extensive Cross-Entry Testing: Test all scenarios with both entry methods
- Payment Flow Automation: Automated testing of all payment scenarios
- Portal Integration Testing: Comprehensive end-to-end portal testing
- Bad Debt Simulation: Automated bad debt creation and resolution testing
- Mixed Load Testing: Realistic load patterns with both entry methods
Test Schedule
| Phase | Duration | Dependencies | Resources |
|---|---|---|---|
| Component Testing | 24-34 days | Infrastructure ready | 4-5 developers, 2-3 QA |
| Integration Testing | 18-23 days | Component tests passed | 3-4 QA engineers, 2 developers |
| Performance Testing | 10-13 days | Integration complete | 2 performance engineers, 1 QA |
| Security Testing | 8-11 days | Performance baseline | 2 security engineers, 1 QA |
| Operational Testing | 12-15 days | Security validated | 2 DevOps engineers, 2 QA |
| Total | 72-96 days | 10-15 team members |
Deliverables
Test Documentation
- Comprehensive test execution reports by entry method
- Performance analysis comparing entry methods
- Security assessment covering both entry paths
- Integration test results and analysis
- Defect reports with entry method correlation
Operational Documentation
- Monitoring configuration for dual entry methods
- Incident response procedures for each entry method
- Performance baselines and thresholds by entry type
- Self-service portal operational guide
- Go-live readiness checklist
Code Artifacts
- Automated test suites for both entry methods
- Performance test scripts with mixed load scenarios
- Monitoring dashboards with entry method breakdowns
- Self-service portal test automation
- Bad debt simulation tools
Appendix
Test Case References
- Create Purchases Test Cases
- Verify Identity Keys Test Cases
- Payment Service Test Cases
- Catalog Upload Test Cases
- Get Transactional Data Test Cases
Related Documentation
- App Entry Store Test Plan
- Credit Card Entry Test Plan
- Combo Store Overview
- Operational Readiness Overview
Entry Method Comparison Matrix
| Capability | App Entry | Credit Card Entry | Testing Notes |
|---|---|---|---|
| Gate Authorization | Retailer-managed | Amazon-managed | Test both authorization paths |
| Identity Verification | Required | Not applicable | App entry requires 2-second response |
| Pre-Auth Trigger | After identity verification | At card tap | Different timing for pre-auth placement |
| payloadType | SCAN_CODE | FINANCIAL | Verify correct identification in Create Purchases |
| Shopper ID | Present in cart | Not present | Test cart processing differences |
| Fallback Method | Credit card tap | None | Test fallback scenarios |
| Bad Debt Enforcement | Via Identity API | Via F&A API (if configured) | Test debt enforcement for both methods |
