# Card reader actions now check who is asking and which venue they belong to

This is an internal security fix. No screen, button, receipt or price changes,
and no card reader needs to be re-paired.

## What was wrong

Eleven server functions behind Stripe Terminal — connection tokens, registering
and removing readers, updating a reader's status, putting a basket on the reader
screen, starting and cancelling a payment on the reader — each took the venue id
as an argument and acted on it directly. They did not check that the caller was
signed in, that the caller was staff, that the caller held a point-of-sale
permission, or that the venue they named was their own venue.

Functions of this kind are reachable by a direct request, not only through the
screens that use them. So the venue id in the argument is something the caller
chooses, and it was being trusted.

## What changed

Every one of those eleven now, before it touches Stripe or the database:

1. requires a signed-in staff member of a venue;
2. requires the matching permission — **Access point of sale** to fetch a
   connection token or list readers, **Ring up sales** to charge, display a
   basket on, or cancel an action on a reader, and **Configure Stripe Terminal
   readers and POS hardware** to register, remove or change the status of a
   reader;
3. refuses outright when the venue in the argument is not the venue the signed-in
   staff member is working in;
4. applies the same venue-wide point-of-sale rule the card-reader charge route
   already applied.

Registering a reader, removing one and changing a reader's status now also write
an entry to the venue's audit log, naming the staff member and the reader. A
refused cross-venue attempt is recorded too.

Support access is unchanged: a platform operator still reaches a venue only
through an active, verified support session, and then only that venue.

## Who can be affected

Only a custom role built to ring up sales without the hardware permission. Such a
role can still take payments on a reader; it can no longer register, remove or
change the status of one. Owners, managers and the front desk are unaffected in
their normal work — owners and managers hold the hardware permission by default,
and the front desk keeps every register action it had.

## What did not change

The card reader flows themselves are byte-for-byte the same Stripe calls in the
same order: the same connection tokens, the same card-present payment intents on
the venue's own connected Stripe account, the same platform fee, the same
idempotency handling, the same reader display and cancellation behaviour. The
Business app's Tap-to-Pay route and the venue workspace's card-reader charge
route keep the gates they already had and call the same code as before.

## Compatibility

| Combination | Result |
|---|---|
| The release serving production today + this release | Safe. This release adds no database object and changes no table, so there is nothing for an older release to be incompatible with. |
| This release's code + the database as it is today | The intended state. There is no migration in this release. |
| Business app currently in the stores + this release | Unaffected. `/api/v1/admin/terminal/connection-token`, `/api/v1/admin/terminal/payment-intent` and `/api/v1/admin/terminal/capture` keep their request and response shapes, their bearer-token permission gates and their idempotency behaviour. |