Case one: the smallest package
Imagine a buyer purchasing the basic option. Which files should be available, and which should not? The expected result must match the product page. An original entitlement matrix makes this explicit without requiring a paid order or pretending that a fictional buyer exists.
Case two: a returning buyer
Imagine the same customer returning after a corrected file is released. Which version should they find, what happens to their access limit and what notice is legitimately available? Keep the expected behaviour separate from what the provider actually documents or what you have observed.
Case three: the wrong format
Imagine a customer choosing an unsuitable variant. Write the information needed to distinguish misunderstanding from a wrong assignment and identify the authorised correction path. Do not assume that a refund, new charge or file transfer is always the right remedy.
Case four: a retired option
Imagine removing an option from new sales while retaining past-buyer access. Identify the underlying files and any continuing commitment before making changes. This case often exposes why a delete action needs more thought than a visibility change. Record unknown platform behaviour as a question, not a successful test.
An original working example
For each case, use three columns: expected behaviour, source or authorised observation, and unresolved question. A fictional basic option expected to deliver two files should not receive an observed-success label until an appropriate check actually establishes that result. Documentation may establish a capability without establishing your configuration. Keep that distinction visible in the sheet. Rehearsing cases locally can expose unclear promises before any merchant test is needed. If a real test is later justified, define its scope and side effects first, preserve the outcome and do not repeat uncertain submissions. The matrix is useful precisely because it permits unknowns rather than manufacturing a completed launch story.
Sources used for this page
These records support the facts and comparisons above. Merchant-controlled records are labelled so you can separate product claims from independent evidence.
- Adding a digital product — Merchant documentation · help.payhip.com · Merchant-controlled · checked 2026-09-27
- Digital product variants — Merchant documentation · help.payhip.com · Merchant-controlled · checked 2026-09-27
- Product protection — Merchant documentation · help.payhip.com · Merchant-controlled · checked 2026-09-27
- Email updates — Merchant documentation · help.payhip.com · Merchant-controlled · checked 2026-09-27