Pre-event checklist
Before-you-charge-money checklist
Before you accept the first dollar from the first paying customer, eight things must be verifiable end-to-end. Each item is something that, if broken, becomes a refund trigger. Run this checklist on the same day you turn Stripe live mode on.
Run before: First real (live-mode) Stripe charge
When: On the day you switch Stripe from test mode to live mode — before the first real charge runs.
Verified · editorial policy
The 8-step checklist
Step 1
Test a $1 real charge end-to-end
Charge yourself $1 on a real card in live mode. Verify the charge appears in Stripe Dashboard, the receipt arrives, the access link works, and the refund completes cleanly.
Done when: A live $1 charge to a real card has been issued, received, refunded, and the refund email has arrived in the inbox.
Step 2
Verify the refund mechanism
Issue a refund from the Stripe Dashboard for the $1 charge above. Time how long it takes; document the steps so a future-you under stress can find them.
Done when: The refund completes, the refund email arrives, and the refund process is documented in a known location (Notion, README, etc.).
Step 3
Document the customer-facing refund policy
One page with the refund window, the trigger, the verifier, and the contact method. Linked from the checkout page and the footer.
Done when: The refund policy page is live, linked from the footer, and tells a customer exactly how to ask for a refund.
Step 4
Verify the customer-support email path
A real human-readable contact email. Not a no-reply address. Customers must be able to reach you with one email.
Done when: An external email sent to the support address reaches a human inbox within one hour during business hours.
Step 5
Set up Stripe receipt branding
Stripe Dashboard → Settings → Branding. Logo, color, and from-address on the receipt match the rest of the brand.
Done when: A receipt from the test charge shows the correct logo, color, and from-address.
Step 6
Verify the access-delivery path under failure
Simulate a failed webhook (kill the listener, then re-send). The customer must still receive access. Webhook idempotency is non-negotiable.
Done when: A failed-then-retried webhook results in the customer receiving access exactly once, not zero times or twice.
Step 7
Test the receipt-to-access flow on a fresh device
Open the receipt email on a phone you have not used for development. Click the access link. Verify it works without a cached session.
Done when: A fresh-device access click works first time without requiring login or copy-paste of an access code.
Step 8
Issue yourself a real refund and confirm
Run the refund flow on the test charge from step 1. Time it. The refund must complete in your own dashboard view as well as in Stripe.
Done when: The refund completes, the receipt is updated to refunded, and your own access shows revoked.
Related Brunson terms
If a step fails, diagnose the element
Frequently asked
- Do I need a written refund policy for $1 products?
- Yes. Stripe requires one, card networks require one, and the absence of one is a Brunson Hard-Rule violation. Even a one-paragraph refund policy linked from the checkout is enough.
- What if my refund volume turns out to be high?
- A 2-8% refund rate within the guarantee window is healthy. Above 8%, treat it as an offer-fit signal, not a refund-policy problem. The fix is the offer, not the policy.
More checklists
Run the diagnostic on your live page
The free 90-second Launch Diagnostic labels which Brunson failure mode your page hits — Wrong Person, Weak Offer, or Weak Belief — so you know which checklist to run first.