What should server-side affiliate tracking software actually do?
Short answer: A suitable platform should connect a valid affiliate referral to a customer, identify an eligible paid transaction from a trusted server-side source, and reconcile renewals, refunds and commission adjustments. A server-to-server postback does not magically recover a referral identifier that was never captured. Evaluate the entire data path, not a marketing claim that a vendor is “cookieless.”
This guide is for SaaS teams comparing implementation options. For the conceptual difference between cookies and server-side attribution, read our cookie versus server-side tracking explainer. Here we focus on vendor capabilities, data contracts and acceptance tests.
Design the attribution data model before choosing software
The minimal chain is partner → referral token → signup → internal customer ID → billing customer ID → subscription or order → paid event → commission ledger. Store a referral token at the first lawful capture point, then attach it to an authenticated account after signup. The billing customer ID must be stable across plan changes. Never rely on an email address alone as a universal transaction key: people can change addresses, share domains or create duplicate accounts.
For each commission, record the payment provider, transaction ID, affiliate ID, qualifying amount, currency, commission rule version, event ID and current approval state. This makes duplicate prevention, refunds and disputes auditable. A useful idempotency key is the combination of provider, transaction ID and commission rule or recipient. The exact key depends on the product and must be tested.
Client-side collection still has a role
Many programs use a browser link or landing-page identifier to establish the original referral and a server-side billing event to confirm the sale. These are complementary steps. If a visitor rejects optional tracking, your consent policy and applicable law still govern whether you may retain an identifier; a server request is not a workaround for privacy requirements. Capture only necessary data, document retention and avoid putting API secrets in page JavaScript.
Documented software options worth evaluating
| Product | Documented integration route | What to verify |
|---|---|---|
| Tapfiliate | Its S2S postback guide documents conversion requests with an external transaction ID and referral code or coupon; REST API conversion creation is also documented. | Which plan includes your desired integration, account-level authentication, retries, refunds and customer continuity. |
| FirstPromoter | Publishes admin/tracking APIs and webhook events for program data. Billing integrations are separately documented. | Whether your exact checkout can create or associate the referral without relying solely on the browser. |
| Partnero | Offers payment-provider integrations and API or webhook workflows for custom setups. | Specific billing version, event mapping, approval workflow and the plan needed for custom API use. |
| Rewardful | Connects affiliate attribution to Stripe and Paddle billing and calculates commissions from qualifying paid invoices. | Where attribution is first captured and whether your checkout architecture fits its supported integration. |
These are documentation-based evaluation candidates, not an independently tested ranking. A product supporting outgoing webhooks does not necessarily support incoming server-side conversion creation. Ask vendors to demonstrate the exact direction and authentication of each integration.
Map Stripe and Paddle Billing events correctly
With Stripe Billing, subscribe to the documented subscription and invoice lifecycle, verify webhook signatures and treat a confirmed successful payment as the financial trigger for an eligible commission. A created invoice or trial signup alone should not be paid by default. Handle payment failures, retries, discounts and refunds explicitly. Stripe's subscription webhook guide is the primary reference.
With Paddle Billing, you can carry an allowed referral identifier in transaction custom_data. Paddle documents propagation to newly created subscriptions and later renewal or upgrade transactions. Reconcile against transaction.completed and other relevant events as appropriate for your ledger; confirm the vendor's support for Paddle Billing rather than legacy Paddle Classic. See the official custom-data documentation and our Paddle affiliate integration guide.
Build a safe and reversible event pipeline
- Authenticate billing notifications using the provider's signature verification process before accepting their contents.
- Store incoming event IDs and ignore previously processed IDs. Expect retries and events arriving out of order.
- Keep an append-only or auditable commission ledger; make adjustments rather than silently overwriting approved payouts.
- Use least-privilege API credentials, encrypt secrets at rest and rotate compromised credentials.
- Separate development, staging and production accounts. Do not create live affiliate liabilities with test payments.
- Require manual approval for unusual or high-value adjustments and self-referral anomalies.
Do not interpret a successful HTTP response as proof that the affiliate received the right amount. Validate the resulting commission record and its approval state. Our affiliate webhook integration guide covers the broader event-delivery contract.
Acceptance tests to request during a vendor demo
| Scenario | Expected outcome |
|---|---|
| Referred visitor signs up and starts a free trial | Referral association is recorded, but no paid commission is created unless the program explicitly pays for trials. |
| First eligible invoice is paid | Exactly one commission is created for the correct affiliate and eligible net amount. |
| Identical webhook is delivered twice | Ledger remains unchanged after the first successful processing. |
| Monthly subscription renews | Renewal commission follows the configured duration and rate, if recurring commissions are enabled. |
| Annual plan upgrades mid-term | Proration is handled according to the documented policy, not counted as a new full annual sale. |
| Refund or chargeback arrives | Pending commission is reduced or reversed with a traceable adjustment. |
| Referral was not captured with valid consent | System does not manufacture attribution or override consent controls. |
A practical procurement scorecard
Ask each vendor to show: (1) a complete referral-to-payment trace, (2) documented conversion creation API or billing connector, (3) unique transaction identifiers, (4) signed incoming events and replay protection, (5) renewals and refunds, (6) manual commission overrides, (7) a downloadable reconciliation report, (8) supported regions and currencies, (9) plan-specific API limits, and (10) data export on cancellation. Record pass, fail or unknown rather than assigning arbitrary scores.
If your team has limited engineering capacity, a documented native billing integration may be safer than a custom postback. If your stack uses multiple processors or custom invoicing, the API and reconciliation model become more important than an attractive partner portal. Compare developer requirements in our affiliate tracking API checklist.
Frequently asked questions
Does server-side tracking eliminate cookies?
Not necessarily. A server-side conversion event still needs a lawful way to associate the customer with an affiliate. Some implementations start with a browser identifier, while others use coupon codes or account-based referrals.
Is a webhook the same as an API conversion?
No. A webhook typically reports that an event happened. A conversion API or postback endpoint accepts a new event or conversion. Vendors may support one, both or neither in a given plan.
Should commissions trigger on checkout completion?
Only when that event represents a verified qualifying payment under your policy. Some checkouts can finish before settlement, and subscriptions can start with trials or zero-value invoices.
Official references and editorial notes
- Tapfiliate S2S postback documentation
- Tapfiliate REST API conversion guidance
- FirstPromoter API and webhooks
- Stripe subscription events
- Paddle transaction custom data
Documentation reviewed 27 October 2026. No independent vendor account testing is claimed. Features and plan entitlements should be reconfirmed before procurement.