#504 shipped order recovery for #501/#503. One finding from its review is knowingly unfixed, and the cheapest fix is to remove the feature that produces it rather than to extend it.
The open defect
An order the buyer cancelled ("Cancel this payment and start over") is kept rather than deleted, because cancelling refunds nothing server-side and a funded payment can still confirm. If it settles after the buyer has started a newer order, settleQuietly must not install its key over the newer purchase — so it shows a toast pointing at Settings → Subscription instead.
Settings has no way to reach that key. The delivered apiKey is dropped with the toast, nothing persists it, and the retained record holds only the order id. Every reopen repeats the toast until the record ages out at 24h, so a paid key is announced and then lost.
Reproduce: buy → cancel → buy again → let the first order confirm → reopen Subscription.
Why not just fix it
Storing or revealing that key needs a place to put it: a "recovered keys" surface in Settings where a key can be seen, copied and adopted deliberately. That is a new product surface, and it exists only to serve a corner of a feature that is itself the source of most of #504's review findings — abandon, background settlement, and superseded-order handling produced five P1s between them, each fix opening the next case.
Proposed cut
Remove the abandon machinery and let the gateway answer the question it was invented for:
- Drop
abandonedAt, settleQuietly, readSettlableOrders, the cancel/dismiss controls, and the superseded check (~250 lines of PlanScreen/pendingOrder, plus their tests).
- One order at a time: a stored order blocks a new checkout while it is inside Paymento's one-hour payment window.
- Past that window, resume it once in the foreground — where a UI exists to adopt or paste — and use
order-status.confirming to decide what happens next:
confirming: true → funded, keep waiting; never discard it,- pending and not confirming → it was never paid, drop it and let the buyer start over.
That replaces a model of the buyer's intent (did they mean to give up? is this order superseded?) with server truth, which is what the rest of the recovery path already relies on. It removes the trapped-buyer case that motivated the cancel control in the first place, so nothing regresses.
Not a regression either way
Before #504 the client kept no handle on an order at all, so every interrupted purchase lost its key. The defect above is narrower than what shipped as normal behaviour before it.
#504 shipped order recovery for #501/#503. One finding from its review is knowingly unfixed, and the cheapest fix is to remove the feature that produces it rather than to extend it.
The open defect
An order the buyer cancelled ("Cancel this payment and start over") is kept rather than deleted, because cancelling refunds nothing server-side and a funded payment can still confirm. If it settles after the buyer has started a newer order,
settleQuietlymust not install its key over the newer purchase — so it shows a toast pointing at Settings → Subscription instead.Settings has no way to reach that key. The delivered
apiKeyis dropped with the toast, nothing persists it, and the retained record holds only the order id. Every reopen repeats the toast until the record ages out at 24h, so a paid key is announced and then lost.Reproduce: buy → cancel → buy again → let the first order confirm → reopen Subscription.
Why not just fix it
Storing or revealing that key needs a place to put it: a "recovered keys" surface in Settings where a key can be seen, copied and adopted deliberately. That is a new product surface, and it exists only to serve a corner of a feature that is itself the source of most of #504's review findings — abandon, background settlement, and superseded-order handling produced five P1s between them, each fix opening the next case.
Proposed cut
Remove the abandon machinery and let the gateway answer the question it was invented for:
abandonedAt,settleQuietly,readSettlableOrders, the cancel/dismiss controls, and the superseded check (~250 lines ofPlanScreen/pendingOrder, plus their tests).order-status.confirmingto decide what happens next:confirming: true→ funded, keep waiting; never discard it,That replaces a model of the buyer's intent (did they mean to give up? is this order superseded?) with server truth, which is what the rest of the recovery path already relies on. It removes the trapped-buyer case that motivated the cancel control in the first place, so nothing regresses.
Not a regression either way
Before #504 the client kept no handle on an order at all, so every interrupted purchase lost its key. The defect above is narrower than what shipped as normal behaviour before it.