Security overview

Layout places real, paid restaurant orders on a person's behalf. Developers build it into their apps, and people reach it through assistants they connect, through Layout's own web and iPhone app, and by text. That is a system with somebody's money inside it, reached through software and models that a stranger can type into. This section is how it is held together, written for the people whose job is to check.

What the system does

A request for food arrives from an app, an assistant or a person. Layout works out which restaurant and which location, reads the menu, builds the order on the restaurant's own ordering site, and stops at a priced cart. The total is shown and confirmed. Only then does Layout complete the restaurant's checkout, paying with a card of its own rather than the person's.

No integration with the restaurant is needed, and the restaurant never receives the person's card.

The boundaries

There are three, and they are worth naming separately because they fail differently.

• The caller is untrusted input. A host model can be talked into anything by the person typing at it, or by text it read. So no model, ours or a host's, is load bearing for identity or for the limits on spend. Those are checked on our servers against a signed token and a stored record.
• The restaurant's website is untrusted content. We read it and act on it, so the money gate has to survive a site that lies about a price, and our own agent is stopped mechanically rather than asked politely to behave.
• Our own blindness is not the customer's problem. A check that cannot run has no opinion. It does not silently pass and it does not veto an order on the basis of something it could not read.

The rules the code is built to

• Nothing is spent without a confirm call against a total we calculated and showed. The server checks that call against the stored cart, the price, the daily limit and the per order ceiling. Above $50, on a risk step up, or for an app the person has not given standing consent, it also needs a code texted to the person. Under that floor, a confirm from a connected assistant is the person's authorization, and we say exactly what that does and does not prove in money controls.
• No order is claimed as placed without evidence, and no failure is claimed without evidence either. A confident false failure invites a duplicate order, so uncertainty is stated as uncertainty.
• Card numbers never reach a log, a model, a trace, or our database. A person's card lives in Stripe's vault. See card data.
• A user reads only their own rows. Isolation is enforced in the database itself rather than by every query remembering to filter.
• Observability never delays or alters an order. Telemetry is fire and forget.

Where to go next