Server-to-server only. For vendors who collect scan payments through their own
payment gateway rather than Oyster's (collection_mode: vendor_gateway on
/scan-payments/entitlement).

This is the ONLY thing that settles such a payment, and it must be called from your
server. The API key it needs is a private credential — putting it in front-end code
exposes it to anyone who opens the page, and a leaked key can confirm scans against your
account for as long as it stays valid.

Your page MAY tell the widget it has collected, so the UI can move on promptly, but that
is a display hint and nothing more: the scan does not proceed until this server-side call
verifies it. Treat the browser as unable to settle anything, because it is. Call this
from the same server-side hook that observes your order reaching a paid state.

The flow:

1. The widget calls /scan-payments/initialize and receives provider: vendor_gateway
   plus a reference.
2. Your page collects payment however you like — an order, a checkout, a terminal.
3. Your server calls this endpoint with that reference.
4. The widget's open event stream sees the change and the scan proceeds.

Billing. A vendor on this mode is invoiced for every scan, including ones the
customer paid for — you are holding that money. Your Oyster scan markup does not apply
and nothing is accrued to you for these payments.

The amount is advisory. You charge whatever you charge; Oyster does not validate it
and it never replaces the quoted amount on the record. Send it only so a dispute can be
reconciled later.

Retries are safe. Confirming an already-settled payment returns replayed: true
with the existing status and changes nothing — one collection can never become two
billable scans. Treat replayed: true as success.

Requires the scans:collect scope on a vendor API token.