veza/docs/PAYMENT_E2E_LIVE_REPORT.md
senke 2bf798af9c
Some checks failed
Veza deploy / Deploy via Ansible (push) Blocked by required conditions
Veza deploy / Resolve env + SHA (push) Successful in 14s
Veza deploy / Build backend (push) Failing after 7m25s
Veza deploy / Build web (push) Has been cancelled
Veza deploy / Build stream (push) Has been cancelled
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 15:35:53 +02:00

8.4 KiB

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 :

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

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).