Partner engine: Resolve referral ownership before commission is reviewed.

The problem

Partner registrations can overlap existing CRM opportunities, compete with another partner’s claim or generate commissions before customer cash is collected. The system is designed to separate registration, ownership protection, conflict resolution, commission earning and payment authorization so that each decision has evidence and an accountable reviewer.

The dashboard

13 views: Today, Partner summary, Partner directory, Partner applications, Co-sell deals, Integration installs, Integration health, Referrals, Commissions and payouts, Deal registration conflicts, Training and certification, Partner content, Reporting.

The partner leaderboard: every partner with its manager, tier, sourced against influenced pipeline and next payout date, with the top three of the quarter lifted into their own band.

State lives in the URL (view, filters, date range), records open in drawers with their history, and every action that changes something is written to an activity log and is safe to repeat.

Data model

• partners(id, external_id, status, terms_version)
• registrations(id, partner_id, domain, submitted_at, state)
• deal_links(id, registration_id, crm_deal_id, match_evidence)
• protections(id, registration_id, starts_at, expires_at, status)
• conflicts(id, registration_id, competing_id, reason, resolution)
• collections(id, stripe_payment_id, crm_deal_id, net_amount_cents)
• commissions(id, collection_id, partner_id, earned_cents, payable_cents)
• payouts(id, partner_id, amount_cents, approved_by, state).

Rules in the backend

1. Proposed duplicate detection flags an active HubSpot deal for the same canonical entity and overlapping product scope; uncertain aliases require review.
2. Protection begins on approval and lasts exactly 90 days; expired claims do not renew automatically.
3. Competing eligible registrations are adjudicated using timestamped evidence and recorded terms, not silent overwrites.
4. Earn commission only from qualifying Stripe collections using the approved rate and terms version.
5. Move earned commission to payable only after the configured hold and compliance checks; refunds create linked adjustments rather than deleting history.

Storage

Recommend Supabase Postgres with partner-scoped RLS. Retain raw payloads for 30 days, registration/audit history for 24 months and financial records under the applicable accounting policy. Restrict personal contact and payout details; never store card data.

Reliability

Use unique payment-event constraints, idempotent registration updates and payout keys. Failed jobs enter a dead-letter queue. Show stale CRM matching, unreconciled collections, pending approval and failed payout states separately.

Security and access

Partner users see only their registrations and permitted commission details. Operators manage cases; independent approvers authorize payouts. Tokens remain server-side, and payout preparation is separate from payout execution.

Cost

Partner-platform licensing, payment processing, commission expense and reconciliation infrastructure cost money. Rates, holds and eligibility depend on signed partner terms, not interface defaults.

Technology stack

• PartnerStack
• HubSpot
• Stripe
• Slack
• LinkedIn
• Calendly

Map a workflow like this

Start with the handoffs your team already runs and where they break.

Discuss a workflow →