Umsatzattribution

Verbinden Sie verifizierte Bestellungen mit dem Traffic und den Kampagnen dahinter.

Bestellungen erreichen Seean auf zwei Wegen: Ein nativer Connector empfängt die signierten Webhooks eines Zahlungsanbieters, oder Ihr Server sendet verifizierte Bestellungen und Erstattungen an die Order API von Seean. Jede Website berichtet in einer Währung, die Sie wählen. Nennt eine Bestellung einen Besucher, den Seean kennt, wird die Attribution (Kontakte, erste und letzte Quelle, Landingpage, Zeit bis zum Kauf) serverseitig aus den erfassten Besuchen dieses Besuchers in den 90 Tagen vor der Bestellung abgeleitet. Felder, die Ihre Integration liefert, werden nur für Besucher ohne erfasste Besuche verwendet.

Zahlungsanbieter verbinden

Öffnen Sie Settings → Integrations → Payment providers (Einstellungen → Integrationen → Zahlungsanbieter) auf Ihrer eigenen Website und wählen Sie Enable (Aktivieren) unter Creem, Mollie, Paddle, Polar, RevenueCat, Revolut, Shopify, Stripe, Superwall oder Whop. Das Panel listet die Einrichtungsschritte, die Webhook-URL der Website für diesen Anbieter (https://events.seean.io/api/connect/<provider>/<site ID>) und die zu aktivierenden Ereignisse; fügen Sie das Signing Secret des Anbieters ein, und Seean verifiziert jede Zustellung vor dem Speichern. Für Stripe, Polar und Paddle erstellt Quick connect (Schnellverbindung) den Webhook stattdessen aus einem API-Schlüssel, den Sie einmal einfügen; der Schlüssel wird nicht gespeichert. Nach Save secret (Secret speichern) wird das Feld aus Sicherheitsgründen geleert, und die Zeile darunter lautet Secret saved (ends in …) mit den letzten vier Zeichen, damit Sie bestätigen können, dass das richtige Secret gespeichert ist; fügen Sie nur einen neuen Wert ein, um es zu ersetzen. Bezahlte Bestellungen und Erstattungen kommen dann automatisch an, und die Statuszeile zeigt das letzte Ereignis und jeden Fehler. Ein fehlgeschlagenes Verbinden oder Trennen zeigt den Grund des Servers, einschließlich der Wartesekunden, wenn die Anfrage ratenbegrenzt wurde. Die Anbieteranleitungen unten geben für jeden Anbieter die Schritte, das Attributions-Snippet, das Erstattungs- und Währungsverhalten und die Grenzen.

Stripe bietet nach der Verbindung zusätzlich einen separaten, nur für Eigentümer sichtbaren Abschnitt Optional Stripe payment reads (Optionale Stripe-Zahlungsabfragen). Ein anfänglich nicht angekreuztes Einwilligungssteuerelement autorisiert ausdrücklich die Aufbewahrung eines eingeschränkten Leseschlüssels für die genaue erste Checkout-Rechnung, Zahlungen und Erstattungen - nicht Verlängerungen oder ein Backfill. Der Schlüssel wird nie vorausgefüllt oder zurückgegeben; nur der Eigentümer sieht den aktivierten Status, Test-/Live-Modus, Konto und Suffix. Ersetzen erfordert eine neue Einwilligung. Remove read key (Leseschlüssel entfernen) lässt Webhook, Bestellungen und bestehende Zahlungsverknüpfungen unberührt. Eine schnelle/manuelle Neuverbindung entfernt den gespeicherten Lesezugriff, während der Schnellverbindungsschlüssel weiterhin einmal verwendet und verworfen wird. Demo-/ausgelastete Steuerelemente sind deaktiviert; erfolgreiche Aktionen und Anbieterwechsel löschen den eingegebenen Leseschlüssel. Siehe die Stripe-Anleitung für Berechtigungen, Prüfungen erfolgreicher Erstattungen, Verknüpfung über signierte Ereignisse/Wiederholungen und begrenzte explizite Einzelsitzungs-Wiederherstellung. Diese Quellauslieferung bestätigt weder einen Produktions-Rollout noch eine Live-Wiederherstellung historischer Daten.

Zustellungswiederherstellung

Ein nativer Connector liefert 503, wenn eine Erstattung vor ihrer Bestellung eintrifft (bis zu einem Tag nach Erstellung der Erstattung; danach wird die Erstattung bestätigt und ignoriert), eine Revolut-Bestellsuche fehlschlägt oder die Aufnahme vorübergehend nicht verfügbar ist. Ratenbegrenzungen liefern 429. Diese Antworten lassen die Zustellung für die Wiederholungen des Anbieters offen; Seean führt keine zweite Webhook-Warteschlange. Nachdem die ursprüngliche Bestellung gespeichert ist, wendet eine Wiederholung der Erstattung mit derselben Erstattungs-ID sie einmal an.

Prüfen Sie Settings → Integrations → Payment providers auf die letzte Zustellzeit und den erfassten Zuordnungs- oder Suchfehler. Korrigieren Sie Zugangsdaten oder ungültige Zahlungsdaten an ihrer Quelle. Eine spätere erfolgreiche Zustellung löscht den letzten Fehler, prüfen Sie also auch fehlgeschlagene Zustellungen im Dashboard des Anbieters. Nicht unterstützte Ereignisse und dauerhafte Payload-/Währungsfehler werden mit 200 bestätigt; abgelehnte Bestellungen werden nicht gespeichert.

Wiederholungszeitpläne und Ablauf steuert jeder Anbieter selbst. Laufen Zustellversuche ab, nutzen Sie seine Steuerelemente zur erneuten Zustellung, falls verfügbar, oder senden Sie die verifizierte Bestellung/Erstattung über die Order API mit den ursprünglichen Kennungen. Zuvor bestätigte Fehler werden durch diese Änderung nicht automatisch wiederholt. Die optionalen Stripe-Abfragen können Verknüpfungen zur ersten Zahlung aus neu zugestellten signierten Checkout-Ereignissen oder exakten Wiederholungen herstellen; das Aktivieren des Schlüssels startet keine historische Wiederherstellung. Authentifizierte Eigentümer können separat einen Abgleichs-Probelauf für eine einzelne Sitzung und dann eine explizite Anwendung über eine eigene Integration anfordern; es gibt keinen automatischen oder websiteweiten Lauf. Nicht unterstützte Mehrfachrechnungs-/Gutschriftvereinbarungen und fehlende Referenzen erfordern eine Prüfung. Erstellen Sie niemals eine neue Bestell-ID nur, um eine Zahlung zu wiederholen.

Bestellungen von Ihrem Server senden

Öffnen Sie Settings → Integrations → Revenue (Einstellungen → Integrationen → Umsatz) und erweitern Sie Custom server integration (Order API) (Eigene Serverintegration), um die Berichtswährung zu wählen und ein Order-API-Secret zu erstellen. Nutzen Sie Ihren Server oder Zahlungs-Webhook-Handler, um verifizierte Bestellungen an den angezeigten Endpunkt zu senden. Behalten Sie das Secret auf Ihrem Server; nehmen Sie es nicht in Browsercode auf. Dies ist eine eigene Integration, keine automatische Verbindung zu jedem Checkout-Anbieter.

Der Tracker stellt window.seean.attribution() mit Besucher-ID, Landingpfad, konvertierendem Pfad und Kampagne bereit. Übergeben Sie diese Felder mit der Bestellung an Ihren Server: Die Besucher-ID verknüpft die Bestellung mit den Besuchen des Käufers. Ohne sie wird die Bestellung als nicht zugeordnet erfasst. Leiten Sie Zahlungsereignisse erst weiter, nachdem Sie sie bei Ihrem Anbieter verifiziert haben.

Berichtswährung

Jede Website hat eine Berichtswährung. Öffnen Sie das Dropdown unter Reporting currency (Berichtswährung) in der Umsatzintegrationskarte und wählen Sie einen ISO-4217-Code (standardmäßig USD); die Auswahl wird automatisch gespeichert. Beträge werden in der kleinsten Einheit dieser Währung gesendet: 2900 ist USD 29.00, JPY hat keine Untereinheit, also ist 2900 JPY 2,900, und KWD verwendet drei Dezimalstellen, also ist 2900 KWD 2.900. Eine Bestellung in einer anderen Währung wird mit HTTP 400 und der Meldung Order currency EUR does not match the website's reporting currency USD (mit den beteiligten Codes) abgelehnt. Seean rechnet keine Währungen um.

Eine Änderung der Berichtswährung rechnet bereits gesendete Bestellungen nicht um. Analysen zählen sie als ausgeschlossen, und die Umsatzseite zeigt einen Hinweis wie „3 Bestellungen verwenden eine andere Währung und sind aus den USD-Summen ausgeschlossen.“ Nur die Bestellungen in der aktuellen Berichtswährung bilden die Summen.

Erstattungen

Erstattungen sind ein Buch pro Bestellung. Eine Erstattung kann den vollen Restbetrag oder einen Teil-amount abdecken, trägt optional Ihre refundId, damit Wiederholungen dedupliziert werden, und kann einen eigenen Zeitstempel tragen. Eine Erstattung, die den Restbetrag übersteigt, wird mit HTTP 400 abgelehnt; eine Bestellung akzeptiert höchstens 50 Erstattungen. Sobald die erstattete Summe den Bestellbetrag erreicht, wird die Bestellung als erstattet markiert.

Erstattungen verringern den Nettoumsatz im Zeitraum der ursprünglichen Bestellung, nicht im Zeitraum des Erstattungsdatums. Eine Juni-Bestellung, die im Juli erstattet wird, senkt den Netto-Juni; der Juli zeigt dafür nichts. Prüfen Sie den Zeitraum, der die Bestellung enthält.

Abgeleitete Attribution

Für eine Bestellung mit bekanntem Besucher liest Seean die Besuche dieses Besuchers in den 90 Tagen vor dem Bestellzeitstempel:

• Kontakte: die Zahl der Besuche in diesem Fenster.
• Erste Quelle und Letzte Quelle: der Referrer oder utm_source des ersten und letzten Besuchs; Direct, wenn keines vorhanden ist.
• Landingpage: die Einstiegsseite des ersten Besuchs.
• Zeit bis zum Kauf: vom Beginn des ersten Besuchs bis zur Bestellung.
• Kampagne: die Kampagne, die Ihre Integration liefert; sonst die utm_campaign des jüngsten getaggten Besuchs.

Hat der Besucher keinen erfassten Besuch im Fenster, werden die erste Quelle, letzte Quelle, Kontakte und Zeit bis zum Kauf aus Ihrer Integration verwendet, und die Bestellung zählt nur dann als attribuiert, wenn sie einen Besucher und einen Landingpfad nennt. Bestellungen ohne Besucher-ID sind Nicht zugeordnet. Bestellungen, die vor der abgeleiteten Attribution erfasst wurden, werden einmal aus den erfassten Besuchen ihres Besuchers nachgefüllt; eine von Ihrer Integration gelieferte Kampagne bleibt erhalten.

Attributionslimits

Die Bestellaufnahme akzeptiert Verläufe mit bis zu 2.000 passenden Ereignissen im 90-Tage-Fenster. Sie prüft höchstens 2.001 Zeilen, um einen Überlauf zu erkennen, mit einem Lesebudget von 1 MiB. Ein vollständig gespeicherter Weg kann bis zu 64 KiB belegen. Diese Grenzen gelten für den Besucherverlauf jeder Bestellung, nicht für den gesamten Traffic einer Website. Seean speichert jeden Kontakt, wenn der vollständige Verlauf passt; Besuche nach dem dreißigsten werden nicht mehr verworfen.

Überschreitet der Verlauf eine Grenze, werden Bestellung und Erstattungen weiterhin exakt erfasst. Der Umsatzbericht zeigt einen Hinweis auf unvollständigen Verlauf und eine Aufschlüsselungszeile Unvollständiger Verlauf, statt aus einem Teil des Wegs Anteile zuzuweisen. Diese Bestellungen tragen nicht zum attribuierten Umsatz oder zur durchschnittlichen Zeit bis zum Kauf bei; sie bleiben in den Geldsummen und im Nenner der Attributionsrate. Der Bericht zählt betroffene Bestellungen für seine gewählte Währung und seinen Zeitraum, einschließlich vollständig erstatteter. Eine Änderung des Attributionsfensters stellt keinen Verlauf wieder her, der bei der Aufnahme nicht erfasst werden konnte.

Veraltete gekürzte Wege werden ebenfalls als unvollständig markiert, bis ihr vollständiger Verlauf wiederhergestellt werden kann. Bestehende gespeicherte Berichtsergebnisse bleiben erhalten. Verläufe ohne erfasste Besuche behalten die oben beschriebene, von der Integration gelieferte Attribution; sie unterscheiden sich von einem Verlauf, der eine Grenze überschritten hat. Eine automatische Anreicherung jenseits dieser Grenzen ist derzeit nicht verfügbar.

Checkout- und Danke-Seiten-Besuche ignorieren

Eine Rückkehr vom Zahlungsanbieter startet oft einen neuen Besuch auf Ihrer Danke- oder Checkout-Seite, der den Last-Touch-Anteil beanspruchen würde. Unter Settings → Exclusions → Revenue attribution only (Einstellungen → Ausschlüsse → Nur Umsatzattribution) fügen Admins und Eigentümer bis zu 20 Pfadregeln mit der Syntax der Traffic-Ausschlüsse hinzu (/thanks genau oder /checkout/* für ein Präfix). Besuche, die auf einem passenden Pfad einsteigen, werden aus den Kontakten der Bestellung entfernt, bevor Attributionsfenster und Modell angewendet werden; bleibt kein Kontakt übrig, ist die Bestellung Nicht zugeordnet. Nichts wird gelöscht: Traffic, Übersichtsseiten und jeder andere Bericht behalten diese Besuche, und die konvertierende Seite zeigt weiterhin den Pfad, den Ihre Integration geliefert hat. Regeln gelten nur für neue Berechnungen - die Berichte Umsatz und Übersicht starten eine neue Analyse, wenn sich eine Regel ändert, während bereits gespeicherte Ergebnisse, bereits berechnete geplante Berichte und API-Ergebnisse bleiben, wie sie waren; die nächste API-Anfrage rechnet mit den neuen Regeln. Bestellungen ohne Besuchsverlauf (ohne Besucher-ID gesendet oder älter als die abgeleitete Attribution) können nicht gefiltert werden; der Bericht zählt sie unter dem Regelhinweis.

Umsatzbericht

Öffnen Sie Revenue (Umsatz) in der Website-Seitenleiste. Seine Tabellen halten jeden Wert auf einer Zeile; auf schmalen Bildschirmen scrollt eine Tabelle innerhalb ihrer Karte seitwärts, und lange Kaufwege werden mit Auslassungspunkten gekürzt (zeigen Sie darauf für den vollständigen Pfad). Die Symbolleiste hat den Zeitraum plus die Attributionssteuerungen:

• Attribution model (Attributionsmodell): First touch rechnet dem ersten Besuch im Attributionsfenster zu, Last touch dem Besuch, der zur Bestellung führte, Linear teilt die Bestellung gleichmäßig auf ihre Besuche auf.
• Attribution lookback (Attributionsfenster): 7, 14, 30 oder 90 Tage vor der Bestellung. Ein Besuch, der älter als das Fenster ist, ist kein Kontakt. Vollständig gespeicherte Besuche werden für den Modellanteil verwendet, vorbehaltlich der Attributionslimits oben.
• Website-Standard: Die Seite öffnet mit dem gespeicherten Modell und Fenster der Website (Last Touch, 30 Tage, bis eines gespeichert ist). Weicht Ihre Auswahl ab, sehen Admins und Eigentümer Save as website default (Als Website-Standard speichern); der Standard wird mit der Umsatzzuordnung der Übersicht, der Analytics-API und MCP get_revenue sowie mit jedem Teammitglied geteilt. Eine Auswahl in der URL gewinnt für diese Ansicht immer. Overview: net / gross (Übersicht: netto / brutto) wählt, was die Übersichts-KPI zeigt (siehe KPIs); die Demo-Website kann diese Einstellungen nicht ändern.

Die obere Leiste zeigt Brutto, Erstattungen (mit der Erstattungsanzahl), Netto, attribuierten Umsatz, Attributionsrate und durchschnittliche Zeit bis zum Kauf. Attribution breakdown (Attributionsaufschlüsselung) hat fünf Tabs: Landing pages, Converting pages, First source, Last source und Sources (Landingpages, Konvertierende Seiten, Erste Quelle, Letzte Quelle und Quellen). Quellen rechnet jeder Quelle nach dem gewählten Modell zu, sodass bei Linear eine Bestellung einmal unter jeder ihrer Quellen mit einem Anteil ihres Nettobetrags erscheint. Revenue by product (Umsatz nach Produkt) listet Bestellungen, Umsatz, Anteil und den attribuierten Teil. Touches before purchase (Kontakte vor dem Kauf) gruppiert Bestellungen nach abgeleiteter Kontaktzahl. Purchase journeys (Kaufwege) gruppiert bezahlte Bestellungen nach der Einstiegsseite jedes Besuchs im Attributionsfenster, älteste zuerst (/ → /pricing → /checkout): aufeinanderfolgende Wiederholungen werden zusammengefasst, nur die letzten sechs Schritte bleiben hinter Auslassungspunkten erhalten, ein von Ihrer Integration gelieferter Pfad ersetzt den abgeleiteten Weg, und Bestellungen ohne Besuchsverlauf zeigen ihre Landingpage. Wege sind Einstiegsseiten von Besuchen, nicht jede angesehene Seite.

Orders (Bestellungen) listet die Bestellungen des Zeitraums, neueste zuerst, zwanzig auf einmal mit Load more (Mehr laden), nur in der Berichtswährung: Zeit (zeigen Sie darauf für den genauen Moment in Ihrer Anzeigezeitzone), Produkt mit den Badges Refunded (Erstattet) oder Partially refunded −amount (Teilweise erstattet), erste Quelle, Weg und Betrag nach dem gewählten Modell und Fenster. Bestellungen mit unvollständigem Verlauf zeigen Incomplete history (Unvollständiger Verlauf). Refunds (Erstattungen) listet jede Erstattung dieser Bestellungen - Erstattungszeit, Bestell-ID (oder Bestellzeit), Produkt, Erstattungs-ID und Betrag - ebenfalls zwanzig auf einmal; eine vollständige Erstattung, die vor der Einführung der Erstattungsbücher erfasst wurde, erscheint einmal als legacy. Erstattungen zählen immer im Zeitraum ihrer Bestellung, hier wie in den Summen. Betrachter können beide Listen lesen; Rohexporte bleiben unter Settings → Data.

Eine Änderung von Modell oder Fenster startet eine neue Analyse für denselben Zeitraum; bestehende Ergebnisse und gespeicherte Bestellungen werden nicht umgeschrieben.

Zeiträume vergleichen

Die Vergleichsschaltfläche neben dem Zeitraum bietet dieselben Optionen wie die Übersicht: Previous period, Previous week, Previous month, Previous quarter, Previous year, Custom range… und No comparison (siehe Zeiträume und Filter). Mit aktivem Vergleich zeigt jede KPI in der oberen Leiste ihre prozentuale Änderung gegenüber dem Vergleichsintervall statt ihrer Zahl: Brutto, Erstattungen, Netto, attribuierter Umsatz, Attributionsrate und Zeit bis zum Kauf. Ein Anstieg bei Erstattungen oder Zeit bis zum Kauf wird als Rückgang gezeigt. Previous period wird in derselben Analyse berechnet; andere Optionen starten eine zusätzliche Umsatzanalyse mit demselben Modell, Fenster und derselben Berichtswährung. Aufschlüsselungstabellen, Produkte, Kontakte, Wege, Bestellungen und Erstattungen bleiben Ansichten des aktuellen Zeitraums, und All time hat keinen Vergleich.

Attributionsübergabe

Ob ein Connector oder Ihr Server die Bestellung erfasst, die Verknüpfung zum Besuch ist die Besucher-ID. Mit einem Connector hängen Sie seean_visitor_id (und optional seean_landing_path, seean_converting_path, seean_campaign) aus window.seean.attribution() an die Checkout-Metadaten, benutzerdefinierten Daten, Warenkorbattribute oder Subscriber-Attribute des Anbieters, wie die Anbieteranleitung zeigt; Seean liest diese Schlüssel aus dem verifizierten Ereignis. Das öffentliche Tracking-Token autorisiert nie die Bestellaufnahme.

Für eine eigene Integration erfassen Sie window.seean?.attribution?.(), wenn verfügbar, bei der Checkout-Erstellung und übergeben nur die unterstützten Felder an Ihren Server. Speichern Sie sie mit der Checkout-/Bestellreferenz, damit das spätere verifizierte Zahlungsereignis sie nutzen kann. Der Helfer kann vor dem Laden fehlen oder keine Attribution liefern, wenn die Erfassung deaktiviert ist. Akzeptieren Sie in diesem Fall eine nicht zugeordnete Bestellung; erfinden Sie keine Besucher- oder Kampagnenwerte.

Warten Sie nach dem Laden des Trackers auf window.seean?.ready, bevor Sie die Attribution lesen. Dies endet nach dem ersten Erfassungsversuch oder seinem Timeout; es garantiert nicht, dass eine Besucher-ID existiert. Verwenden Sie es innerhalb Ihres asynchronen Checkout-Handlers und lassen Sie den Checkout ohne Attribution weiterlaufen. Jedes Anbieterbeispiel enthält das Warten.

Der Standard-Besucher-Hash ändert sich um Mitternacht UTC und ist auf eine Website begrenzt. Das 90-Tage-Fenster durchsucht Datensätze mit der erfassten Kennung; es verbindet nicht die verschiedenen Tages-Hashes dieses Besuchers. Bewahren Sie die Attribution zum Checkout-Zeitpunkt für verzögerte Zahlungs-Webhooks. Eine spätere Rückkehr an einem neuen UTC-Tag hat eine neue Identität, sodass mehrtägige Wege nicht rekonstruiert werden. Veraltete Bestellungen und gespeicherte Ergebnisse behalten ihre ursprünglichen Kennungen und Werte.

Halten Sie externe Bestellkennungen über Wiederholungen hinweg stabil. Leiten Sie wiederkehrende Zahlungen als die eigenen bezahlten Bestellungen weiter, die sie darstellen, und ordnen Sie jede Erstattung mit der Erstattungs-ID des Anbieters der ursprünglichen externen Bestell-ID zu. Ihre Integration muss die Ereignisreihenfolge und Duplikate des Anbieters berücksichtigen. Rechnen Sie Anbieterbeträge nur dann in die kleinste Einheit der Berichtswährung der Website um, wenn die Zahlung tatsächlich in dieser Währung belastet wurde; Seean lehnt andere Währungen ab, statt sie umzurechnen.

Integration prüfen

Nutzen Sie die Testmöglichkeiten Ihres Anbieters und, wo möglich, eine separate Seean-Testwebsite. Prüfen Sie eine bezahlte Bestellung, eine identische Wiederholung, eine Teilerstattung, eine vollständige Erstattung und eine Bestellung ohne Attribution. Vergleichen Sie den Umsatzbericht der Website mit den genauen Beträgen und der abgeleiteten Attribution. Eine erfolgreiche Tracker-Anfrage oder ein Besuch der Bestätigungsseite beweist nicht, dass die Bestellung aufgenommen wurde.

Integrationsreferenz

Folgen Sie Order API und Erstattungen für Payloads, Umgang mit Serverschlüsseln, Währungsregeln, Erstattungsregeln und Wiederholungsverhalten. Die Anbieterverfügbarkeit fasst zusammen, welche Anbieter einen nativen Connector haben.

Anbieteranleitungen

Jede Anleitung behandelt die Einrichtungsschritte des Anbieters, das Attributions-Snippet für seinen Checkout, was erfasst wird, Erstattungen, Währung, Prüfung und Grenzen.

Der erfasste Besucherverlauf wird einmal festgehalten, wenn eine neue Bestellung angenommen wird, entweder über die Order API oder einen unterstützten Anbieter-Connector. Ein vorübergehender Fehler bei der Verlaufssuche liefert eine wiederholbare Antwort; ein angenommenes Duplikat behält die ursprüngliche Attribution und den exakten Betrag. Siehe Order-API-Wiederholungen.

• Creem

  Connect Creem to Seean with the webhook secret, pass the visitor ID as checkout metadata and receive completed checkouts and refunds.

• Mollie

  Connect Mollie to Seean through signed next-generation webhooks, pass the visitor ID as payment metadata and receive paid payments and refunds.

• Paddle

  Connect Paddle to Seean with the notification secret key, pass the visitor ID as checkout custom data and receive completed transactions and approved refunds.

• Polar

  Connect Polar to Seean with the webhook secret, pass the visitor ID as checkout metadata and receive paid orders, renewals and refunds.

• RevenueCat

  Connect RevenueCat to Seean with the webhook authorization value, pass the visitor ID as Web Billing metadata or a subscriber attribute and receive purchases, renewals and refunds.

• Revolut

  Connect the Revolut Merchant API to Seean with the webhook signing secret and Merchant API secret key, pass the visitor ID as order metadata and receive completed orders.

• Shopify

  Connect a Shopify store to Seean with the webhook signing secret, write the visitor ID as a cart attribute and receive paid orders and refunds.

• Stripe

  Connect Stripe Checkout to Seean with the webhook signing secret, pass the visitor ID as session metadata and receive paid orders and refunds.

• Superwall

  Connect Superwall to Seean with the webhook signing secret, set the visitor ID as a user attribute and receive purchases and renewals.

• Whop

  Connect Whop to Seean with the webhook signing secret, pass the visitor ID as checkout metadata and receive successful payments and refunds.

Etwas unklar? Support kontaktieren.