See which traffic sources bring Stripe customers.

In cookie mode, read _tb_vid and _tb_sid on your server and put them on the Stripe Checkout Session. For a subscription, also put them on subscription_data.metadata. This excerpt assumes your existing Stripe client, validated price and redirect URLs.

// Add this to your existing server-side Stripe checkout.
// Keep your authentication, validated price and redirect URLs.
import { cookies } from "next/headers";

const jar = await cookies();
const visitor = jar.get("_tb_vid")?.value;
const session = jar.get("_tb_sid")?.value;
const ids = {
  ...(visitor && { twelvebit_visitor_id: visitor }),
  ...(session && { twelvebit_session_id: session }),
};

const checkout = await stripe.checkout.sessions.create({
  mode: "subscription",
  line_items: [{ price: validatedPriceId, quantity: 1 }],
  success_url: successUrl,
  cancel_url: cancelUrl,
  metadata: { ...ids, plan: "pro" },
  subscription_data: { metadata: { ...ids, plan: "pro" } },
});

For a one-time payment, use mode: payment and payment_intent_data.metadata instead of subscription_data. Receive payment revenue through the connected provider; do not send the same payment again through the payments API. The full Stripe guide explains the integration.

Illustrative example · USD · 1–30 October 2026 · last-touch attribution

Someone follows a newsletter link tagged utm_source=newsletter and utm_campaign=launch, starts checkout and pays $49 in the same visit. Stripe sends the payment with the twelvebit IDs. A $10 refund in the same reporting range subtracts from that visit, leaving $39 net revenue credited to the newsletter and launch campaign.

If the person returns through a different source before paying, last touch can credit that later visit. The Revenue page can switch to first touch to show the original visit. These are rules for assigning credit, not proof that a campaign caused a sale. See the attribution model.

Check the setup before relying on the numbers

1. Confirm that visits and the expected goals arrive from your production domain.
2. Inspect a checkout's metadata: the visitor and session IDs should be present when tracking is allowed.
3. Compare a received payment and refund with Stripe, using the same currency and date range. Open the credited visit to check its source.

Production connections require a live-mode Stripe restricted key by default; test keys need an explicitly enabled test setup. Use the troubleshooting guide if a visit, payment or refund is missing.

Does it work with Stripe Payment Links?

Yes. Payment Links cannot receive your server's checkout metadata, but Stripe can redirect to a page on your site with session_id={CHECKOUT_SESSION_ID}. The twelvebit script can link that session to the visit. The visitor must reach the return page, and automatic payment linking must be enabled. See payments from the success page.

What changes in cookieless mode?

There are no twelvebit cookies for the server excerpt to read. A cookieless visitor ID changes daily, so cross-day returning-visitor attribution is limited. Consent choices, blockers, another browser or another device can also prevent a match. Read the privacy and cookieless documentation before choosing a setup.

Is this multi-touch attribution?

No. Each payment is credited to one visit. Channel and campaign reports use last touch; the Revenue page also offers first touch. twelvebit does not divide a payment between several visits.

Can my agent read the reports?

Yes. Connect the analytics MCP server and ask which channels or landing pages brought Stripe customers, with a site and date range. Read-only access is the default; connecting MCP does not itself install tracking or connect Stripe.

Which plan includes Stripe revenue attribution?

Every paid plan includes revenue attribution, funnels, journeys and MCP. Starter starts at $9 a month for 10k events. Start with a 14-day trial, with no card. Compare plans and usage or twelvebit and DataFast before you choose.