POS trial checklist: test awkward sales before committing

Use a POS trial to run the awkward transactions your business encounters, then compare the receipt, payment and closing report. A feature tick on a sales page doesn't establish that it works on your chosen plan and hardware. Record each observed result and leave untested scenarios marked as untested.

Run this checklist on the systems in your shortlist. Ask for a supported demo or test mode first. If a feature requires a live merchant account, get a demonstration or written limitation instead of creating real customer charges for an experiment.

Build a small, recognisable test basket

Create fictional products with a size variant, a discount-eligible line and an excluded line. Write down the expected stock changes and amounts before running the test. Keep the same basket across vendors so you aren't comparing different tasks.

Scenario	Expected outcome	Evidence to keep
Two sizes of the same product	Correct variant sold and stock reduced	Item report and stock record
10% discount on a $50 eligible line	Line becomes $45; excluded item unchanged	Receipt and discount report
$120 sale, $40 cash and $80 card	One completed sale; two tender allocations	Receipt and payment-method report
Return one item from a mixed sale	Correct item, amount and stock decision	Original sale and linked refund
Interrupted payment response	Staff can identify the actual payment status	Vendor demonstration and written procedure
Daily close	Sales and tender reports use the same period	Exported reports and time settings

Fictional test scripts, not results of ASBG product testing. Add pass, fail or not-tested columns to your own copy.

Test the exact setup you'll pay for

Note the app version, subscription, hardware and location settings beside each result. For example, Square lists restrictions for split payments, including a connected-terminal configuration where a card split isn't supported. A demonstration on different hardware may not answer your question.

Ask the provider to demonstrate how staff return to an incomplete transaction and how they avoid a duplicate charge after a timeout. Use the split-tender guide to identify the records that should agree.

Follow the sale into the reports

After the checkout tests, find each fictional transaction in the sale history and payment-method totals. Inspect discounts, voids and refund references. If you need an accounting connection, ask which records it sends, when it sends them and how failed transfers are shown.

Square separates dashboard reports from those available in its POS app; some reports also depend on subscription. Check that the person doing your close has the necessary access. A report only the owner can view may leave the closing team stuck.

Give blockers more weight than a score

Don't average a missing essential workflow into a cheerful percentage. If split payments are common in your shop and the proposed setup can't process them, record a blocker. Then decide whether an affordable, tested alternative resolves it.

A workaround should name the extra steps and who performs them. Repeat the test after a configuration change. Keep unsupported or undemonstrated features out of the pass column even if support expects them to arrive soon.

Once a candidate passes, prepare the migration checklist and outage procedure. The POS comparison can help narrow a shortlist, while this trial determines whether it fits the way you trade.

Key takeaways

• Define the expected transaction before running a demo.
• Check receipts, stock and reports, not just the checkout screen.
• Resolve essential failures individually rather than hiding them in a total score.

Where to get help

• Square: split payment restrictions
• Square: reports and reporting periods