--- title: "Mollie API: Webhook, SEPA-Mandat, iDEAL | JustAutomate" description: "Technische Ebene der Mollie-Anbindung: Webhook mit Statusabruf, Idempotenz, SEPA-Mandate, Rückerstattungen. Umsetzung in 2 bis 4 Wochen." url: "https://justautomate.ai/de/api/mollie/" lang: de --- Integration über Schnittstellen # Mollie API bezahlt gilt erst nach geprüftem Status Die technische Ebene der Zahlung: Zahlung anlegen, Käufer zur Methode weiterleiten, den Webhook mit der Payment-ID entgegennehmen und den Status bei Mollie abrufen, bevor etwas als bezahlt gilt. Dazu Idempotenz bei doppelt gelieferten Benachrichtigungen, Abgleich der Zahlung mit Bestellung und Rechnung, SEPA-Mandate und Rückerstattungen. Geprüft wird im Testmodus mit eigenen Schlüsseln. Kostenloses Erstgespräch [So läuft der Workshop ab](https://justautomate.ai/de/ki-beratung/) - 1 Quelle der Wahrheitüber den Zahlungsstatus entscheidet der Abruf bei Mollie über die Payment-ID, nicht die Rückkehr des Käufers auf die Dankeseite - 0 KartendatenKartennummer und Prüfziffer nimmt Mollie entgegen; durch Ihren Server und durch den Ablauf gehen Payment-ID, Betrag, Währung und Status - 2 bis 4 Wochenvom Workshop bis zur laufenden Integration, nachdem die Randfälle im Testmodus durchgespielt sind - 14 Tageso lange dauert es meist bis zur ersten laufenden Automatisierung, in der Regel die Rechnung nach der bestätigten Zahlung Das Problem ## Warum steht eine Bestellung auf offen, obwohl der Kunde bezahlt hat? Der Kunde zahlt per iDEAL in seiner Banking-App, sieht die Bestätigung der Bank und schließt den Tab, bevor er auf Ihre Seite zurückkommt. Im Shop steht die Bestellung weiter auf offen. Am nächsten Morgen vergleicht jemand die Umsätze im Mollie-Dashboard mit der Bestellliste und trägt die Zahlungen von Hand nach. Abends schreibt dieselbe Person die Rechnungen zu den Zahlungen des Tages. Die zweite Fassung desselben Problems läuft umgekehrt. Die Benachrichtigung kommt zweimal an, weil Ihr Server beim ersten Versuch nicht rechtzeitig geantwortet hat, und der Kunde bekommt zwei Rechnungen und zwei Mails mit dem Zugang. Die dritte Fassung ist die unangenehmste: jemand schickt eine Anfrage an Ihre Webhook-Adresse, die wie eine Zahlungsbestätigung aussieht, und die Anbindung glaubt sie und schließt die Bestellung ab. Die Reihenfolge der Schritte ist hier keine Geschmacksfrage. Die [Entwicklerdokumentation von Mollie](https://docs.mollie.com/) beschreibt den Webhook als reine Benachrichtigung: er trägt die Payment-ID und sonst nichts über den Ausgang. Den tatsächlichen Status holt die Anbindung selbst mit GET /v2/payments/{id}. Wer diesen zweiten Schritt weglässt, hält jede Anfrage an seine Adresse für eine Zahlung. - Der Kunde hat bezahlt, die Bestellung wartet, weil niemand die Zahlung nachgetragen hat - Jeden Morgen gleicht jemand das Zahlungs-Dashboard mit der Bestellliste ab - Eine doppelt gelieferte Benachrichtigung erzeugt eine zweite Rechnung und eine zweite Mail - Eine im Dashboard ausgelöste Rückerstattung hat keine Entsprechung in Bestellung und Gutschrift - Niemand kann sagen, auf welcher Grundlage eine Bestellung als bezahlt gilt Warum jetzt ## Warum lässt sich das heute in Wochen statt in einem Quartal anbinden? Mollie hat für alles eine REST-Schnittstelle, was früher im Dashboard erledigt wurde: Zahlung anlegen, Status prüfen, Bestellungen lesen, Mandate und wiederkehrende Zahlungen führen. Die Anmeldung läuft über einen API-Schlüssel im Bearer-Header, getrennt für Test und Produktivbetrieb. Auf einen Kontoauszug oder einen CSV-Export muss niemand mehr warten, um zu wissen, wer bezahlt hat. Die zweite Änderung liegt in der Automatisierungsschicht. Make hat ein eigenes Mollie-Modul, n8n bindet Mollie über den HTTP-Baustein an, und beide liefern Warteschlange, Wiederholung und Protokoll. Eine Benachrichtigung geht also nicht verloren, während Ihr Server gerade neu startet. Der Statusabruf und der Schlüssel für die Idempotenz müssen trotzdem dort stehen, denn kein Werkzeug erledigt sie von allein; erspart bleibt Ihnen nur ein eigenes Backend dafür. Die dritte Änderung ist der KI-Agent. Eine Anbindung trägt die Zahlung in die Bestellung ein, 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 Zahlungs-Dashboard. Was sich ändert ## Was bekommt ein Team, das Zahlungen heute von Hand prüft? - ### Zahlungsstatus ohne Rückfrage beim Kunden Der Webhook erreicht Ihre Adresse Sekunden nach der Zahlung, die Anbindung holt den Status über die Payment-ID und trägt die Zahlung in die Bestellung ein. Ob der Käufer den Tab geschlossen hat, spielt keine Rolle mehr. Quelle der Wahrheit ist der abgerufene Status, nicht die Rückkehr auf die Dankeseite - ### Eine gefälschte Bestätigung kommt nicht durch Aus dem Webhook nehmen wir ausschließlich die Payment-ID und fragen den Status bei Mollie ab. Betrag und Währung aus der Antwort vergleichen wir mit der Bestellung. Eine Anfrage mit einer unbekannten ID landet im Protokoll und nicht in den Bestellungen. Der Inhalt der Anfrage entscheidet nichts, entschieden wird nach dem abgerufenen Status - ### Ein doppelter Webhook erzeugt keine zweite Rechnung Jede Zahlung bekommt einen Schlüssel aus der Payment-ID von Mollie. Die zweite und dritte Benachrichtigung zu derselben Zahlung wird quittiert und bleibt folgenlos. Der Kunde erhält keine zwei Rechnungen und keine zwei Mails mit dem Zugang. Schlüssel für die Idempotenz aus der Payment-ID, Wiederholungen werden quittiert und übersprungen - ### Lokale Zahlarten aus einem Zugang iDEAL für die Niederlande, Bancontact für Belgien, SEPA-Lastschrift und Kauf auf Rechnung über Klarna für den deutschsprachigen Raum, TWINT für die Schweiz, dazu Kreditkarte und PayPal. Alle laufen über dieselbe Schnittstelle, Ihre Anbindung bekommt je Methode denselben Ablauf. Eine Anbindung für Benelux und DACH statt einer je Markt - ### SEPA-Mandat einmal, danach automatisch Der Kunde erteilt das Mandat einmal, danach bucht Mollie wiederkehrende Beträge über die Schnittstelle ab. Für Kunden mit Betreuungspauschale entfällt damit die monatliche Rechnung samt Zahlungserinnerung. Mandat und wiederkehrende Zahlung liegen bei Mollie, die Bestellung führt nur die Referenz - ### Rückerstattungen an einer Stelle Eine Rückerstattung ganz oder in Teilen lösen Sie aus der Bestellung aus, die Anbindung meldet sie bei Mollie an und stößt die Gutschrift zur Rechnung an. Der Kundendienst meldet sich nicht mehr im Zahlungs-Dashboard an, um 40 EUR für eine Position zurückzugeben. Teilrückerstattung an der Bestellung und in der Gutschrift, mit derselben Payment-ID Und bei Ihnen ## Was, wenn wir das Mollie-Plugin im Shop schon haben? Vier Sätze hören wir bei Zahlungen am häufigsten, und das antworten wir darauf. Kundendaten aus Bestellungen verarbeiten wir nach der [Verordnung 2016/679](https://eur-lex.europa.eu/legal-content/DE/TXT/?uri=CELEX:32016R0679): an den Ablauf gehen nur die Felder, die für Abgleich und Rechnung nötig sind. - Wir haben das Mollie-Plugin in Shopware, warum mehr? Wenn Sie über einen Shop verkaufen und die Rechnung aus demselben Shop kommt, genügt das Plugin, und wir sagen Ihnen das im Gespräch. Eine Anbindung über die Schnittstelle lohnt sich, wenn eine Zahlung eine Rechnung in sevDesk oder lexoffice, eine Stufe im CRM, einen Versandauftrag in Xentral und die Freigabe eines Zugangs nach sich ziehen soll, oder wenn der Verkauf über mehrere Kanäle läuft. - An der Zahlung im Produktivbetrieb wollen wir nichts anfassen. Tun wir auch nicht. Der Ablauf entsteht im Testmodus von Mollie mit eigenen Schlüsseln, die Sie im Dashboard unter Entwickler anlegen. Danach läuft er im Beobachtungsmodus neben Ihrem heutigen Weg und schreibt nur mit, was er tun würde. Umgeschaltet wird erst, wenn seine Entscheidungen mit dem übereinstimmen, was Sie im Dashboard sehen. - Bekommen Sie Zugriff auf die Kartendaten unserer Kunden? Nein. Kartennummer und Prüfziffer gibt der Käufer auf der Seite von Mollie ein. Durch Ihren Server und durch unseren Ablauf gehen Payment-ID, Betrag, Währung, Status und die Felder für die Rechnung. Das hält den Umfang der PCI-DSS-Anforderungen auf Ihrer Seite eng, und wir speichern und verarbeiten keine Kartendaten. - Wir verkaufen in mehreren Ländern und über Marktplätze. Dann gibt es mehr als eine Quelle der Wahrheit über Geld: Mollie für den Verkauf aus Ihrem Shop, die Abrechnung der Plattform für den Verkauf über den Marktplatz. Im Workshop legen wir fest, was womit abgeglichen wird und in welcher Währung die Bestellung geführt wird, damit dieselbe Zahlung nicht zweimal gezählt wird. Zahlungen Mollie, Testmodus und getrennte API-Schlüssel je Umgebung, iDEAL, Bancontact, SEPA-Lastschrift, Klarna, TWINT, Kreditkarte, PayPal Shops und Verkauf Shopware, JTL, Shopify, WooCommerce, eigene Shops über die Schnittstelle Rechnung und Buchhaltung sevDesk, lexoffice, DATEV, Xentral CRM HubSpot, Pipedrive, Salesforce Meldungen und Teamarbeit Slack, Microsoft Teams, Microsoft 365, Google Workspace Daten und Automatisierungsschicht BigQuery, Google Sheets, n8n, Make, Zapier, eigene Anbindungen über die Schnittstelle ## Situationen im Zahlungsverkehr und was die Anbindung damit macht Zahlungen sind einfach in der Fassung, in der alles gut geht. Die Arbeit entsteht in den Zeilen unten, deshalb schreiben wir sie im Workshop auf, bevor jemand den ersten Baustein des Ablaufs setzt. | Situation | Was die Anbindung tut | Was sie nicht tut | | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | | Webhook zu einer Zahlung | liest die Payment-ID, holt den Status bei Mollie, vergleicht Betrag und Währung und trägt die Zahlung in die Bestellung ein | hält den Inhalt der Anfrage nicht für einen Beleg über den Ausgang der Zahlung | | Käufer ist zurück, der Webhook fehlt | hält die Bestellung im Zustand „Zahlung läuft“ und wartet auf die Bestätigung | stellt keine Rechnung aus und gibt keinen Zugang zum Produkt frei | | Dieselbe Benachrichtigung kam zweimal | erkennt sie an der Payment-ID und beendet den Lauf ohne Wirkung | erzeugt keine zweite Rechnung und keine zweite Mail mit dem Zugang | | Betrag weicht von der Bestellung ab | schreibt die Zahlung mit und meldet die Abweichung zur Entscheidung durch einen Menschen | schließt die Bestellung nicht still ab und gleicht die Differenz nicht selbst aus | | Zahlung ohne eingegangene Benachrichtigung | fängt sie beim täglichen Abgleich mit Mollie ab und meldet sie mit Grund | wartet nicht auf den Anruf des Kunden, der bezahlt hat | | SEPA-Lastschrift geht zurück | setzt die Bestellung anhand des abgerufenen Status zurück und meldet den Fall an den Kundendienst | behandelt eine Lastschrift nicht schon bei der Einreichung als endgültig bezahlt | | Kartendaten des Käufers | verarbeitet Payment-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 Zugang am schwersten, beim Versandhandel die Zeile über Teilrückerstattungen. Die Bedeutung der Statuswerte prüfen wir vor der Umsetzung in der Dokumentation auf docs.mollie.com. Wie wir arbeiten ## Fünf Schritte vom Nachtragen von Hand bis zur Anbindung im Produktivbetrieb Erst der Prozess. Dann die Werkzeuge. Jeder Schritt endet mit etwas, das Sie beurteilen können, bevor Sie über den nächsten entscheiden. Bis zur Umschaltung rührt nichts an Ihrem produktiven Zahlungsweg. 1. ### Workshop Wir zerlegen den heutigen Weg des Geldes: vom Klick auf „Bezahlen“ bis zur Rechnung und zum Eintrag in der Buchhaltung. Wer erkennt eine Zahlung an und woran, wer sucht die fehlenden, wie viele Stunden kostet das in der Woche. Wir schreiben die Randfälle aus der Tabelle oben auf, denn im Zahlungsverkehr kosten genau sie die Zeit. 2. ### Entwurf des Ablaufs Wir legen Reihenfolge und Quelle der Wahrheit fest: Zahlung anlegen, Käufer weiterleiten, Webhook an Ihre Adresse, Status bei Mollie über die Payment-ID abrufen, erst danach Rechnung und Zugang. Dazu der Schlüssel für die Idempotenz, die Warteschlange für den Fall, dass Ihr System nicht erreichbar ist, und die Regel, wann ein Fall zu einem Menschen geht. 3. ### Testmodus Der Ablauf entsteht im Testmodus mit eigenen Schlüsseln aus dem Mollie-Dashboard, Zahlungen daraus tauchen auf keinem echten Konto auf. Wir spielen die Fälle durch, die niemand im Produktivbetrieb durchspielen will: Benachrichtigung zu einer unbekannten ID, dieselbe Benachrichtigung zweimal, gar keine Benachrichtigung, Teilrückerstattung, Zahlung nach dem Storno der Bestellung. 4. ### Beobachtungsmodus und Umschaltung Die Anbindung läuft neben dem heutigen Weg und schreibt nur mit, was sie tun würde. Wir vergleichen ihre Entscheidungen mit dem Stand im Dashboard und schalten um, wenn die Status übereinstimmen. Überwachung und eine Meldung über jede Benachrichtigung, die nicht verarbeitet werden konnte, gehen mit der Umschaltung live und nicht nach der ersten Störung. 5. ### Abgleich und Messung Der tägliche Abgleich stellt die Zahlungen bei Mollie den Bestellungen und Rechnungen gegenüber und listet die Abweichungen mit Grund. Nach 30 und nach 90 Tagen sehen wir auf eine Zahl: wie viele Zahlungen eine menschliche Hand gebraucht haben und warum. Diese Zahl sagt, ob die Anbindung trägt, und nicht der Umstand, dass sich niemand beschwert hat. Vorher und nachher ## Wie sich der Tag der Person ändert, die die Zahlungen im Blick hat ### Vorher - Morgens vergleicht sie das Zahlungs-Dashboard mit der Bestellliste und trägt Fehlendes nach - Sie nimmt den Anruf des Kunden entgegen, der bezahlt hat und dessen Bestellung steht - Die Rückerstattung macht sie im Dashboard, die Gutschrift getrennt davon, aus dem Gedächtnis - Die Rechnungen zu den Zahlungen des Tages schreibt sie abends, wenn Zeit dafür ist ### Nachher - Die Zahlung steht wenige Sekunden nach dem abgerufenen Status an der Bestellung - Abweichungen kommen als Liste mit Grund, bevor der Kunde zum Hörer greift - Die Rückerstattung löst sie aus der Bestellung aus, die Gutschrift läuft im selben Durchgang - Rechnung und Zugang gehen ohne Zutun eines Menschen an den Kunden Die ersten geprüften Zahlungen sehen Sie am Tag der Umschaltung. Wie viele Zahlungen noch von Hand abgeglichen werden müssen, beurteilen wir nach 30 und nach 90 Tagen, an Ihren Daten. Für die Person, die das beauftragt ## Was die Person davon hat, der der Onlineverkauf gehört 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 ihre Grundlage: Payment-ID, Betrag, Währung, abgerufener Status. Bei einem Streit mit dem Kunden oder bei einer Prüfung zeigen Sie den Eintrag und nicht das Gedächtnis eines Mitarbeiters. Der zweite Punkt wiegt im Gespräch mit der Buchhaltung und der Geschäftsführung mehr. Sie wissen, wie viele Zahlungen im Monat von Hand abgeglichen werden mussten und aus welchem Grund. Das ist eine Zahl, die sich senken lässt, und die Grundlage dafür, die Kosten je Transaktion überhaupt zu rechnen. - Jede anerkannte Zahlung trägt im Protokoll ihre Grundlage: ID, Betrag, Währung, Status - Kartennummer und Prüfziffer liegen weder in Ihren Systemen noch in unserem Ablauf - Abweichungen kommen aus einer Liste und nicht vom Kunden, der bezahlt hat und wartet - Bis zur Umschaltung beobachtet der neue Weg nur, der alte führt die Zahlungen Kosten ## Der Workshop hat einen offenen Preis, die Anbindung ein Angebot danach Der Workshop kostet **3.500 EUR netto pro Woche** und dauert 1 bis 7 Wochen. Bei Zahlungen genügt meistens eine Woche, zwei dann, wenn mehrere Verkaufskanäle oder mehrere Währungen im Spiel sind. Die Anbindung kalkulieren wir nach dem Workshop, denn der Umfang hängt daran, wie viele Systeme eine einzelne Zahlung sehen sollen: Shop, Lager, CRM, Rechnungsprogramm. Die Gebühr je Transaktion zahlen Sie direkt an Mollie, den Betrieb des Automatisierungswerkzeugs an dessen Anbieter, oder Sie zahlen ihn gar nicht, wenn der Ablauf auf Ihrer Infrastruktur steht. Ohne Aufschlag von uns auf das eine wie auf das andere. Läuft im Ablauf ein Sprachmodell mit, liegen die Kosten des Anbieters bei 0,005 bis 0,07 EUR pro Anfrage und werden ebenfalls direkt abgerechnet. - ### Workshop 3.500 EUR netto pro Woche, bei Zahlungen genügt meistens eine Woche Abgeschlossene Einheit. Endet mit dem beschriebenen Zahlungsweg und Regeln dafür, wann eine Zahlung als anerkannt gilt. - Karte des Geldwegs vom Klick auf „Bezahlen“ bis zum Eintrag in der Buchhaltung - Liste der Randfälle mit der Entscheidung, was in jedem einzelnen passiert - Empfehlung: Plugin im Shop, Automatisierungsschicht oder Anbindung über die Schnittstelle - Regeln für die Anerkennung einer Zahlung und Kennzahlen für die Messung nach 30 Tagen Mit dem Workshop beginnen - Am häufigsten gewählt ### Workshop und Anbindung Angebot nach dem Workshop der Umfang folgt aus der Zahl der Systeme, die eine Zahlung sehen sollen Die meistgewählte Variante. Eine laufende Anbindung 2 bis 4 Wochen nach dem Workshop, umgeschaltet nach dem Beobachtungsmodus. - Alles aus dem Workshop - Zahlung anlegen und Webhooks verarbeiten, mit Statusabruf über die Payment-ID - Idempotenz, Warteschlange und Wiederholung, damit keine Benachrichtigung verloren geht - Abgleich der Zahlungen mit Bestellungen und Rechnungen, täglicher Bericht der Abweichungen - Testmodus, getrennte Schlüssel, Beobachtungsmodus und Umschaltung mit Überwachung Gespräch zur Umsetzung vereinbaren - ### Zahlungen und KI-Agent Angebot nach dem Workshop für Teams, die mehrmals täglich nach Zahlungen fragen Alles aus der Anbindung und dazu BOND, der Firmen-KI-Agent, der Fragen zu Zahlungen und Rechnungen in normalen Sätzen beantwortet. - Alles aus der Anbindung - KI-Agent an Bestellungen, Zahlungen und das Rechnungsprogramm angebunden - Meldungen über Zahlung ohne Bestellung und Bestellung ohne Zahlung - Antwort in 5 bis 10 Sekunden, ohne Anmeldung im Zahlungs-Dashboard Nach dem Agenten fragen Der Workshop endet mit einem Dokument, das ohne uns Bestand hat: Zahlungsweg, Liste der Randfälle, Regeln für die Anerkennung einer Zahlung. Zeigt sich dabei, dass das Plugin in Ihrem Shop bereits leistet, was gebraucht wird, sagen wir das und zeigen, was in der Konfiguration zu ändern ist. Wir versprechen bei Zahlungen nicht, dass nie etwas auseinanderläuft. Wir versprechen, dass eine Abweichung am selben Tag sichtbar ist und einen Verantwortlichen hat. ## Häufige Fragen Was bedeutet eine Mollie-Anbindung über die Schnittstelle? Ihr Shop oder Ihr Backend legt die Zahlung über die REST-Schnittstelle an und leitet den Käufer zur Auswahl der Methode weiter. Nach der Zahlung schickt Mollie eine Benachrichtigung an die von Ihnen hinterlegte Adresse. Die Anbindung holt daraufhin den Status bei Mollie und löst erst dann aus, was nach der Zahlung passieren soll: Rechnung, Zugang zum Produkt, Stufe im CRM, Versandauftrag. Angemeldet wird sich über einen API-Schlüssel im Bearer-Header. Warum reicht die Rückkehr des Käufers auf die Dankeseite nicht? Weil die Rückkehr am Käufer hängt und die Benachrichtigung an Mollie. Der Kunde kann den Tab schließen, den Empfang verlieren oder in der Banking-App auf dem Handy zahlen und nie auf Ihre Seite zurückkommen. Die Benachrichtigung kommt in all diesen Fällen trotzdem, deshalb ist der daraufhin abgerufene Status die Quelle der Wahrheit und nicht die Weiterleitung im Browser. Warum darf man dem Inhalt des Webhooks nicht vertrauen? Weil die Adresse, an die Benachrichtigungen gehen, öffentlich erreichbar ist. Die Benachrichtigung von Mollie trägt ohnehin nur die Payment-ID und sagt nichts über den Ausgang der Zahlung. Der Status kommt aus einem eigenen Aufruf GET /v2/payments/{id} mit Ihrem Schlüssel, und den kann niemand von außen fälschen. Zusätzlich vergleichen wir Betrag und Währung aus der Antwort mit der Bestellung. Eine Anfrage mit unbekannter ID landet im Protokoll. Was passiert, wenn der Webhook zweimal ankommt? Jede Zahlung bekommt einen Schlüssel aus ihrer Payment-ID. Die erste Benachrichtigung löst die Folgen aus, die zweite und dritte werden quittiert und übersprungen. So bekommt der Kunde keine zwei Rechnungen, keine zwei Mails mit dem Zugang und keine zwei Reservierungen im Lager, auch wenn dasselbe Ereignis mehrfach geliefert wird. Eine Benachrichtigung, die Ihr Server nicht bestätigt, wird von Mollie erneut zugestellt, dafür steht auf unserer Seite eine Warteschlange. Wie testen Sie, ohne echte Zahlungen auszulösen? Im Testmodus von Mollie, mit eigenen Schlüsseln, die Sie im Dashboard unter Entwickler und API-Schlüssel anlegen. Zahlungen aus dem Testmodus erscheinen auf keinem echten Konto. Danach läuft der Ablauf im Beobachtungsmodus neben Ihrem heutigen Weg und schreibt nur mit, was er tun würde. In den Produktivbetrieb schalten wir, wenn seine Entscheidungen mit dem Stand im Dashboard übereinstimmen. Welche Zahlarten deckt Mollie in DACH und Benelux ab? Über dieselbe Schnittstelle laufen iDEAL für die Niederlande, Bancontact für Belgien, SEPA-Lastschrift, Kreditkarte, PayPal, Kauf auf Rechnung über Klarna und TWINT für die Schweiz. Für Ihre Anbindung ändert sich je Methode wenig, weil der Ablauf derselbe bleibt: Zahlung anlegen, weiterleiten, Benachrichtigung entgegennehmen, Status abrufen. Welche Methoden für Ihr Konto freigeschaltet sind, sehen Sie im Dashboard. Wie funktionieren SEPA-Lastschrift und wiederkehrende Zahlungen? Der Kunde erteilt einmal ein Mandat, das Mollie führt, danach legt die Anbindung die wiederkehrende Zahlung über die Schnittstelle an und liest deren Zahlungen aus. Für Betreuungspauschalen entfällt damit die monatliche Rechnung samt Erinnerung. Zu bedenken ist, dass eine Lastschrift nach der Buchung noch zurückgehen kann: die Bestellung setzen wir dann anhand des abgerufenen Status zurück und melden den Fall an den Kundendienst. Speichern Sie die Kartendaten unserer Kunden? Nein. Kartennummer und Prüfziffer gibt der Käufer auf der Seite von Mollie ein, sie gehen also weder durch Ihren Server noch durch unseren Ablauf. Wir verarbeiten Payment-ID, Betrag, Währung, Status und die Felder, die für die Rechnung nötig sind. Das hält den Umfang der PCI-DSS-Anforderungen auf Ihrer Seite eng, und darüber sprechen wir auch im Workshop. ## Sehen wir uns an, wo Ihre Zahlungen heute auseinanderlaufen Das kostenlose Erstgespräch dauert 30 Minuten. Sie erzählen, wie der Weg vom Klick auf „Bezahlen“ bis zur Rechnung aussieht und wer prüft, ob das Geld angekommen ist. Wir zeigen, was sich sofort anbinden lässt und wofür zuerst Bestellungen oder Rechnungsstellung geordnet werden müssen. Zugriff auf Ihr Zahlungs-Dashboard oder auf Schlüssel brauchen wir in diesem Schritt nicht. Wir führen höchstens zwei Umsetzungen gleichzeitig, damit bei jeder wirklich jemand sitzt. [Kostenloses Erstgespräch](https://justautomate.ai/de/kontakt/) **PS.** Wenn bei Ihnen in dieser Woche jemand von Hand geprüft hat, ob ein Kunde bezahlt hat, dann ist genau das der Punkt. Ein abgerufener Status 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 in der Regel 14 Tage danach. ## Verwandt - [Integrationen über Schnittstellen](https://justautomate.ai/de/api/) - [Stripe API](https://justautomate.ai/de/api/stripe/) - [sevDesk API](https://justautomate.ai/de/api/sevdesk/) - [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/