Technical notes

Part 5 of 5 · 9. The extension points, and how to ask for a new one

Back: When your service is down, and when the till is offlineNext: 10. Integrations

What the kit has proven

• The manifest installs the declarations of the extension points. On the test site a manifest installed a Desk action, a Desk-action and a page subscription, two save rules, a fiscal reader, a check and a capture subscription, a scan source and field rules on a named till theme; each was used by the product, exported as the retailer left it, uninstalled to the schema as found and reinstalled (chapter 7).
• Two were walked on screen. The Desk action (S16) and the partner page (S17) were walked in a real browser on the test bench on 2026-10-07.
• The document check and the two newest save-rule kinds were used on a sandbox site (2026-10-21), through the API. A purchase order's submit with S34's service unreachable took the declared refuse, and its log row was written by the next scheduled job; a subscription naming a standard or a money field to fill was refused at its save; a second customer with one tax id in one customer group was refused; a Material Request of type Purchase was refused at submit for a user without the role and submitted by one with it. Not run there: Desk's question and approval dialogs, an import, and a service's own answers (proven on the laptop against the contract).
• A remote till key was pressed by a cashier on the till's own screen, the iVendNext POS app in a desktop browser on our test bench (S6's AI tip, 2026-10-07, frame /pos?frame=terminal, POS app at 8dc36aab8), answered over HTTPS with a certificate the bench's server trusted for the run. S1's Warranty key was pressed through the same endpoint from the bench's console as the cashier, not from a screen (2026-10-07).

What it has not

• The kit's contracts are a copy. The tables name each page; the pages and schemas are in contracts/, copied from the product at a pinned commit, and the product's own pages are the source.
• The check, the scan source, the capture and field rules were used through the till's own server calls (2026-10-08). S18's check was driven through the till's payment door on the test site: a refusal in the service's own words, with the card push refused before any money and no sale booked; a question refused until the cashier's Yes; a slow, down, invalid or malformed service under both declared down answers. S19's unit codes, S20's scan capture and customer code and S21's field rules ran too, and the money kit rings a sale through the check as a till does.
• Those four were not walked on a till screen, and were not run offline. Not run for S18: a check with ask as its down answer, excluded payment methods, a manager's approval, a return. Not run for S20: confirm and refuse on scan. A sale refused after a failed check but paid by card books and is flagged (read in the code, not run).
• The scoped event feed: the kit's client reads its door with POST (read on a test site on 2026-10-09). The client's crash-and-restart exit check ran against a stand-in for the door only.
• The wallet was walked on a sandbox till only with CitiXsys's own reference implementation (the wallet recipe says which steps); the kit's sample S22 has run only in its laptop tests.
• A press from a physical till device (a counter terminal or a phone, rather than the till app in a desktop browser) was not tried, and neither were the Desk screens for registering a till key.
• The payer, the register books, the check's four things and the lot fence are read from the product's pages and code and were walked by the product; no kit sample has run them on a sandbox site yet.
• The open check, the app's own user and the register's privacy are read from the product's pages and code. The product walked the open check: an outside app's user opened a tab by name and added to it, and was refused a move and a close in the right's words, through the API; tills opened, claimed, paid and gave back checks on phone, counter and tablet. No kit sample has run any of the three on a sandbox site yet.
• The station ticket, a check's fill and the open check's weighed lines are read from the product's pages and code. The product walked the station ticket: an integration user's server, signed in with its key on the site's socket, was told within 0.1 seconds of a till's send and of each move, read the board and moved a ticket through its steps, through the API. No kit sample has run any of them on a sandbox site yet.

Sources

• Not listed on purpose. Two engine-side items (narrowing the feed's grant, and default permissions on two record types) are product work on the underlying engine, not extension points a partner uses, so they have no row here.
• What the table does not mean. Being in the table does not mean every example in the kit has run against it; this chapter's other parts say which have.
• Request form. ../feedback/point_request.md, three questions and a tick box; the rest is asked in the issue.
• Names. The record the retailer's administrator fills in for most of these is a Retail Extension Subscription; its call log is the Retail Extension Log; a sandboxed module's record is a Retail Extension Module.

See also

3. The ladder and the four rules · Outside apps and the event feed · Till keys · 7. Manifests · Payments · 16. Possible, not possible, limits · Feedback

Back: When your service is down, and when the till is offlineNext: 10. Integrations

This page in the kit