impact.com und PartnerStack: Plattformen vor der Auswahl prüfen

Entscheidend ist, ob eine Plattform die tatsächlichen Geschäftsvorgänge Ihres Partnerprogramms nachvollziehbar abbildet. Ein erfasster Klick beweist nicht, dass eine zurückgegebene Bestellung keine Provision mehr auslöst. Ein gewonnener Deal belegt noch keinen Zahlungseingang für ein Abonnement. Diese Übergänge zu prüfen hilft bei einer Kaufentscheidung mehr als die Länge zweier Funktionslisten zu vergleichen.

Dieser Leitfaden liefert ein Abnahmepaket für impact.com und PartnerStack: Anforderungen, zwei Testszenarien, ein Abgleichsprotokoll und eine Entscheidung. Die offiziellen Quellen wurden am 25. Oktober 2026 geprüft. Der Canva-Fall stammt vom Anbieter; Shop, Softwareunternehmen und ausgefüllte Arbeitsblätter sind Lehrbeispiele, keine Kundenergebnisse. Kontozugang, Länderzulässigkeit, Produkteignung und vertraglicher Funktionsumfang sind gesondert zu bestätigen.

Mit den Vorgängen beginnen, die Sie erklären können müssen

Wählen Sie ein Produkt, einen zulässigen Markt und ein Partnermodell. Benennen Sie einen Programmverantwortlichen, einen Entwickler mit Zugriff auf Bestell- oder Abrechnungssystem und einen Prüfer aus dem Finanzbereich. Bereiten Sie Vergütungsbedingungen, Rückgaberegeln, die Definition bestehender Kunden, das Attributionsfenster und einige pseudonymisierte Datensätze vor. Trennen Sie Ereigniszeit und Empfangszeit: Eine verspätete Übermittlung darf nicht unbemerkt zu einem neuen Verkauf werden.

Wenn zunächst ein Angebot für ein CPA-Netzwerk vorbereitet werden soll, kommt unsere AffiliateCore als Ausgangspunkt infrage: Registrieren Sie sich als Advertiser und bereiten Sie Ihr Angebot vor. Die Advertiser-Ressourcen sehen Angebotsentwürfe und die Ansicht von Conversion-Datensätzen vor. Die Arbeitsblätter dieses Leitfadens bleiben Ihre eigenen Dokumente. Eine AffiliateCore-Integration mit den beiden Anbietern, automatische Abonnementabrechnung, Deal-Registrierung oder ein Import ihrer Partner wird hier nicht behauptet.

Für diesen Vergleich steht bereits fest, dass Sie Software für ein eigenes Programm benötigen. Lassen Sie beide Anbieter dieselben Eingaben und erwarteten Ausgaben in einer freigegebenen Testumgebung vorführen. Erzeugen Sie keine fingierten vergüteten Bestellungen und schleusen Sie Demodaten nicht in echte Partnerauszahlungen ein. Fehlt eine sichere Umgebung oder eine notwendige Funktion, lautet der Eintrag „nicht vorgeführt“. Eine Vertriebsfolie ersetzt keinen bestandenen Test.

Datenmodelle statt nur Markennamen vergleichen

impact.com: Action und Korrektur. Eine einem Partner zugeordnete Conversion wird zur Action. Solange sie pending ist, kann sie vor ihrem Sperrdatum geändert oder storniert werden; mit dem Locking wird die Provisionsverpflichtung endgültig. Rückgabefrist und Korrekturschluss gehören daher in den Abnahmetest. Prüfen Sie Ihre konkreten Vertragsdaten statt eine allgemeine Anzahl von Tagen anzunehmen. impact.com: action life cycle

impact.com: Ereignisketten. Chained Actions verbinden ein übergeordnetes Ereignis mit späteren Ereignissen über eine gemeinsame Kunden-ID. Das übergeordnete Ereignis muss zuerst erfasst sein; bei bestehenden Konfigurationen kann die Aktivierung Unterstützung erfordern. Damit lässt sich der Übergang von Testphase zu Zahlung oder Verlängerung dokumentiert prüfen. Vollständige Daten aus Ihrem Abrechnungssystem sind damit noch nicht bewiesen. impact.com: chained actions

PartnerStack: partnergeführter Vertrieb. Deal-Registrierung hängt vom Tarifumfang ab und wird für Partnergruppen aktiviert. Die Dokumentation beschreibt manuelle Freigaben für vom Partner als Closed Won gemeldete Deals und die Anlage eines Kunden für Provisionen aus späteren Transaktionen. CRM-Kompatibilität ist beim Anbieter zu bestätigen. Deal-Phase, Kundendatensatz und bezahlte Transaktion sind verschiedene Objekte. PartnerStack: deal submission

PartnerStack: Provisionsprüfung. Vor der Rechnungserstellung lassen sich Provisionen freigeben, ablehnen oder zurückstellen. Geeignete Provisionen im Status New können bei Rechnungserstellung automatisch freigegeben werden. Bereits freigegebene Provisionen lassen sich in dieser Ansicht nicht einfach umstellen; der beschriebene Korrekturweg führt über die Rechnung. Planen Sie den Abgleich vor dieser Grenze. PartnerStack: commission review

Diese Unterschiede bestimmen die sinnvolle Reihenfolge der Vorführung: bei impact.com zunächst Bestellkorrekturen, bei PartnerStack den partnergeführten Vertriebsablauf. Das ist keine Aussage, dass das jeweils andere Produkt den Anwendungsfall nicht bedienen kann. Beide Kandidaten müssen den Pflichtablauf bestehen. Katalogeinträge, Marktplatzgrößen und Logos helfen bei der Recherche, beweisen aber weder für Sie verfügbare Partner noch Verkäufe.

Öffentlicher Fall: Aus unterschiedlichen Partnerschaften werden überprüfbare Regeln

impact.com berichtet über anpassbare Canva-Partnerverträge nach dem Start im September 2019. Veröffentlichungsdatum nicht verfügbar; unabhängige Prüfung und Nachweise einzelner Stornierungen nicht verfügbar. Unser redaktioneller Prüfauftrag daraus: Übersetzen Sie jede gewünschte Vertragsvariante in ein Ereignis, eine Zuordnungsregel und eine Ausnahmebehandlung. Ein Vertrag für Empfehlungen und ein Vertrag für betreute Verkäufe können denselben Kunden betreffen; der Pilot muss zeigen, welcher Partner warum berücksichtigt wird. Lassen Sie denselben Beispieldatensatz mit der vorher vereinbarten Regel durchlaufen und bewahren Sie die Begründung auf. Ein bekanntes Kundenlogo ersetzt diese Prüfung nicht. Die folgenden Testdaten sind unsere eigenen Lehrbeispiele und keine Rekonstruktion des Canva-Programms. Die Fallbeschreibung dient als Anlass für Fragen, nicht als Abnahmenachweis oder Empfehlung eines Gewinners. impact.com — Canva

Eine Anforderungskarte muss auch scheitern können

Kopieren Sie für jede Pflichtfunktion: „Geschäftsereignis: ___. Quellsystem und ID: ___. Erwarteter Partner: ___. Erwarteter Geschäftsstatus: ___. Erwarteter Provisionsstatus: ___. Frist und Zeitzone: ___. Nachweis: ___. Abhängigkeit von Plan oder Konfiguration: ___. Verantwortlicher: ___. Ergebnis: bestanden / nicht bestanden / nicht vorgeführt.“ Halten Sie Geschäftsstatus und Anbieterbegriffe getrennt.

Ein ausgefülltes Beispiel lautet: „Bestellung O-104 vollständig erstattet; Erstattung R-104; ursprünglicher Partner P-A; kein verbleibender Verkauf; keine zahlbare Provision; Korrektur vor vertraglichem Locking eingegangen; Nachweise sind Erstattungsdatensatz und zugehörige Plattform-Action.“ Ein Screenshot mit gesunkenem Dashboard-Gesamtwert genügt nicht. Er identifiziert die korrigierte Bestellung nicht. Verwenden Sie eine exportierte Zeile oder Datensatzansicht, mit der ein zweiter Prüfer dieselbe ID abgleichen kann.

Bestätigen Sie benötigte Module, Implementierungsaufgaben, Support, Zugang und Exportbedingungen gesondert. Halten Sie fest, wer Korrekturen freigeben darf und wer diese Person vertritt. Eine zugesagte Konfiguration bleibt bis zur Vorführung eine offene Anforderung und darf nicht als bestandene Kontrolle gelten.

Szenario 1: Ein Shop prüft Bestellungen, Wiederholungen und Retouren

Briefing und Material. Ein fiktiver Shop verkauft gewöhnliches Schreibtischzubehör über zugelassene redaktionelle Partner. Bereiten Sie Kaufberatung, Produktseite und partnerspezifischen Link vor. Die Abnahmeregel verlangt eine Provision je angenommener Bestellung und ein dokumentiertes Verfahren für vollständige Erstattungen. O-101 ist der Normalfall, O-102 dient der erneuten Übermittlung, O-104 der vollständigen Retoure und O-109 enthält eine abweichende Währung. Das sind synthetische Prüfdaten in einer freigegebenen Umgebung, keine Kunden.

Die Protokollvorlage lautet: „Bestell-ID | Partner | Ereigniszeit | Empfangszeit | ursprünglicher Betrag und Währung | Erstattungs-ID | endgültig angenommener Betrag | Plattform-ID | Provisionsentscheidung | Grund.“ O-101 soll genau einen angenommenen Verkauf ergeben. Bei O-102 wird dieselbe Meldung erneut geschickt; erwartet wird weiterhin ein Geschäftsergebnis. O-104 wird vollständig erstattet und das ursprüngliche Ergebnis storniert. O-109 enthält eine abweichende Währung: Erwartet wird eine Untersuchung statt einer improvisierten Umrechnung.

Vorführung. Vereinbaren Sie Attributionsregel und sicheren Testweg. Übermitteln Sie die Ausgangsdatensätze, ordnen Sie jede Quell-ID dem Plattformdatensatz zu und prüfen Sie den Partner. Übermitteln Sie O-102 erneut über den unterstützten Integrationsweg mit unveränderter Geschäftskennung. Vergleichen Sie vorher und nachher: Ein API-Feld allein garantiert keine Dublettenvermeidung. Ein zweites zahlbares Ergebnis bedeutet einen fehlgeschlagenen Test. Der Entwickler muss vor der Wiederholung klären, ob Identitätszuordnung oder Zustelllogik die Ursache war.

Bei impact.com zeigen Sie die pending Action und ihr Sperrdatum, anschließend die vollständige Stornierung vor dieser Grenze. Die Feldreferenz unterscheidet Action-IDs von der Kombination aus Bestellung und Ereignistyp und beschreibt Änderungen auf Bestell- und Positionsebene. Verwenden Sie die für Ihre Methode erforderlichen Identifikatoren. Ersetzen Sie eine Transaktion nicht blind durch einen negativen Betrag. impact.com: action and conversion fields

Bei PartnerStack muss dieselbe Quellbestellung durch Kunden-, Transaktions- und Provisionsdatensatz nachvollziehbar sein. Gleichen Sie zuerst die Transaktion ab und zeigen Sie danach die Entscheidung in der Provisionsprüfung. Eine abgelehnte Provision beweist nicht, dass die Quelltransaktion verschwunden ist. Aus einem Zahlungs-Webhook folgt keine automatische Erstattungsbearbeitung. Dokumentieren Sie den vorgeführten Korrekturweg und verbleibende manuelle Aufgaben.

Ausgefülltes Lehrbeispiel. O-101 bleibt angenommen. O-102 verweist auch nach erneuter Übermittlung auf das ursprüngliche Geschäftsergebnis. O-104 ist mit Erstattung R-104 verknüpft und erzeugt nach den Beispielregeln keine berechtigte Provision mehr. O-109 bleibt mit zugewiesenem Entwickler offen: weder angenommener Verkauf noch gescheiterter Kunde. Dieser Durchlauf besteht erst, wenn O-109 eine dokumentierte Lösung hat. Entscheidend sind verknüpfte Datensätze und Gründe, nicht ein gesunkener Dashboard-Gesamtwert.

Stoppen oder erweitern. Stoppen Sie bei zahlbaren Dubletten, Erstattungen ohne Quellverknüpfung, ungeklärten Währungsänderungen oder abgelaufener Prüfung vor dem Abgleich. Sichern Sie Fehlerdatensatz und Konfigurationsversion. Wiederholen Sie nach der Reparatur diesen Datensatz und eine normale Kontrollbestellung. Erweitern Sie erst nach Klärung aller Pflichtzeilen, Abschluss der Retourenbeobachtung und unabhängigem Abgleich durch einen zweiten Prüfer. Ein kleiner sauberer Test belegt Prozessreife, keinen zusätzlichen Umsatz.

Szenario 2: B2B-Software prüft Deal-Zuordnung und Folgezahlungen

Briefing und Material. Ein hypothetischer Anbieter von Terminsoftware arbeitet mit Beratern, die Unternehmen vorstellen und teilweise beim Verkaufsabschluss helfen. Der Pilot unterscheidet reine Empfehlungen von partnergeführten Deals. Materialien sind ein kurzes Demo-Briefing und ein Formular mit pseudonymisiertem Organisationscode, Partner, Produkt, Phase, geplantem Abschlussdatum, Betrag und Verweis auf die zulässige Kontaktverarbeitung. Private Kundendaten gehören nicht in ein öffentliches Demonstrationspaket.

Die Abnahmeregel lautet: „Eine qualifizierte Verkaufschance ist noch kein vergüteter Verkauf; ein überprüfter Zahlungseingang bestimmt die Lehrprovision.“ Verwenden Sie: „Organisationscode → Lead-/Deal-ID → Kunden-ID → Rechnungs-ID → Transaktions-ID → Provisions-ID.“ Ergänzen Sie Verantwortliche für jeden Übergang und die Regel für zwei Partner, die dieselbe Organisation beanspruchen. Lassen Sie diesen Konflikt vorführen; ein Marktplatz löst ihn nicht automatisch.

PartnerStack vorführen. Bestätigen Sie den Deal-Zugang der Testgruppe, richten Sie das zulässige Formular ein und aktivieren Sie gegebenenfalls manuelle Freigaben für gemeldete Abschlüsse. Lassen Sie einen normalen Deal und eine unbelegte Abschlussmeldung einreichen. Prüfen Sie, dass die Vertriebsvalidierung von der Partnerbehauptung getrennt ist. Zeigen Sie anschließend die Kundenerstellung aus dem angenommenen Deal und die korrekte Provision aus einer späteren geeigneten Transaktion. PartnerStack: deal submission

Die Transaktions-API verlangt eine Kundenreferenz, einen Betrag in Hundertsteleinheiten der angegebenen Währung und einen Währungscode; zusätzlich gibt es eine Abonnementkennung. Ordnen Sie diese Felder ausdrücklich zu. Laut Webhook-Leitfaden sind vorhandene Kundendatensätze, passende Identifikatoren und Entwicklungsarbeit erforderlich. Der Name eines unterstützten Zahlungsanbieters beweist keine korrekte Kontozuordnung. Testen Sie eine fehlende Kundenreferenz und dokumentieren Sie Erkennung und Wiederherstellung. PartnerStack: transaction API PartnerStack: payment webhooks

impact.com vorführen. Fordern Sie ein konfiguriertes übergeordnetes Ereignis, etwa einen angenommenen Testzugang, und eine spätere Zahlung mit derselben Kunden-ID an. Übermitteln Sie zuerst das übergeordnete Ereignis. Führen Sie anschließend im erlaubten Testablauf ein untergeordnetes Ereignis ohne passende Verbindung vor. Der Entwickler muss die Abweichung erkennen und einen unterstützten Wiederherstellungsweg zeigen. Prüfen Sie, dass eine erstattete Verlängerung die gültige ursprüngliche Akquisition nicht unbemerkt aufhebt. Die Dokumentation erlaubt getrennte Stornierungen beider Ereignisebenen; bestätigen Sie die tatsächliche Konfiguration. impact.com: chained actions

Ausgefüllte Lehrsequenz für Abonnements. ORG-DEMO wird nach der Zuordnungsprüfung P-A zugewiesen. D-DEMO bleibt bis zur Vertriebsprüfung unbestätigt; ein Testzugang allein erzeugt nach der Beispielregel keine berechtigte Provision. Kunde C-DEMO und Abonnement S-DEMO verbinden die erste bestätigte Zahlung I-FIRST mit Verlängerung I-RENEW. Wird I-RENEW erstattet, entfällt nur deren Provisionsberechtigung; die gültige Erstzahlung und Akquisitionshistorie bleiben erhalten. Ein anderer offener Deal bleibt mit Verantwortlichem offen. Das Abschalten künftiger Verlängerungen ist kein Rückerstatten einer früheren Rechnung.

Stoppen oder erweitern. Stoppen Sie, wenn ein ungeprüfter Abschluss zahlbare Vergütung erzeugt, zwei Partner denselben exklusiven Anspruch erhalten, eine Transaktion ihre Kundenverbindung verliert oder eine erstattete Verlängerung vergütet bleibt. Prüfen Sie ein Upgrade oder Downgrade als eigenen Übergang: Kunden- und Abonnementbezug erhalten, Wirksamkeitsereignis bestimmen und die vereinbarte Berechtigungsregel anwenden, ohne eine neue Akquisition zu erfinden. Erweitern Sie nach einem vollständigen bestandenen Abrechnungs- und Korrekturzyklus; offene Deals bleiben sichtbar und zugewiesen. Ergänzen Sie jeweils eine Partnergruppe oder Abrechnungsvariante.

Kopierbare Abnahmematrix und Entscheidungsblatt

Nutzen Sie dasselbe Blatt für jeden Kandidaten und vergleichen Sie anschließend die Nachweise. Die folgenden Statusangaben sind Geschäftserwartungen dieses Lehrpiloten, keine allgemeingültigen Plattformbezeichnungen. Notieren Sie daneben den tatsächlich angezeigten oder exportierten Status. Ein fehlendes Ergebnis heißt „nicht vorgeführt“, niemals bestanden. Das Blatt ist auch ohne Download hier verwendbar.

Arbeitsblatt als UTF-8-Text herunterladen

ARBEITSBLATT ZUR PILOTABNAHME
Leere Felder — für jeden Kandidaten kopieren
Kandidat / Konfigurationsversion: ___
Produkt / zulässiger Markt / Partnermodell: ___
Verantwortlicher / Entwickler / zweiter Prüfer: ___
Testumgebung / Nachweis der Auszahlungstrennung: ___
Quellsystem / Geschäfts-ID / Plattform-ID: ___
Kunden- / Abonnement- / Rechnungs- / Erstattungs-ID: ___
Erwarteter Partner / Version der Attributionsregel: ___
Geschäftsstatus vorher → nachher: ___
Provisionserwartung / beobachteter Anbieterstatus: ___
Ereigniszeit / Empfangszeit / Zeitzone: ___
Prüffrist / Locking- oder Rechnungsgrenze: ___
Nachweis / Fehlerverantwortlicher / Wiederholungstermin: ___
Ergebnis: BESTANDEN / NICHT BESTANDEN / NICHT VORGEFÜHRT

TESTMATRIX — für beide Kandidaten
BESTELLUNG: angenommen → ein nachvollziehbares Geschäftsergebnis.
WIEDERHOLUNG: gleiches Ereignis → keine weitere berechtigte Provision.
ERSTATTUNG: vollständig vor Korrekturgrenze → ursprüngliches Ergebnis nicht berechtigt, Grund erhalten.
VERSPÄTUNG: Korrektur nach Grenze → dokumentierte Eskalation, keine stille Überschreibung finaler Historie.
TESTZUGANG: ohne bestätigte Zahlung → keine berechtigte Provision nach Pilotregel.
ZAHLUNG: erste bestätigt → gleicher Kunde, vereinbarter Partner, verknüpfte Rechnung.
VERLÄNGERUNG: Folgezahlung → gleiches Abonnement, eigene Rechnungs-/Ereigniskennung.
WECHSEL: Upgrade/Downgrade → dokumentierter Übergang, keine erfundene Neuakquisition.
KÜNDIGUNG: künftige Verlängerung beendet → kein angenommener künftiger Verkauf; gültige frühere Rechnung bleibt.
RETOURE: Verlängerung erstattet → Verlängerung korrigiert, Erstakquisition erhalten.
FEHLENDE VERKNÜPFUNG: Kunde fehlt → sichtbarer Fehler und unterstützte Wiederherstellung.
KONFLIKT: konkurrierender Partneranspruch → Zuordnungsentscheidung vor Freigabe.

AUSGEFÜLLTES LEHRBEISPIEL — synthetisch, kein Anbietertest
Kandidat: Demonstration A; Konfiguration DEMO-v1.
Quelle: synthetisches Abrechnungsprotokoll; Prüfer: Kontrollrolle.
Verbindungen: C-DEMO / S-DEMO / I-RENEW / R-RENEW; Partner P-A.
Vorher: Verlängerung bezahlt, Provision wartet auf Prüfung.
Eingabe: vollständige Erstattung R-RENEW vor vereinbarter Prüfgrenze.
Erwartung: Verlängerung erstattet, deren Provision nicht berechtigt.
Erhalten: I-FIRST und ursprüngliche Akquisition.
Beispielbeobachtung: verknüpfte Verlängerung korrigiert, ursprünglicher Datensatz erhalten.
Nachweis: synthetische Protokollzeile und verknüpfter Demodatensatz.
Ergebnis: BESTANDEN für diese Zeile, keine Plattformabnahme.
Offen: verspätete Korrektur nicht vorgeführt; verantwortlich: Entwickler.
Gesamtentscheidung: STOPP bis Nachweis und Wiederholung der verspäteten Korrektur vorliegen.

CHECKLISTE UND ENTSCHEIDUNG
[ ] Sicherer Testweg und Ausschluss echter Auszahlungen bestätigt.
[ ] Gleiche Prüfdaten und Regeln für beide Kandidaten.
[ ] Jede Pflichtzeile besitzt Nachweis und Prüfer.
[ ] Keine berechtigten Dubletten, verwaisten Datensätze oder unerklärten Stornierungen.
[ ] Offene Fehler sichtbar; Frist und Eskalationsverantwortlicher festgehalten.
[ ] Export ermöglicht unabhängige Wiederholung der Zuordnung.
BESTANDEN erst nach Erfolg jeder Pflichtzeile.
Abweichung bedeutet NICHT BESTANDEN; STOPP der Erweiterung bei Fehler oder fehlender Vorführung.
Nach Reparatur Fehlerdatensatz und normalen Kontrollfall wiederholen.
Entscheidung / Grenzen / nächster erlaubter Schritt / Prüfer / Datum: ___

Mit Nachweisen entscheiden und den nächsten Schritt begrenzen

Pflichtkontrollen haben ein Vetorecht: richtiger Partner, ein Geschäftsergebnis, erklärbare Stornierung, kontrollierte Freigabe und brauchbarer Abgleich. Weitere Anforderungen gelten als vorgeführt, mit bestätigtem Aufwand konfigurierbar oder ungeprüft. Eine ungeprüfte Pflichtfunktion verhindert die Auswahl für diesen Umfang, beweist aber nicht ihr generelles Fehlen. Vergleichen Sie unter bestandenen Kandidaten manuelle Restarbeit, Abhängigkeiten, Exportqualität und Verantwortung für die Wiederherstellung. Sichern Sie Entscheidung, Datum und genaue Konfigurationsversion.

Abschlusscheck: Kann eine zweite Person beide Protokolle reproduzieren? Sind Währungen und Fristen eindeutig, Testdatensätze aus echten Auszahlungen ausgeschlossen und offene Objekte sichtbar? Sind Plan, Zugang und Exportbedingungen bestätigt? Hat eine benannte Person das Recht, die Erweiterung zu stoppen? Bewahren Sie Nachweise und Konfigurationsdaten auf. Wiederholen Sie betroffene Tests nach Änderungen an Provisionsbedingungen oder Abrechnungsintegration.

Für einen separaten Weg über ein CPA-Netzwerk bringen Sie Ereignisdefinition und Angebotsbedingungen in das AffiliateCore-Advertiserkonto ein. Bestätigen Sie vor dem Start den geeigneten Ablauf für Ihr Produkt. Vergleich und Pilotprotokoll werden nicht automatisch übertragen. Die benachbarte Organisationsfrage behandelt der Leitfaden zur Übergabe von Programmaufgaben; hier ist das Arbeitsergebnis eine konkrete Produktabnahme.