Lustr's best acquisition channel isn't paid search — it's warm referrals from businesses whose clients already need automotive detailing. A gym whose members drive to every workout, a car dealership's service lane, a body shop waiting room. The overlap is perfect. The challenge was turning that warm overlap into a measurable, low-friction channel that doesn't require the partner to do anything more than put a card on their front desk.

The insight was to make the referral hardware-simple. A physical NFC card — designed, manufactured, and distributed by Lustr — gets programmed to a unique lustrservices.ca/r/<code> URL. The partner sets it on their counter. Their customer taps their phone, lands on the Lustr site, and can book at their own pace. No app, no partner login, no training, no concierge flow. When the booking is paid, the partner earns their commission. The card does the only thing that matters: create the attributable touchpoint.

Attribution via a redirect sounds simple until you think about where the cookie has to live. The customer's booking happens on lustrservices.ca. If the redirect goes through a Supabase function URL (*.supabase.co), any cookie it sets is third-party from the browser's perspective — blocked by default in Safari, increasingly restricted everywhere else. The attribution would evaporate exactly for the customers least likely to be using a Chrome-based browser.

The fix is Vercel edge middleware: a thin function that runs on lustrservices.ca itself, resolves the referral code anon-side over fetch (edge-runtime-safe, no Node SDK), sets the attribution cookie as first-party, logs the click with sha256-hashed IP, and redirects to the homepage. The cookie is HttpOnly to prevent client-side tampering, plus a second readable copy that the checkout fetch (going to *.supabase.co) can include in the request body. Server-side re-validation at checkout and again at the Stripe webhook means the readable cookie is verified, not trusted — a forged value resolves to nothing.

The same /r/<code> middleware and webhook attribution path work for social media with zero additional engineering. An influencer's link in an Instagram bio, a YouTube description, or a TikTok profile routes through the identical attribution hop. The commission engine, earnings dashboard, and payout reports are all channel-agnostic.

Partner affiliate and influencer affiliate are the same software but different operational models: a physical business partner gets an NFC card and earns a recurring commission on client bookings; a social media influencer gets a referral link and earns a flat fee per serviced booking. Volume and risk profile differ, but the tracking and payout machinery doesn't. The distinction is kept at the commission tier and lifecycle level, not at the code level.

Future proposals doc notes the remaining considerations for opening the influencer channel: capacity constraints (a viral post can overwhelm a finite crew calendar in a way a gym's trickle of referrals can't), commission math verification against the cheapest qualifying services, and member-booking edge cases (active members pay no deposit, which removes the self-funding mechanism for the commission). The infrastructure is already there when the operational prerequisites are met.

Every write path is defense-in-depth. The referral code resolver is anon-callable but returns only an opaque affiliate_id UUID — no PII, no business info. The validator RPC (used at checkout and webhook) is authenticated/service-role only; an explicit REVOKE EXECUTE from anon prevents Supabase's default auto-grant from accidentally making it callable by a random visitor.

Attribution is stamped exactly once and is then immutable. A database trigger (appointments_guard_attribution) reverts any non-service-role attempt to overwrite an already-stamped affiliate_id, so neither a client bug nor a malicious request can re-attribute a booking after the fact. The self-referral guard runs at webhook time against the paying customer's auth.uid, so an affiliate can't book under a different email and then collect on themselves.

Suspension and channel kill-switch both drop attribution between scan and pay — if an affiliate is suspended after a customer taps their card but before that customer pays, the webhook finds status != 'active' and skips the stamp. Commission is earned only on bookings that are fully paid and serviced, not on holds.

The NFC cards are a deliberate physical-product decision. A QR code alone works fine, but NFC creates a frictionless mobile tap and signals quality — it's the same mechanism as contactless payment, familiar to every smartphone user. For a premium detailing brand, a matte-finished card with the Lustr mark on the counter of a partner business does brand work in addition to attribution work.

Distribution is admin-gated: a Lustr admin provisions a partner account through the in-person provisioning flow, which creates the auth user, affiliates row with a unique referral_code, and fires a magic-link welcome email. The partner's referral_code is then the programming target for their NFC card — one card per partner, programmed once, replaced if the card is lost or the partner relationship ends. Card design uses the same brand system as Lustr's other print collateral (B2B partner cards from the design sub-project).