Mobile selling is a kit that travels: a phone or tablet, a reader, power, a connection, and the accounts behind them. The three candidates approach that kit from different directions, according to their published positioning. PayPal Zettle is pitched as a straightforward PayPal-connected in-person checkout for small and mobile sellers. Square is pitched as an integrated POS, payment, hardware, and business-software ecosystem. Helcim is pitched to US and Canadian merchants as payments plus a POS from one provider, where processing cost is the number to compare. The three are evaluated here against those published criteria, not in a field test.

Which mobile seller starts where

The occasional market seller already paid through PayPal: PayPal Zettle. A crafter, baker, or reseller who already invoices or takes online payments through PayPal and wants in-person sales to land in the same place. The appeal is a small kit connected to the PayPal account the seller already uses; confirm in writing how in-person sales appear there. What it costs: this guide's PayPal Zettle profile flags deep restaurant, warehouse, or multi-location controls as a poor fit, so a seller planning a second stall with its own stock, or a food truck that needs kitchen tickets, should not start here.

The mobile business with staff and a catalog: Square. A service business on house calls, a seller with two workers at different events, or a vendor whose catalog, customer list, and staff permissions matter as much as the payment itself. Square's breadth earns its place when the seller will actually use the adjacent business tools. What it costs: payments are sold with the software, and this guide found no Square documentation on running another processor through its app, so a seller who may want to change processors later should get that answer in writing first.

The high-volume seller watching processing cost: Helcim. A seller at large events or with steady card volume, where the processing line is the cost that matters, and who can live with a checkout scope sized to that. What it costs: the pick rests on a dated written proposal modeled on the seller's own card mix, not on a headline rate, and this guide's Helcim profile flags restaurant-specific front- and back-of-house needs as a poor fit.

The outdoor event that loses power and signal

Two workers, a crowded field, intermittent signal, one device going flat, a customer unsure whether the card went through, cash still moving, and a refund request after the team packs up. The owner is unreachable, and the backup must find the receipt and close the day.

The seller resolves this before the event, not during it, by reading each finalist's offline documentation for the exact app and reader and writing down the answers:

  • Which tenders still work without a connection, and which are blocked.
  • How long a stored payment can wait before it must upload, and what happens if it does not.
  • Whether a decline is reported only after reconnection, and who bears the loss.
  • Whether the payment stays linked to the sale or must be matched by hand.
  • Which devices and app versions the offline behavior applies to.

If a finalist's documentation does not answer those questions for the proposed kit, the seller should plan on cash only when signal drops, whatever the brand. The pick then follows the profile above; offline behavior is a gate each candidate must clear, not a tiebreaker. POS Platform Guide has not tested offline behavior for any of the three.

Pack, assemble, and recover

Before the first event, pack the kit, check charge, assemble from labels, and run a sale, a decline, cash, a corrected basket, and a partial refund in approved test modes. Hand the kit to the backup, drain one device, swap the reader, and have the backup retrieve a receipt and export the day. A bookkeeper should reconcile it without the owner's login. One owner's personal phone and password are not a continuity plan.

Card data and event sales tax

Taking cards on a phone does not make the seller PCI DSS compliant. PCI SSC merchant resources help identify the validation path with the acquiring bank for the actual reader, device, and app. Sales tax at an event location is a merchant and adviser decision; a stored rate does not prove the obligation.

When none of the three fits

Some festivals, stadiums, and markets require vendors to use the organizer's payment system, wristbands, or terminals. In that case the seller's own POS choice matters only for sales elsewhere, and the question becomes how to reconcile the organizer's payouts. A seller who needs warehouse-grade stock control across several vans, or a food truck that needs restaurant kitchen tools, should look at a specialized shortlist instead. Otherwise: PayPal income means PayPal Zettle, staff and catalog mean Square, and processing-cost-led volume means a written Helcim proposal.

If you take only a few card payments, you may not need a reader at all: see Tap to Pay on your phone compared.

Traceable evidence

Sources for this decision

5 sources
  1. vendorSquare official product siteSquare · checked Aug 5, 2026 · supports: Vendor-published product scope used to verify capabilities relevant to this buyer context: Small merchants evaluating an integrated POS, payment, hardware, and business-software ecosystem. It does not prove the guide's fit verdict, configured performance, current pricing or compliance.
    Open source ↗
  2. vendorPayPal Zettle official product sitePayPal Zettle · checked Aug 5, 2026 · supports: Vendor-published product scope used to verify capabilities relevant to this buyer context: Small and mobile sellers evaluating a straightforward PayPal-connected in-person checkout. It does not prove the guide's fit verdict, configured performance, current pricing or compliance.
    Open source ↗
  3. vendorHelcim official product siteHelcim · checked Aug 5, 2026 · supports: Vendor-published product scope used to verify capabilities relevant to this buyer context: US and Canadian merchants evaluating payments and POS economics together. It does not prove the guide's fit verdict, configured performance, current pricing or compliance.
    Open source ↗
  4. standardsPCI Data Security StandardPCI Security Standards Council · checked Aug 5, 2026 · supports: The published PCI Data Security Standard requirements for payment account data environments; it does not certify a merchant, processor, integration or POS product.
    Open source ↗
  5. standardsPCI SSC Merchant ResourcesPCI Security Standards Council · checked Aug 5, 2026 · supports: PCI SSC merchant guidance for identifying validation responsibilities and SAQ starting points; it does not determine the validation path without the merchant's acquiring bank and actual environment.
    Open source ↗