impact.com and PartnerStack: test the platform before choosing

The useful question is whether a platform can reproduce your partner programme’s actual business events. A recorded click does not prove that a returned order will stop generating commission. A deal marked won does not prove that a subscription payment has arrived. Comparing those transitions produces a more useful purchasing decision than comparing the length of feature lists.

This guide produces an acceptance pack for impact.com and PartnerStack: requirements, two test scenarios, a reconciliation ledger and a decision. Official sources were checked on 25 October 2026. The named Canva case below is a vendor-published account; the shop, software company and completed worksheets are educational examples, not customer results. Account access, country eligibility, product suitability and contracted functionality require separate confirmation.

Start with the events you must be able to explain

Choose one product, one approved market and one partner model. Appoint a programme owner, an engineer with access to the order or billing system, and a finance reviewer. Prepare the commission terms, return rules, existing customer definition, attribution window and a small set of pseudonymous records. Separate the event time from the time an event reaches the platform. A late delivery must not quietly become a new sale.

If the immediate task is to prepare an offer for a CPA network, our AffiliateCore is one possible starting point: register as an advertiser and prepare the proposal. Its advertiser resources support offer drafts and viewing conversion records. The worksheets in this guide remain your own documents. We do not claim an AffiliateCore integration with either vendor, automatic subscription accounting, deal registration or an import of their partners.

For this comparison, assume you already want software for your own programme. Ask each vendor to demonstrate the same inputs and expected outputs in an authorised test environment. Do not place fake compensated orders or send demonstration data into live partner payouts. If a safe environment or an essential feature is unavailable, record “not demonstrated” and postpone that test; do not award a pass from a sales slide.

Compare the data models, not just the brand names

impact.com: action and correction. A credited conversion becomes an action. Pending actions can be changed or reversed before their locking date; locking finalises the commission obligation. This makes the return period and the correction deadline central to the acceptance test. Check the actual dates in your terms rather than assuming a universal number of days. impact.com: action life cycle

impact.com: event chains. Chained actions connect a parent event with later events using a shared customer ID. The parent must be recorded first; existing event configurations may require support to enable chaining. This gives a documented route to test trial-to-paid or renewal attribution, but does not itself prove that your billing system sends complete events. impact.com: chained actions

PartnerStack: partner-led sales. Deal registration depends on the plan and is enabled by partner group. Its documentation describes manual approval for partner-submitted Closed Won deals, and creating a customer for subsequent transaction-based commissions. CRM compatibility must be confirmed with the vendor. A deal stage, a customer record and a paid transaction are different objects. PartnerStack: deal submission

PartnerStack: commission review. The review screen supports approval, decline and hold before invoicing. Eligible New commissions can be automatically approved when the invoice is generated. An already approved commission cannot simply be changed to another status in that screen; the documented correction route involves the invoice. Schedule review before that boundary. PartnerStack: commission review

These differences suggest what to demonstrate first: order corrections with impact.com, partner-owned sales workflow with PartnerStack. That is a test order, not a verdict that one cannot serve the other use case. Require both shortlisted products to pass the mandatory workflow. Treat catalogue listings, marketplace size and logos as discovery information, not proof of available partners or sales.

Public case: Canva turns different partner relationships into explicit rules

impact.com describes Canva using configurable contracts after a September 2019 start. Publication date unavailable; independent audit and cancellation-level evidence unavailable. Our editorial test proposal is to translate each required contract variant into an event, an attribution rule and an exception procedure. A referral and a partner-managed sale may concern the same customer: the pilot must explain who receives credit and why. Run the same synthetic record under the rule agreed in advance and retain the rationale. A familiar customer logo cannot replace that check. The following fixtures are our educational designs, not a reconstruction of Canva’s programme. Use the case to frame questions, not to accept a platform or declare a winner. impact.com — Canva

Use a requirement card that can fail

Copy this template for each mandatory capability: “Business event: ___. Source system and ID: ___. Expected partner: ___. Expected business status: ___. Expected commission status: ___. Deadline and timezone: ___. Evidence: ___. Plan or configuration dependency: ___. Owner: ___. Result: passed / failed / not demonstrated.” Keep the business status separate from vendor terminology.

A completed example is: “Order O-104 fully refunded; source refund R-104; original partner P-A; no retained sale; no payable commission; correction received before the contractual lock; evidence is the refund record plus the linked platform action.” A screenshot of a lower dashboard total is insufficient because it does not identify the corrected order. Include the export or record view that lets a second person reconcile the same ID.

Confirm required modules, implementation responsibilities, support, access and export conditions separately. Record who can approve a correction and who substitutes for that person. A configuration promise is an open requirement until demonstrated; keep it out of the list of passed controls.

Scenario 1: an online shop checks orders, duplicates and returns

Brief and material. An educational shop sells ordinary desk accessories through approved editorial partners. Prepare a buying guide, product landing page and partner-specific link. The acceptance rule is one commission per accepted order, with documented treatment of a full refund. Prepare O-101 as a normal order, O-102 for replay, O-104 for a full return and O-109 with a currency mismatch. Use synthetic records in the authorised environment; these are test fixtures, not customers.

Use this test ledger: “Order ID | partner | event time | received time | original amount and currency | refund ID | final accepted amount | platform record ID | commission decision | reason.” For O-101 expect one accepted sale. For O-102 resend the same event and expect one business result. For O-104 issue a full refund and expect the original result to be cancelled. For O-109 use a mismatched currency and expect an investigation, not an improvised conversion.

Run the demonstration. Agree the configured attribution rule and safe test route. Submit the initial fixtures, match each source ID to its platform record and verify the partner assignment. Replay O-102 through the supported integration route while preserving its business identifier. Compare the record before and after delivery: an API field alone does not guarantee deduplication. A second payable result fails the test. Have the engineer identify whether identity mapping or delivery logic caused it before repeating the same fixture.

In impact.com, demonstrate the pending action and its locking date, then apply the full reversal before that boundary. Its field reference distinguishes action identifiers from order/event-type identifiers and describes order-level and item-level modifications. Use the identifier combination required by your configured method. Do not blindly replace a transaction with a negative amount. impact.com: action and conversion fields

In PartnerStack, require the same source order to be traceable through the customer, transaction and commission records. Reconcile the transaction first, then demonstrate the commission review decision. Declining a commission must not be presented as proof that the source transaction disappeared. Do not infer automatic refund handling from the existence of a payment webhook. Record the demonstrated correction route and what still needs manual work.

Filled educational outcome. O-101 remains accepted. O-102 still points to its original business result after replay. O-104 is linked to refund R-104 and no longer creates an eligible commission under the example’s rules. O-109 stays unresolved with an engineer assigned; it is neither an accepted sale nor a failed customer. This run cannot pass while O-109 lacks a documented resolution. A lower dashboard total is not the evidence: the decision needs each linked record and its reason.

Stop or expand. Stop if a duplicate remains payable, a refund has no source link, a currency changes without explanation or the review deadline expires before reconciliation. Save the failing fixture and configuration version. After repair, replay it and the normal control order. Expand only after every mandatory row is resolved, the return observation period is complete and a second reviewer can reproduce the ledger. A small clean test demonstrates process readiness, not incremental revenue.

Scenario 2: B2B software checks deal ownership and recurring payments

Brief and material. A hypothetical scheduling-software supplier works with consultants who introduce businesses and sometimes help close sales. The pilot separates introductions from partner-led deals. Its materials are a short demonstration brief and a deal form containing a pseudonymous organisation code, partner, product, stage, expected close date, amount and a reference to authorised contact handling. Do not include private customer data in a public demonstration pack.

The acceptance rule is “a qualified opportunity is not yet a payable sale; a verified payment determines the teaching commission.” Use this mapping template: “Organisation code → lead/deal ID → customer ID → invoice ID → transaction ID → commission ID.” Add the owner of each transition and the rule for two partners claiming the same organisation. Ask the vendor to show that conflict; do not assume a marketplace resolves it for you.

PartnerStack demonstration. Confirm deal access for the test group, configure the permitted form, and enable manual approval for partner-reported wins if that is your chosen control. Have the demonstrator submit one ordinary deal and one unsupported win claim. Confirm that sales validation is distinct from the partner’s declaration. Then show how an accepted deal becomes a customer, and how a later qualifying transaction produces the intended commission. PartnerStack: deal submission

The transaction API requires one customer reference, an amount in cents for the specified currency and a currency code; it also exposes a subscription identifier. Map these fields explicitly. The webhook guide requires existing customer records and correct matching identifiers, and warns that implementation requires development work. A supported provider name is not proof that your account mapping is correct. Test a missing customer reference and record how it is detected and recovered. PartnerStack: transaction API PartnerStack: payment webhooks

impact.com demonstration. Ask for a configured parent event such as an accepted trial and a later payment event linked by the same customer ID. Send the parent first. Then deliberately present a child event with a missing link in the authorised test flow: the engineer must identify the discrepancy and show a supported recovery. Check that a returned renewal does not silently erase the valid original acquisition. The documentation allows parent and child actions to be reversed separately; confirm the actual configured treatment. impact.com: chained actions

Filled educational subscription sequence. Organisation ORG-DEMO is assigned to P-A after the ownership check. Deal D-DEMO remains unverified until sales review; a trial alone creates no eligible commission under this example’s rule. Customer C-DEMO and subscription S-DEMO connect to the first verified payment I-FIRST and later renewal I-RENEW. When I-RENEW is refunded, mark that renewal ineligible while keeping the valid first payment and acquisition trace. A separate open deal stays open with an owner. Cancelling future renewal is not the same event as refunding a past invoice.

Stop or expand. Stop if an unverified win generates payable remuneration, two partners receive the same exclusive credit, a transaction loses its customer link or a refunded renewal remains payable. Check an upgrade or downgrade as its own transition: preserve the customer and subscription relationship, identify the effective event and apply the agreed eligibility rule rather than inventing a new acquisition. Expand after a complete billing and correction cycle passes, with open deals visible and owned. Add one partner group or billing variant at a time.

Copyable acceptance matrix and decision worksheet

Use the same worksheet for each candidate, then compare the evidence. The statuses below are business expectations for this educational pilot, not universal platform status names. Map the observed screen or export status beside them. A missing result is “not demonstrated”, never a pass. The worksheet is usable here without a download.

Download the worksheet as UTF-8 text

PILOT ACCEPTANCE WORKSHEET
Blank fields — copy for each candidate
Candidate / configuration version: ___
Product / permitted market / partner model: ___
Owner / engineer / second reviewer: ___
Authorised test environment / payout isolation evidence: ___
Source system / business ID / platform ID: ___
Customer / subscription / invoice / refund ID: ___
Expected partner / attribution rule version: ___
Business status before → after: ___
Commission expectation / observed vendor status: ___
Event time / received time / timezone: ___
Review deadline / lock or invoice boundary: ___
Evidence reference / exception owner / retest date: ___
Result: PASS / FAIL / NOT DEMONSTRATED

TEST MATRIX — apply to both candidates
ORDER: accepted order → one traceable business result.
REPLAY: same order event → no additional eligible commission.
REFUND: full return before correction boundary → original result ineligible, reason retained.
LATE: correction after boundary → documented escalation, no silent rewrite of finalised history.
TRIAL: trial without verified payment → no eligible commission under this pilot rule.
PAID: verified first payment → same customer, agreed partner, linked invoice.
RENEW: later payment → same subscription, separate invoice/event identity.
CHANGE: upgrade/downgrade → recorded transition, no invented new acquisition.
CANCEL: stop future renewal → no assumed future sale; historical valid invoice retained.
RETURN: refund renewal → renewal corrected, valid initial acquisition retained.
MISSING: absent customer link → visible exception and supported recovery.
CONFLICT: competing partner claim → recorded ownership decision before approval.

FILLED EDUCATIONAL EXAMPLE — synthetic, not a vendor test result
Candidate: demonstration A; configuration: DEMO-v1.
Source: synthetic billing ledger; reviewer: review role.
Links: C-DEMO / S-DEMO / I-RENEW / R-RENEW; partner P-A.
Before: renewal paid, commission awaiting review.
Input: full refund R-RENEW before agreed review boundary.
Expected: renewal refunded, its commission ineligible.
Keep: I-FIRST and initial acquisition unchanged.
Illustrative observation: linked renewal corrected; initial record retained.
Evidence: synthetic ledger row + linked demonstration record.
Result: PASS for this row only, not acceptance of a platform.
Open issue: late correction route not demonstrated; owner engineer.
Overall decision: STOP until late-correction evidence and retest exist.

CHECKLIST AND DECISION
[ ] Safe test route and exclusion from real payouts confirmed.
[ ] Same fixtures and rules used for both candidates.
[ ] Every mandatory row has linked evidence and reviewer.
[ ] No duplicate eligible result, orphan record or unexplained cancellation.
[ ] Open exceptions remain visible; deadline and escalation owner recorded.
[ ] Export independently reproduces source-to-platform mapping.
PASS only when every mandatory row passes.
FAIL on mismatch; STOP expansion while any mandatory row fails or is not demonstrated.
After repair repeat the failed fixture and a normal control.
Decision / limitations / next permitted step / reviewer / date: ___

Choose from evidence, then set a bounded next step

Mandatory controls have veto power: correct partner, one business result, explainable reversal, controlled approval and usable reconciliation. Mark other requirements as demonstrated, configurable with confirmed work, or unproven. An unproven mandatory function blocks selection for this scope; it does not establish that the vendor universally lacks it. Compare remaining manual work, dependencies, export quality and recovery ownership among passing candidates. Save a dated decision and the exact configuration it covers.

Final checklist: can another reviewer reproduce both ledgers; are all currencies and deadlines explicit; are test records excluded from real payouts; are unresolved objects visible; is the required plan confirmed; are access and export conditions documented; and is there a named person authorised to stop expansion? Preserve evidence and configuration dates. Retest affected cases after changing commission terms or billing integration.

For a separate CPA-network route, bring the resulting event definition and offer terms to the AffiliateCore advertiser account. Confirm which workflow suits the proposed product before launch. The vendor comparison and its pilot ledger do not migrate automatically. For the neighbouring organisational question, read the guide to handing over programme responsibilities; this article’s deliverable is a product acceptance decision.