fix: stop stranding Stripe customers on failed signups

[ndemianc]

The leak

User#create_stripe_customer hung off before_validation, on: :create, which fires even when the record is about to be rejected. So every failed signup called Stripe::Customer.create, kept the customer, and threw the user away — leaving a real, billable Stripe customer with no users row pointing at it.

#403 is the reason this surfaced. Until it shipped, the LevelCode Google flow called User.from_google without terms_accepted:, tripping validates :terms_accepted, acceptance: true, on: :create on every new Google signup — one orphaned Stripe customer per attempt, for the whole outage.

#403 fixed that one caller. This fixes the class: duplicate-email attempts and every other validation failure leak the same way, at a lower background rate, and still do in production today.

The fix

before_validation → before_create. That is the correct hook for an external side effect: it runs only once validation has passed, and still before the INSERT, so stripe_id is part of the initial row and create_default_subscription (before_commit) still sees it.

Checked before moving it — nothing validates stripe_id, the only validates on User is the terms acceptance, the column is nullable, and no callback between validation and insert reads it.

This narrows the window rather than closing it absolutely. The call sits inside the create transaction, so a Stripe success followed by a failed INSERT (a unique-email race) can still strand one. That is a far smaller target than every rejected signup, and creating the customer after commit instead would need a second write and leave stripe_id nil for the subscription callback. The trade-off is written down at the callback.

Cleanup for what is already stranded

Second commit adds stripe:orphans:report (read-only) and stripe:orphans:delete (gated). The report diffs Stripe against users.stripe_id and users.levelcode_stripe_id over a window and classifies:

Class	Meaning
ORPHAN_RETRY	a user exists with the same email and a different stripe_id — rejected, retried, got in. Safest to delete.
ORPHAN_DUPLICATE	several unreferenced customers share one email: a retry burst.
ORPHAN_UNMATCHED	no user, no activity. Probably an orphan — but this is also exactly what a legitimately deleted user looks like, so it is quarantined, not proposed.
REVIEW_ACTIVITY	has a subscription/invoice/charge/payment method. Never a signup that failed, so never deleted here.

delete refuses without CONFIRM=DELETE, takes only ORPHAN_RETRY by default, and re-checks the live database and Stripe activity per customer — someone rejected during the outage may since have signed up and been assigned that very customer, which would make the manifest stale. Both tasks refuse a live key outside production, since the report is a diff against this database's users table and a live key with a dev database would call every real customer an orphan.

Two limits, both printed in the report output:

• thin.ly and LevelCode share one Stripe account and Stripe::Customer.create(email:) writes no metadata, so nothing on a customer says which product made it. The time window is the only separator — thin.ly signups that failed validation in the same window land in the report too.
• The auth_events failure rows carry no email (the OAuth callback has no user by then), so they corroborate the orphan count and time span, not the identities.

Testing

Two examples pin the timing from both sides: a rejected create must not reach Stripe, an accepted one still must. They build User.new directly rather than using the factory, which no-ops create_stripe_customer and would have tested nothing.

Verified non-vacuous — with the callback put back on before_validation, the negative fails with exactly the orphan symptom:

expected: 0 times with any arguments
received: 1 time

1018 examples, 0 failures; rubocop clean. The rake task was exercised end to end against test-mode Stripe: 321 scanned, 305 unreferenced, all four classifications hit, and delete correctly refused without CONFIRM.

After merge

Deploy stops the ongoing leak. Then, to reconcile what is already there:

bundle exec rake stripe:orphans:report SINCE=2026-07-22

SINCE is an inference, not an observation — the LevelCode Google flow could not have completed before ecace42 (2026-07-22) because the authorize URL was built from an unset GOOGLE_OAUTH_ID. Check it against the observed first/last failure the report prints from auth_events, and sanity-check the failure count against the candidate count before deleting anything.

[Copilot]

Pull request overview

This PR prevents orphaned, billable Stripe customers from being created when user signups fail validation by moving User#create_stripe_customer from a validation callback to a create callback, and adds tooling to identify and (optionally) delete already-orphaned Stripe customers.

Changes:

• Move Stripe customer creation from before_validation to before_create to avoid side effects on rejected creates.
• Add model specs that assert Stripe is not called for invalid creates, and is called for valid creates (storing stripe_id).
• Add rake tasks to report and (gated) delete Stripe customers not referenced by users.stripe_id / users.levelcode_stripe_id.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
app/models/user.rb	Moves Stripe customer creation to before_create and documents the transactional trade-off.
spec/models/user_spec.rb	Adds regression specs to pin when the Stripe API call may occur during user creation.
lib/tasks/stripe_orphans.rake	Introduces reconciliation tasks to report/delete unreferenced Stripe customers within a time window.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.