Can Stripe Payment Links track affiliate referrals?
Short answer: Yes, Stripe Payment Links support a client_reference_id URL parameter that is included with the Checkout Session and surfaced in the checkout.session.completed webhook. You can use an opaque reference to connect a paid checkout to an existing affiliate attribution record. Stripe also supports UTM campaign parameters, but those are marketing tags, not a commission engine. Your application must validate attribution, verify the payment and apply program rules.
A reusable payment link can be shared in email, a landing page or a partner campaign. Because that URL may circulate outside the original channel, do not treat a copied link as proof of affiliate ownership. For broader platform selection, compare our Stripe affiliate software guide.
What client_reference_id actually does
Stripe's Payment Links URL parameter documentation states that client_reference_id can be an alphanumeric, hyphen or underscore string up to 200 characters. It is attached to the Checkout Session and sent with checkout.session.completed. Invalid values may be silently dropped. Do not put customer emails, API keys, passwords or personal secrets in this public URL parameter.
For affiliate tracking, generate an opaque, short-lived reference such as r_8F2K6M in your own backend. Map it to an approved affiliate, program, offer, landing page and expiry date. Store that mapping before redirecting the customer to the Stripe link. When Stripe later sends the Checkout Session, look up the opaque reference and validate its eligibility. An affiliate ID alone in the URL is easy to substitute and does not provide sufficient evidence.
Illustrative link and internal mapping
https://buy.stripe.com/EXAMPLE?client_reference_id=r_8F2K6M&utm_source=partner&utm_medium=affiliate
| Field | Example | Purpose |
|---|---|---|
| client_reference_id | r_8F2K6M | Opaque lookup key, not the payout instruction |
| affiliate_id (server) | aff_104 | Verified partner association |
| campaign_id (server) | launch_q4 | Eligible campaign and offer |
| expires_at (server) | Program-specific | Attribution window enforcement |
| checkout_session_id | cs_… | Reconciliation and duplicate prevention |
Use UTM tags for analytics, not payout decisions
Stripe supports utm_source, utm_medium, utm_campaign, utm_content and utm_term. Its documentation says these codes can be carried into a redirect URL when the Payment Link confirmation behavior is set to redirect. That helps campaign reporting, but a customer may never reach the redirect page or may edit the URL. A UTM string is therefore not a verified sale or a trustworthy affiliate identity.
Separate analytics dimensions from your commission ledger. You might report a campaign as utm_source=partner while only approving commission when the signed Stripe event matches a valid reference and an eligible payment. Avoid claiming UTM reporting alone proves affiliate conversion.
Build the webhook reconciliation flow
- Create and store an opaque attribution reference on your server after validating the incoming referral.
- Append that reference to a Payment Link using the supported
client_reference_idparameter. - Receive
checkout.session.completedat a secure HTTPS webhook endpoint and verify the Stripe signature. - Record the Checkout Session ID, customer, payment status, payment intent or subscription reference and source event ID.
- Resolve the internal referral record and check the attribution window, self-referral policy and eligible offer.
- Confirm successful collection using the appropriate payment or subscription event before creating a pending commission.
- Reconcile refunds, disputes and later invoices against the original paid transaction.
Stripe warns that some payment methods complete asynchronously. A completed Checkout Session is not universally equivalent to final funds collection for every payment method. Use the relevant delayed-payment events and payment state, and for recurring subscriptions inspect billing events such as invoice.paid. Read Stripe's webhook guidance for signature verification and delivery behavior.
Prevent double commissions
Stripe can retry webhooks. Store processed event IDs and enforce a unique commission business key such as (program_id, checkout_session_id, commission_type) for one-time purchases or (program_id, invoice_id, commission_type) for recurring invoices. The event ID alone does not replace business-level deduplication, because different event types can describe the same underlying purchase.
Process events asynchronously after durable receipt. If the reference is missing, invalid or expired, mark the transaction for review rather than assigning the sale to a guessed partner. If a customer has two tabs with different partner links, use the predeclared attribution rule, not whichever query parameter arrives last.
Example: a payment link reused by two affiliates
Affiliate A sends a campaign-specific landing page and the backend issues reference r_A1. Affiliate B sends the same Stripe Payment Link without a valid backend reference. A $120 purchase arrives with r_A1, a verified successful payment and an eligible program rule. At a 15% commission rate, the pending commission is $18 before any policy exclusions. The purchase without a valid reference should not automatically credit Affiliate B merely because its UTM tag says so.
If the $120 payment is refunded, the program may reverse the $18 under its published policy. This is a hypothetical calculation, not a statement about Stripe's default affiliate behavior. Stripe does not independently decide your commission rate or payout eligibility.
When Payment Links are the wrong architecture
For complex cart contents, dynamic commission rates, multi-seat SaaS subscriptions or partner-specific pricing, a server-created Checkout Session or a specialized affiliate platform may give you better control. If you need cross-device sign-in attribution, store the referral against a stable account identity before checkout. Never rely solely on browser storage surviving until payment.
Also plan for payment-link forwarding, link scraping, fake referrals, multiple payment attempts, coupon stacking and changes in customer email. For custom integrations, our affiliate tracking API guide covers additional reconciliation questions.
Implementation QA checklist
- Confirm the reference ID survives a valid Payment Link URL and appears in the Checkout Session webhook.
- Try an invalid reference and verify it is not silently awarded a commission.
- Test both immediate and delayed payment methods.
- Replay the same event and ensure no duplicate commission.
- Check UTM redirect behavior without treating the redirect as payment confirmation.
- Test a refunded payment, an expired attribution token and a forwarded link.
- Verify that no personal data or secrets appear in URL parameters or logs.
- Reconcile the final ledger to Stripe payment or invoice IDs.
Frequently asked questions
Can I put an affiliate ID directly in a Stripe Payment Link?
Technically a public string can be passed as the client reference, but it can be copied or changed. An opaque reference mapped to a validated server-side record is safer.
Does Stripe Payment Links pay affiliates automatically?
No. Payment Links accepts customer payments. Affiliate eligibility, commission calculation and payouts require your own process or a compatible affiliate service.
Is checkout.session.completed enough to pay a commission?
Not for every payment method or subscription policy. Confirm the relevant successful payment or paid invoice before approval.
Sources and editorial disclosure
Official Stripe documentation reviewed 30 October 2026. This article is a technical design guide, not a hands-on integration test or a claim that Stripe supplies a native affiliate payout program.