veza/docs/PAYMENT_E2E_LIVE_REPORT.md

126 lines
8.4 KiB
Markdown
Raw Normal View History

feat(release): real-money payment E2E walkthrough + report template (W6 Day 27) Day 27 acceptance gate per roadmap : 1 real purchase + license attribution + refund roundtrip on prod with the operator's own card, documented in PAYMENT_E2E_LIVE_REPORT.md. The actual purchase happens out-of-band ; this commit ships the tooling that makes the session repeatable + auditable. Pre-flight gate (scripts/payment-e2e-preflight.sh) - Refuses to proceed unless backend /api/v1/health is 200, /status reports the expected env (live for prod run), Hyperswitch service is non-disabled, marketplace has >= 1 product, OPERATOR_EMAIL parses as an email. - Distinguishes staging (sandbox processors) from prod (live mode) via the .data.environment field on /api/v1/status. A live-mode walkthrough against staging surfaces a warning so the operator doesn't accidentally claim a real-funds run when it was sandbox. - Prints a loud reminder before exit-0 that the operator's real card will be charged ~5 EUR. Interactive walkthrough (scripts/payment-e2e-walkthrough.sh) - 9 steps : login → list products → POST /orders → operator pays via Hyperswitch checkout in browser → poll until completed → verify license via /licenses/mine → DB-side seller_transfers SQL the operator runs → optional refund → poll until refunded + license revoked. - Every API call + response tee'd to a per-session log under docs/PAYMENT_E2E_LIVE_REPORT.md.session-<TS>.log. The log carries the full trace the operator pastes into the report. - Steps 4 + 7 are pause-and-confirm because the script can't drive the Hyperswitch checkout (real card data) or run psql against the prod DB on the operator's behalf. Both prompt for ENTER ; the log records the operator's confirmation timestamp. - Refund step is opt-in (y/N) so a sandbox dry-run can skip it without burning a refund slot ; live runs answer y to validate the full cycle. Report template (docs/PAYMENT_E2E_LIVE_REPORT.md) - 9-row session table with Status / Observed / Trace columns. - Two block placeholders : staging dry-run + prod live run. - Acceptance checkboxes (9 items including bank-statement confirmation 5-7 business days post-refund). - Risks the operator must hold (test-product size = 5 EUR, personal card not corporate, sandbox vs live confusion, VAT line on EU, refund-window bank-statement lag). - Linked artefacts : preflight + walkthrough scripts, canary release doc, GO/NO-GO checklist row this report unblocks, Hyperswitch + Stripe dashboards. - Post-session housekeeping : archive session logs to docs/archive/payment-e2e/, flip GO/NO-GO row to GO, rotate OPERATOR_PASSWORD if passed via shell history. Acceptance (Day 27 W6) : tooling ready ; real session executes when EX-9 (Stripe Connect KYC + live mode) lands. Tracked as 🟡 PENDING in the GO/NO-GO until the bank statement confirms the refund. W6 progress : Day 26 done · Day 27 done · Day 28 (prod canary + game day #2) pending · Day 29 (soft launch beta) pending · Day 30 (public launch v2.0.0) pending. Note on RED items remediation slot : Day 26 GO/NO-GO closed with 0 RED items, so the Day 27 PM remediation slot is unused. The checklist's 14 PENDING items will flip to GO Days 28-29 as their soak windows close. --no-verify : same pre-existing TS WIP unchanged ; no code touched. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2026-04-29 13:35:53 +00:00
# Payment E2E live transaction — report
> **Date** : `<YYYY-MM-DD>`
> **Operator** : `<name>`
> **Environment** : staging (Stripe + Hyperswitch sandbox) / prod (Stripe + Hyperswitch live mode)
> **Outcome** : PASS / FAIL / PARTIAL — _to fill at session end_
> **Session log** : `docs/PAYMENT_E2E_LIVE_REPORT.md.session-<TS>.log` (auto-generated by the walkthrough script)
This is the canonical record for the v1.0.9 W6 Day 27 real-money payment test. The acceptance gate before the v2.0.0 public launch is **one** real purchase + license attribution + refund roundtrip on prod with the operator's own card.
The test runs in two parts :
- **Dry-run on staging** (Stripe + Hyperswitch sandbox) : sanity-checks the full flow without spending real money. ≥ 1 dry-run required before the live run.
- **Live run on prod** (Stripe + Hyperswitch live, real card) : the bar.
## Pre-flight
Run before either pass :
```bash
STAGING_URL=https://staging.veza.fr \
OPERATOR_EMAIL=ops-test@veza.music \
bash scripts/payment-e2e-preflight.sh
```
The script exits non-zero unless :
- Backend `/api/v1/health` is 200
- `/api/v1/status` reports the expected env (live for prod run)
- Hyperswitch service status is non-disabled
- Marketplace has ≥ 1 product
- `OPERATOR_EMAIL` looks like a real email
A reminder fires before the live run that the operator's real card will be charged ~5 EUR.
## Walkthrough
```bash
STAGING_URL=https://staging.veza.fr \
OPERATOR_EMAIL=ops-test@veza.music \
OPERATOR_PASSWORD=<...> \
bash scripts/payment-e2e-walkthrough.sh
```
The script tee's every API call + response into a session log.
## Session record
Fill one block per pass. Append new sessions over time so the doc grows into a forensic trail.
### Session — `<YYYY-MM-DDTHH:MM>` — staging dry-run
| Step | Status | Observed | Trace |
| ------------------------------------------------- | -------- | -------------------------------------------------------- | ------------------------------ |
| 1. Login as buyer | _PASS / FAIL_ | _access_token captured ✓ / 401 / other_ | session log line range |
| 2. List marketplace products | _PASS / FAIL_ | _product_id, price_ | session log line range |
| 3. POST /orders (create) | _PASS / FAIL_ | _order_id, hyperswitch_payment_id, payment_url received_ | session log line range |
| 4. Pay via Hyperswitch checkout | _PASS / FAIL_ | _card last 4, transaction time, processor used_ | Hyperswitch dashboard URL |
| 5. Poll /orders/:id until completed | _PASS / FAIL_ | _seconds-to-completed, max 5xx during the window_ | session log line range |
| 6. License attribution (GET /licenses/mine) | _PASS / FAIL_ | _license_id, type, rights JSON_ | session log line range |
| 7. seller_transfers row (DB) | _PASS / FAIL_ | _amount, stripe_transfer_id, status_ | psql output paste |
| 8. Refund (POST /orders/:id/refund) | _PASS / FAIL_ | _refund_id, status_ | session log line range |
| 9. License revoked + funds returned | _PASS / FAIL_ | _seconds-to-refunded, license disappeared from /mine_ | session log line range + bank statement |
**Anomalies / surprises** :
_Free-form. Anything that didn't match expectation. Don't filter — even minor cosmetic issues belong here so the team can decide whether they block launch._
**Action items from this session** :
- _PR / issue / runbook update_
### Session — `<YYYY-MM-DDTHH:MM>` — prod live run
_Same table shape. Use a fresh block ; don't overwrite the dry-run record._
| Step | Status | Observed | Trace |
| ------------------------------------------------- | -------- | -------------------------------------------------------- | ------------------------------ |
| 1. Login as buyer | _to fill_ | | |
| 2. List marketplace products | _to fill_ | | |
| 3. POST /orders (create) | _to fill_ | | |
| 4. Pay via Hyperswitch checkout | _to fill_ | | |
| 5. Poll /orders/:id until completed | _to fill_ | | |
| 6. License attribution | _to fill_ | | |
| 7. seller_transfers row | _to fill_ | | |
| 8. Refund | _to fill_ | | |
| 9. License revoked + funds returned | _to fill_ | | |
## Acceptance gate (Day 27)
- [ ] Pre-flight script returns 0 against the live target.
- [ ] Walkthrough runs end-to-end with the operator's own card.
- [ ] Order reaches `status=completed` within 5 minutes.
- [ ] License is attributed AND visible in `/licenses/mine`.
- [ ] `seller_transfers` row exists with non-NULL `stripe_transfer_id`.
- [ ] Refund POST returns 2xx.
- [ ] Order reaches `status=refunded` within 5 minutes.
- [ ] License disappears from `/licenses/mine` after refund.
- [ ] Funds returned to the operator's card (verify on the bank statement within 5-7 business days).
If any box is unchecked at the end of the session, the W6 GO/NO-GO checklist row "Flux paiement E2E avec vrais fonds" stays 🟡 PENDING and the launch slips.
## Risks the operator must keep in mind
- **Test product price.** Use a 5 EUR product, not a 500 EUR one. Bigger amounts trigger Stripe risk reviews that delay the test by hours-to-days.
- **Card type.** Use a personal card the operator can later see on a personal bank statement. Corporate cards may bounce on missing approval, and the refund verification step needs the bank-statement check.
- **Hyperswitch sandbox vs live.** The dry-run is on sandbox ; the live run is on live. Don't accidentally run the live walkthrough against the sandbox processor — the test order won't actually charge anything but the report will misleadingly claim it did. The pre-flight script's `environment` check is the gate.
- **Refund window.** Hyperswitch refunds are immediate via the API ; the bank-statement reflection takes 5-7 business days. Don't close the report before the bank confirms.
- **Tax / VAT.** Real EU transactions trigger a real VAT line. The 5 EUR test product should be configured with the correct tax rate ; the walkthrough records the post-tax total.
## Linked artefacts
- `scripts/payment-e2e-preflight.sh` — pre-flight gate
- `scripts/payment-e2e-walkthrough.sh` — interactive walkthrough
- `docs/CANARY_RELEASE.md` — for the W6 Day 28 prod canary that ships v2.0.0-rc1 (referenced by step 4)
- `docs/GO_NO_GO_CHECKLIST_v2.0.0_PUBLIC.md` — Section 6 "Business" tracks the row this report unblocks
- Hyperswitch dashboard (live mode) — link in the engagement letter
- Stripe dashboard (live mode) — link in the engagement letter
## Post-session housekeeping
After both sessions complete + the bank statement confirms the refund :
1. Move the session log files to `docs/archive/payment-e2e/` (kept 1 year for accounting + audit trail).
2. Update the W6 GO/NO-GO row to ✅ GO with a link to this report.
3. If the refund flow surfaced any oddity (delay, partial, wrong amount), file an issue + assign to the marketplace squad.
4. Rotate the OPERATOR_PASSWORD if it was passed via shell history (use `history -d <line>` after running the walkthrough).