Stripe Terminal setup

Stripe Terminal is the integrated card provider in Bitta Retail POS: the register creates the charge, hands it to a registered Stripe reader, and books the captured payment automatically. This page covers provider selection, key management, readers, the simulated option for demos, the PCI posture, and how open transactions are recovered. The cashier-facing flow is on Card payments at the register.

Choosing a provider

The provider is selected once, in POS Setup under Payments:

Provider	Use
None (default)	No integrated payments. The register hides Pay card; cashiers use the plain "Card (external terminal)" tender instead.
Stripe	Live Stripe Terminal. Requires a stored secret key; configuration is fail-closed - a missing required setting stops the charge before any transaction is created.
Simulated	An in-process fake processor for demos, training, and QA. No keys, no hardware, never handles real money.

Bitta Retail POS never switches a live provider to Simulated automatically - you select Simulated explicitly, and it is safe to leave configured in a sandbox.

Each payment attempt permanently records which provider took it. A charge started under Stripe is always resolved, cancelled, and refunded through Stripe, even if an administrator changes the Setup provider mid-day.

Stripe configuration

1. In POS Setup, set EFT Provider to Stripe.
2. Run the Set Stripe Key action to store your Stripe secret key. The key is held in company-scoped Isolated Storage - never in a table field or on a page. The page only shows a read-only "Stripe API Key Set" flag confirming a key is stored for this company.
3. Set Stripe Currency Code to the charge currency. The sale currency must match the provider currency, or the charge is refused before anything is sent - amounts are converted to exact minor units per ISO currency rules, never assumed to be two-decimal cents.
4. Register your readers through the Stripe setup flow.

The setup wizard walks a new company through these steps in order.

Supported readers

Bitta Retail POS targets Stripe's smart readers - the Stripe Reader S700 family (S700/S710). These are server-driven devices: the register commands the reader over Stripe's API and polls it in the background, so no app is installed on the reader and the browser till never freezes while a customer pays. Use Chrome or Edge for the register browser.

Simulated readers for demos

Two layers of simulation are available:

• Simulated provider (POS Setup -> EFT Provider = Simulated): fully in-process, approves or declines on demand, exercises the complete dialog, capture, and reconcile flow. The best choice for sales demos and cashier training.
• Stripe simulated readers (Stripe test mode): with a test key and a simulated smart reader, the full server-driven flow runs against Stripe with zero hardware. While the card dialog is polling, present a test card via Stripe's test helper endpoint (test_helpers/terminal/readers/{reader}/present_payment_method) - creating the simulated reader alone does not present a card.

PCI posture

Card data never touches Business Central. The customer's card is read by the Stripe reader and processed entirely inside Stripe's certified environment; Bitta Retail POS stores only the processor's transaction reference. Practical consequences:

• No ISV payment certification is required for the app.
• The merchant qualifies for Stripe's pre-filled SAQ C self-assessment path.
• Provider secrets live in Isolated Storage, and audit surfaces show only a masked reference (last four characters) - never a raw processor id.

Crash recovery and open transactions

Every attempt is tracked in an EFT transaction ledger with a recovery state machine (Processing -> Captured / Failed / Cancelled / Refunded), and the transaction record is persisted before the reader is commanded. That ordering is what makes recovery safe:

• At register open, any payment left in flight by a crash or closed browser is reconciled with its own provider before the till opens: a charge the reader captured while the register was down is booked, an abandoned attempt is voided, and an unresolvable one is flagged for attention. The outcome appears as a non-blocking toast.
• If reconcile finds the sale already completed by another path, it voids the charge rather than double-charging.
• Manual review: open Tell Me and search "POS EFT Transactions" for the ledger of every attempt and its final state. Rows marked as needing attention are there for a supervisor to resolve.

Related pages

• Card payments at the register - the cashier flow, cancel/retry, and refunds.
• Tender screen and split payments - the tender method catalog, including the external terminal fallback.
• Payment acceptance labs - payment, refund, and recovery acceptance drills.
• Troubleshooting - reader offline and other common symptoms.