Customer profitability needs one durable identity chain: your internal account ID links to the Stripe customer, and the same account ID is attached to every server-side model call. Email is useful contact data, but it is not a stable accounting key.
Create one canonical account link
await telemetry.identifyAccount({
accountId: "account_123",
stripeCustomerId: "cus_123",
});Send this mapping from your authenticated backend after you have verified that the Stripe customer belongs to the current account. Never expose a Stripe secret key or a Grow or Die ingest key in browser code.
Record signed payment and refund facts
Use signed Stripe webhook events and the Stripe customer ID to retain charges, invoices, refunds, currency, and event time. Keep gross revenue, refunds, and known processor fees separate; do not turn a missing fee into zero.
Attach the same account to model calls
await telemetry.context({
accountId: "account_123",
feature: "research-agent",
promptVersion: "v5",
}, () => modelCall());The SDK observes provider usage on the server. Once payment and AI usage share the canonical account, Grow or Die can compute customer contribution profit for a compatible reporting window.
Fail closed on competing links
If two internal accounts claim the same Stripe customer, or a payment cannot be placed in the selected time window and currency, keep it unallocated. Do not choose the newest email or divide revenue by usage.
A refund belongs at its provider event time. Snapshot-only refund timing makes the window partial and blocks a confident profit result.
What this evidence can and cannot prove
A verified identity link supports observed customer revenue minus observed attributable AI cost for the same window and currency. It does not prove full accounting profit, allocate infrastructure cost, or resolve two accounts that claim the same provider customer. Conflicts remain unlinked until corrected.