Skip to content

Instantly share code, notes, and snippets.

@tranduongms1

tranduongms1/HGE-11862.md

Created September 9, 2026 02:26
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save tranduongms1/acbf8fe5189762fc20cb4cdd026e3e5a to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save tranduongms1/acbf8fe5189762fc20cb4cdd026e3e5a to your computer and use it in GitHub Desktop.
Download ZIP
HGE-11862
Raw
HGE-11862.md

HGE-11862 test cases

Due to structural errors and insufficient authentication in the dot-com payment system, there are numerous instances where orders can be processed without actual payment.

  • Source: HGE-11862
  • Type: Maintenance Request | Priority: P1 (Urgent) | Category: Security
  • Expectations are numbered to match Test Steps 1:1

Sources used

  • Ticket description and all comments (findings 1–6 + email timing)
  • Attached PDF (NASCA DRM; content aligned with the source-code analysis in comments)
  • Linked Confluence pages (pageId 651700427, 662406435, 672129003) returned No Permission
  • Related mentions: HGE-11850 (checkAuthAndCartAmount), INM-10736 (skipValidation)

QA stance from comments: the original “order fulfilled with no payment” claim is not end-to-end reproducible; capture is enforced by takePayment / takePartialPayment requiring an AUTHORIZATION entry with status ACCEPTED. These cases verify that defense, plus the remaining gaps (checksum, zero-total, skipValidation, confirmation timing, failed capture).

Preconditions

  • Run on the agreed test storefront (guest + registered).
  • Have a paid SKU, a valid test payment method, and (if the site supports it) COD.
  • Access My Orders, Backoffice order status, and the customer email/SMS inbox.
  • Record cluster flags: ENABLE_CART_TOTAL_VALIDATION, checkAuthAndCartAmount.
  • Do not change production payment-mode configuration.

Test cases

Test case ID Test Objective Test Steps Expectations
HGE-11862_01 Happy path: registered user with successful card payment is captured and can be fulfilled (Finding 1 defense line: takePayment/doCapture). 1. Log in as a registered user and add a paid in-stock product to cart.
2. Proceed to checkout, complete delivery, and pay with a valid test card so authorization is accepted.
3. Complete place-order and wait for the order process to run.
4. Open My Orders and Backoffice for the new order number.
5. Confirm fulfilment is allowed only after capture success.		 1. Cart total is greater than zero and checkout is available.
2. Payment authorization succeeds (ACCEPTED).
3. Order is created; process does not stop at payment error.
4. Order shows payment captured (e.g. PAYMENT_CAPTURED or equivalent site status), not unpaid.
5. Order can move toward fulfilment; goods are not treated as free/unpaid.
HGE-11862_02 Happy path: guest checkout with successful payment cannot skip payment. 1. As guest, add a paid product and go to checkout.
2. Enter guest details and complete a successful test payment.
3. Place the order and note the order number from OCP/email.
4. Check Backoffice payment and order status.		 1. Guest checkout loads with a non-zero total.
2. Authorization is ACCEPTED before the order is treated as paid.
3. Order confirmation is created for that guest order.
4. Payment transaction has a successful authorization and later capture; order is not fulfilled as unpaid.
HGE-11862_03 COD (if enabled): order can be placed without card authorization, but is not treated as already paid (Finding 1 — OrderCheck is not the payment gate). 1. Confirm COD is enabled for the test country/store.
2. Add a COD-eligible product and select Cash on Delivery.
3. Place the order without entering card details.
4. Check order status, payment mode, and that capture is not marked successful for a card.		 1. COD is offered only where configured.
2. Checkout allows COD without card authorization.
3. Order is placed as COD, not as a captured online payment.
4. Status reflects COD/pending collection, not PAYMENT_CAPTURED for an unpaid card flow.
HGE-11862_04 Rejected or failed authorization must not result in a fulfilled paid order (Finding 1, 2, 7B). 1. Add a paid product and go to payment.
2. Complete payment so the provider returns rejected/failed authorization (test decline card or test decline path).
3. Observe storefront result and whether an order number is shown as successful.
4. If any order record exists, check Backoffice status and stock.
5. Confirm the user cannot receive the product as a completed paid order.		 1. Checkout shows a payable amount greater than zero.
2. Authorization is not ACCEPTED.
3. Storefront does not present a successful paid order confirmation.
4. Order is not PAYMENT_CAPTURED; if created, it is failed/cancelled/not captured.
5. Order is not fulfilled; stock is not permanently reserved for a paid sale.
HGE-11862_05 Failed capture after a successful authorization must stop fulfilment and release virtual stock (Finding 1 — takePayment NOK → releaseVirtualStockWhenFailed). 1. Place an order with authorization ACCEPTED using a path where capture can fail in test (or use an existing test capture-fail scenario agreed with the team).
2. Wait for the order process to pass takePayment.
3. Check order status in Backoffice.
4. Check stock/reservation for the SKU.
5. Confirm the order does not proceed to ship as paid.		 1. Order exists with ACCEPTED authorization before capture.
2. Capture does not succeed (PAYMENT_NOT_CAPTURED or equivalent).
3. Order process takes the payment-failure path, not fulfilment.
4. Virtual/reserved stock is released.
5. Consignment/fulfilment does not complete as a paid shipment.
HGE-11862_06 Order confirmation email/SMS is sent only after payment authorization, not with zero payment attempt (New Finding — confirmation vs capture). 1. Place a successful authorized paid order (HGE-11862_01).
2. Check customer email and SMS immediately after place-order.
3. Check Backoffice: authorization vs capture timestamps vs notification time.
4. Confirm the message does not claim the order is fully paid/captured if capture has not run yet (if copy was updated).		 1. Authorization is ACCEPTED.
2. Confirmation email/SMS is received after authorization (current documented policy).
3. Notification is not sent when no authorization exists.
4. Wording matches the agreed policy (placed vs pending capture). If copy was not changed, record actual wording as a finding vs. the requested “pending payment confirmation” text.
HGE-11862_07 Capture-failure communication: customer is told the order is cancelled/not completed when capture fails (New Finding — sendCaptureFailedNotificationAction). 1. Reproduce a capture-failure order (HGE-11862_05).
2. Wait for capture-failed notification job/action.
3. Check email/SMS content.
4. Check My Orders / order tracking for the same order.		 1. Capture has failed and order is not fulfilled.
2. Capture-failed notification is triggered.
3. Message clearly states payment/capture failure and that the order will not be shipped as paid.
4. Customer-facing order state matches cancellation/payment failure, not “completed”.
HGE-11862_08 Cart checksum must reject a stale/changed cart (Finding 6 — validateCartChecksum; drift detection). 1. Add product A and proceed to checkout until place-order is ready.
2. In another tab/session for the same user, change the cart (qty, add/remove SKU, or change payment mode if possible) so server cart no longer matches the checkout snapshot.
3. Return to the original checkout and submit place-order without refreshing a new checksum.
4. Check whether the order is created and whether totals match the latest cart.		 1. Original checkout shows the first cart total and SKUs.
2. Server cart is different from the submitted checkout snapshot.
3. Place-order is rejected (checksum/cart validation error); no unpaid/mismatched order is created.
4. Any created order matches the server cart and still requires successful payment; a mismatched checksum must not place the order.
HGE-11862_09 Zero-total order for a normally paid SKU is blocked when cart-total validation is on; if the flag is off, capture must still fail or the order must not be fulfilled unpaid (Finding 6 — ENABLE_CART_TOTAL_VALIDATION). 1. Record whether ENABLE_CART_TOTAL_VALIDATION is true for the store.
2. Build a cart whose displayed total is 0 for a SKU that is not a free/zero-price eligible item (use only allowed test promotions/testdata provided by the team — do not invent a price exploit).
3. Attempt place-order and payment.
4. Check storefront error, order creation, and capture result.		 1. Flag value is documented in the test log.
2. If the product is not zero-eligible, a 0 total is not a valid payable cart.
3. With validation on, place-order is blocked. With validation off, place-order must still not fulfil without ACCEPTED capture; zero-amount capture must not ship a paid SKU for free.
4. Result is either blocked at submit or payment/capture fails; no fulfilled unpaid order.
HGE-11862_10 Storefront/client must not be able to skip stock, purchase-limit, or coupon validation via skipValidation (Finding 5). 1. Prepare a cart that should fail validation (e.g. over purchase limit, invalid/expired coupon, or OOS depending on what the site enforces).
2. Attempt place-order from the normal storefront (no internal/admin role).
3. If API testing is in scope, retry place-order as the same shopper with skipValidation=true only as a negative check that the flag is ignored or forbidden for that caller.
4. Confirm checksum and payment capture are still required.		 1. Cart is in a state that normal validation should reject.
2. Storefront place-order fails with the expected validation error; order is not placed.
3. Unauthorized skipValidation does not disable stock/limit/coupon checks; request is rejected or validations still run.
4. Checksum validation and payment capture are not skipped.
HGE-11862_11 An empty payment-transaction record must not be treated as paid or fulfilled (Finding 3). 1. Start checkout and place an order with a real payment method.
2. Immediately after submit, open Backoffice payment transactions for the order (before capture completes if possible).
3. Confirm transaction existence vs authorization/capture entries.
4. Wait until the process finishes and re-check status.		 1. Order is created in the normal submit flow.
2. A payment transaction row may exist before capture; this alone is not proof of payment.
3. Fulfilment does not start solely because a transaction record exists.
4. Final success requires ACCEPTED authorization and successful capture (or COD rules for COD).
HGE-11862_12 Split payment / partial capture: consignment still cannot ship without successful partial capture (Finding 1 — takePartialPayment). 1. Identify a store/product path that uses split or partial capture (if enabled on the test cluster).
2. Place an order that authorizes successfully.
3. Observe consignment/partial-capture step in Backoffice.
4. If partial capture fails, check that the consignment is not shipped as paid.		 1. Split/partial-capture path is actually used (or N/A if not configured — log and skip).
2. Authorization is ACCEPTED.
3. Capture (full or partial) is attempted before fulfilment of that consignment.
4. Failed partial capture blocks that consignment; order is not fulfilled unpaid.
HGE-11862_13 Authorized amount must match the order total when checkAuthAndCartAmount is enabled; mismatch must not fulfil (Finding 2; related HGE-11850). 1. Record whether checkAuthAndCartAmount is true on the test payment mode.
2. Place a normal order and confirm auth amount equals order total.
3. Using only the agreed test/mock payment result (not production request tampering), create or locate an order whose authorization amount does not equal order total.
4. Check whether the order is captured and fulfilled.		 1. Parameter value is logged per cluster/payment mode.
2. Happy path: auth amount equals order total; order can capture.
3. Mismatch case is visible in payment entries.
4. Order is not captured/fulfilled with a mismatched amount. If the flag is false, still confirm takePayment does not capture without ACCEPTED auth; log residual risk if amount is not compared.
HGE-11862_14 Payment in REVIEW must not be treated as ACCEPTED capture (Finding 2 — REVIEW vs ACCEPTED). 1. Place an order that enters payment REVIEW (e.g. 3DS/review test card, if available).
2. Check order process: checkTransactionReviewStatus / order not captured yet.
3. Do not complete the review; check fulfilment and notifications.
4. Complete review as ACCEPTED in a second run and confirm capture then proceeds.		 1. Payment entry status is REVIEW, not ACCEPTED.
2. Capture/fulfilment does not complete while REVIEW.
3. No PAYMENT_CAPTURED / shipped paid order in REVIEW.
4. After ACCEPTED, capture can succeed and the order can continue.
HGE-11862_15 Every live storefront payment method must actually require payment processing; none may place a paid-looking order without authorization (Finding 4 — forcedResponseCode must not silently skip submit in prod-like test). 1. List all payment methods shown on checkout for the test store.
2. For each method, complete a full place-order attempt with a successful test instrument (or COD where applicable).
3. For each successful order, check Backoffice for authorization/capture (or COD pending).
4. Confirm no method returns success and creates a shippable paid order with no payment record.		 1. All checkout methods are listed in the test log.
2. Each method either takes the user through real payment/COD or errors clearly.
3. Successful orders have the expected payment/COD records.
4. No method creates a fulfilled paid order with only a dummy success code and no authorization/capture/COD.
HGE-11862_16 Checksum is still enforced even if cart validation skip is requested (Finding 5 + 6). 1. Reach place-order with a valid cart and note the payable total.
2. Change the cart so the checksum should fail (HGE-11862_08), and also attempt the client skip-validation flag if API-in-scope.
3. Submit place-order.
4. Verify no order is placed on the stale checksum.		 1. Original total/SKU snapshot is known.
2. Cart and checksum no longer match.
3. Place-order fails checksum validation even if skip-validation is sent.
4. No order is created from the mismatched cart.
HGE-11862_17 Pre-order / delayed capture (if the site has pre-order): confirmation and capture timing follow the documented business rule (New Finding). 1. Confirm whether the test store has pre-order SKUs.
2. Place a pre-order with successful authorization.
3. Check confirmation email wording and when capture runs.
4. Fail capture (if a test path exists) and check customer messaging.		 1. Pre-order is available or case is N/A.
2. Authorization succeeds; order is created as pre-order.
3. Email matches the agreed copy (placed / pending payment confirmation vs captured).
4. Failed later capture does not fulfil; customer is notified of failure/cancellation.
HGE-11862_18 Regression: after any HMAC / ENABLE_CART_TOTAL_VALIDATION change, a normal paid order still succeeds and a zero-total paid SKU still cannot fulfil unpaid (Finding 6 P1). 1. Confirm with the team whether HMAC and/or default total validation were enabled on this build.
2. Repeat HGE-11862_01 (happy path).
3. Repeat HGE-11862_09 (zero-total paid SKU).
4. Repeat HGE-11862_08 (checksum mismatch).		 1. Build/config under test is recorded.
2. Happy path still places and captures.
3. Zero-total paid SKU cannot be fulfilled unpaid.
4. Checksum mismatch still rejects place-order.

Out of scope for external storefront QA

Track in comments/BO, not as UI exploits:

  • HMAC secret storage and partner source-code review
  • Removing orphaned CheckAuthorizeOrderPaymentAction
  • Renaming forcedResponseCode (code quality); only the customer-visible “every payment method really pays” check is above (HGE-11862_15)
  • Opening the DRM PDF or Confluence pages this account cannot read
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment