What both outside systems share
Part 3 of 3 · 1c. How the data travels: loyalty and telecom plan integrations
Back: Example 2Next: What you can use
- The till never calls the outside system. The chain's iVendNext calls your service; your service calls the outside system; the answer comes back the same way.
- Money enters the sale before payment, through the till's own pricing: a promotion (loyalty) or a price list your service keeps in step (telecom). Your answers carry messages and verdicts, never money.
- The outside account is the chain's, kept in the chain's own iVendNext and read with that chain's key at the moment of each call.
- After payment is the event feed's job. Your service pulls the sale, does the outside work once (an idempotency key it derives from the sale), and writes the result to the chain's own records. S52's key also names the retailer's site, because one telecom company serves many retailers; S22's names the ledger row only, because the loyalty system is the chain's own and hears from one chain. A loyalty service shared by several chains would need the site in its key too.
Next: What you can use, the developer's map of every endpoint, record type and screen.
Technical notes
- The doors: a remote till key (contract): no price is sent and no answer carries money; the check before payment (contract): the server prices the basket, the answer is stored against its fingerprint, the down answer applies when the service cannot be asked, offline included; the wallet door (contract); the event feed (contract); the price door only takes money off (contract); the capture and the partner page carry no money (capture, partner page).
- The settings route: a field limited to roles (
read_roles, chapter 7) would narrow it further; S22 and S52 give the whole settings record to the System Manager and the app's own role only, which the record's own permission rows do. - The bench run (the programme's test bench, POS app 2.1.0 at the till app's commit
60147699c, 2026-10-28, runpp-20261028T170105Z-24298): S52's manifest installed; the install made the app's own user,pp_tel@integration.invalid, holding only PP TEL Integration; that user read the telecom account and key whole from PP TEL Settings, and a cashier could not read the record; the service wrote the plans' prices (25.00, 35.00, 50.00) for account North; the Plans key, pressed through the till's own call and answered over HTTPS, listed S and M for the phone and not L; a sale of the phone and Plan S at 25.00 was confirmed at Pay, its card push passed and it booked (ACC-PSINV-2026-12468); the check refused a plan on a sale with only the walk-in customer, a price the telecom company had moved by 0.50 ("M 50 GB is now ZAR 35.50 …"), and a telecom company that was down, while Plans said it was not answering; after payment the service read the real event feed and wrote Activated,ACT-NORTH-00001, to the sale's PP TEL Activation row; every POS day opened was closed (0 open). The run's first try found that a till puts its walk-in customer on a sale that has none, which the walk-in customers setting now covers. The till's own screens (the plan sheet, the plan's line) were not photographed on this run. - S22's adapter has run on the laptop only (its tests and canaries, against the stand-in); S22's own bench proof (2026-10-09) predates it.
- The samples: S22 (its adapter:
service/outside.py,tests/test_adapter.py) · S52. The template's handshake: the app template.