How to Evaluate a POS Integration with WooCommerce

WooCommerce can be extended through many connection paths, so the phrase “works with” is not specific enough for a POS decision. WooCommerce documents three connection routes, checked on October 7, 2026: a Square extension, In-Person Payments with Stripe, and a PayPal POS for WooCommerce extension. Whether that last route connects a PayPal Zettle account is not established by the documentation, so the Zettle candidate stays unverified until PayPal confirms it in writing. The routes place the product master in different systems.

• Square: the WooCommerce Square extension keeps products and stock aligned between WooCommerce and a Square account, and in its sync settings the merchant chooses which platform is the source of truth for product data: WooCommerce pushing updates to Square, or Square pulling them into WooCommerce. It also acts as a payment gateway.
• PayPal Zettle: WooCommerce documents a PayPal POS for WooCommerce extension; its older logs still carry the zettle-pos-integration name and it relies on zettle.com services, but the page does not say outright that PayPal POS and PayPal Zettle are one product, so confirm with PayPal that it connects the Zettle account you are evaluating. In that extension, WooCommerce is the source of truth for products, prices, and SKUs, and stock syncs in both directions through webhooks.
• Stripe (WooCommerce In-Person Payments): WooCommerce's In-Person Payments with Stripe uses supported card readers or Tap to Pay through the Woo mobile app. The sale stays in WooCommerce, so there is no second catalog to sync; the counter runs in the Woo mobile app rather than in a separate POS product.

Evaluate the exact connector, hosting setup, store extensions, and support chain the merchant will actually use.

Buyer constraint: integration ownership is fragmented

Imagine an online store managed by an agency, a POS account managed by the owner, and a connector maintained by another company. A product update fails after an extension change. Without named ownership, each party can show its own system working while the merchant absorbs the mismatch.

The documented routes change who absorbs that failure. With Square, two catalogs must agree, so the merchant must decide which one wins. With PayPal POS for WooCommerce, WooCommerce wins by design, but stock updates depend on webhooks reaching a public site. With In-Person Payments with Stripe, there is no second catalog, but the counter depends on the Woo mobile app and its supported readers and countries.

Decision criteria for connector responsibility

Map products, variants, identifiers, prices, tax fields, stock, locations, customers, orders, payment references, fulfillment, cancellations, returns, and refunds. Record which direction each field moves, the triggering event, conflict rule, retry method, logging, version support, maintenance owner, and escalation sequence.

Require an exit path that can export source records without the connector. Integration behavior does not prove correct bookkeeping, inventory valuation, privacy practice, or sales-tax treatment; those remain merchant processes requiring appropriate review.

Reproducible mini-check after a connection break

Create fictional products with variants and separate stock. Sell one online and another in person, edit a product in the authorized source, cancel an order, issue a partial refund, and deliberately disable or misconfigure the connector before another change. For In-Person Payments with Stripe, which has no second catalog, interrupt the reader or mobile-app connection during a sale instead. Capture identifiers before attempting repair.

Restore the supported connection and verify ordering, duplicates, stock, refund linkage, and error closure. Repeat after a staging extension update if the maintenance model permits it. POS Platform Guide has not tested this proposed integration.

Exception and verdict: both systems accept edits

Suppose staff change the same product in WooCommerce and the POS while disconnected. This applies to the Square and PayPal POS routes; with In-Person Payments with Stripe there is only one product record. A safe design should apply an explicit authority or surface a conflict; last-write-wins behavior can erase a valid change without notice.

Choose Square when the shop needs a separate POS with its own catalog and accepts deciding which system leads the sync. Choose PayPal POS for WooCommerce when WooCommerce should remain the only product master and the site can reliably receive webhooks, and only after PayPal confirms in writing that the extension connects the Zettle account you are evaluating. Choose In-Person Payments with Stripe when the counter is occasional or small enough to run from the Woo mobile app. Keep that candidate only after its specific WooCommerce route passes the test and support ownership is contractual. Reject any chain where no party owns diagnosis from source event to destination record.