Using a web-based POS with a mobile Terminal reader

Summary

Web-based POS systems can reuse ecommerce infrastructure for showroom-floor selling, but mobile readers such as the Stripe M2 and Tap to Pay cannot be accessed directly by a mobile browser. The proposed wrapper app avoids a complete native POS rebuild by embedding the site in a React Native WebView and connecting a mobile or Tap to Pay reader through the Stripe Terminal React Native SDK. A bridge message carries cart information, such as a cart ID and ready-to-pay status, to a ReaderManager that retrieves the amount and calls createPaymentIntent(), collectPaymentMethod(), and confirmPaymentIntent(). Payment results can return to the POS through a backend webhook and WebSocket or frontend polling, while security requires origin-checked messages, nonces, and server-side validation. The approach retains WebView performance, offline, native-access, debugging, and security limitations.

Context

Retailers want to reuse their ecommerce web stack for in-person selling rather than maintain separate web and native POS applications. Mobile readers such as the M2, WisePad 3, and Tap to Pay require mobile SDK integration because a mobile browser cannot communicate directly with the local reader.

Approach / What changed

A React Native wrapper loads the web-based POS in a WebView, receives cart state through window.ReactNativeWebView.postMessage, and passes that state to a ReaderManager using the Stripe Terminal React Native SDK. The ReaderManager discovers and connects to a reader, retrieves server-calculated cart details, creates and confirms a PaymentIntent, and supports payment-status notifications back to the POS through webhooks and WebSockets or polling.

Takeaways

• The wrapper architecture consists of an App component for shared state, a WebView for the POS, and a ReaderManager for reader discovery, connection, and payment processing.
• The payment flow uses a cart ID and ready_to_pay status, server-side amount calculation, PaymentIntent metadata, and the SDK methods createPaymentIntent(), collectPaymentMethod(), and confirmPaymentIntent().
• WebView introduces possible performance, offline, native-functionality, debugging, and security limitations; suggested mitigations include HTTPS, CSP, origin-checked and signed messages, one-time nonces, and server-side cart validation.

Related reading