
Chapter 3
Complete one controlled purchase
controlled-purchase observation log is the practical output of this chapter. Complete it in one focused work session so you can decide the safest supported purchase method and the data you must capture during it, without rushing through the order and losing evidence needed to reproduce a failure.
What you’ll get
- A completed controlled-purchase observation log ready for the next chapter.
- A documented decision about the safest supported purchase method and the data you must capture during it.
- A pass or fail signal: one complete purchase produces a timestamped buyer record, payment result, confirmation, and expected next step.
- A first implementation move: Use a dedicated buyer email, record the start time, and move slowly enough to capture every state before and after payment.
Choose the safest supported method
Use a Tapmy or Stripe test workflow when the current account exposes one. If it does not, create a temporary low-priced private product, make one authorized purchase, and process it according to the current refund procedure. Do not invent test card numbers in a live checkout.
Observe rather than rush
During the purchase, record:
- Device, browser, and entry link
- Product and price shown
- Fields that caused confusion
- Time when payment was submitted
- Confirmation destination
- Reference or order identifier
Do not reload repeatedly after submitting payment. If the screen appears stuck, wait for the defined test window, then verify the order status seller-side before trying again; repeated submissions can create duplicate orders.
Apply this chapter to your store
Start with the live customer path, not a hypothetical version. Open the relevant content, profile, Tapmy page, email, or operational record and capture what a buyer sees now. Keep the scope to one campaign and one decision so the result can be measured.
Implementation move: Use a dedicated buyer email, record the start time, and move slowly enough to capture every state before and after payment.
Connect the decision to evidence: customer language, transition counts, questions, observed behavior, or a completed end-to-end test. If another person cannot understand why you chose the action, add the missing evidence rather than more strategy language.
Decision checkpoint
| Check | Pass condition | If it fails |
|---|---|---|
| Scope | One buyer, one campaign, and one next action are named | Narrow the work before creating more assets |
| Evidence | The current state is visible in a live route or record | Capture the source, destination, and decision point |
| Decision | the safest supported purchase method and the data you must capture during it is written clearly | Remove competing goals and choose one priority |
| Verification | one complete purchase produces a timestamped buyer record, payment result, confirmation, and expected next step | Rework the weakest boundary, then retest it |
Common failure mode
Running several purchases at once before one clean baseline exists. It creates activity without reliable learning. Use the chapter deliverable as a gate: the work is complete only when the decision is written, applied to the live path, and verified with the stated signal.
20-minute implementation sprint
- Open the live route or record and capture the starting state.
- Complete the smallest useful version of the controlled-purchase observation log.
- Apply the decision to one campaign or Tapmy path.
- Test the pass signal from the buyer’s point of view.
- Save the evidence and the next review date.







