Revenue attribution

Under your site's Settings, Integrations, connect Stripe with a restricted, read-only key: a couple of minutes, no code changes. From then on payments, refunds, disputes and fees flow into the Revenue tab, joined to the visits that produced them where a signal exists. Disconnecting stops the flow immediately.

Fire a conversion on your success page carrying the order:

oa.conversion("purchase", { order_id: "cs_live_a1B2c3" });

• order_id is the Stripe Checkout Session (cs_…), PaymentIntent (pi_…) or charge id (ch_…), whichever your page has.
• The join is exact: the transaction and its journey get confidence “exact”, the strongest the system issues.
• A conversion is a billable custom event, one unit; nothing about the recipe bills twice.

When your success page cannot know the order, pass the same stable user reference to both sides:

oa.identify("user_8f21c4");

stripe.checkout.sessions.create({
  client_reference_id: "user_8f21c4",
  // ...
});

Both sides are hashed with the same site-scoped derivation and joined without either value ever being stored raw. This yields confidence "linked": it identifies the person rather than the order, which is exactly what makes it the fallback. See identify for the rules.

• Net revenue with its parts printed: gross, refunds, disputes, fees. A flat month of quiet trading and a flat month of heavy refunds look different here, on purpose.
• Gross and net share one chart; the gap between the lines is the cost of doing business.
• Payments the join could not attribute still count in every total; they simply have no journey. There is no IP matching and no time-proximity guessing, by policy.
• Currencies that could not be converted are listed beside the totals rather than silently dropped.