fix(api): reuse or replace unpaid checkout by phone and cart#301

P1 security Reuse bypasses checkout ownership

When an unauthenticated caller submits another customer's phone number and matching cart, this branch updates the existing order and returns its payment number, after which the flow issues checkout credentials accepted by protected order and payment operations. This lets the caller overwrite delivery details and access the customer's checkout. How this was verified: The public request's phone and cart flow directly into the lookup and update without ownership verification, and the resulting guest claims or token authorize the selected payment.

Known tradeoff. Guest addOrder is already public and keyed by typed phone. Facebook iOS kills the session, so a session-phone gate recreates the production duplicate case. Phone + matching cart within 2h is the identity that survives webview death. Leaving this thread open for a human call if we want OTP before reuse instead.

Understood. Given that guest checkout is intentionally public and Facebook iOS can destroy the session, phone + matching cart within the 2-hour window is the practical identity available for deduplication. This still means someone who knows the phone and cart could overwrite checkout details, but that is an acknowledged product tradeoff rather than an implementation oversight. Leaving the thread open for a human decision on requiring OTP before reuse is reasonable.

P1 Reused checkout returns stale amount

When a product price changes before a matching checkout is retried, total is recomputed from current prices but this branch retains the original order total and payment amount. The addOrder response consequently reports a different amount from the persisted payment and subsequent getPaymentByNumber response.

Fixed: reuse returns the persisted payment amount (openPayment.amount), not the recomputed cart total.

P1 Claimed orders can be cancelled

If the customer claims the transfer after this transaction reads the payment as pending, the conditional payment update affects no row, but the independent order update still marks the created order as cancelled. The payment therefore remains customer_claimed_paid while its order is cancelled instead of remaining available for support review.

Fixed: cancel the Order only when the Payment pending → failed update returns a row, so a concurrent claim leaves the claimed Payment and its Order alone.

_{P1 Badge} Cancel payable checkouts older than the reuse window

The createdAt >= reuseAfter predicate excludes every unpaid checkout older than two hours from both the reuse and replacement paths. If a customer returns later and submits a new cart, the old Payment remains pending while this mutation creates another pending Payment, breaking the one-payable-checkout-per-phone invariant and leaving two payments the customer can act on. Use the time window only to decide whether a matching cart is a retry; an older payable Payment still needs to be found and retired before inserting its replacement.

Useful? React with 👍 / 👎.

Fixed: dropped the 2h window. Latest created unpaid checkout for the phone is always reused (same cart) or retired (different cart) before insert.

_{P1 Badge} Do not mutate claimed-paid orders during reuse

Because this public procedure treats customer_claimed_paid as reusable, a same-cart submission reaches this update and can replace the address and notes of an order whose bank transfer is already under review; the response subsequently issues a fresh checkout token and guest session. A caller only needs the phone number and matching product quantities to redirect the order before support confirms it, after which the existing confirmation flow promotes the same mutated order. Claimed payments should be returned without mutable updates and without granting new access absent authorization.

Useful? React with 👍 / 👎.

_{P1 Badge} Prevent retired payments from accepting QPay funds

When a customer submits a different cart after the old QR was created—or while its queued precreateQpayInvoice is still running—this marks the payment failed without invalidating the provider invoice. Both precreateQpayInvoice and payment.createQr reject only success, so the failed payment can still expose or create a payable QR, while confirmPaymentAndApplyStock transitions only pending/claimed payments; a successful charge therefore leaves the customer with a cancelled order and an unrecognized payment. The retirement path must cancel/invalidate the invoice and all invoice-creation paths must refuse failed payments.

Useful? React with 👍 / 👎.