Restaurant POS

Two refund paths existed in parallel: a direct per-item refund from the order card and kitchen screen, and the dispute resolution flow. The direct path moved money with no ticket behind it and no record of who authorised it or why.

The direct path has been closed. All refunds now go through a dispute, which means every refund has a reason, an owner, and an audit trail before the money moves. The refund control remains visible in the interface but disabled, with a tooltip directing staff to the dispute flow — this was deliberate: removing the button entirely would have left staff hunting for a feature they knew existed.

Two defects were found and fixed in the process.

The first affected Stripe refunds. The code set reverse_transfer whenever a tenant had a Connect account, but Stripe rejects that parameter on charges that were never routed through Connect — which describes every order placed before Connect was configured. Those refunds were failing outright. The code now inspects the actual charge and only reverses a transfer that exists.

The second affected delivery credentials. Secrets are masked as asterisks when sent to the browser, and the save path was meant to restore the real value when the mask came back. On a tenant's first save there was nothing to restore from, and the literal mask string was written to the database as the credential. The mask is now never persisted under any path.