Payment Flow QA

The route

5 steps to Done

1. 01

   Audit the money path

   Trace where amounts come from and who declares success.

   Preview prompt + verify gate ▾ Hide ▴

   Audit the payment implementation. Trace and report: where amounts/prices are defined (must be server-side - flag any client-sent amount that the server trusts); how checkout sessions are created; who declares success (must be server verification with the provider, never the redirect alone); where payment records live and their state model; how paid access is granted. Produce the money-path diagram in text and flag every trust violation.

   • ✓ Amount sources identified as server or client
   • ✓ The success authority is identified
   • ✓ All trust violations listed
2. 02

   Verify the success path

   Prove a test payment grants correctly - exactly once.

   Preview prompt + verify gate ▾ Hide ▴

   Test the success path in provider test mode: complete a purchase with the standard test card; verify the provider dashboard shows the payment; verify our payment record transitions to paid via server verification (not the redirect); verify the purchased value is granted (access/plan/credits) and visible in the UI; then refresh the success page repeatedly and re-visit the URL - the grant must not duplicate. Record each observation.

   • ✓ The provider shows the test payment
   • ✓ The record flipped to paid via verification
   • ✓ Repeated success-page visits do not re-grant
3. 03

   Verify decline and cancel paths

   Failed money moments must be honest and recoverable.

   Preview prompt + verify gate ▾ Hide ▴

   Test the failure paths: a declined test card (the UI must show an honest failure with retry - no success theater, and no partial grant); user cancels on the provider page (clean return, record marked canceled/pending appropriately, retry available); abandonment (close the tab mid-checkout - what state remains and is it recoverable?); verify no failure path leaves the database claiming paid. Record the state after each scenario.

   • ✓ Decline shows failure and grants nothing
   • ✓ Cancel returns cleanly with retry
   • ✓ No path leaves a false paid state
4. 04

   Attack the payment flow

   Try to cheat your own checkout before someone else does.

   Preview prompt + verify gate ▾ Hide ▴

   Attack-test the payment flow: attempt to modify the amount/product client-side (devtools request editing) - the server must price from its own catalog; attempt to call the grant/verification endpoint directly with fake or reused session ids - must reject; attempt to reach paid features as an unpaid user via direct URLs and API calls - must be blocked server-side; attempt double-submission of the same checkout - must not double-charge or double-record. Fix and re-attack every hole.

   • ✓ Amount tampering had no effect
   • ✓ Fake/reused sessions were rejected
   • ✓ Paid features blocked for unpaid users at the API level
5. 05

   Reconcile states end to end

   The final check: provider, database, and UI must tell one story.

   Preview prompt + verify gate ▾ Hide ▴

   Run the reconciliation pass: list every test payment made during QA and for each compare provider status, database record status, and what the UI shows the user - all three must agree; verify plan/entitlement displays match records; run one fresh end-to-end purchase as a final confirmation and document the full lifecycle with timestamps. Deliver the reconciliation table and any remaining known issues.

   • ✓ Every test payment reconciles across all three layers
   • ✓ Entitlement displays match records
   • ✓ The final purchase documented cleanly