How to use this record. Complete it with a controlled test transaction or approved test procedure before a machine opens to customers. One successful sale does not prove every handoff or exception path is ready. Attach the actual records, name an owner for every mismatch, and retest after a material fix or configuration change.
What this worksheet is—and is not
This is an AgeVend buyer and operator worksheet for documenting a particular machine, location, product setup, and payment path. It is field-informed by two currently active production machines in one deployed operation. It is not multi-platform validation, a performance benchmark, legal advice, payment-provider rules, tax advice, or a substitute for a venue’s operating procedure.
Equipment, controller, payment, processor, network, tax, venue, product, and local-rule behavior can vary. Use the written requirements that govern the actual deployment. For age-restricted categories, confirm current product, licensing, placement, signage, privacy, tax, payment, and customer-access requirements with qualified advisers and the relevant authorities. Laws and program rules can change.
Identify the exact configuration
- Record machine ID, serial or controller identifier, physical location, venue contact, test date, local time zone, tester, and the deployed software or configuration version.
- Record the selected product, slot, published price, tax treatment, customer-flow configuration, payment path, network condition, and the intended customer-support method.
- Write down the expected result in each record before the test: customer screen, payment authorization, vend command, delivery outcome, inventory change, operator order, fault or alert, refund or reversal, and settlement entry.
- Use a safe, approved test procedure. Do not expose customer data, bypass configured controls, or create a live payment event without a documented recovery and reconciliation plan.
Test the handoffs, not just the happy path
1. Declined before a vend command
Confirm that a declined payment produces no delivery and that the customer message, kiosk state, operator record, and inventory all agree. The team should know whether a second attempt creates a distinct record and when support needs to intervene.
2. Approved and dispensed
Use a successful controlled transaction as the comparison baseline. Match the customer-facing completion, payment result, machine event, delivered product, slot count, order record, tax result, and later settlement record.
3. Approved but not dispensed
Define how the operator establishes whether delivery occurred, how the customer can get help, who can authorize a refund, which records must be preserved, and when the product count is corrected. Do not mark the incident resolved simply because one system says “approved.”
4. Timeout or unknown
Plan for an interrupted network, reader, or controller sequence that leaves the outcome unclear. Capture identifiers and timestamps from every available record, tell the customer what happens next, prevent blind duplicate handling, and give one person a review deadline.
5. Interrupted or duplicate customer attempt
Confirm what occurs if the customer taps again, leaves the screen, or starts a second selection. The kiosk should provide an understandable outcome, while the operator record must distinguish attempts without treating every partial action as a completed sale.
6. Refund, reversal, or customer recovery
Run the route’s approved recovery method and record who initiated it, the reason, the customer communication, and the expected payment-system result. A refund, reversal, credit, or support case can have different timing and evidence requirements.
7. End-of-day reconciliation
Compare physical stock, machine or controller state, operator orders, payment events, refunds, tax totals, and settlement. Leave discrepancies open until the route can explain both the customer outcome and the financial outcome.
Keep the records together
| Record | What to capture | Question before sign-off |
|---|---|---|
| Customer outcome | Screen state, receipt or support reference, and customer-facing message. | Could support explain the outcome without guessing? |
| Machine and delivery | Machine ID, selected slot, controller or fault event, and physical check where required. | Is there enough evidence to distinguish a missed vend from a completed delivery? |
| Payment and refund | Attempt identifier, authorization result, reversal or refund reference, and timing. | Does the customer outcome match the payment outcome? |
| Inventory and tax | Expected and actual stock change, product record, price, and tax treatment. | Can the route explain any count or tax difference? |
| Remote operations | Order, fault, support, and audit records with the assigned owner and deadline. | Can the next person find the incident and act safely? |
| Settlement | Processor or settlement report and the reconciliation decision. | Has the route resolved every customer and accounting impact? |
Do not launch through an unexplained mismatch
- Mark every state passed, failed, not applicable, or pending—not merely “tested.”
- For each failed or unknown state, assign an accountable operator, equipment, payment, or integration owner and an evidence-review deadline.
- Document the customer-recovery decision, any inventory adjustment, and the accounting or settlement follow-up required.
- Retest the successful path and the affected exception after a firmware, reader, network, catalog, payment, tax, or configuration change.
Use this alongside the full buyer diligence board.
The go-live test records a configured transaction path. The broader checklist covers the site, commercial scope, products, verification, payment underwriting, tax, inventory, support, and ongoing operator responsibilities.