All posts

May 10, 2026 · 4 min read

The Checklist Specific to Anything That Sells Physical Products Online

I wrote earlier this year about payment-specific checks: never trusting a price from the client, verifying webhook signatures, checking discount code abuse. A full online store selling physical products has a few additional, specific failure modes worth their own dedicated pass, beyond the general payment checklist.

Inventory race conditions

If your store tracks limited stock, check what happens when two people try to buy the last unit of something at nearly the same moment. A naive implementation, check the stock count, then separately decrease it, can let both purchases succeed even though only one item existed, because both checks happened before either decrease was applied. This isn't a security vulnerability in the traditional sense, but it's a real business logic bug that costs real money and creates real fulfillment problems, and it gets worse, not better, the more popular a limited item is.

Coupon and discount stacking

Beyond the basic "can the same code be used twice" check from the earlier payments post, verify whether multiple different discount codes can be combined in ways that weren't intended, whether a percentage-off code and a flat-amount code stack together to produce a price far below what either was meant to allow on its own.

Shipping address and order data separation

Check whether your order-lookup or order-tracking feature respects the same access boundaries as everything else. A tracking page that takes an order number and shows shipping status without verifying it belongs to the person asking is the same class of bug as everything else on this blog, applied to shipping addresses and order contents specifically.

Return and refund authorization

If customers can initiate a return or refund request themselves, confirm that action is scoped to their own orders specifically, checked the same way any other action should be: does this request belong to this user, not just is this user logged in.

Guest checkout data handling

Guest checkouts, where someone buys without creating a full account, still involve real personal and payment-adjacent data. Check that a guest order's data gets the same access-control treatment as a logged-in customer's, rather than assuming it's lower stakes because no account was technically created.

The condensed list

  • Test what happens when two people try to buy the last unit of a limited item at the same time.
  • Check whether discount codes can be combined in unintended ways.
  • Confirm order tracking and lookup features check ownership, not just that a valid order number was provided.
  • Confirm return and refund requests are scoped to the requesting customer's own orders.
  • Apply the same access-control standard to guest checkouts as to logged-in customer accounts.

None of this replaces the general payment and access-control checklist from earlier this year. It's what's specifically worth adding once real inventory, real shipping, and real physical goods are part of the picture, not just a payment flow in the abstract.

Related reading

Harbova is a security service for apps built with AI tools. Start with a free scan, and if it finds something serious, we can fix it and prove it is closed.