Amazon Developer

Console

as

Settings
Sign out
Notifications
Alexa
Amazonアプリストア
Ring
AWS
ドキュメント
Support
Contact Us
My Cases

Console

as

Docs
Resources
Ecommerce Plug-ins
Publish
Connect
アクセスいただきありがとうございます。こちらのページは現在英語のみのご用意となっております。順次日本語化を進めてまいりますので、ご理解のほどよろしくお願いいたします。

Credit Card Entry Store Test Plan

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

This test plan serves as a sample guidance document for testing a Just Walk Out store that uses credit card entry with the retailer managing the full payment lifecycle through Amazon's Payment Service APIs. Amazon handles shopper identity at the gate and charge calculation, while the retailer orchestrates adjust, capture, cancel, and refund operations and retrieves transactional and shopper identity data.

This plan should be supplemented with your organization's established testing best practices.

Test Plan Overview

APIs Under Test:

  • Create Purchases API (POST /v1/order/purchases) — Order Delegation — Test Cases
  • Shopper Authorization API (POST /v1/fraudandabuse/shopperauthorization) — Risk Overview | API Reference
  • Report Payment Status API (POST /v1/feedback/payment-status) — API Reference | Test Cases
  • Adjust Charge API (POST /v1/adjust/charge) — Test Cases
  • Cancel Charge API (POST /v1/cancel/charge) — Test Cases
  • Capture Charge API (POST /v1/capture/charge) — Test Cases
  • Refund Charge API (POST /v1/refund) — Test Cases
  • Get Transactional Data API (POST /v1/payment/transactional-data) — Test Cases
  • Get Shopper Identity API (POST /v1/identity/shopper) — Test Cases

Key Reference Documentation:

Test Environment Setup

  • Test Store ID: TEST_STORE_001
  • Test Payment Cards: Multiple test cards (Visa, Mastercard, Amex) with known outcomes
  • Test Shopping Trip IDs: Pre-generated UUIDs for each test scenario
  • Mock Payment Processor: Configured to simulate approved, declined, and pending responses

1. Adjust Charge Test Cases

1.1 Successful Adjustment

Test Case ID: AC-001 Objective: Verify a successful charge adjustment after a shopping trip

Test Data:

{
  "storeId": "TEST_STORE_001",
  "shoppingTripId": "550e8400-e29b-41d4-a716-446655440000",
  "amount": {
    "amount": 25.99,
    "code": "USD"
  }
}

Expected Result:

  • HTTP 200 response
  • Status: APPROVED
  • authorizedAmount matches the requested amount

1.2 Declined Adjustment

Test Case ID: AC-002 Objective: Verify handling of a declined adjustment (e.g., insufficient funds)

Expected Result:

  • HTTP 200 response with status: DECLINED
  • System records the decline and triggers bad debt workflow
  • Alert generated for operations team

1.3 Pending Adjustment

Test Case ID: AC-003 Objective: Verify retry logic when adjustment returns PENDING status

Expected Result:

  • HTTP 200 response with status: PENDING
  • System retries until terminal state (APPROVED or DECLINED) is reached
  • Maximum retry attempts enforced

1.4 Adjustment with Zero Amount

Test Case ID: AC-004 Objective: Verify behavior when cart total is zero (empty cart scenario)

Test Data: amount: 0.00

Expected Result: System triggers cancel charge flow instead of adjust

1.5 Unknown Shopping Trip

Test Case ID: AC-005 Objective: Verify 400 error for invalid shoppingTripId

Expected Result:

  • HTTP 400 UnknownShoppingTrip
  • Error logged and no charge adjustment attempted

1.6 Rate Limiting

Test Case ID: AC-006 Objective: Verify 429 handling with Retry-After header

Test Method: Send rapid concurrent adjust requests exceeding rate limit

Expected Result:

  • HTTP 429 with Retry-After: 600
  • System retries after backoff period

1.7 Server Error and Retry

Test Case ID: AC-007 Objective: Verify retry with exponential backoff on 500/503 errors

Expected Result:

  • System retries with exponential backoff
  • Adjustment succeeds on retry or alert raised after max retries

2. Cancel Charge Test Cases

2.1 Successful Cancellation — Empty Cart

Test Case ID: CC-001 Objective: Verify charge cancellation when shopper exits with an empty cart

Test Data:

{
  "storeId": "TEST_STORE_001",
  "shoppingTripId": "550e8400-e29b-41d4-a716-446655440001"
}

Expected Result:

  • HTTP 200 response
  • Pre-auth released on shopper's payment instrument

2.2 Cancel After Successful Adjust

Test Case ID: CC-002 Objective: Verify cancellation behavior after a charge has already been adjusted

Expected Result: Document whether cancel is accepted or rejected after adjustment

2.3 Cancel Already-Captured Charge

Test Case ID: CC-003 Objective: Verify system prevents cancellation of an already-captured charge

Expected Result:

  • Cancel is rejected or routed to refund flow
  • Error logged

2.4 Unknown Shopping Trip

Test Case ID: CC-004 Objective: Verify 400 error for invalid shoppingTripId

Expected Result: HTTP 400 UnknownShoppingTrip

2.5 Server Error and Retry

Test Case ID: CC-005 Objective: Verify retry logic on 500/503 errors for cancel

Expected Result: System retries with exponential backoff

3. Capture Charge Test Cases

3.1 Successful Capture After Approved Adjust

Test Case ID: CAP-001 Objective: Verify successful capture following an approved adjustment

Test Data:

{
  "storeId": "TEST_STORE_001",
  "shoppingTripId": "550e8400-e29b-41d4-a716-446655440000",
  "amount": {
    "amount": 25.99,
    "code": "USD"
  }
}

Expected Result:

  • HTTP 200 response
  • Funds captured from shopper's payment instrument

3.2 Capture Amount Matches Adjusted Amount

Test Case ID: CAP-002 Objective: Verify capture amount matches the authorized amount from the adjust response

Expected Result:

  • Capture succeeds when amount matches authorizedAmount
  • Document behavior when capture amount differs from authorizedAmount

3.3 Partial Capture

Test Case ID: CAP-003 Objective: Verify capture of an amount less than the pre-authorized amount

Expected Result:

  • Partial amount captured
  • Remaining authorization released
  • Accurate transaction record

3.4 Capture Declined

Test Case ID: CAP-004 Objective: Handle declined capture scenarios

Test Scenarios:

  • Card expired since pre-auth
  • Account closed
  • Fraud detection triggered post-adjust

Expected Result:

  • Capture declined
  • Appropriate error handling triggered
  • Bad debt workflow initiated

3.5 Capture Without Prior Adjust

Test Case ID: CAP-005 Objective: Verify behavior when capture is attempted without a prior adjustment

Expected Result: HTTP 400 error or appropriate rejection

3.6 Capture After Declined Adjust

Test Case ID: CAP-006 Objective: Verify capture is rejected when the prior adjustment was declined

Expected Result: Capture fails with appropriate error

3.7 Duplicate Capture — Idempotency

Test Case ID: CAP-007 Objective: Verify duplicate capture requests do not result in double charges

Test Steps:

  1. Successfully capture a charge
  2. Send the same capture request again

Expected Result: No duplicate financial transaction

3.8 Unknown Shopping Trip

Test Case ID: CAP-008 Objective: Verify 400 error for invalid shoppingTripId

Expected Result: HTTP 400 UnknownShoppingTrip

3.9 Server Error and Retry

Test Case ID: CAP-009 Objective: Verify retry logic on 500/503 errors for capture

Expected Result: System retries with exponential backoff; no duplicate captures

4. Refund Test Cases

4.1 Successful Refund — Each Reason Code

Test Case ID: REF-001 Objective: Verify successful refund for each refundReasonCode

Test Steps:

  1. Refund with DAMAGED_ITEM
  2. Refund with EXPIRED_ITEM
  3. Refund with UNWANTED_ITEM
  4. Refund with JWO_TECH_ERROR
  5. Refund with OTHER

Expected Result:

  • HTTP 200 with reconciliationId for each
  • Refund reflected in payment processor records

4.2 Refund Idempotency

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

Expected Result: Same reconciliationId returned; no duplicate refund

4.3 Refund After 30-Day Window

Test Case ID: REF-003 Objective: Verify refund is rejected after the 30-day window

Expected Result: Refund rejected with appropriate error

4.4 Refund for Unknown Shopping Trip

Test Case ID: REF-004 Objective: Verify 400 error for invalid shoppingTripId

Expected Result: HTTP 400 UnknownShoppingTrip

4.5 Partial Refund

Test Case ID: REF-005 Objective: Verify a partial refund (amount less than captured total)

Expected Result:

  • HTTP 200 with reconciliationId
  • Partial amount refunded
  • Remaining charge intact

4.6 Refund Declined

Test Case ID: REF-006 Objective: Handle declined refund

Expected Result:

  • Refund declined with reason
  • Manual intervention required
  • Incident logged

4.7 Rate Limiting and Retry

Test Case ID: REF-007 Objective: Verify 429 and 500/503 handling for refund API

Expected Result: System retries with backoff; no duplicate refunds

5. Get Transactional Data Test Cases

5.1 Successful Data Retrieval

Test Case ID: TD-001 Objective: Verify transactional data is returned for a completed shopping trip

Test Data:

{
  "storeId": "TEST_STORE_001",
  "shoppingTripId": "550e8400-e29b-41d4-a716-446655440000"
}

Expected Result:

  • HTTP 200 response
  • Response contains: brand, posEntryMode, currency, tail (last 4 digits), reconciliationId, cardStatementTransactionId, expirationDate, terminalId

5.2 EMV Field Validation

Test Case ID: TD-002 Objective: Verify all EMV fields are present and correctly formatted

Expected Result:

  • posEntryMode matches valid enum values
  • cryptogramInformationData is 2-character hex
  • panSequenceNumber is present
  • applicationId is valid hex

5.3 Transactional Data for Refunded Trip

Test Case ID: TD-003 Objective: Verify transactional data includes refund details for a refunded shopping trip

Expected Result:

  • Original charge details present
  • Refund transaction details present
  • Net transaction amount accurate

5.4 Unknown Shopping Trip

Test Case ID: TD-004 Objective: Verify 400 error for non-existent shoppingTripId

Expected Result: HTTP 400 UnknownShoppingTrip

5.5 Data Retrieval Before Capture

Test Case ID: TD-005 Objective: Verify transactional data availability before capture is completed

Expected Result: Document whether data is available after adjust or only after capture

5.6 Rate Limiting and Retry

Test Case ID: TD-006 Objective: Verify 429 and 500/503 handling

Expected Result: System retries with backoff

6. Get Shopper Identity Test Cases

6.1 Successful Shopper Identity Retrieval

Test Case ID: SI-001 Objective: Verify shopper email is returned for a valid shopper ID

Test Data:

{
  "storeId": "TEST_STORE_001",
  "shopperId": {
    "id": "shopper-identity-001"
  }
}

Expected Result:

  • HTTP 200 response
  • shopperEmail returned in valid email format

6.2 Invalid Shopper ID

Test Case ID: SI-002 Objective: Verify 400 error for non-existent shopper ID

Expected Result: HTTP 400 BadRequestException

6.3 Shopper Without Email Registration

Test Case ID: SI-003 Objective: Verify behavior when shopper has not registered an email at the receipt kiosk

Expected Result: Document whether empty string, null, or 404 is returned

6.4 Unauthorized Identity Request

Test Case ID: SI-004 Objective: Verify 403 when request lacks proper authorization

Expected Result:

  • HTTP 403 Access denied
  • Security audit logged

6.5 PII Handling

Test Case ID: SI-005 Objective: Verify shopper email is not logged in application logs or error messages

Test Steps:

  1. Retrieve shopper identity
  2. Inspect application logs
  3. Verify email is masked or absent from logs

Expected Result: No PII in logs

6.6 Rate Limiting and Retry

Test Case ID: SI-006 Objective: Verify 429 and 500/503 handling

Expected Result: System retries with backoff

7a. Shopper Authorization Test Cases (POST /v1/fraudandabuse/shopperauthorization)

7a.1 Shopper Authorized — Low Risk

Test Case ID: FA-001 Objective: Authorize low-risk shopper for store entry

Test Data:

{
  "storeId": "TEST_STORE_001",
  "shopperIdentity": { "id": "shopper-low-risk-001" },
  "authorizedAmount": { "value": 50.00, "currencyCode": "USD" },
  "shopperInteraction": {
    "shoppingTripId": "550e8400-e29b-41d4-a716-446655440000",
    "gateAuthenticationEvent": {
      "id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
      "type": "CREDIT_CARD",
      "interactionType": "TAP",
      "timestamp": "2024-03-22T17:00:00Z",
      "location": "ENTRY"
    },
    "recommendation": {
      "shopperAuthorized": true,
      "shopperRisks": []
    }
  }
}

Expected Result:

  • HTTP 200 response
  • shopperAuthorized: true
  • No risk flags
  • Gate opens

7a.2 Shopper Denied — High Risk (CustomerFraud, BadDebt)

Test Case ID: FA-002 Objective: Deny high-risk shopper entry based on Amazon recommendation

Test Data: Request with recommendation containing shopperAuthorized: false and shopperRisks: ["CustomerFraud", "BadDebt"]

Expected Result:

  • HTTP 200 response
  • shopperAuthorized: false
  • Risk flags: ["CustomerFraud", "BadDebt"]
  • Gate remains closed

7a.3 Conditional Authorization — Reduced Pre-Auth (ADJUST)

Test Case ID: FA-003 Objective: Authorize with reduced pre-auth amount based on risk using authorizationConditions

Test Data: Request with recommendation containing shopperAuthorized: true, shopperRisks: ["NonpaymentMediumRisk"], and authorizationConditions: [{ "type": "ADJUST", "amount": { "value": 25.00, "currencyCode": "USD" } }]

Expected Result:

  • HTTP 200 response
  • shopperAuthorized: true
  • authorizationConditions with ADJUST type and reduced amount
  • Pre-auth placed at reduced amount
  • Reduced amount flows through adjust → capture lifecycle

7a.4 Invalid Card Detection

Test Case ID: FA-004 Objective: Handle invalid payment method at gate

Test Data: Request with recommendation containing shopperRisks: ["InvalidCard"]

Expected Result:

  • shopperAuthorized: false
  • Risk flags: ["InvalidCard"]
  • Gate remains closed

7a.5 Expired Card Handling

Test Case ID: FA-005 Objective: Detect and handle expired cards at gate

Test Data: Request with recommendation containing shopperRisks: ["ExpiredCard"]

Expected Result:

  • shopperAuthorized: false
  • Risk flags: ["ExpiredCard"]
  • Gate remains closed

7a.6 All ShopperRisk Enum Values

Test Case ID: FA-006 Objective: Verify system handles all shopperRisks enum values correctly

Test Steps: Submit requests with each risk type individually:

  • InvalidCard, ExpiredCard, FailureToVetCard, BillingAddressInvalid
  • CustomerFraud, CustomerConfirmedFraud, BadDebt, AccountIssue
  • CreditCardFraud, CardNotSupported
  • NonpaymentLowRisk, NonpaymentMediumRisk, NonpaymentHighRisk
  • NoRiskEvaluationRun

Expected Result: Each risk type is processed correctly; gate decision matches authorization response

7a.7 All Authentication Event Types

Test Case ID: FA-007 Objective: Verify shopper authorization for each gateAuthenticationEvent type

Test Steps: Submit requests with each type:

  • CREDIT_CARD (with interactionType: TAP, DIP, SWIPE)
  • AMAZON_ONE
  • QR
  • MOBILE_WALLET
  • UNRECOGNIZED

Expected Result: Each authentication type is processed; risk assessment completed; authorization decision returned

7a.8 Override Amazon Recommendation — Accept

Test Case ID: FA-008 Objective: Verify retailer can accept Amazon's recommendation as-is

Test Data: Amazon recommends shopperAuthorized: true; retailer returns shopperAuthorized: true

Expected Result: Gate opens; pre-auth placed at recommended amount

7a.9 Override Amazon Recommendation — Deny

Test Case ID: FA-009 Objective: Verify retailer can override Amazon's recommendation and deny entry

Test Data: Amazon recommends shopperAuthorized: true; retailer returns shopperAuthorized: false

Expected Result: Gate remains closed; override decision logged

7a.10 Override Amazon Recommendation — Adjust Amount

Test Case ID: FA-010 Objective: Verify retailer can override the pre-auth amount in authorizationConditions

Test Data: Amazon recommends amount 50.00; retailer overrides to 75.00 via authorizationConditions ADJUST

Expected Result: Pre-auth placed at retailer-specified amount; override logged

7a.11 Outstanding Balance — Deny Entry

Test Case ID: FA-011 Objective: Verify shopper with outstanding balance is denied entry

Test Data: Shopper has a previous unpaid shopping trip; recommendation includes shopperRisks: ["BadDebt"] and shopperAuthorized: false

Expected Result:

  • shopperAuthorized: false
  • Gate remains closed until outstanding balance is resolved

7a.12 Missing Required Fields (400 Error)

Test Case ID: FA-012 Objective: Verify 400 error for missing required fields

Test Steps: Submit requests missing each required field individually:

  • storeId
  • shopperIdentity.id
  • authorizedAmount (value, currencyCode)
  • shopperInteraction.gateAuthenticationEvent (id, type, timestamp, location)

Expected Result: HTTP 400 BadRequestException for each missing field

7a.13 Invalid Store ID (400 Error)

Test Case ID: FA-013 Objective: Verify 400 error for invalid storeId

Expected Result: HTTP 400 BadRequestException

7a.14 Missing Connector Configuration (404 Error)

Test Case ID: FA-014 Objective: Verify 404 when the Fraud and Abuse Connector is not configured

Expected Result: HTTP 404 NoConnectorConfiguredException

7a.15 Server Error and Retry (500/503)

Test Case ID: FA-015 Objective: Verify retry with exponential backoff on 500/503 errors

Expected Result:

  • System retries with exponential backoff
  • Gate follows default decision during retries
  • Alert raised after max retries exhausted

7a.16 Fraud System Unavailable — Fallback

Test Case ID: FA-016 Objective: Verify fallback behavior when the Fraud and Abuse Connector is unavailable

Expected Result:

  • Default authorization rules applied
  • System continues operating
  • Alert generated for fraud system outage

7b. Report Payment Status Test Cases (POST /v1/feedback/payment-status)

7b.1 Successful Payment Report — Full Settlement

Test Case ID: FBK-001 Objective: Report successful payment where settledAmount equals totalAmount

Test Data:

{
  "storeId": "TEST_STORE_001",
  "shoppingTripId": "550e8400-e29b-41d4-a716-446655440000",
  "totalAmount": { "amount": 25.99, "code": "USD" },
  "settledAmount": { "amount": 25.99, "code": "USD" },
  "paymentStatusTime": 1640995200
}

Expected Result:

  • HTTP 200 response
  • status: "Accepted"
  • Amazon clears outstanding balance for this shopping trip

7b.2 Partial Settlement — Outstanding Balance

Test Case ID: FBK-002 Objective: Report partial payment where settledAmount is less than totalAmount

Test Data: totalAmount: 25.99, settledAmount: 15.00

Expected Result:

  • HTTP 200 with status: "Accepted"
  • Amazon records outstanding balance of 10.99 for the shopper
  • Outstanding balance considered in future shopper authorization decisions

7b.3 Zero Settlement — Full Bad Debt

Test Case ID: FBK-003 Objective: Report zero settlement (complete payment failure)

Test Data: totalAmount: 25.99, settledAmount: 0.00

Expected Result:

  • HTTP 200 with status: "Accepted"
  • Full amount recorded as outstanding balance

7b.4 Unknown Shopping Trip (400 Error)

Test Case ID: FBK-004 Objective: Verify 400 error for non-existent shoppingTripId

Expected Result: HTTP 400 UnknownShoppingTrip

7b.5 Missing Required Fields (400 Error)

Test Case ID: FBK-005 Objective: Verify 400 error for missing required fields (storeId, shoppingTripId, totalAmount, settledAmount, paymentStatusTime)

Expected Result: HTTP 400 BadRequestException for each missing field

7b.6 Server Error and Retry (500)

Test Case ID: FBK-006 Objective: Verify retry with exponential backoff on 500 errors

Expected Result: System retries with backoff; alert raised after max retries

7b.7 Payment Feedback After Each Payment Lifecycle Outcome

Test Case ID: FBK-007 Objective: Verify payment status is reported after each payment outcome

Test Steps:

  1. Report status after successful capture (settled = total)
  2. Report status after declined adjust (settled = 0)
  3. Report status after partial capture (settled < total)
  4. Report status after cancelled charge (settled = 0, total = 0)

Expected Result: Each outcome correctly reported; Amazon outstanding balance tracking updated accordingly

7c. Charge Calculation Precision Test Cases

7c.1 Decimal Rounding

Test Case ID: CP-001 Objective: Verify 2-decimal place rounding in price calculations

Test Data: Items with prices that produce rounding edge cases (e.g., 0.005, 0.995)

Expected Result: All amounts rounded to 2 decimal places correctly

7c.2 Promotional Pricing — Percentage Discount

Test Case ID: CP-002 Objective: Verify percentage-based promotion calculation

Expected Result: Discount calculated as exact percentage of item price

7c.3 Promotional Pricing — Fixed Amount Discount

Test Case ID: CP-003 Objective: Verify fixed dollar amount discount

Expected Result: Fixed amount deducted from item price

7c.4 Promotional Pricing — BOGO

Test Case ID: CP-004 Objective: Verify buy-one-get-one promotion logic

Expected Result: Free item correctly applied; total reflects BOGO

7c.5 Stacked Promotions

Test Case ID: CP-005 Objective: Verify multiple promotions applied to the same cart

Expected Result: Promotions stacked correctly per business rules; no conflicts

7c.6 Promotion Limits

Test Case ID: CP-006 Objective: Verify maximum discount constraints are enforced

Expected Result: Discount capped at configured limit

7c.7 Tax Calculation — Standard Sales Tax

Test Case ID: CP-007 Objective: Verify standard sales tax application

Expected Result: Tax calculated correctly based on item category and jurisdiction

7c.8 Tax Calculation — Tax-Exempt Items

Test Case ID: CP-008 Objective: Verify tax-free product handling

Expected Result: No tax applied to exempt items

7c.9 Tax Calculation — Multiple Tax Rates

Test Case ID: CP-009 Objective: Verify different tax rates per item category

Expected Result: Each item taxed at its correct rate

7c.10 Tax on Discounted Items

Test Case ID: CP-010 Objective: Verify tax is calculated after promotions are applied

Expected Result: Tax calculated on discounted price, not list price

7c.11 Total Formula Validation

Test Case ID: CP-011 Objective: Verify totalPrice = price - promotions + tax

Expected Result: Formula holds for all cart configurations

7c.12 Negative Total Prevention

Test Case ID: CP-012 Objective: Verify system prevents negative cart totals from excessive discounts

Expected Result: Total floored at zero; no negative charges

7c.13 Large Cart Calculation

Test Case ID: CP-013 Objective: Verify calculation accuracy with high-value carts and many items

Expected Result: No arithmetic overflow; precision maintained

7c.14 Catalog Price vs. Calculated Price Consistency

Test Case ID: CP-014 Objective: Verify calculated price matches the catalog price for non-promoted items

Expected Result: No price discrepancies between catalog and charge calculation

7c.15 Duplicate Line Items

Test Case ID: CP-015 Objective: Verify handling of duplicate SKUs in the same cart

Expected Result: Document whether duplicates are merged or processed individually

8. Create Purchases (Order Delegation) Test Cases

8.1 Single Item Cart

Test Case ID: OP-001 Objective: Verify a single-item cart is processed and returns a purchaseId

Test Data:

{
  "requestId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "idempotentShoppingTripId": "11111111-2222-3333-4444-555555555555",
  "storeId": "TEST_STORE_001",
  "shoppingTrip": {
    "startTime": "2024-03-22T17:00:00Z",
    "endTime": "2024-03-22T17:09:39Z",
    "authEvents": [
      {
        "id": "aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee",
        "timestamp": "2024-03-22T17:00:00Z",
        "location": "ENTRY",
        "payloadType": "FINANCIAL"
      }
    ]
  },
  "cartItems": [
    {
      "id": "SKU-001",
      "type": "SKU",
      "quantity": { "value": "1.0", "unit": "unit" }
    }
  ]
}

Expected Result:

  • HTTP 201 response with purchaseId
  • Pricing, promotions, and taxes calculated correctly

8.2 Multi-Item Cart

Test Case ID: OP-002 Objective: Verify a cart with multiple items of varying quantities

Test Data: Cart with 3 items (quantities: 2, 1, 4)

Expected Result:

  • HTTP 201 with purchaseId
  • All items priced correctly

8.3 Weight-Based Item

Test Case ID: OP-003 Objective: Verify a cart item sold by weight

Test Data: cartItem with quantity {"value": "1.5", "unit": "lb"}

Expected Result: HTTP 201; charge calculated based on weight × price per unit

8.4 SCANCODE Cart Item Type

Test Case ID: OP-004 Objective: Verify a cart item with type SCANCODE

Test Data: cartItem with "type": "SCANCODE" and barcode id

Expected Result: HTTP 201 with purchaseId

8.5 Cart with External Identifiers

Test Case ID: OP-005 Objective: Verify cart items with externalIdentifiers (UPC, EAN, GTIN, PLU)

Expected Result: HTTP 201; external identifiers accepted

8.6 Cart with lineItemId

Test Case ID: OP-006 Objective: Verify optional lineItemId is accepted for input/output correlation

Expected Result: HTTP 201 with purchaseId

8.7 Empty Cart

Test Case ID: OP-007 Objective: Verify empty cart returns empty purchaseId and triggers pre-auth cancellation

Test Data: "cartItems": []

Expected Result:

  • HTTP 201 with "purchaseId": ""
  • No charge created
  • Pre-auth cancellation triggered

8.8 Credit Card Entry (FINANCIAL payloadType)

Test Case ID: OP-008 Objective: Verify purchase creation for a credit card entry shopping trip

Test Data: authEvent with "payloadType": "FINANCIAL"

Expected Result: HTTP 201 with purchaseId

8.9 Group Shopping Trip — Multiple Auth Events

Test Case ID: OP-009 Objective: Verify purchase creation when multiple shoppers entered together

Test Data: Two authEvents with different ids and timestamps

Expected Result: HTTP 201; cart associated with the group trip

8.10 Unrecognized SKU in Cart

Test Case ID: OP-010 Objective: Verify behavior when a cart contains a SKU not in the catalog

Test Data: cartItem with "id": "UNKNOWN-SKU-999"

Expected Result:

  • HTTP 201 (structurally valid payload)
  • Item routed to bad cart handling process

8.11 Idempotency — Same idempotentShoppingTripId

Test Case ID: OP-011 Objective: Verify same purchaseId returned on duplicate requests

Test Steps:

  1. Send a valid request with idempotentShoppingTripId AAAA-...
  2. Send the exact same request again
  3. Verify both return the same purchaseId

Expected Result: No duplicate purchase records created

8.12 Idempotency — Different requestId, Same idempotentShoppingTripId

Test Case ID: OP-012 Objective: Verify idempotency is keyed on idempotentShoppingTripId, not requestId

Expected Result: Same purchaseId returned regardless of requestId

8.13 Missing Required Fields

Test Case ID: OP-013 Objective: Verify 400 for missing required fields

Test Steps: Submit requests missing each required field individually:

  • requestId
  • idempotentShoppingTripId
  • storeId
  • shoppingTrip (startTime, endTime, authEvents)
  • cartItems (id, type, quantity)

Expected Result: HTTP 400 for each missing field

8.14 Invalid Field Formats

Test Case ID: OP-014 Objective: Verify 400 for invalid field formats

Test Data:

  • Invalid requestId (not UUID)
  • storeId exceeding 255 characters
  • Invalid authEvent.id (not UUID)
  • Invalid payloadType (not FINANCIAL or SCAN_CODE)
  • Invalid cartItem.type (not SKU or SCANCODE)
  • quantity.value exceeding 10 characters

Expected Result: HTTP 400 for each invalid format

8.15 endTime Before startTime

Test Case ID: OP-015 Objective: Verify 400 when endTime precedes startTime

Expected Result: HTTP 400

8.16 Unauthorized Request

Test Case ID: OP-016 Objective: Verify 401 when IAM role is not allowlisted

Expected Result: HTTP 401 Authorization declined

8.17 Rate Limiting

Test Case ID: OP-017 Objective: Verify 429 handling for Create Purchases API

Test Method: Send rapid concurrent requests exceeding rate limit

Expected Result: HTTP 429; retry with backoff succeeds

8.18 Server Error and Retry

Test Case ID: OP-018 Objective: Verify retry with exponential backoff on 500/503 errors

Expected Result: System retries; no duplicate purchases due to idempotentShoppingTripId

8.19 Forward Compatibility — Unknown Fields

Test Case ID: OP-019 Objective: Verify the Ordering Connector ignores unknown fields gracefully

Test Data: Add "newFutureField": "value" to the request body

Expected Result: HTTP 201; unknown field does not cause failure

9. Integration Flow Test Cases

9.1 Complete Flow — Order Delegation Through Capture

Test Case ID: IF-001 Objective: End-to-end flow from order delegation to capture

Test Flow:

  1. Shopper enters store via credit card tap
  2. Shopper selects items and exits
  3. Amazon sends cart to retailer via Create Purchases API
  4. Retailer calculates pricing, returns purchaseId
  5. Retailer calls Adjust Charge → receives APPROVED
  6. Retailer calls Capture Charge → receives 200
  7. Retailer calls Get Transactional Data → receives EMV data
  8. Retailer calls Get Shopper Identity → receives shopperEmail
  9. Retailer generates and delivers receipt

Expected Result: Seamless flow; all APIs respond correctly; receipt delivered

9.2 Empty Cart — Cancel Flow

Test Case ID: IF-002 Objective: Verify cancel flow when shopper exits without items

Test Flow:

  1. Shopper enters store
  2. Shopper exits without taking items
  3. Amazon sends empty cart via Create Purchases API
  4. Retailer returns empty purchaseId
  5. Retailer calls Cancel Charge → receives 200
  6. Pre-auth released

Expected Result: No charge; pre-auth cancelled

9.3 Declined Adjust — Bad Debt Flow

Test Case ID: IF-003 Objective: Verify bad debt handling when adjustment is fully declined

Test Flow:

  1. Shopper completes shopping trip with cart total $25.99
  2. Retailer calls Adjust Charge → receives DECLINED with authorizedAmount: $0.00
  3. System records bad debt incident (full cart amount)
  4. Retailer calls Report Payment Status API with totalAmount: $25.99, settledAmount: $0.00
  5. Amazon records outstanding balance against the shopper's payment instrument
  6. Alert generated for operations team

Expected Result:

  • Bad debt recorded with shoppingTripId, amount, and root cause "payment decline"
  • Payment feedback sent to Amazon
  • Outstanding balance tracked for future gate decisions
  • No capture attempted

9.4 Partial Capture — Partial Bad Debt Flow

Test Case ID: IF-004 Objective: Verify partial payment capture when full adjustment is declined but a lower amount is authorized

Test Flow:

  1. Shopper completes shopping trip with cart total $50.00
  2. Retailer calls Adjust Charge → receives DECLINED with authorizedAmount: $30.00 (last successful amount)
  3. Retailer decides to capture the authorized amount based on risk tolerance
  4. Retailer calls Capture Charge with amount: $30.00 → receives 200
  5. Retailer records remaining $20.00 as bad debt
  6. Retailer calls Report Payment Status API with totalAmount: $50.00, settledAmount: $30.00
  7. Amazon records $20.00 outstanding balance against the shopper

Expected Result:

  • $30.00 captured successfully
  • $20.00 recorded as bad debt
  • Payment feedback reflects partial settlement
  • Outstanding balance of $20.00 tracked for future gate decisions

9.5 Incremental Adjust — Find Maximum Approved Amount

Test Case ID: IF-005 Objective: Verify incremental adjustment strategy to maximize captured amount when full amount is declined

Test Flow:

  1. Shopper completes shopping trip with cart total $100.00
  2. Retailer calls Adjust Charge with $100.00 → DECLINED, authorizedAmount: $0.00
  3. Retailer calls Adjust Charge with $75.00 → DECLINED, authorizedAmount: $0.00
  4. Retailer calls Adjust Charge with $50.00 → APPROVED, authorizedAmount: $50.00
  5. Retailer calls Capture Charge with $50.00 → 200
  6. Retailer records $50.00 as bad debt
  7. Retailer calls Report Payment Status with totalAmount: $100.00, settledAmount: $50.00

Expected Result:

  • Maximum recoverable amount captured
  • Remaining balance recorded as bad debt
  • Payment feedback accurately reflects partial settlement
  • No duplicate charges from incremental adjustments

9.6 Bad Debt Shopper Denied Entry on Next Visit

Test Case ID: IF-006 Objective: Verify a shopper with outstanding balance is denied entry on their next store visit

Test Flow:

  1. Shopper has outstanding balance from a previous declined payment (IF-003 or IF-004)
  2. Shopper returns to store and taps credit card at gate
  3. Amazon calls Shopper Authorization API with recommendation: shopperAuthorized: false, shopperRisks: ["BadDebt"]
  4. Retailer's Fraud and Abuse Connector returns shopperAuthorized: false
  5. Gate remains closed

Expected Result:

  • Shopper denied entry due to outstanding balance
  • Gate remains closed
  • Denial reason logged for audit
  • Shopper is informed of outstanding balance (if applicable via in-store signage or support)

9.7 Bad Debt Shopper — Conditional Entry with Increased Pre-Auth

Test Case ID: IF-007 Objective: Verify a shopper with outstanding balance can be conditionally authorized with an increased pre-auth amount

Test Flow:

  1. Shopper has $20.00 outstanding balance from a previous partial settlement
  2. Shopper returns to store and taps credit card
  3. Amazon calls Shopper Authorization API with recommendation: shopperAuthorized: true, shopperRisks: ["NonpaymentMediumRisk"], authorizationConditions: [{ type: "ADJUST", amount: { value: 70.00 } }]
  4. Retailer accepts the recommendation and returns shopperAuthorized: true with increased pre-auth
  5. Gate opens with higher pre-auth amount
  6. Shopper completes shopping trip
  7. Retailer captures full cart amount successfully
  8. Retailer calls Report Payment Status with full settlement

Expected Result:

  • Conditional entry granted with increased pre-auth
  • Higher pre-auth covers both new cart and outstanding risk
  • Successful capture clears the current trip
  • Payment feedback updates Amazon's outstanding balance tracking

9.8 Bad Debt Resolution — Shopper Pays Off Outstanding Balance

Test Case ID: IF-008 Objective: Verify a shopper can resolve their outstanding balance and regain store access

Test Flow:

  1. Shopper has $25.99 outstanding balance and was denied entry (IF-006)
  2. Shopper resolves outstanding balance through retailer's payment resolution process (e.g., online payment portal, customer service)
  3. Retailer calls Report Payment Status API for the original shoppingTripId with totalAmount: $25.99, settledAmount: $25.99
  4. Amazon clears the outstanding balance for this shopping trip
  5. Shopper returns to store and taps credit card
  6. Amazon calls Shopper Authorization API → recommendation: shopperAuthorized: true, shopperRisks: []
  7. Gate opens normally

Expected Result:

  • Outstanding balance cleared after payment feedback confirms full settlement
  • Shopper authorized on next visit with no risk flags
  • Gate opens normally
  • Audit trail shows debt resolution lifecycle (incurred → denied → resolved → re-authorized)

9.9 Bad Debt Resolution — Partial Payoff Still Denied

Test Case ID: IF-009 Objective: Verify a shopper who partially pays off their outstanding balance is still denied or conditionally authorized

Test Flow:

  1. Shopper has $50.00 outstanding balance across two shopping trips
  2. Shopper pays off $25.00 of the outstanding balance
  3. Retailer calls Report Payment Status for the first trip with updated settledAmount
  4. Shopper returns to store
  5. Amazon calls Shopper Authorization API → recommendation still includes shopperRisks: ["BadDebt"] or ["NonpaymentMediumRisk"]

Expected Result:

  • Remaining $25.00 outstanding balance still tracked
  • Shopper denied or conditionally authorized based on retailer's risk tolerance
  • Gate decision reflects remaining outstanding balance

9.10 Multiple Bad Debt Incidents — Repeat Offender Escalation

Test Case ID: IF-010 Objective: Verify escalation when a shopper accumulates multiple bad debt incidents

Test Flow:

  1. Shopper has 3 separate shopping trips with outstanding balances
  2. Shopper attempts entry
  3. Amazon calls Shopper Authorization API → recommendation: shopperAuthorized: false, shopperRisks: ["NonpaymentHighRisk", "BadDebt"]
  4. Retailer denies entry

Expected Result:

  • Repeat offender flagged with escalated risk level
  • Entry denied regardless of pre-auth amount
  • Incident logged for fraud investigation
  • Shopper must resolve all outstanding balances before re-entry is considered

9.11 Pre-Auth Expiration — Uncharged Cart Creates Bad Debt

Test Case ID: IF-011 Objective: Verify bad debt is recorded when the payment token expires before the cart is charged

Test Flow:

  1. Shopper enters store, pre-auth placed
  2. Shopper exits, cart received
  3. Charge calculation or payment processing is delayed beyond the token expiration window (~46 hours)
  4. Retailer attempts Adjust Charge → receives ShoppingTripExpiredException
  5. Retailer records full cart amount as bad debt
  6. Retailer calls Report Payment Status with totalAmount: cart total, settledAmount: $0.00

Expected Result:

  • Expired token detected
  • Full cart amount recorded as bad debt with root cause "pre-auth expiration"
  • Payment feedback sent to Amazon
  • Outstanding balance tracked for future gate decisions
  • Alert generated for operations

9.12 Capture Failure After Successful Adjust

Test Case ID: IF-012 Objective: Verify recovery when capture fails after a successful adjustment

Test Flow:

  1. Adjust Charge → APPROVED
  2. Capture Charge → 500 error
  3. System retries capture with exponential backoff
  4. If all retries fail, alert generated and incident recorded

Expected Result: Retry logic handles transient failures; escalation on persistent failure

9.13 Refund After Successful Capture

Test Case ID: IF-013 Objective: Verify end-to-end refund flow

Test Flow:

  1. Complete full payment lifecycle (adjust → capture)
  2. Shopper requests refund
  3. Retailer calls Refund API with reason code
  4. Verify reconciliationId returned
  5. Verify refund reflected in payment processor

Expected Result: Refund processed; reconciliationId matches

9.14 Concurrent Payment Operations — Race Condition

Test Case ID: IF-014 Objective: Verify system handles concurrent operations on the same shopping trip

Test Steps:

  1. Send adjust and cancel simultaneously for the same shoppingTripId
  2. Verify only one operation succeeds
  3. Verify no inconsistent state

Expected Result: No race condition; system reaches consistent terminal state

9.15 Cascading Failure Recovery

Test Case ID: IF-015 Objective: Verify recovery from cascading failures across the adjust → capture pipeline

Test Steps:

  1. Simulate adjust service returning 503
  2. Verify circuit breaker prevents overloading
  3. Restore service
  4. Verify pending operations resume

Expected Result: Circuit breaker activates; operations resume after recovery

9.16 Unrecognized SKU — Bad Cart Through Payment

Test Case ID: IF-016 Objective: Verify end-to-end handling when cart contains an unrecognized SKU

Test Flow:

  1. Amazon sends cart with an unknown SKU via Create Purchases API
  2. Retailer accepts the cart (201) and routes item to bad cart process
  3. Verify bad cart is flagged for review
  4. Verify payment lifecycle proceeds for recognized items or is cancelled

Expected Result: Unrecognized SKU flagged; recognized items processed normally

9.17 Order Delegation Failure — Retry and Recovery

Test Case ID: IF-017 Objective: Verify recovery when Create Purchases API fails transiently

Test Flow:

  1. Amazon sends cart to Create Purchases API
  2. API returns 500 error
  3. Amazon retries with same idempotentShoppingTripId
  4. Retry succeeds with 201
  5. Retailer proceeds with adjust → capture

Expected Result: Retry succeeds; no duplicate purchase; payment lifecycle completes

9.18 Payment Failure Recovery — Alternative Payment

Test Case ID: IF-018 Objective: Handle payment failure with alternative payment method

Test Flow:

  1. Attempt charge adjustment (fails — DECLINED)
  2. Cancel original authorization
  3. Request new payment method from shopper
  4. Process alternative payment

Expected Result:

  • Graceful failure handling
  • No duplicate charges
  • Customer experience maintained

9.19 High-Risk Shopper Workflow

Test Case ID: IF-019 Objective: Handle high-risk shopper detection through full payment lifecycle

Test Flow:

  1. Shopper attempts entry
  2. Fraud system flags high risk
  3. Entry denied or conditional approval with reduced pre-auth
  4. If conditional, verify reduced pre-auth amount flows through adjust → capture

Expected Result:

  • Risk properly assessed
  • Conditional pre-auth amount respected in adjust
  • Security maintained

9.20 Refund and Reconciliation

Test Case ID: IF-020 Objective: Verify complete refund workflow with reconciliation

Test Flow:

  1. Complete full payment lifecycle (order delegation → adjust → capture)
  2. Customer requests refund
  3. Validate refund eligibility
  4. Process refund
  5. Retrieve transactional data
  6. Verify reconciliationId matches across refund response and transactional data
  7. Verify financial reconciliation is correct

Expected Result:

  • Accurate refund processing
  • Complete audit trail
  • reconciliationId consistent across all sources

9.21 Pre-Auth Expiration — Uncharged Cart Alert

Test Case ID: IF-021 Objective: Verify alert when cart is received but not charged before pre-auth expires

Test Flow:

  1. Shopper enters store, pre-auth placed
  2. Shopper exits, cart received
  3. Delay charge calculation/adjustment beyond pre-auth window
  4. Pre-auth expires

Expected Result:

  • System detects expired pre-auth
  • Alert generated for operations
  • Cart flagged for manual review
  • No silent revenue loss

10. Error Handling Test Cases

10.1 Network Timeout Handling

Test Case ID: EH-001 Objective: Handle API timeouts gracefully across all APIs

Expected Result:

  • Timeout detected
  • Retry mechanism triggered
  • No orphaned transactions

10.2 Invalid Payment Data

Test Case ID: EH-002 Objective: Handle malformed payment requests

Expected Result:

  • Validation errors caught before API call
  • Clear error messages
  • No system compromise

10.3 Per-API Retry Validation — Create Purchases

Test Case ID: EH-003 Objective: Verify Create Purchases API retry with idempotency

Expected Result:

  • Retried with exponential backoff
  • idempotentShoppingTripId prevents duplicates
  • Alert raised after max retries

10.4 Per-API Retry Validation — Adjust Charge

Test Case ID: EH-004 Objective: Verify Adjust Charge API retry

Expected Result: Retried with backoff; alert after max retries

10.5 Per-API Retry Validation — Cancel Charge

Test Case ID: EH-005 Objective: Verify Cancel Charge API retry

Expected Result: Retried with backoff; alert after max retries

10.6 Per-API Retry Validation — Capture Charge

Test Case ID: EH-006 Objective: Verify Capture Charge API retry with idempotency (no duplicate captures)

Expected Result: Retried with backoff; idempotency maintained; alert after max retries

10.7 Per-API Retry Validation — Refund

Test Case ID: EH-007 Objective: Verify Refund API retry with idempotency (no duplicate refunds)

Expected Result: Retried with backoff; refundRequestId prevents duplicates; alert after max retries

10.8 Per-API Retry Validation — Get Transactional Data

Test Case ID: EH-008 Objective: Verify Get Transactional Data API retry

Expected Result: Retried with backoff; alert after max retries

10.9 Per-API Retry Validation — Get Shopper Identity

Test Case ID: EH-009 Objective: Verify Get Shopper Identity API retry

Expected Result: Retried with backoff; alert after max retries

10.10 Retry Max Attempts Exceeded

Test Case ID: EH-010 Objective: Verify system stops retrying after maximum attempts and raises alert

Expected Result:

  • Retries stop after configured max
  • Alert raised for manual intervention
  • Incident recorded

10.11 Retry Backoff Strategy Validation

Test Case ID: EH-011 Objective: Verify retry intervals follow exponential backoff

Expected Result: Each retry interval increases exponentially; respects Retry-After headers

11. Performance Test Cases

11.1 Peak Load Testing

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

Test Parameters:

  • 500 concurrent operations (mixed Create Purchases, adjust, capture, cancel, refund)
  • Sustained load for 15 minutes

Expected Result:

  • All operations complete within SLA
  • No failed transactions due to load
  • System remains stable

11.2 Individual API Latency

Test Case ID: PF-002 Objective: Measure p99 response time for each API

Expected Result:

  • Create Purchases: < 2 seconds p99
  • Adjust Charge: < 2 seconds p99
  • Cancel Charge: < 2 seconds p99
  • Capture Charge: < 2 seconds p99
  • Refund: < 2 seconds p99
  • Get Transactional Data: < 1 second p99
  • Get Shopper Identity: < 1 second p99

11.3 Rate Limiting Validation

Test Case ID: PF-003 Objective: Verify rate limiting behavior across all APIs

Test Method: Exceed rate limits for each API

Expected Result:

  • 429 responses with Retry-After: 600
  • System respects backoff and recovers

11.4 Complex Calculation Performance

Test Case ID: PF-004 Objective: Test charge calculation performance with complex carts

Test Scenarios:

  • Cart with 50+ items and multiple promotions
  • Stacked promotions with different tax categories
  • Weight-based and unit-based items mixed

Expected Result:

  • Calculations complete within SLA (< 2 seconds)
  • No timeout errors
  • Accurate results maintained

12. Security Test Cases

12.1 Payment Data Protection

Test Case ID: SEC-001 Objective: Verify payment data is encrypted in transit

Test Steps:

  1. Capture network traffic during API calls
  2. Verify all communication uses TLS
  3. Verify no plaintext payment data in transit

Expected Result: All API calls encrypted; no plaintext exposure

12.2 PII Protection

Test Case ID: SEC-002 Objective: Verify shopper PII is not logged or exposed

Test Steps:

  1. Call Get Shopper Identity and Get Transactional Data
  2. Inspect application logs, error messages, and monitoring dashboards
  3. Verify shopperEmail, card last four digits, and expiration date are masked or absent

Expected Result: No PII in logs or error messages

12.3 Input Validation

Test Case ID: SEC-003 Objective: Verify all APIs reject malformed input

Test Data:

  • SQL injection in storeId (all APIs)
  • Oversized shoppingTripId (> 255 characters)
  • Invalid currency code
  • Negative amount
  • Malformed cartItems in Create Purchases (missing id, invalid type, oversized quantity.value)

Expected Result: All malformed inputs rejected with 400 error

12.4 Fraud Detection Accuracy

Test Case ID: SEC-004 Objective: Validate fraud detection effectiveness

Test Scenarios:

  • Known fraudulent patterns
  • Legitimate customer behavior
  • Edge case scenarios

Expected Result:

  • High fraud detection accuracy
  • Low false positive rate
  • Appropriate risk scoring

13. Store Reporting Test Cases

13.1 Payment Event Feed Validation

Test Case ID: RPT-001 Objective: Verify PAYMENT events are received via EventBridge for each lifecycle stage

Test Steps:

  1. Complete a full payment lifecycle (adjust → capture)
  2. Monitor EventBridge for PAYMENT events
  3. Verify events for AuthorizationApproved and CaptureApproved
  4. Validate event payload matches API responses

Expected Result: Events received for each stage with accurate data

13.2 Decline Event Alerting

Test Case ID: RPT-002 Objective: Verify decline events trigger alerts

Test Steps:

  1. Trigger a declined adjustment
  2. Verify AuthorizationDeclined event received via EventBridge
  3. Verify alert triggered

Expected Result: Decline event received; alert generated

13.3 Reconciliation Across Sources

Test Case ID: RPT-003 Objective: Verify payment data reconciles across API responses, Event feed, and Merchant Portal

Test Steps:

  1. Complete 10 shopping trips
  2. Collect data from Get Transactional Data API, Event feed, and Merchant Portal
  3. Compare reconciliationId, amounts, and statuses

Expected Result: All sources contain consistent data

14. Post-Purchase Test Cases

14.1 Receipt Generation from Transactional Data

Test Case ID: PP-001 Objective: Verify receipts are generated using Get Transactional Data and Get Shopper Identity responses

Test Steps:

  1. Complete a shopping trip and capture the charge
  2. Call Get Transactional Data → extract EMV fields, reconciliationId, card last four
  3. Call Get Shopper Identity → extract shopperEmail
  4. Generate receipt and deliver to shopper

Expected Result: Receipt contains accurate payment details and is delivered to correct email

14.2 Refund Flow — End to End

Test Case ID: PP-002 Objective: Verify complete refund flow from shopper request to confirmation

Test Steps:

  1. Shopper requests refund for a captured charge
  2. Validate eligibility (within 30 days, valid reason)
  3. Call Refund API
  4. Verify reconciliationId returned
  5. Verify refund appears in payment processor records
  6. Communicate refund status to shopper

Expected Result: Refund processed; shopper notified

14.3 Bad Debt — Declined Adjustment (Full Write-Off)

Test Case ID: PP-003 Objective: Verify bad debt recording when adjustment is fully declined and no amount is captured

Test Steps:

  1. Complete a shopping trip with cart total $25.99
  2. Call Adjust Charge → DECLINED, authorizedAmount: $0.00
  3. Record full amount as bad debt
  4. Call Report Payment Status with totalAmount: $25.99, settledAmount: $0.00
  5. Verify bad debt incident recorded with shoppingTripId, amount, and root cause

Expected Result:

  • Bad debt incident recorded: $25.99
  • Payment feedback sent to Amazon
  • Outstanding balance tracked against shopper's payment instrument

14.4 Bad Debt — Partial Capture (Partial Write-Off)

Test Case ID: PP-004 Objective: Verify bad debt recording when only a partial amount can be captured

Test Steps:

  1. Complete a shopping trip with cart total $50.00
  2. Call Adjust Charge → DECLINED, authorizedAmount: $30.00
  3. Capture $30.00 successfully
  4. Record $20.00 as bad debt
  5. Call Report Payment Status with totalAmount: $50.00, settledAmount: $30.00
  6. Verify bad debt incident recorded for the $20.00 shortfall

Expected Result:

  • $30.00 captured; $20.00 recorded as bad debt
  • Payment feedback reflects partial settlement
  • Outstanding balance of $20.00 tracked

14.5 Bad Debt — Failed Capture After All Retries

Test Case ID: PP-005 Objective: Verify bad debt recording when capture fails after all retries are exhausted

Test Steps:

  1. Adjust Charge → APPROVED
  2. Capture Charge fails with 500 error on all retry attempts
  3. Record full amount as bad debt
  4. Call Report Payment Status with settledAmount: $0.00

Expected Result:

  • Bad debt incident recorded with root cause "capture failure"
  • Escalation triggered
  • Payment feedback sent to Amazon

14.6 Bad Debt — Pre-Auth Token Expiration

Test Case ID: PP-006 Objective: Verify bad debt recording when the payment token expires before the cart is charged

Test Steps:

  1. Complete a shopping trip
  2. Delay processing beyond the token expiration window (~46 hours)
  3. Attempt Adjust Charge → ShoppingTripExpiredException
  4. Record full cart amount as bad debt
  5. Call Report Payment Status with settledAmount: $0.00

Expected Result:

  • Bad debt recorded with root cause "pre-auth expiration"
  • Payment feedback sent to Amazon
  • Outstanding balance tracked

14.7 Bad Debt — Entry Denial Due to Outstanding Balance

Test Case ID: PP-007 Objective: Verify shopper with outstanding balance is denied entry on subsequent visit

Test Steps:

  1. Confirm shopper has outstanding balance from PP-003 or PP-004
  2. Shopper returns and taps credit card at gate
  3. Shopper Authorization API returns shopperAuthorized: false with shopperRisks: ["BadDebt"]
  4. Verify gate remains closed

Expected Result:

  • Shopper denied entry
  • Denial reason: outstanding balance
  • Audit trail records the denial with shopper identity and outstanding amount

14.8 Bad Debt — Debt Resolution and Store Re-Entry

Test Case ID: PP-008 Objective: Verify shopper regains store access after resolving their outstanding balance

Test Steps:

  1. Shopper has $25.99 outstanding balance and was denied entry (PP-007)
  2. Shopper pays off the outstanding balance through the retailer's resolution process
  3. Retailer calls Report Payment Status for the original shoppingTripId with settledAmount matching totalAmount
  4. Amazon clears the outstanding balance
  5. Shopper returns and taps credit card at gate
  6. Shopper Authorization API returns shopperAuthorized: true with no risk flags
  7. Gate opens normally

Expected Result:

  • Outstanding balance cleared after full settlement reported
  • Shopper authorized on next visit
  • Gate opens
  • Complete audit trail: debt incurred → entry denied → debt resolved → entry authorized

14.9 Bad Debt — Partial Debt Payoff Still Blocked

Test Case ID: PP-009 Objective: Verify shopper with partially resolved outstanding balance is still denied or conditionally authorized

Test Steps:

  1. Shopper has $50.00 outstanding balance across multiple trips
  2. Shopper pays off $25.00
  3. Retailer reports partial settlement via Report Payment Status
  4. Shopper returns to store
  5. Shopper Authorization API returns shopperRisks: ["BadDebt"] or ["NonpaymentMediumRisk"]

Expected Result:

  • Remaining $25.00 outstanding balance still tracked
  • Shopper denied or conditionally authorized based on risk tolerance
  • Gate decision reflects remaining debt

14.10 Bad Debt — Repeat Offender Flagging

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

Test Steps:

  1. Simulate 3 bad debt incidents for the same shopper across separate shopping trips
  2. Report each via Report Payment Status with settledAmount < totalAmount
  3. Shopper attempts entry
  4. Shopper Authorization API returns shopperRisks: ["NonpaymentHighRisk", "BadDebt"]

Expected Result:

  • Repeat offender flagged with escalated risk level
  • Entry denied regardless of pre-auth amount
  • Shopper must resolve all outstanding balances before re-entry
  • Incident logged for fraud investigation

14.11 Bad Debt Metrics and Reporting

Test Case ID: PP-011 Objective: Verify bad debt reporting shows accurate metrics by root cause and resolution status

Test Steps:

  1. Generate bad debt incidents with different root causes (payment decline, partial capture, token expiration, capture failure)
  2. Resolve some incidents via Report Payment Status (full and partial payoffs)
  3. Run bad debt reports
  4. Verify reports show: total outstanding amount, frequency by root cause, recovery rate, resolved vs. unresolved breakdown

Expected Result:

  • Metrics are accurate and categorized by root cause
  • Recovery rate reflects resolved incidents
  • Reports support business monitoring and decision-making

15. Shopper Self-Service Portal Test Cases

15.1 Receipt Lookup — By Payment Card

Test Case ID: PTL-001 Objective: Verify shoppers can look up past shopping trips by payment card

Test Steps:

  1. Complete multiple shopping trips using the same payment card
  2. Authenticate to the portal using the payment card
  3. Verify all shopping trips are listed with correct dates and totals
  4. Verify cardStatementTransactionId is displayed to help match card statements

Expected Result: All trips retrievable; transaction details match API data

15.2 Receipt Lookup — By Email or Loyalty Account

Test Case ID: PTL-002 Objective: Verify shoppers can look up past shopping trips by email or loyalty account

Test Steps:

  1. Complete shopping trips as an app entry shopper with a known identity
  2. Authenticate to the portal using email or loyalty account
  3. Verify all shopping trips are listed

Expected Result: All trips retrievable for the authenticated shopper

15.3 Receipt Download — Itemized Receipt

Test Case ID: PTL-003 Objective: Verify shoppers can view and download an itemized receipt

Test Steps:

  1. Select a shopping trip from the receipt lookup results
  2. Verify receipt displays: items, quantities, prices, promotions, taxes, payment total
  3. Verify EMV data (card brand, last four digits) is displayed from Get Transactional Data API
  4. Download receipt as PDF or printable format

Expected Result: Itemized receipt is accurate and downloadable

15.4 Refund Request — Successful Submission

Test Case ID: PTL-004 Objective: Verify shoppers can submit a refund request through the portal

Test Steps:

  1. Select a shopping trip within the 30-day refund window
  2. Submit a refund request with a reason (DAMAGED_ITEM, EXPIRED_ITEM, UNWANTED_ITEM, OTHER)
  3. Portal calls Refund API with idempotent refundRequestId
  4. Verify refund confirmation displayed with reconciliationId
  5. Verify refund status is trackable in the portal

Expected Result: Refund processed; confirmation displayed; status trackable

15.5 Refund Request — Outside 30-Day Window

Test Case ID: PTL-005 Objective: Verify the portal prevents refund requests outside the 30-day window

Test Steps:

  1. Select a shopping trip older than 30 days
  2. Attempt to submit a refund request

Expected Result: Portal displays message that the refund window has expired; no API call made

15.6 Refund Request — Duplicate Prevention

Test Case ID: PTL-006 Objective: Verify the portal prevents duplicate refund submissions for the same trip

Test Steps:

  1. Submit a refund for a shopping trip
  2. Attempt to submit another refund for the same trip

Expected Result: Portal detects the existing refund and prevents duplicate submission

15.7 Outstanding Balance View

Test Case ID: PTL-007 Objective: Verify shoppers can view their current outstanding balance

Test Steps:

  1. Create a bad debt scenario (declined adjustment or partial capture)
  2. Authenticate to the portal
  3. Verify outstanding balance is displayed with breakdown by shopping trip (date, store, amount owed)

Expected Result: Outstanding balance displayed accurately with per-trip detail

15.8 Debt Payoff — Full Balance

Test Case ID: PTL-008 Objective: Verify shoppers can pay off their full outstanding balance through the portal

Test Steps:

  1. Shopper has $25.99 outstanding balance
  2. Shopper authenticates to the portal and navigates to outstanding balance
  3. Shopper submits payment for $25.99
  4. Portal processes payment through payment processor
  5. Portal calls Report Payment Status API with totalAmount: $25.99, settledAmount: $25.99
  6. Verify outstanding balance shows $0.00
  7. Verify confirmation message indicates store access is restored

Expected Result:

  • Payment processed
  • Report Payment Status sent to Amazon
  • Outstanding balance cleared
  • Shopper informed that store access is restored

15.9 Debt Payoff — Partial Balance

Test Case ID: PTL-009 Objective: Verify shoppers can make a partial payment toward their outstanding balance

Test Steps:

  1. Shopper has $50.00 outstanding balance across two trips
  2. Shopper pays off $25.00 (one trip)
  3. Portal calls Report Payment Status for the resolved trip
  4. Verify remaining balance of $25.00 is displayed
  5. Verify portal indicates store access may still be restricted

Expected Result: Partial payment applied; remaining balance displayed; access status updated

15.10 Debt Payoff — Re-Entry Verification

Test Case ID: PTL-010 Objective: Verify shopper can enter the store after paying off their full outstanding balance via the portal

Test Steps:

  1. Shopper pays off full outstanding balance through the portal (PTL-008)
  2. Shopper returns to store and taps credit card or scans QR code
  3. Shopper Authorization API returns shopperAuthorized: true with no risk flags
  4. Gate opens

Expected Result: Shopper re-authorized; gate opens; end-to-end debt resolution lifecycle confirmed

15.11 Portal Authentication — Invalid Credentials

Test Case ID: PTL-011 Objective: Verify the portal rejects invalid authentication attempts

Test Steps:

  1. Attempt to authenticate with an invalid payment card or email
  2. Verify access is denied with appropriate error message

Expected Result: Access denied; no shopper data exposed

15.12 Portal — PII Protection

Test Case ID: PTL-012 Objective: Verify shopper PII is protected in the portal

Test Steps:

  1. Authenticate and view receipts and outstanding balance
  2. Verify card numbers are masked (show last 4 only)
  3. Verify email is partially masked
  4. Inspect network traffic for PII leakage
  5. Verify session timeout after inactivity

Expected Result: PII masked in UI; no PII in network payloads; session expires after inactivity

15.13 Portal — Unavailability Handling

Test Case ID: PTL-013 Objective: Verify graceful handling when backend APIs are unavailable

Test Steps:

  1. Simulate Get Transactional Data API unavailability
  2. Attempt receipt lookup
  3. Simulate Report Payment Status API unavailability
  4. Attempt debt payoff

Expected Result: User-friendly error messages displayed; no data corruption; retry guidance provided

16. Compliance Test Cases

15.1 Tax Calculation Accuracy

Test Case ID: COMP-001 Objective: Verify tax calculations comply with tax authority requirements

Expected Result:

  • Tax amounts match jurisdiction rules
  • Tax-exempt items handled correctly
  • Audit trail for tax calculations

15.2 Pricing Compliance

Test Case ID: COMP-002 Objective: Verify pricing meets retail pricing laws

Expected Result:

  • Charged price matches displayed/catalog price
  • Promotion disclosure is transparent
  • Currency handling is correct

15.3 Receipt Accuracy

Test Case ID: COMP-003 Objective: Verify receipts meet compliance requirements

Expected Result:

  • Itemized receipt with correct prices, taxes, and totals
  • Required merchant information present
  • Transaction identifiers traceable

17. Monitoring and Observability Test Cases

17.1 Calculation Accuracy Metrics

Test Case ID: MON-001 Objective: Verify charge calculation accuracy is tracked

Expected Result: Metrics capture calculation accuracy rate, discrepancy count

17.2 Error Rate Metrics

Test Case ID: MON-002 Objective: Verify error rates are tracked per API

Expected Result: Dashboards show error rates for each of the 7 APIs

17.3 Business Metrics

Test Case ID: MON-003 Objective: Verify revenue, discount, and refund metrics are tracked

Expected Result: Business metrics (total revenue, total discounts, refund rate, bad debt rate) are accurate and reportable

17.4 Security Event Logging

Test Case ID: MON-004 Objective: Verify security events are logged for audit

Expected Result: All authentication failures, unauthorized access attempts, and PII access events are logged

18. Test Data Requirements

Payment Cards

  • Valid Visa test card (approved)
  • Valid Mastercard test card (approved)
  • Valid Amex test card (approved)
  • Declined test card (insufficient funds)
  • Expired test card
  • Invalid test card
  • Test card that triggers PENDING status
  • Test card for Amazon One biometric
  • Test card for mobile wallet

Shopping Trips

  • 10 pre-generated shoppingTripId UUIDs
  • 5 invalid shoppingTripId values for negative testing
  • 1 shopping trip older than 30 days (refund window testing)

Product Catalog

  • 20 test products with various prices
  • 5 promotional items (percentage, fixed, BOGO)
  • Items across different tax categories (taxable, tax-exempt)
  • Weight-based items
  • Items with multiple external identifiers

Store Configuration

  • Test store with all 9 APIs configured
  • Rate limiting enabled
  • Error handling and retry logic enabled
  • Event feed (EventBridge) configured for CART and PAYMENT events
  • Fraud and abuse detection configured
  • Shopper Authorization Connector (/v1/fraudandabuse/shopperauthorization) configured
  • Report Payment Status API (/v1/feedback/payment-status) configured
  • Test shoppers with known risk profiles (low risk, high risk, outstanding balance)
  • Test shopper with single outstanding balance (for entry denial testing)
  • Test shopper with multiple outstanding balances across separate trips (repeat offender testing)
  • Test shopper with resolved outstanding balance (for re-entry testing)
  • Test shopper with partially resolved outstanding balance (for conditional entry testing)
フォローする
amazon_developer_logo

© 2010-2026, Amazon.com, Inc. or its affiliates. All Rights Reserved. 無断複写·転載を禁じます。

利用規約

Amazon開発者ブログ

お問い合わせ