Check Stripe state
Check not only Checkout Session, but also Payment Intent. Sometimes the session is canceled and the user pays later.
- succeeded, failed, processing, canceled.
- duplicate payments by email and amount.
- receipt email status.
coins and webhook
Payment issue workflow
Workflow for duplicate charges, failed payments, processing payments, canceled checkout, and webhook delays.
Goal: do not run paid results without payment confirmation and do not leave a paying client without access.
what to ask first
Purchase email.
Approximate time and product.
Receipt screenshot is acceptable, but without full payment details.
Success/cancel page URL if client saved it.
Compare webhook
If Stripe succeeded but Supabase did not update, this is a webhook gap. Do not make the client pay again.
- Webhook endpoint correct.
- Webhook secret current.
- Paid status backfilled if safe.
Restore the path
After confirming payment, restore reading access, send email, and add an internal note.
- Access link sent.
- Client warned not to pay again.
- Incident logged if repeated.
reply templates
Payment processing
Stripe shows processing.
Checking payment status
Your payment currently appears as processing. Please do not pay again while we check status. If it confirms, we will restore scroll access; if not, we will suggest the next safe step.
Duplicate charge
There are two succeeded payments for one scenario.
Checking possible duplicate charge
I see there may have been a repeated payment attempt. We will check payments by your email and, if duplicate charge for the same scroll is confirmed, process the correction according to the Refund Policy.
red flags
- AI generated before payment succeeded.
- Webhook retries failing after deploy.
- Many payment issues after one code release.
closed when
- Payment state matched to reading state.
- Client told whether to retry, wait, or open restored access.
- Duplicate or webhook issue recorded.
related doors