What is refused, and technical notes

Back: Worked example Next: 9. The extension points, and how to ask for a new one

What is refused, and why

An app may do anything the retailer's administrator can do in Desk. The install refuses only what would:

book a wrong money, tax, stock or fiscal figure;
stop the till saving a sale, the day's close or a new customer at the counter;
send the retailer's data somewhere the consent does not show;
let someone act as someone else, code running in the retailer's saves or in a viewer's browser included.

Every refusal, with the reason for it, is on What an app may not do. Everything else iVendNext checks when the install saves it, in its own words.

When your service is down, and when the till is offline

A manifest runs no code, and the rules of this chapter keep it out of the till's own saves, so it cannot stop a sale. Its webhooks behave as every webhook does: three tries, then your reconciliation (the event feed recipe). A till key that reads your records works only online; the till dims it offline (per the till's own documentation; not run here).

Technical notes

Sources for the plain layer

Sandboxed modules: a manifest may carry a certified module (extension_modules); the retailer's administrator can still add one in Desk instead. The check before payment and pricing run a module; capture and the other extension points have no module leg (the Wasm kit).
Offline: a till key that reads your records is dimmed offline per the till's own documentation; not run here.

What the kit has proven

Install → export → uninstall → reinstall leaves the schema as found, for a manifest carrying every kind but the remote till key. Planted leaks (a report, a link, a workflow state) were each seen by the check.
The kinds were used, not just installed: the numbering rule numbered a claim, the workflow moved it through its states, the report listed the open claim and its totals row, the card summed, the chart grouped, the Connections link listed the claims.
A list mark and print format readers (2026-10-21, a sandbox site): a manifest's list mark reached the Desk page's data when on and left it when switched off; a manifest's print format on a price list printed all its prices and an item's photo through ivn_rows and ivn_value. Both uninstalled to nothing left.

What it has not

No kit sample has yet run these on a sandbox site: a report's table columns, a date reminder, a settings record, a multi-select field, a notification's own print, the readers for a viewer with fewer rights, a field only named roles read or change, a certified module in a package, a payer service, a Desk page out of the menu, a label's item and line placeholders, customer fields asked for at customer add. They are read from the product's pages and from its checker, which the kit copies. Register books are installed by sample S41.
A press from a physical till was not tried.
The markup check is a tripwire, not a guarantee (a print template's output is not escaped). The retailer's administrator decides, from a summary our installer writes, where a print format is listed as a template that runs on the server when printed, able to read, change and send the retailer's data.
A site does not check your company's word. The App library gives each registered company its own first word, one company per word, and publishes only that company's apps under it; a manifest installed by hand can use any prefix, and the site refuses only names already taken on it.
A site with developer mode off was not tried; the test site runs with it on.

The pictures

S2 (under the title): walked on our test bench, frame Desk, 1440 wide. The names are the sample's own placeholders, and its till key "Where is it?" is not shown.