Payment acceptance labs

The payment acceptance labs are structured scenarios for proving your card-payment setup before go-live: first with the Simulated provider (no account, no hardware), then with Stripe Terminal in test mode, and finally with the physical reader. Run them in that order - each stage isolates a different failure surface.

Roles

The administrator owns credentials and configuration, a cashier runs the sales, and a supervisor reconciles any interrupted transactions.

Prerequisites

• Simulated provider: nothing - no account and no hardware.
• Stripe Terminal (test mode): a Stripe test account and key, a Stripe location, and a simulated smart reader created in test mode.
• Physical Stripe reader: a compatible reader (S700/S710) and network - only after the simulated stages pass.

Setup itself (keys, locations, readers, the setup wizard) is covered on Stripe Terminal setup; the cashier-facing flow is on Card payments at the register.

Configure

EFT readiness comes from four independent controls: an active tender assignment, provider configuration, device readiness, and the operator's permission. Before running the scenarios:

1. Create the card tender method and select its provider (Simulated or Stripe Terminal).
2. Assign the tender to the terminal you are testing.
3. Enter credentials through the protected setup dialogs and verify the location and terminal identifiers.
4. Connect (or create, for simulated) the expected reader.
5. Grant the operator only the required permission.

Acceptance scenarios

1. Simulated provider: run the full outcome matrix - approve, decline, cancel, timeout, reconcile after an interruption, and refund. This proves the tender flow, payment-line stamping, and recovery logic with zero external dependencies. The Demo walkthrough uses this provider.
2. Stripe Terminal, simulated smart reader: create the payment at the register, then drive the simulated reader's card presentment from Stripe test mode, and let the polling dialog run to completion. Repeat for an approved payment, a cancellation, and a refund back to the exact original tender.
3. Physical Stripe reader: repeat the approved, cancelled, interrupted, and refund cases with the actual reader on the store network - only after the simulated stages are green, so any new failure is isolated to hardware or network.

Suggested test ids for your evidence log: EFT-SIM-001, EFT-STRIPE-READER-001, EFT-STRIPE-PHY-001.

Expected results

A completed sale has exactly one payment line per tender with stamped method and provider facts, plus a durable EFT transaction history record. Only masked, safe references appear anywhere in the UI and reports - never raw processor identifiers.

When the tender is unavailable

If the card tender is absent or unavailable at the register, that is the readiness controls doing their job: a payment start is rejected when the tender is inactive or unassigned, the provider configuration is incomplete, the device is unavailable, or the operator lacks permission - always before any money is completed. The unintegrated "Card (external terminal)" tender remains the universal fallback while you finish setup.

Records and accounting

For each scenario, capture the POS sale, the payment line, the EFT transaction, any attention/reconciliation state, and the settlement entry. A provider capture is not a G/L posting: end-of-day or per-sale posting creates the Business Central document and accounting entries - see Per-tender settlement and Consolidated posting.

Recovery drill

For symptom-based help during the lab, see Troubleshooting. Card-payment lifecycle events also emit privacy-safe telemetry you can reference in evidence - see Telemetry and diagnostics.