// Mini POS wiki
EFT Labs
Prove each payment-provider boundary separately: simulated logic, Stripe test smart reader, Stripe QR, physical Stripe acceptance, and Datacap certification readiness.
Purpose
Prove each payment-provider boundary separately: simulated logic, Stripe test smart reader, Stripe QR, physical Stripe acceptance, and Datacap certification readiness.
Role
Administrator owns credentials/configuration; cashier runs the sale; supervisor reconciles interrupted transactions.
Prerequisites
- Simulated: no account or hardware.
- Stripe test smart reader: Stripe test account/key, location, simulated smart reader, and explicit card-presentment helper access.
- Stripe QR: Stripe test mode, phone, and a valid HTTPS success URL.
- Physical Stripe: compatible reader and network only after simulation passes.
- Datacap: portal/certification account plus verified endpoint and device contract before hardware purchase.
Enable / Configure
EFT readiness comes from four independent controls: active tender assignment, provider configuration, device readiness, and the operator's permission. Create the EFT Tender Method, select its provider, assign it to the terminal, set credentials through the protected dialogs, verify location/terminal identifiers, connect the expected device, and grant only the required permission. Register Profiles do not contain an EFT enable switch. Never place secrets in evidence or screenshots.
Steps
- Simulated: run approve, decline, cancel, timeout, reconcile, and refund cases.
- Stripe test smart reader: create the payment, then issue the explicit test-helper card-presentment request for the simulated reader before polling to completion.
- Stripe QR: create the session, scan with a phone, complete in test mode, return through the HTTPS success URL, and reconcile.
- Physical Stripe: repeat approved/cancelled/interrupted/refund acceptance with the actual reader after test simulation is green.
- Datacap: execute only the portal-approved certification script against the verified endpoint/device contract.
Expected Result
A completed sale has one Payment Line with stamped method/provider facts and durable EFT Transaction history. Only masked safe references appear in UI/reports. Datacap is not production-ready while portal-verification placeholders remain.
When Disabled
The EFT method/control is absent or unavailable. A direct payment start rejects an inactive or unassigned tender, incomplete provider configuration, an unavailable device, or insufficient permission before money is completed.
Records / Accounting
Capture POS Sale, Payment Line, EFT Transaction, attention/reconciliation state, and Settlement Entry. Provider capture is not a G/L posting; EOD or individual posting creates the BC document and accounting entries.
Recovery
Do not charge again after an interruption. Open EFT Attention, poll/reconcile the durable transaction, then resume completion or refund according to its provider state.
Test IDs
EFT-SIM-001; EFT-STRIPE-READER-001; EFT-STRIPE-QR-001; EFT-STRIPE-PHY-001; EFT-DATACAP-CERT-001.
Screenshots
Task 9 captures provider evidence from one tagged package. Record provider mode, profile/Setup state, safe transaction ID/masked reference, POS document, tester/date, and Pass/Fail. Exclude keys, tokens, raw processor payloads, reader secrets, and customer secrets.