--- title: "Stripe API: Webhook, Abgleich, Rechnung | JustAutomate" description: "Stripe-Webhook mit Signaturprüfung, Idempotenz und Abgleich von Zahlung, Bestellung und Rechnung. Test im Testmodus, Umsetzung in 2 bis 4 Wochen." url: "https://justautomate.ai/de/api/stripe/" lang: de --- Integration über Schnittstellen # Stripe API: Integration und Automatisierung ohne manuelle Prüfung, wer bezahlt hat Die technische Schicht Ihrer Zahlungen: Zahlung anlegen, Käufer zu Stripe schicken, das Ereignis auf Ihrem Endpunkt entgegennehmen und die Signatur prüfen, bevor irgendetwas als bezahlt gilt. Dazu Idempotenz bei doppelten Ereignissen, Abgleich der Zahlung mit Bestellung und Rechnung, Abonnements und Rückerstattungen. Getestet wird im Stripe-Testmodus mit eigenen Schlüsseln, nicht in Ihrem Produktivbetrieb. Kostenloses Erstgespräch [So läuft der Workshop](https://justautomate.ai/de/ki-beratung/) - 1 Quelle der Wahrheitüber den Zahlungsstatus entscheidet das geprüfte Stripe-Ereignis, nicht die Rückkehr des Käufers auf die Danke-Seite - 0 KartendatenKartennummer und Prüfziffer gibt der Käufer bei Stripe ein; wir speichern und verarbeiten sie nicht - 2 bis 4 Wochenvom Workshop bis zur laufenden Integration, nach den Randfällen im Stripe-Testmodus - 14 Tageso lange dauert es meist bis zur ersten laufenden Automatisierung, in der Regel die Rechnung nach bestätigter Zahlung Das Problem ## Warum steht eine Bestellung auf offen, obwohl das Geld da ist? Ein Kunde zahlt per SEPA-Lastschrift oder Karte, sieht die Bestätigung von Stripe und schließt den Tab, bevor er auf Ihre Danke-Seite zurückkommt. Im Shop hängt die Bestellung als unbezahlt. Am nächsten Morgen vergleicht jemand die Stripe-Auszahlung mit der Bestellliste und trägt die Zahlungen von Hand nach. Abends schreibt dieselbe Person die Rechnungen zu den Zahlungen des Tages. Die zweite Variante ist der umgekehrte Fall. Das Ereignis kommt zweimal an, weil Ihr Endpunkt beim ersten Versuch nicht rechtzeitig geantwortet hat, und der Kunde bekommt zwei Rechnungen und zwei Zugangsmails. Die dritte Variante ist die teuerste: jemand schickt eine Anfrage an Ihre öffentliche Webhook-Adresse, die wie eine Zahlungsbestätigung aussieht, und die Integration glaubt sie. Die Reihenfolge der Schritte ist hier keine Geschmacksfrage. Die [Stripe-Dokumentation zu Webhooks](https://docs.stripe.com/webhooks) beschreibt zwei getrennte Dinge: das Ereignis auf Ihrer Adresse und die Prüfung der Signatur aus dem Header gegen das Signing Secret des Endpunkts. Eine Integration, die nur das Erste tut, hält jede Anfrage für eine Zahlung. - Der Kunde hat bezahlt, die Bestellung wartet, weil niemand die Zahlung nachgetragen hat - Jemand vergleicht jeden Tag die Stripe-Auszahlung mit den Bestellungen und sucht Differenzen - Ein doppeltes Ereignis erzeugt eine zweite Rechnung und eine zweite Mail an den Kunden - Eine im Stripe-Dashboard ausgelöste Rückerstattung hat kein Gegenstück in Bestellung und Gutschrift - Niemand kann sagen, auf welcher Grundlage eine Bestellung als bezahlt gilt Warum jetzt ## Was sich geändert hat, seit Zahlungen über Schnittstellen laufen Stripe bietet heute für alles eine Schnittstelle, was früher im Dashboard passierte: Zahlung anlegen, Status abfragen, Rechnung finalisieren, Abonnement ändern, Rückerstattung auslösen, Auszahlungen und Gebühren auslesen. Sie warten nicht mehr auf einen Kontoauszug oder einen CSV-Export, um zu wissen, wer bezahlt hat. Die zweite Veränderung liegt in der Automatisierungsschicht. n8n, Make oder eine eigene Anbindung liefern Warteschlange, Wiederholung und Protokoll, damit ein Ereignis nicht verloren geht, während Ihr System gerade neu startet. Signaturprüfung und Idempotenzschlüssel müssen trotzdem dort stehen, denn die nimmt Ihnen kein Werkzeug ab. Der Unterschied ist, dass Sie dafür kein eigenes Backend mehr schreiben. Die dritte Veränderung ist der KI-Agent. Eine Integration trägt die Zahlung an der Bestellung nach, beantwortet der Buchhaltung aber nicht die Frage, welche Zahlungen von gestern noch keine Rechnung haben. BOND, unser Firmen-KI-Agent, antwortet darauf aus Ihren Unternehmensdaten in 5 bis 10 Sekunden, ohne Anmeldung im Stripe-Dashboard. Was sich ändert ## Was bekommt ein Team, das heute Zahlungen von Hand prüft? - ### Zahlungsstatus ohne Rückfrage beim Kunden Das Ereignis erreicht Ihren Endpunkt Sekunden nach der Zahlung, die Integration prüft die Signatur und trägt die Zahlung an der Bestellung nach. Ob der Käufer den Tab geschlossen hat, spielt keine Rolle mehr. Quelle der Wahrheit ist das geprüfte Ereignis, nicht die Rückkehr des Käufers - ### Eine gefälschte Bestätigung kommt nicht durch Bevor etwas als bezahlt gilt, prüfen wir die Signatur aus dem Stripe-Header gegen das Signing Secret des Endpunkts und vergleichen Betrag und Währung mit der Bestellung. Eine Anfrage ohne gültige Signatur landet im Protokoll, nicht in den Bestellungen. Signatur, Betrag und Währung geprüft, jede Ablehnung protokolliert - ### Ein doppeltes Ereignis erzeugt keine zweite Rechnung Jede Zahlung bekommt einen Schlüssel aus der Stripe-Ereignis-ID. Das zweite und dritte Mal desselben Ereignisses bleibt ohne Wirkung. Der Kunde erhält keine zwei Rechnungen und keine zwei Zugangsmails. Idempotenzschlüssel aus der Ereignis-ID, Wiederholung quittiert und übersprungen - ### Rechnung wenige Sekunden nach der bestätigten Zahlung Nach erfolgreicher Prüfung legt die Integration die Rechnung in sevDesk, lexoffice oder DATEV an, schickt sie an den Käufer und schiebt die Bestellung im Shop und im CRM weiter. Nicht nach der Weiterleitung, sondern nach der bestätigten Zahlung. Rechnung nach geprüftem Ereignis, nicht nach der Rückkehr des Käufers - ### Fehlende Zahlungen sehen Sie am selben Tag Der tägliche Abgleich stellt die Stripe-Vorgänge den Bestellungen und Rechnungen gegenüber und listet Abweichungen mit Begründung. Eine Zahlung ohne zugestelltes Ereignis fällt aus der Liste, nicht aus einem Anruf. Drei Arten von Abweichung: Zahlung ohne Bestellung, Bestellung ohne Zahlung, abweichender Betrag - ### Abonnements und Rückerstattungen aus einer Oberfläche Fehlgeschlagene Abbuchungen bei Stripe Billing lösen eine festgelegte Folge von Erinnerungen aus, und eine volle oder teilweise Rückerstattung starten Sie aus der Bestellung heraus. Der Support meldet sich nicht mehr im Stripe-Dashboard an, um 40 EUR für eine Position zurückzuzahlen. Teilrückerstattung an Bestellung und Gutschrift, mit derselben Stripe-ID Und bei Ihnen ## Was, wenn Stripe im Shop schon angebunden ist? Vier Sätze hören wir bei Zahlungen am häufigsten, und das antworten wir darauf. - Wir haben das Stripe-Plugin in Shopware, wozu mehr? Wenn Sie über einen Shop verkaufen und die Rechnung aus demselben Shop kommt, reicht das Plugin, und genau das sagen wir Ihnen im Erstgespräch. Eine Anbindung über die Schnittstelle lohnt sich dann, wenn eine Zahlung eine Rechnung in einem separaten Programm, eine Stufe im CRM, einen Produktzugang und eine Reservierung im Lager auslösen soll, oder wenn der Verkauf über mehrere Kanäle läuft. - Wir wollen an den Zahlungen im Produktivbetrieb nichts anfassen. Tun wir auch nicht. Der Ablauf entsteht mit eigenen Schlüsseln im Stripe-Testmodus, läuft danach im Beobachtungsmodus neben dem bestehenden Weg und schreibt nur mit, was er tun würde. Umgestellt wird erst, wenn seine Entscheidungen mit dem übereinstimmen, was Sie im Stripe-Dashboard sehen. - Bekommen Sie Zugriff auf die Kartendaten unserer Kunden? Nein. Kartennummer und Prüfziffer gibt der Käufer auf der Seite von Stripe ein. Über Ihren Server und über den Ablauf laufen nur die Zahlungs-ID, Betrag, Währung, Status und die Daten für die Rechnung. Damit bleibt der PCI-DSS-Umfang auf Ihrer Seite eng, und wir speichern und verarbeiten keine Kartendaten. - Wir verkaufen in mehreren Währungen und über Marktplätze. Dann gibt es mehr als eine Quelle der Wahrheit über das Geld: Stripe für den Verkauf aus Ihrem Shop, die Abrechnung der Plattform für den Verkauf über den Marktplatz. Im Workshop legen wir fest, was mit was abgeglichen wird und in welcher Währung die Bestellung gespeichert wird, damit dieselbe Zahlung nicht zweimal gezählt wird. Zahlungen Stripe, Testmodus und getrennte Schlüssel je Umgebung, Mollie als zweiter Anbieter Shop und Verkauf Shopware, Shopify, WooCommerce, JTL, Xentral Rechnung und Buchhaltung sevDesk, lexoffice, DATEV, SAP Business One CRM HubSpot, Pipedrive, Salesforce, Microsoft Dynamics Benachrichtigung und Teamarbeit Slack, Microsoft Teams, Microsoft 365, Google Workspace Daten und Automatisierung BigQuery, Google Sheets, n8n, Make, Zapier, eigene Anbindungen ## Situationen im Zahlungsverkehr und was die Integration damit macht Zahlungen sind einfach in der Variante, in der alles gut geht. Die Arbeit erzeugen die Zeilen unten, deshalb schreiben wir sie im Workshop auf, bevor jemand den ersten Schritt baut. | Situation | Was die Integration tut | Was sie nicht tut | | --------------------------------------- | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------ | | Ereignis über eine erfolgreiche Zahlung | prüft die Signatur, gleicht Betrag und Währung mit der Bestellung ab, trägt die Zahlung nach | hält keine Anfrage für eine Zahlung, nur weil sie an der Webhook-Adresse ankam | | Käufer ist zurück, das Ereignis fehlt | hält die Bestellung im Zustand Zahlung offen und wartet auf die Bestätigung | stellt keine Rechnung aus und schickt keinen Produktzugang | | Dasselbe Ereignis kam zweimal an | erkennt es an der Ereignis-ID und beendet ohne Wirkung | erzeugt keine zweite Rechnung und keine zweite Zugangsmail | | Betrag weicht von der Bestellung ab | verbucht die Zahlung und meldet die Abweichung zur Entscheidung | schließt die Bestellung nicht still und gleicht die Differenz nicht aus | | Zahlung ohne zugestelltes Ereignis | findet sie im täglichen Abgleich und meldet sie mit Begründung | wartet nicht auf den Anruf des Kunden, der bezahlt hat | | Volle oder teilweise Rückerstattung | verbucht die Rückerstattung an der Bestellung und startet die Gutschrift | zahlt kein Geld zurück ohne Bestätigung auf Ihrer Seite | | Kartendaten des Käufers | verarbeitet Zahlungs-ID, Betrag, Währung und Status | speichert weder Kartennummer noch Prüfziffer | Die Zeilen sind ein Ausgangspunkt. Welche davon bei Ihnen wirklich vorkommen, zeigt der Workshop: bei digitalen Produkten wiegt die Zeile über den Produktzugang am schwersten, im Warenversand die Zeile über Teilrückerstattungen. Wie wir arbeiten ## Fünf Schritte vom manuellen Nachtragen zur Integration im Betrieb Jeder Schritt endet mit etwas, das Sie beurteilen können, bevor Sie über den nächsten entscheiden. Bis zur Umstellung rührt nichts Ihren produktiven Zahlungsweg an. 1. ### Workshop Wir zerlegen den heutigen Weg des Geldes: vom Klick auf Bezahlen bis zur Rechnung und zum Eintrag in der Buchhaltung. Wer erklärt eine Zahlung für gültig und auf welcher Grundlage, wer sucht die fehlenden, wie viele Stunden kostet das pro Woche. Wir schreiben die Randfälle aus der Tabelle oben auf, denn bei Zahlungen kosten genau die Zeit. 2. ### Entwurf des Ablaufs Wir legen Reihenfolge und Quelle der Wahrheit fest: Zahlung anlegen, Käufer zu Stripe, Ereignis auf Ihrem Endpunkt, Signaturprüfung, erst danach Rechnung und Produktzugang. Dazu Idempotenzschlüssel, Warteschlange für den Fall, dass Ihr System nicht erreichbar ist, und die Regel, wann ein Fall an einen Menschen geht. 3. ### Stripe-Testmodus Der Ablauf entsteht mit getrennten Schlüsseln im Testmodus, mit den Testkarten aus der Dokumentation, und die Stripe CLI leitet die Ereignisse lokal weiter. Wir gehen die Fälle durch, die niemand im Produktivbetrieb durchgehen will: manipulierter Betrag, dasselbe Ereignis zweimal, fehlendes Ereignis, Teilrückerstattung, Zahlung nach Stornierung. 4. ### Beobachtungsmodus und Umstellung Die Integration läuft neben dem bestehenden Weg und schreibt nur mit, was sie tun würde. Wir vergleichen ihre Entscheidungen mit dem Stand im Stripe-Dashboard und stellen um, wenn die Status übereinstimmen. Überwachung und ein Alarm für ein nicht verarbeitetes Ereignis kommen mit der Umstellung, nicht nach dem ersten Ausfall. 5. ### Abgleich und Messung Der tägliche Abgleich stellt Stripe-Vorgänge, Auszahlungen und Gebühren den Bestellungen und Rechnungen gegenüber und listet Abweichungen mit Begründung. Nach 30 und nach 90 Tagen sehen wir auf eine Zahl: wie viele Zahlungen eine menschliche Hand gebraucht haben und warum. Vorher und nachher ## Wie sich der Tag der Person ändert, die auf die Zahlungen schaut ### Vorher - Vergleicht morgens die Stripe-Auszahlung mit der Bestellliste und trägt fehlende Zahlungen nach - Nimmt den Anruf eines Kunden entgegen, der bezahlt hat und dessen Bestellung steht - Löst die Rückerstattung im Stripe-Dashboard aus, die Gutschrift getrennt davon, aus dem Gedächtnis - Schreibt die Rechnungen zu den Zahlungen des Tages abends, wenn Zeit dafür ist ### Nachher - Die Zahlung steht wenige Sekunden nach dem geprüften Ereignis an der Bestellung - Abweichungen kommen als Liste mit Begründung, bevor der Kunde anruft - Die Rückerstattung startet aus der Bestellung, die Gutschrift läuft im selben Durchlauf - Rechnung und Produktzugang gehen ohne einen Menschen an den Kunden Die ersten geprüften Zahlungen sehen Sie am Tag der Umstellung. Wie viele Zahlungen noch von Hand abgeglichen werden, beurteilen wir nach 30 und nach 90 Tagen, auf Ihren Daten. Für die Person, die das beauftragt ## Was die Geschäftsführung davon hat Die Frage, ob dieser Kunde bezahlt hat, kommt nicht mehr bei Menschen an. Der Zahlungsstatus hat eine Quelle und ein Datum, und jede anerkannte Zahlung hinterlässt im Protokoll die Grundlage: Zahlungs-ID, Betrag, Währung, Ergebnis der Signaturprüfung. Bei einem Streit mit dem Kunden oder bei einer Prüfung zeigen Sie den Eintrag, nicht das Gedächtnis eines Mitarbeiters. Der zweite Punkt wiegt im Gespräch mit Buchhaltung und Beirat schwerer. Sie wissen, wie viele Zahlungen im Monat einen manuellen Abgleich gebraucht haben und aus welchem Grund. Das ist eine Zahl, die sich senken lässt, und die Grundlage dafür, die Bearbeitungskosten je Transaktion zu rechnen. - Jede anerkannte Zahlung hat im Protokoll ihre Grundlage: ID, Betrag, Währung, Signatur - Kartennummer und Prüfziffer liegen weder in Ihren Systemen noch in unserem Ablauf - Abweichungen kommen aus einer Liste, nicht vom Kunden, der bezahlt hat und wartet - Bis zur Umstellung beobachtet der neue Weg nur, der alte bearbeitet die Zahlungen Kosten ## Der Workshop hat einen offenen Preis, die Umsetzung ein Angebot danach Der Prozess-Workshop kostet **3.500 EUR netto pro Woche**. Bei Zahlungen genügt meist eine Woche, zwei dann, wenn mehrere Verkaufskanäle oder mehrere Währungen im Spiel sind. Die Umsetzung kalkulieren wir nach dem Workshop, weil der Umfang davon abhängt, wie viele Systeme eine einzelne Zahlung sehen sollen: Shop, Lager, CRM, Rechnungsprogramm. Die Transaktionsgebühr zahlen Sie an Stripe, die Kosten der Automatisierungsschicht an deren Anbieter, oder gar nicht, wenn die Schicht auf Ihrer Infrastruktur läuft. Kommt ein KI-Agent dazu, liegen die Modellkosten beim Anbieter bei 0,005 bis 0,07 EUR pro Anfrage. Ohne Aufschlag von uns auf das eine oder das andere. - ### Prozess-Workshop 3.500 EUR netto pro Woche, bei Zahlungen meist eine bis zwei Wochen Abgeschlossene Einheit. Endet mit dem beschriebenen Zahlungsweg und Regeln, wann eine Zahlung als gültig gilt. - Karte des Geldwegs vom Klick auf Bezahlen bis zum Eintrag in der Buchhaltung - Liste der Randfälle mit Entscheidung, was in jedem Fall passiert - Empfehlung: Plugin im Shop, Automatisierungsschicht oder eigene Anbindung - Regeln zur Anerkennung von Zahlungen und Kennzahlen für die Messung nach 30 Tagen Mit dem Workshop starten - Am häufigsten gewählt ### Workshop und Umsetzung Angebot nach dem Workshop der Umfang folgt aus der Zahl der Systeme, die die Zahlung sehen sollen Die meistgewählte Variante. Laufende Integration in 2 bis 4 Wochen nach dem Workshop, umgestellt nach dem Beobachtungsmodus. - Alles aus dem Workshop - Zahlung anlegen und Ereignisse verarbeiten, mit Signaturprüfung - Idempotenz, Warteschlange und Wiederholung, damit kein Ereignis verloren geht - Abgleich von Zahlungen mit Bestellungen und Rechnungen, täglicher Abweichungsbericht - Testmodus, getrennte Schlüssel, Beobachtungsmodus und Umstellung mit Überwachung Über die Umsetzung sprechen - ### Zahlungen und KI-Agent Angebot nach dem Workshop für Teams, die mehrmals täglich nach Zahlungen fragen Alles aus der Umsetzung, dazu BOND, der Fragen zu Zahlungen und Rechnungen in normalen Sätzen beantwortet. - Alles aus der Umsetzung der Integration - KI-Agent verbunden mit Bestellungen, Stripe und dem Rechnungsprogramm - Alarm bei Zahlung ohne Bestellung und bei Bestellung ohne Zahlung - Antworten in 5 bis 10 Sekunden, ohne Anmeldung im Stripe-Dashboard Nach dem KI-Agenten fragen Der Workshop endet mit einem Dokument, das ohne uns Bestand hat: Zahlungsweg, Liste der Randfälle, Regeln zur Anerkennung einer Zahlung. Wenn dabei herauskommt, dass Ihr vorhandenes Plugin bereits leistet, was nötig ist, sagen wir das und zeigen, was in der Konfiguration zu ändern ist. Bei Zahlungen versprechen wir nicht, dass nie etwas auseinanderläuft. Wir versprechen, dass eine Abweichung am selben Tag sichtbar ist und einen Verantwortlichen hat. ## Häufige Fragen Was ist eine Stripe-Integration über die Schnittstelle? Das ist die Verbindung von Stripe mit Ihren Systemen ohne Anmeldung im Dashboard. Ihr Shop oder Ihr Backend legt die Zahlung über die REST-Schnittstelle an und schickt den Käufer zur Bezahlseite. Nach der Zahlung erreicht ein Ereignis Ihren Endpunkt. Die Integration prüft dessen Signatur und startet erst dann, was nach der Zahlung passieren soll: Rechnung, Produktzugang, Stufenwechsel im CRM. Warum ist das Webhook-Ereignis wichtiger als die Rückkehr des Kunden auf die Seite? Weil die Rückkehr vom Käufer abhängt und das Ereignis von Stripe. Der Kunde kann den Tab schließen, das Netz verlieren oder in der Banking-App bezahlen und nie auf die Danke-Seite zurückkommen. Das Ereignis kommt in diesen Fällen trotzdem an, deshalb ist es die Quelle der Wahrheit über den Status, nach geprüfter Signatur. Warum muss die Signatur des Webhooks geprüft werden? Weil die Adresse, an die Stripe die Ereignisse schickt, öffentlich erreichbar ist. Ohne Prüfung könnte jeder, der sie errät, eine gefälschte Zahlungsbestätigung schicken und eine Bestellung ohne Geld abschließen. Stripe signiert jedes Ereignis mit dem Signing Secret des Endpunkts, und wir vergleichen zusätzlich Betrag und Währung mit der Bestellung. Was passiert, wenn der Kunde bezahlt hat und das Ereignis nicht ankommt? Stripe wiederholt die Zustellung, wenn Ihr Endpunkt nicht mit einem Erfolgscode antwortet. Auf unserer Seite steht eine Warteschlange, die Verarbeitung wird also verschoben statt verworfen. Eine Zahlung, deren Ereignis überhaupt nicht ankommt, findet der tägliche Abgleich mit den Stripe-Vorgängen und meldet sie als Abweichung mit Begründung zur Entscheidung. Wie gehen Sie mit doppelten Ereignissen um? Jede Zahlung bekommt einen Schlüssel aus der Stripe-Ereignis-ID. Das erste Ereignis löst die Wirkung aus, das zweite und dritte werden quittiert und übersprungen. Für Anfragen in Richtung Stripe nutzen wir den Idempotenzschlüssel aus der Stripe-Referenz zur Schnittstelle, damit auch eine wiederholte Anfrage nur einmal wirkt. Testen Sie an echten Zahlungen? Nein. Der Ablauf entsteht im Stripe-Testmodus, mit getrennten Schlüsseln und den Testkarten aus der Dokumentation, und die Stripe CLI leitet die Ereignisse an die lokale Umgebung weiter. Danach läuft er im Beobachtungsmodus neben dem bestehenden Weg und schreibt nur mit. Umgestellt wird, wenn seine Entscheidungen mit dem Stand im Dashboard übereinstimmen. Speichern Sie die Kartendaten unserer Kunden? Nein. Kartennummer und Prüfziffer gibt der Käufer auf der Seite von Stripe ein, sie laufen also weder über Ihren Server noch über unseren Ablauf. Wir verarbeiten Zahlungs-ID, Betrag, Währung, Status und die Daten für die Rechnung. Das hält den PCI-DSS-Umfang auf Ihrer Seite eng. Die Verarbeitung personenbezogener Daten regeln wir nach der Verordnung 2016/679. Wie läuft die automatische Rechnung und die Rückerstattung? Nach erfolgreicher Prüfung legt die Integration die Rechnung in sevDesk, lexoffice oder DATEV mit den Daten aus der Bestellung an und schickt sie an den Käufer. Eine volle oder teilweise Rückerstattung starten Sie aus der Bestellung: die Integration verbucht sie bei Stripe und stösst die Gutschrift mit derselben Zahlungs-ID an. Die Auszahlung selbst läuft nie ohne Bestätigung auf Ihrer Seite. ## Sehen wir nach, wo Ihre Zahlungen heute auseinanderlaufen Das kostenlose Erstgespräch dauert 30 Minuten. Sie beschreiben den Weg vom Klick auf Bezahlen bis zur Rechnung und wer prüft, ob das Geld angekommen ist. Wir sagen, was sich sofort verbinden lässt und was zuerst Ordnung in Bestellungen oder Rechnungsstellung braucht. Zugang zu Ihrem Stripe-Konto oder zu Schlüsseln brauchen wir dafür nicht. Wir führen höchstens 2 Umsetzungen gleichzeitig, damit bei jeder wirklich jemand sitzt. [Kostenloses Erstgespräch](https://justautomate.ai/de/kontakt/) **PS.** Wenn diese Woche jemand bei Ihnen von Hand geprüft hat, ob ein Kunde bezahlt hat, ist das genau dieses Problem. Ein geprüftes Stripe-Ereignis nimmt das vom Menschen und hinterlässt einen Eintrag, mit dem Sie jede anerkannte Zahlung belegen. Damit beginnt der Workshop, und die erste Automatisierung läuft meist 14 Tage danach. ## Verwandt - [Alle Schnittstellen im Überblick](https://justautomate.ai/de/api/) - [sevDesk API](https://justautomate.ai/de/api/sevdesk/) - [lexoffice API](https://justautomate.ai/de/api/lexoffice/) - [Shopware API](https://justautomate.ai/de/api/shopware/) - [Prozessautomatisierung](https://justautomate.ai/de/prozessautomatisierung/) - [KI-Agent für Unternehmen](https://justautomate.ai/de/ki-agent/) --- **JustAutomate** · Kontakt: contact@justautomate.ai · Formular: https://justautomate.ai/de/kontakt/