A pop-up shop QR payment link works for a small, stable assortment when each scan identifies the product, price and event context before the customer pays. One generic “pay here” code with a customer-entered amount creates avoidable disputes: staff may not know which variant left the table or whether the screenshot represents a confirmed transaction.
This workflow is for artists, makers and temporary retailers that do not need a full point-of-sale system. Its original asset is a scan-to-sale board joining every displayed QR code to SKU, confirmed payment and physical stock movement.
Decide When a QR Payment Page Is Enough
Use product-specific hosted pages when the stall has a short catalog, fixed prices and simple variants. Choose a proper POS when you need real-time multi-location inventory, weighted items, complex discounts, barcode scanning, staff permissions or integrated returns.
The QR code only opens a destination. It does not prove payment and it does not automatically decrement physical stock. Build those two checks into the counter workflow.
Build the Scan-to-Sale Board
| Display field | Payment field | Counter field |
|---|---|---|
| Event ID and date | Matching page or link ID | Opening stock |
| SKU and variant | Product name and fixed price | Unit handed over |
| Human-readable short URL | Seller identity and payment methods | Confirmed transaction reference |
| QR print version | Success/cancel state | Remaining stock and exception |
Give every code a printed product name and price so a swapped or damaged sign is visible. Use a separate code for materially different prices. If size or color is selected at the table, staff should mark the exact variant when handing it over.
Design the Counter Handoff
Place codes where customers can scan without covering another label. The mobile page should repeat the seller, product, amount and fulfillment expectation. After checkout, staff verify the paid state in the merchant view, say the product and variant aloud, hand it over and mark one unit sold.
Never accept a buyer's screenshot, email or browser success page as the only proof. Confirm the transaction in the payment system. The PCI Security Standards Council's small-merchant guidance recommends using secure payment solutions and providers; a hosted checkout keeps raw card entry out of a homemade form.
Reconcile Without Pretending It Is Live Inventory
At opening, count each sellable variant. During service, record confirmed QR sales, cash sales, reserved items, exchanges, damage and giveaways separately. At close, calculate:
`expected stock = opening stock − confirmed sales − other documented removals + documented returns`
Compare expected with the physical count and investigate differences while the event is fresh. The payment total alone cannot reveal which blue print or large T-shirt left the table.
Prepare for Weak Connectivity and Bad Codes
Test every printed code from an ordinary phone on mobile data. Keep the short URL readable, a charged staff device available and a documented fallback such as cash or a second secure checkout method. Do not collect card details in notes or messages when connectivity fails.
Run five rehearsal sales: two products at the same price, two variants of one product and one cancelled checkout. Confirm that staff do not hand over stock on the cancelled state and can reconcile every successful order.
Launch the Product-Specific Codes
Create product pages with PayRequest's QR payment-link workflow and use the broader payment-links feature when the same hosted checkout also needs to be shared by message or social profile.
Start with three products and one event ID. The setup is ready when a second staff member can scan, verify, hand over and reconcile all five rehearsal orders without asking which code or screenshot to trust.