Revenue attribution

Connect Stripe or Polar and your payments, refunds and fees flow into a Revenue tab, joined to the visits that produced them where a signal exists. You get two things: totals you can trust (net revenue with its parts shown) and, when you opt in, the journey behind each payment, which page, channel and campaign actually earned it. Each site connects its own account, from its Settings → Integrations screen, and the screen walks you through the provider you pick.

• Revenue is read pre-tax.Polar is the merchant of record: it collects tax and remits it, so an order's tax-inclusive total includes money you never receive. We record the post-discount, pre-tax figure, the same number Polar's own dashboard reports, so a comparison against a tax-inclusive total will read lower, correctly.
• There are no dispute events. Polar emits none as the merchant of record, so chargebacks stay empty for a Polar connection. That is the provider having nothing to report, not a gap in your data.
• Sandbox is a separate host.A sandbox token does not work against production and vice versa, so objects created in Polar's sandbox will not appear here.

Revenue totals need nothing from your visitors. Tying a payment back to the visit that produced it is different on both counts: you turn Attributed revenue on when connecting your provider, and the linking itself carries a consent obligation you meet as the controller of your site.

The switch decides whether the link happens at all, not just what the script sends. An order_id that reaches us while it is off, from a cached copy of the script or a request you wrote yourself, is dropped before the event is stored; and the matcher skips your site entirely, so a payment is not linked through your own payments integration either. Conversions are still counted and revenue totals are unaffected; what stops is the journey.

oa.consent("granted"); // or "denied", which stops collection entirely

There are two recipes. The first is exact and is what you should reach for; the second is the fallback for when your success page cannot know 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 success page has. The join is exact, and the transaction and its journey get confidence exact, the strongest the system issues.
• The fallback passes the same stable user reference to both sides. Both are hashed with the same site-scoped derivation and joined without either value ever being stored raw, yielding confidence linked: it identifies the person rather than the order. See identify for the rules.
• On Polar the same reference travels as customer.external_id, metadata.oa_external_id on the checkout, or the reference_id a Polar checkout link propagates, whichever is present, in that order. If you already set external ids for your own system, nothing more is needed.
• A conversion is a billable custom event, one unit; nothing about either recipe bills twice.

• 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.