Draft PR #234 contains the scoped consolidation, but required real proof is blocked: no approved non-production QPay boundary was available to exercise eager creation, cache-miss fallback, stored-invoice reuse, and cleanup without touching production or using a fake provider. The PR remains draft. Resume only when an approved disposable QPay environment plus local Payment/KV/database boundary is available.
Use one QPay create-and-store function#212
Parent
https://github.com/darjss/vit-store/issues/198
Accepted audit ID: S-03.
What to build
Centralize QPay invoice creation so eager checkout preparation and fallback use one Payment-owned persistence behavior.
Acceptance criteria
- Eager and fallback paths retain the existing response, Payment, and cache behavior.
- Eager failure remains non-fatal, is lifecycle-safe, and does not expose sensitive provider information.
- Applicable existing static/build checks pass, and no unrelated behavior changes.
First evidence check and STOP rule
Before editing, perform the plan’s bounded first evidence check: Confirm eager/fallback persistence ordering and the approved Worker-lifecycle boundary for non-fatal eager work. Stop and move this issue to ready-for-human if the required evidence or owner confirmation is unavailable or consequentially ambiguous.