Card terminals: the rules for pairing and revoking
· StorM · 1 min read · BYTHECLOUD ENT
The rules the shop engine follows when a card terminal is registered, paired and revoked, and for sales that were still waiting on a terminal when it was revoked.
Registering and pairing
The registry follows one order: registered, then paired, then revoked (a terminal that was never paired can be revoked too). An administrator registers a terminal. The registry answers once with a pairing code that is valid for a short time and keeps only a hash of it, so the code cannot be read back later. A terminal pairs with that code. Wrong codes are counted per device and lock the pairing after repeated failures, and a code that is used or expired is refused.
Revoking
Only an administrator can revoke a terminal, and a reason is required. Revoking the terminal the administrator is using, or the last active terminal of a store, asks for a confirmation first. Revoking also cancels any pairing code that was never used, and revoking a terminal that is already revoked succeeds again and says it was already revoked.
The question asked before a sale
The registry provides one question for the sale path to ask before a sale is written: is this terminal known, paired, part of this store, and the paired device? It answers from the terminal's record and nothing else, and a revoked terminal gets a refusal.
Sales that were already waiting
A terminal keeps selling when its connection drops, and those sales wait in a queue. For a revoked terminal, the registry's queue check returns review for a sale made at or before the revocation and a refusal for a later one.
Off until it is switched on
The registry is a switch that starts off. While it is off, registering, pairing and revoking are refused with a clear code, and a damaged settings value leaves it off instead of switching it on with defaults.