PartnerStack Fraud Disputes and Held Affiliate Commissions

A practical guide to reviewing PartnerStack fraud flags and reconciling held partner rewards.

Sources checked 4 November 2026 ยท Documentation-based analysis

What happens when PartnerStack flags an affiliate or referred customer?

Short answer: PartnerStack's documented fraud monitoring system can hold partner rewards or prevent a flagged partner from cashing out. A program manager with appropriate permissions can review the case and dispute the fraud decision for a further review. Do not treat every flag as proof of wrongdoing or assume that a merchant can edit the underlying fraud-detection rules.

PartnerStack's official Fraud Monitoring guide describes the security dashboard, review process, reward holds and dispute outcomes. The system uses Sift risk signals; PartnerStack says detailed threat logic is not public. This article addresses handling a flagged case, not generic self-referral prevention.

Understand the documented fraud workflow

Case stateOperational effectRecommended action
Partner flaggedCashout blocked; relevant rewards heldReview identity, program context and evidence
Customer flaggedRelated transactions and rewards heldValidate referral and customer relationship
Dispute submittedCase under PartnerStack reviewPreserve case ID and supporting evidence
Dispute approvedRewards can be generated or released per vendor workflowReconcile against the next invoice and partner statement
Dispute declinedFlag and restrictions remainDocument outcome and communicate policy

PartnerStack documents default removal behavior after a flagged event if no action is taken, including a 30-day timeline in its current guide. Verify the specific account and case status rather than scheduling automatic removal based solely on this article.

Who can review a flagged case?

PartnerStack states that an account Admin or a user with Fraud permissions can access the fraud suite. Flagged events appear in the program dashboard's Security Monitoring area, with Fraud Management as another entry point. Assign review responsibility to a limited set of authorized staff. Avoid sharing broad admin access with an external partner or contractor just to resolve a commission question.

Record the partner or customer, date flagged, affected transactions, current reward status and the reason supplied in the case. Where a referral is legitimate, gather business evidence such as the agency agreement, sales correspondence, customer relationship and paid transaction record. Avoid collecting unnecessary personal information or guessing the fraud algorithm.

How to submit a defensible dispute

  1. Open the relevant case in Fraud Management using an authorized account.
  2. Read the flagged event details and determine whether the issue concerns a partner or a referred customer.
  3. Verify the commercial context against the partner agreement and CRM records.
  4. Use the documented Dispute Decision option when there is credible evidence of a false positive.
  5. Provide a concise explanation with relevant timestamps and transaction identifiers.
  6. Track the review status and do not release a separate manual payout while the same reward is on hold.
  7. After the decision, reconcile partner balances, invoices and internal records.

The official documentation states that the PartnerStack fraud team reviews disputed cases. A merchant cannot simply whitelist a repeatedly flagged partner or customize the vendor's core fraud logic. Where a case repeats, contact PartnerStack through the documented support route rather than building a workaround that bypasses the review.

Reconcile held rewards after a decision

Keep separate columns for original earned reward, held amount, released amount, paid amount and adjustment reason. A reward that becomes eligible after dispute approval may appear in a later billing cycle, so avoid reporting it as a missing payment solely because it did not appear on the original invoice. PartnerStack notes that review timing can delay a reward by a month in some cases.

Example: a partner has $250 in otherwise eligible rewards, of which $90 is held after a customer flag. Your internal ledger should show $160 available subject to other approval conditions and $90 on hold, not a silent reduction to $160 of total earned rewards. After an approved review, reconcile the $90 against the appropriate invoice and actual payout.

Do not pay the held amount manually while PartnerStack may later release it automatically. That creates a duplicate-payment risk. Keep the platform reward key and your accounting entry linked.

Prevent false-positive damage without weakening controls

Some agencies legitimately buy or administer software on behalf of clients. Others may share office networks, payment administrators or corporate domains. A matching signal should prompt review, not an unsupported allegation. Publish partner terms covering self-referrals, prohibited traffic, payout holds and appeals, and apply them consistently.

For evidence classification, see self-referral prevention. For general financial handling, see commission approval workflow and refund reserve policies.

Operational checks for the partner team

Audit a flagged partner, a flagged customer, an approved dispute, a declined dispute and a repeated flag. For each case verify the status displayed in PartnerStack, internal ledger state, communication record and actual payout. Track time to review, amount held, false-positive rate where measurable and unresolved case age. Do not publish a fraud rate without a defined denominator.

Frequently asked questions

Can a program manager change PartnerStack's fraud algorithm?

PartnerStack documents that the core fraud suite is controlled by its fraud team, not configured independently by each merchant.

Can a held reward become payable later?

Yes. Approved disputes may result in rewards appearing in a later invoice cycle.

Does a fraud flag prove an affiliate violated the terms?

No. Review the evidence and use the documented dispute process when appropriate.

Editorial note: Official PartnerStack Fraud Monitoring documentation reviewed 4 November 2026. No access to a live merchant fraud case or independent testing is claimed.