Refund Policy — SpendSentry

SpendSentry — Refund Policy

Status: DRAFT — requires counsel review before publication. Owner: Founder Last updated: 2026-05-13

⚠️ This is not a substitute for legal advice. Counsel must confirm enforceability and App Store / state-law alignment before this is hosted at /legal/refund and before any paid spend runs.

Why this policy exists

Hard-paywall, no-trial. The user pays before they've seen the product fully. Some will regret it. A clean, generous refund window converts that regret into a refund (small revenue hit) instead of a chargeback (large hit: revenue + ad-account standing + Stripe risk score).

The 14-day no-questions-asked window is a deliberate trade per [unit-economics.md](../unit-economics.md). It's also the simplest CS posture — no triage, no judgment calls.

The policy (plain English summary — what users see)

You can request a refund within 14 days of your first purchase. No questions asked.

After 14 days, we review refund requests case-by-case but generally do not refund unless we caused the issue.

Refunds are processed through Stripe. You'll see the credit on the same card you paid with within 5–10 business days.

To request a refund:

From inside the app: Account → Subscription → Request refund.
By email: support@spendsentry.app (TBD — confirm address).

Cancelling your subscription is separate from a refund — see Terms of Service for the cancellation flow.

The policy (operational detail — what the team enforces)

Within 14 days of first purchase

Approve all requests.
Issue full refund.
Cancel the subscription so it doesn't rebill.
Revoke entitlement immediately on refund processing.
Log reason code if user provides one (free-text capture, not required).

After 14 days, before first rebill

Default: do not refund. Subscription continues until cancelled by user.
Exceptions: technical failure on our side, billing error, support couldn't resolve a documented problem with the service.
If approving: pro-rate by remaining term, or full refund if circumstances warrant.

After first rebill

Refunds only for billing errors, unauthorized charges, or service failures.
Cancellation alone does not trigger a refund — users get the service through end of paid term.
Pro-rated refunds: only if required by state law or if our cancellation flow had a defect.

Chargebacks

Always dispute chargebacks if we have evidence the user accessed the service.
A user who initiates a chargeback waives the no-questions-asked refund offer — but we still negotiate to convert to refund if possible (cheaper for us).
Repeat chargebackers are banned from re-subscribing.

Auto-renewal cancellation (separate from refunds)

Distinct concept, often confused. Cancellation stops future billing. Refund returns money already paid.

Cancellation is available at any time, inside the app, in one tap from Account → Subscription.
App Store guideline 3.1.2(a) and FTC ROSCA both require this. CA AB 390 and NY GBL §527-a require it specifically for California and New York residents.
After cancellation, the user retains entitlement until the end of the paid term — they don't lose access immediately.
No re-confirmation required, no "are you sure?" gate beyond one confirmation step. The "Click to Cancel" FTC rule (if in force in 2026) requires cancellation friction not exceed signup friction.

State-specific overlays

Counsel to confirm whether the following require explicit policy carve-outs:

California (AB 390). Easy online cancellation required. Refund language must be available to CA residents in a specific format.
New York (GBL §527-a). Similar to CA. Specific renewal-reminder requirements.
Other states with renewal laws as of 2026. Patchwork — counsel review.

Edge cases

User says they were charged without consent

Verify Stripe customer matches a Supabase account by email.
Verify a checkout.session.completed Stripe event exists.
If the user genuinely didn't authorize: refund, ban the email, investigate as potential fraud (someone else used their card).
If they did authorize but forgot: refund within 14-day window, otherwise apply standard policy.

User says the service didn't work

Try to fix it.
If we can't, refund regardless of window.
"Didn't work" = email scan failed to find their actual subscriptions, app crashed on launch, paywall billed wrong plan, etc.

User requests refund for the value tier they didn't take (the "I would have paid less")

Decline. The user chose the plan they chose. They had price visibility per [paywall-spec.md](../paywall-spec.md). Plan changes are a v2 feature; for v1, this is a hard no.

User asks to switch plans mid-term

V1: not supported. Tell them to cancel + re-subscribe at the new tier (which means waiting until current term ends, or accepting the loss of remaining term).
V2: plan changes via Stripe's subscription update API.

Internal policy: when to escalate

CS handles 14-day refunds automatically — no escalation needed.

Escalate to founder review:

Refund request over $200 (annual plan that's been used substantially).
Repeated refund requests from the same email.
Chargeback patterns from the same card BIN or geo.
User claims service did something the policy says it didn't (e.g. cancelled their subscription with a third-party provider without authorization).
Any threat of legal action.

Open questions for counsel

Whether the 14-day window can be presented as "satisfaction guarantee" without triggering specific state-law disclosure requirements.
Whether "no questions asked" creates any unintended contractual obligation.
Refund-rate ceiling before Stripe flags the merchant account (Stripe's published threshold is dispute-rate-based, but refund-rate-based monitoring exists informally).
Whether the refund flow must be available without account login (e.g. for users who deleted the app and don't remember their password).
How to handle refund requests from users in jurisdictions where the policy is more permissive than ours (e.g. EU 14-day cooling-off — but we may be U.S.-only at launch).

Pointers

[docs/legal/terms-of-service.md](terms-of-service.md)
[docs/legal/privacy-policy.md](privacy-policy.md)
[docs/paywall-spec.md](../paywall-spec.md) — refund link requirement.
[docs/unit-economics.md](../unit-economics.md) — refund-rate target and ceiling.
[docs/stripe-sync.md](../stripe-sync.md) — operational handling.
[docs/decisions/0002-hard-paywall-no-free-trial.md](../decisions/0002-hard-paywall-no-free-trial.md)