Stripe Terminal review: build and operate a custom in-person payment flow

Stripe Terminal should be evaluated as an in-person payment component inside software, not as a complete off-the-shelf POS. The buyer owns the surrounding checkout, order state, devices, integrations, support, and reconciliation. This review applies published criteria and does not claim an API or payment test.

Buyer scenario: the application owns checkout state

Imagine a vertical software company adding in-person payment to an existing order workflow. Product defines the customer experience, engineering creates payment requests and handles events, operations supports devices, and finance reconciles payments, refunds, disputes, and settlement.

Stripe Terminal fits this buyer only if custom checkout is strategic and the organization can operate it. A merchant wanting a ready-made catalog, register, staff, and reporting system should not mistake payment APIs for a finished POS. Draw every state from cart through final financial posting.

Decision criteria: assess the system the buyer must build

Evaluate supported devices and deployment, reader registration, locations, connection modes, payment lifecycle, stable identifiers, event ordering, retries, idempotency, refunds, receipts, offline or deferred behavior, monitoring, logs, support tools, access, sandbox differences, API changes, exports, and reconciliation.

Using a provider does not eliminate PCI DSS obligations automatically. PCI SSC guidance should frame merchant, application, device, network, provider, and validation responsibilities for the actual architecture. Tax determination, calculation, collection, filing, and reconciliation remain separate system and merchant decisions.

Reproducible evaluation plan

In approved test environments, create a synthetic order, initiate payment, produce a decline, complete another payment, deliver the event twice, make the application unavailable, issue a partial refund, and reconcile identifiers. Replace or disconnect a reader during the sequence.

Ask operations—not only engineering—to locate the transaction, explain application and payment states, recover a queued event, and support the device. Score duplicate prevention, diagnostics, state reconciliation, access, and runbook quality. This test was not executed here.

Require production-readiness artifacts: a payment state diagram, device inventory, credential register, webhook verification, retry and dead-letter process, correlation identifiers, monitoring alerts, customer-support decision tree, refund authority, final financial export, API change owner, and rollback plan. Have a developer who did not build the prototype deploy a harmless application change and reconcile an intentionally delayed event. Then ask finance to trace that payment without reading logs. The surrounding application is part of the POS architecture and must be reviewed as rigorously as the provider component.

Edge case: payment succeeds while the application fails

Suppose the customer payment completes but the application never closes the order, so staff attempt another charge. The design needs idempotency, a visible reconciliation queue, stable identifiers, and a safe customer-support response.

Also plan for provider, network, application, or reader outages separately. “Offline” should be defined from current documentation and tested against business risk; deferred acceptance can create payment and inventory exceptions.

Test software and device succession. Remove the original developer and device administrator, rotate credentials, replace a reader, and run the documented recovery in a sandbox. A custom checkout should survive staff turnover without unsafe emergency access.

Model reconciliation after a delayed refund and dispute as well as a normal payment. Finance should trace application order, provider payment, adjustment, payout entry, and accounting entry from stable identifiers. Engineering should not be required to interpret financial state manually.

Review data retention and observability separately: logs may aid diagnosis but should not become an uncontrolled store of payment or customer information.

Conclusion: choose a component only with production ownership

Stripe Terminal is the right choice for a software-led business that already runs on Stripe, has engineers who will own the in-person flow after launch, and wants checkout embedded in its own product. The failed-application case above is the test: if engineering, operations, finance, and support can each handle their part, building is justified.

A store owner who wants a register, catalog, staff permissions, and reports working next week should buy a finished POS instead. On the custom-integration path evaluated here, Stripe Terminal supplies payment acceptance and the rest is yours to build; Stripe's documentation also lists third-party POS integrations that use Terminal without code and no-code ready-made apps in preview, which a store owner can choose instead of building. Document PCI DSS responsibilities, tax boundaries, device lifecycle, monitoring, evidence, and exit before production.