Stripe integration: which signups become revenue

Every SaaS has the data that says which signups pay. It sits in Stripe, unjoined to anything that happened at the signup form. Connect it, and every payment, upgrade, churn, refund and dispute is tied back to the decision that let that customer in.

What you get from it

Conversion by segment. Paid rate by mailbox type, industry, company size, seniority, ICP fit, the decision and the rule that made it — with intervals, and with any segment too small to judge labelled as such instead of shown.
Experiments scored on money. “Did reviewing Gmail signups change paid conversion?” answered from Stripe’s own record of who paid.
A report card for your ICP rubric. If strong fit does not out-convert no_fit, the rubric is wrong, and the numbers say so.
Suggested rules, with evidence. A segment that clearly converts worse than your average comes with a proposed review rule and the numbers behind it. Never a deny; that is your decision.

What connecting takes

A restricted key with read-only access to Customers, Subscriptions, Invoices, Charges and Disputes, and write access to nothing. Secret keys are refused. The key is optional; it powers the backfill of your existing customers and the lookups that make the join work.
A webhook endpoint in Stripe pointing at the URL Sortance gives you, with its signing secret handed back to Sortance. Every delivery is signature-checked.
One line in your signup code: store the decision’s trace_id as metadata.sortance_trace_id on the Stripe customer. That is what makes the join exact.

Secrets are encrypted at rest, never shown again, and deleted when you disconnect. Sortance never writes to your Stripe account. The step-by-step, including the permission list and the events to subscribe, is in the Stripe reference.

The join, and its caveat

With metadata.sortance_trace_id on the customer, a payment is tied to its signup decision exactly. Without it, Sortance falls back to the customer’s email: hashed, and matched to your most recent decision for that hash in the 90 days before the payment.

The email fallback is approximate

Someone who signs up with one address and pays with another is missed, and Sortance cannot tell. So every event records how it was joined, and segment reports show exact, by-email and unmatched counts side by side. If the by-email share is large, set the metadata key and the caveat goes away.

What Sortance keeps from Stripe

Stripe objects are full of email addresses. Each one is hashed for the join and then dropped; it is never stored, logged or put on an event. What is kept is an allow-list of non-identifying fields: Stripe object ids, status, amounts, currency and reasons.

Not yet

Stripe Connect. One-click, revocable from the Stripe side, needs Stripe’s platform review. Today it is a restricted key and a webhook secret.
Automatic backfill of large accounts. Connecting backfills up to 500 existing Stripe objects at a time; continuing beyond that means connecting again, which resumes where it stopped.