Stripe Terminal vs Square: custom checkout or ready-made stack?

Stripe Terminal and Square are not two versions of the same product. Stripe Terminal is positioned for software-led businesses that want developer-controlled in-person payments within a Stripe stack. Square is a complete small-merchant POS with payments, hardware, and business software, configured rather than built. Both are evaluated here against published criteria; no API or payment test was run.

A software company whose customers want to take cards in person

A vertical software company already runs its merchants' orders, customers, and inventory in its own application. Those merchants now ask to take cards at the counter. The company can either embed card readers in its product or tell merchants to run a finished POS alongside it.

Square does not replace the product; it sits next to it

Choosing Square does not mean the company swaps its application for Square. It means each merchant opens its own Square account and takes in-person payments there, while the company's product keeps the orders and customers. The cost is a seam: the sale lives in Square, the order lives in the company's product, and someone has to match them. Ask what Square can export or pass back, and how often, before promising merchants a combined view.

Choosing Stripe Terminal removes that seam, because the payment happens inside the company's own checkout. In exchange, the company takes on everything a finished POS would have handled: pairing and replacing readers, tracking payment state, retries, receipts, refunds, monitoring, and the support calls when a charge looks doubled.

The deciding condition: named owners for the custom surface

Write down, by name, who will own each of these jobs: reader rollout and replacement, application releases, payment exceptions, merchant onboarding, staff permissions in the merchant's checkout, customer support for disputed charges, reconciliation, security review, and incident communication. Give each person a backup.

If every line has a name and a backup, build on Stripe Terminal. Payments become part of the product, merchants get one system, and the company controls the experience.

If any line is blank, send merchants to Square for now. With a finished POS, readers, payments, and the register come from one company, so a missing owner means a gap the merchant can raise with Square rather than a production incident inside your product.

What going wrong looks like

• Stripe Terminal without owners: a reader drops offline on a Saturday, the order stays open after the payment succeeded, staff charge again, and the support queue has nobody who can tell application state from payment state.
• Square when owners exist and payments are core to the product: unless Square's current documentation shows each sale passing back to the matching order in your product, merchants live with two systems and manual matching indefinitely, and the company keeps paying in support time for a gap it had the people to close.

Card-security scope moves with the choice

Building in-person payments into your own application changes which parts of the card-handling environment you are responsible for. The PCI Security Standards Council notes that outsourcing payment processing does not automatically remove merchant responsibilities, so ask Stripe which PCI DSS tasks remain with the company and its merchants under the proposed integration. With Square, each merchant's own responsibilities still need confirming with its acquiring bank. Tax calculation and filing are separate from payment acceptance in both cases.

Rehearse the bad day before launch

In test mode, run a decline and a success, deliver the same completion event twice, take the application offline mid-payment, issue a partial refund, and swap a reader. For the Square path, run the same merchant day without custom code and try to match the export to orders in your product. Have a support agent resolve a duplicate-looking charge without engineering help. This exercise was not run for this page.