Testing Integration

Before going live, verify each layer in order to confirm that your identifiers, metadata, and revenue path line up correctly:

1. click tracking
2. signup/lead tracking
3. sale tracking

The synthetic verification chainCopy Anchor Link

Once your tracking code is live on your public site, Affitor detects it automatically (no debug mode required). Go live publishes the program once its business details, commission and payments are set (what each needs). It does not test your integration, and the sale in the synthetic chain below does not count as your payment connection: with the Server API, the sale that unlocks Go live has to come from your server.

To check the whole pipeline without a real customer, run the synthetic click → signup → sale chain through Affitor's real attribution and commission pipeline, with no real money. Three ways run it:

• Run check under Check Affitor's tracking on the Payments step of setup, once payments are connected (Stripe connected, or with the Server API, a first sale received from your server)
• npx affitor onboard, which fires the chain and then polls readiness until integration_verified is reached (see CLI commands)
• the MCP affitor_run_verification tool, followed by affitor_readiness

affitor test click|lead|sale sends one test event at a time; it does not run the chain.

The manual, per-layer checks below are optional — useful when you want to confirm a specific layer is firing in the browser.

1. Test Click Tracking (optional, manual)Copy Anchor Link

Tracker debug modeCopy Anchor Link

Enable debug mode in your tracker install.

Script tag:

<script
  src="https://api.affitor.com/js/affitor-tracker.js"
  data-affitor-program-id="YOUR_PROGRAM_ID"
  data-affitor-debug="true">
</script>

What to verifyCopy Anchor Link

• the tracker script loads successfully
• the page can set/read Affitor cookies
• click/pageview-related requests are visible in the browser
• your dashboard shows test/debug activity for the pageview step

2. Test Lead TrackingCopy Anchor Link

Browser-side signup testCopy Anchor Link

After a successful signup in a tracked browser session, call:

await window.affitor.signup('user_123', 'user@example.com');

Verify that:

• the same internal ID you passed as customerKey is the one you plan to reuse later
• the tracker emits the expected network/debug activity
• the dashboard/test-event view reflects lead test activity where applicable

Server-side lead API testCopy Anchor Link

curl -X POST https://api.affitor.com/api/v1/track/lead \
  -H "Content-Type: application/json" \
  -d '{
    "click_id": "test_lead_001",
    "customer_key": "test_customer",
    "additional_data": {
      "test_mode": true,
      "program_id": "YOUR_PROGRAM_ID"
    }
  }'

Expected response:

{
  "success": true,
  "message": "Test lead event tracked successfully",
  "data": {
    "eventId": 456,
    "programId": 1,
    "test_mode": true
  }
}

What test mode means for leadsCopy Anchor Link

• creates a test lead event only
• does not create a production lead/customer progression
• helps verify that your program ID and endpoint wiring are correct

3. Test Sale TrackingCopy Anchor Link

You can test sale tracking in two different ways depending on your implementation: server-side tracking vs Stripe integration.

Option A — Test Server-side trackingCopy Anchor Link

curl -X POST https://api.affitor.com/api/v1/track/sale \
  -H "Authorization: Bearer YOUR_PROGRAM_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "additional_data": { "test_mode": true },
    "amount_cents": 9999,
    "currency": "USD",
    "sale_type": "payment"
  }'

Expected response:

{
  "success": true,
  "message": "Test sale event tracked successfully",
  "data": {
    "eventId": 789,
    "programId": 1,
    "test_mode": true
  }
}

What test mode means for salesCopy Anchor Link

• still requires the Bearer token
• creates a test sale event only
• does not create commissions
• does not create platform fees
• does not update production metrics

Option B — Test Stripe integrationCopy Anchor Link

If you use Stripe Checkout:

1. switch Stripe to test mode
2. complete a test checkout
3. check that the program's Stripe card under Program settings › Payments reads Connected. Affitor receives the events through Stripe Connect, so there is no webhook delivery to verify on your side
4. inspect the metadata on the checkout/payment objects

Check that metadata includes:

• program_id
• affitor_click_id
• affitor_customer_key

For subscriptions, also confirm the same values exist in subscription_data.metadata.

4. Verify Test Events Were ReceivedCopy Anchor Link

Each test-mode call above answers with "test_mode": true and an eventId when the event was recorded, so the response is your first check.

The dashboard also looks up recent test events through POST /api/tracking/check-test-events, for every step or for one (pageview, referrals or payments). It is a dashboard endpoint: it needs a signed-in dashboard session from someone on the program's team with the Member, Admin or Owner role (a Viewer is refused) and does not accept a program API key, so you cannot call it from your backend.

5. Recommended Real-World Test ScenariosCopy Anchor Link

Scenario A — Full tracked funnelCopy Anchor Link

1. open a fresh browser session
2. land through an affiliate link
3. sign up
4. complete payment
5. verify click → lead → sale linkage

Scenario B — Server-side tracking pathCopy Anchor Link

1. complete a backend-controlled purchase
2. send POST /api/v1/track/sale
3. verify the response contains sale_id and commission_id
4. confirm no duplicate retries reuse the same transaction_id

Scenario C — Stripe subscription pathCopy Anchor Link

1. create a Stripe Checkout subscription in test mode
2. ensure subscription_data.metadata carries affitor_click_id and affitor_customer_key (Affitor reads the subscription's invoices, which carry it, not the session's metadata)
3. check that the subscription's first payment appears under Commissions, marked Test
4. confirm your renewal setup will preserve those identifiers

Common Failure ModesCopy Anchor Link

Lead works but sales do not attributeCopy Anchor Link

Usually caused by one of these:

• customerKey at signup does not match the later payment identifier
• Stripe metadata uses the wrong customer key
• transaction_id is duplicated or missing in the server-side tracking path
• no tracked click/customer relationship exists for the customer

One-time Stripe works but renewals do notCopy Anchor Link

Usually caused by:

• missing subscription_data.metadata: the subscription's invoices carry it, not the checkout's metadata, so the first subscription payment never sees the click (renewals follow the first payment)
• relying only on initial checkout metadata
• mismatched customer key between signup and Stripe metadata

Dashboard status is confusingCopy Anchor Link

The dashboard combines:

• test event presence for click/lead verification
• Stripe connection/configuration state for payment setup
• real sale events for broader integration completeness

Treat dashboard status, test-event checks, and the payments in your Stripe Dashboard as complementary signals: no single source is the full picture.

Before You Send Partner TrafficCopy Anchor Link

Go live itself needs only business details, commission and payments (Go live). Before partners start sending traffic, confirm all of the following:

• tracker installed on all landing pages
• signup tracking sends a stable internal customer ID
• Server-side tracking or Stripe integration path is fully implemented
• Stripe subscription metadata is duplicated correctly when relevant
• one end-to-end test has succeeded with the exact path you will use in production

Related guides:

• 3-Step Integration Guide
• Lead Tracking
• Payment Tracking