> For the complete documentation index, see [llms.txt](https://one-loop.gitbook.io/help/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://one-loop.gitbook.io/help/plattform/one-loop-plattform/automatisierung/workflows/zahlungsereignisse-in-workflows-nutzen.md).

# Zahlungsereignisse in Workflows nutzen

Richte bestätigte Workflow-Auslöser für wiederkehrende Zahlungen und Rückerstattungen ein, grenze sie mit Status- und Produktfiltern ein und teste jeden Pfad vor der Aktivierung.

## Was diese Anleitung zuverlässig abdeckt

Diese Anleitung beschreibt drei bestätigte Zahlungsereignisse für Workflows:

| Auslöser                   | Wann er startet                                                                                                    | Wofür er geeignet ist                                                                                               |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------- |
| **Zahlung eingegangen**    | Eine passende Zahlung wird erfasst. Ohne Statusfilter reagiert der Auslöser sowohl auf Erfolg als auch auf Fehler. | Bestätigung, interne Prüfung oder eine Folgeaufgabe nach einer Zahlung aus Bestellformular, Rechnung oder Kalender. |
| **Wiederkehrende Zahlung** | Eine Vereinbarung wird angelegt, wechselt aus einer Testphase in den aktiven Zustand oder wird beendet.            | Interne Vorbereitung, Begrüßung nach Aktivierung oder eine Klärung nach Beendigung.                                 |
| **Rückerstattung**         | Ein Rückerstattungsversuch wird verarbeitet.                                                                       | Erfolg und Fehler getrennt behandeln, interne Prüfungen anlegen und passende Nachrichten vorbereiten.               |

> **Wichtig:** Ein Workflow ist eine Folge von Regeln. Er ersetzt weder die Prüfung im Zahlungsbereich noch die Entscheidung, ob eine Rückerstattung oder weitere Kommunikation fachlich richtig ist.

## Voraussetzungen vor dem Einrichten

Kläre vor dem Bau diese Punkte:

1. **Zahlungsanbindung:** Der gewünschte Vorgang muss über eine im Standort verbundene Zahlungsanbindung abgewickelt werden.
2. **Zweck:** Soll das Team informiert werden, soll eine Aufgabe entstehen oder soll eine Nachricht vorbereitet werden?
3. **Zuständigkeit:** Eine Person prüft die tatsächliche Zahlung oder Rückerstattung, bevor daraus wichtige weitere Schritte entstehen.
4. **Filter:** Lege vorher fest, welches Produkt, welcher Status, welcher Betrag oder welche Quelle wirklich gemeint ist.
5. **Testfall:** Verwende einen eindeutig gekennzeichneten Testkontakt und einen sicheren Testvorgang.

Für diese beiden Auslöser sind bestätigte Zahlungsanbindungen mit **Stripe**, **Authorize.net** und **NMI** bekannt. Bei **PayPal** ist nur das Anlegen einer wiederkehrenden Zahlung bestätigt; spätere Änderungen dieser Vereinbarung solltest du dort nicht als automatischen Auslöser voraussetzen.

## Zahlung eingegangen: auf passende Zahlungen reagieren

Der Auslöser **Zahlung eingegangen** startet einen Workflow, wenn eine Zahlung im Standort erfasst wird. Er kann Zahlungen aus Bestellformularen, Rechnungen und Kalendern unterscheiden. Ohne einen Statusfilter startet er laut Quelle sowohl bei erfolgreichen als auch bei fehlgeschlagenen Vorgängen.

Das ist sinnvoll, wenn dein Team nach einer gelungenen Zahlung eine Aufgabe oder eine Bestätigung vorbereiten soll – oder wenn ein Fehlerfall sofort intern geprüft werden muss.

### Auslöser einrichten

1. Öffne **Automatisierungen** > **Workflows** und erstelle einen neuen Ablauf.
2. Wähle bei den Zahlungs-Auslösern **Zahlung eingegangen**.
3. Gib dem Ablauf einen eindeutigen Namen, zum Beispiel **„Zahlung eingegangen – interne Prüfung“**.
4. Klicke auf **Filter hinzufügen** und wähle zuerst die **Quelle**.
5. Ergänze bei Bedarf einen Unterfilter. Bei Bestellformularen kann dieser zum Beispiel zwischen ein- und zweistufigem Formular oder einem nachgelagerten Zusatzangebot unterscheiden.
6. Ergänze einen Statusfilter, wenn der Ablauf nur bei Erfolg oder nur bei Fehler starten soll.
7. Speichere den Auslöser, ergänze die Folgeaktionen und teste den Ablauf vor der Aktivierung.

Beginne mit Quelle und Status. Weitere Filter für Produkt, Kalender oder Seite ergänzt du erst, wenn der einfache Test zuverlässig funktioniert.

### Erfolg und Fehler in getrennte Wege leiten

Nach dem Auslöser kannst du eine **Wenn/Dann-Verzweigung** einfügen. Die sichtbare Auswahl erlaubt unter anderem Bedingungen für Produkt, Website oder Funnel, Kalender, Quelle und Zahlungsstatus.

Ein sicherer Aufbau ist:

* **Erfolgreich:** Interne Aufgabe erstellen oder eine vorbereitete Bestätigung versenden.
* **Fehlgeschlagen:** Nur das zuständige Team informieren und die Transaktion prüfen.
* **Kein passender Zweig:** Keine Nachricht an die betroffene Person senden, bevor die Ursache geklärt ist.

So verhinderst du, dass eine Bestätigung bei einem fehlgeschlagenen Vorgang verschickt wird.

### Angaben in Folgeaktionen verwenden

Sobald dieser Auslöser eingerichtet ist, stehen in Folgeaktionen dynamische Angaben zur Zahlung bereit. Die Quelle nennt unter anderem:

* Name, E-Mail-Adresse und Telefonnummer des Kontakts,
* Rechnungsname, Rechnungsnummer, Ausstellungs- und Fälligkeitsdatum sowie Rechnungslink,
* Transaktionskennung, Zahlungsstatus, Zahlungsdienst und Zahlungsart.

Verwende nur Angaben, die für die jeweilige Nachricht oder Aufgabe nötig sind. Prüfe sie mit einem Testkontakt, bevor sie an Kundinnen oder Kunden gehen.

### Praxisbeispiel: Fehlerhafte Kalenderzahlung prüfen

Ein Team möchte bei einer fehlgeschlagenen Zahlung für eine Terminbuchung sofort informiert werden. Es erstellt den Auslöser **Zahlung eingegangen**, wählt als Quelle den Kalender und als Status **fehlgeschlagen**. Als Folgeaktion erstellt es eine interne Aufgabe mit Kontaktname, Terminbezug und Transaktionsstatus. Ein Testvorgang zeigt anschließend, ob nur der vorgesehene Fehlerfall den Workflow startet.

## Wiederkehrende Zahlung: auf wichtige Statuswechsel reagieren

Der Auslöser **Wiederkehrende Zahlung** ist für Veränderungen im Lebenszyklus einer laufenden Vereinbarung gedacht. Er startet bei drei bestätigten Ereignissen:

* eine wiederkehrende Zahlung wird für einen Kontakt angelegt,
* eine Testphase wird aktiv,
* eine Vereinbarung wird beendet.

Das macht ihn geeignet, wenn ein Team zum Beispiel beim aktiven Start eine interne Aufgabe benötigt oder bei einer Beendigung die weitere Betreuung prüfen soll.

### So planst du den Workflow

1. Öffne den Workflow-Editor und lege einen neuen Ablauf an.
2. Gib dem Ablauf einen eindeutigen Namen, zum Beispiel **„Wiederkehrende Zahlung aktiv – interne Prüfung“**.
3. Wähle den Auslöser **Wiederkehrende Zahlung**.
4. Begrenze den Auslöser bei Bedarf mit einem Status- oder Produktfilter.
5. Ergänze die Folgeaktionen.
6. Speichere den Entwurf.
7. Teste den Ablauf mit einem sicheren Testfall.
8. Aktiviere ihn erst nach erfolgreicher Kontrolle.

### Filter richtig verwenden

Mit Filtern verhinderst du, dass ein Workflow bei jeder wiederkehrenden Zahlung startet.

| Filter                     | Wann er sinnvoll ist                                        | Kontrollfrage                                                 |
| -------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------- |
| **Status**                 | Nur ein bestimmter Wechsel soll reagieren.                  | Reagiert der Ablauf wirklich nur auf den gewünschten Zustand? |
| **Produkt**                | Der Ablauf gilt nur für ein bestimmtes Angebot.             | Ist dieses Produkt eindeutig ausgewählt?                      |
| **Eigene Zahlungsangaben** | Ihr habt einen belegten, einheitlich gepflegten Zusatzwert. | Wird der Wert beim Test tatsächlich am Ereignis übergeben?    |

Beginne mit einem einzigen Filter und ergänze weitere erst nach einem Test. Zu viele Bedingungen machen einen Workflow schnell so eng, dass er nicht mehr startet.

### Praxisbeispiel: Aktivierung nach Testphase prüfen

Ein Team möchte nach dem Ende einer Testphase nicht sofort automatisch umfangreiche Folgeaktionen auslösen.

1. Es erstellt einen Workflow für den Wechsel in den aktiven Zustand.
2. Es begrenzt ihn auf das passende Produkt.
3. Als erste Aktion wird eine interne Aufgabe erstellt.
4. Die zuständige Person prüft Zahlungsbezug und Kontakt.
5. Erst danach wird die vorgesehene weitere Betreuung gestartet.
6. Das Team testet den Ablauf mit einem Testkontakt, bevor der Workflow aktiv wird.

So bleibt eine fachliche Kontrolle erhalten, obwohl die Information automatisch beim Team ankommt.

## Rückerstattung: Erfolg und Fehler trennen

Der Auslöser **Rückerstattung** startet, wenn ein Rückerstattungsversuch verarbeitet wird. Er kann danach unterscheiden, ob der Versuch erfolgreich oder fehlgeschlagen war, ob es sich um eine vollständige oder teilweise Rückerstattung handelt und welcher Betrag oder welche Quelle betroffen ist.

Nutze diesen Auslöser vor allem für eine kontrollierte interne Nachbearbeitung. Eine Nachricht an die betroffene Person sollte erst nach einer klaren Prüfung des Ergebnisstatus erfolgen.

### So richtest du ihn ein

1. Öffne den Workflow-Editor und erstelle einen neuen Ablauf.
2. Benenne ihn eindeutig, zum Beispiel **„Rückerstattung erfolgreich – interne Prüfung“**.
3. Wähle den Auslöser **Rückerstattung**.
4. Ergänze nur die Filter, die für diesen Ablauf nötig sind.
5. Speichere den Auslöser.
6. Ergänze die gewünschten Folgeaktionen.
7. Teste einen sicheren Fall.
8. Aktiviere den Workflow erst nach der Kontrolle im Ausführungsverlauf.

### Verfügbare Filtergruppen

| Filter     | Bedeutung                                                | Beispiel für einen sicheren Einsatz                                                  |
| ---------- | -------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| **Status** | Unterscheidet Erfolg und Fehler.                         | Bei Erfolg wird eine interne Aufgabe zur Abschlussprüfung erstellt.                  |
| **Betrag** | Grenzt nach Höhe der Rückerstattung ein.                 | Ab einem intern festgelegten Betrag wird zusätzlich eine zweite Prüfung angefordert. |
| **Art**    | Unterscheidet vollständige und teilweise Rückerstattung. | Bei einer Teilrückerstattung wird eine andere interne Information erstellt.          |
| **Quelle** | Bezieht den Entstehungsweg ein.                          | Nur Vorgänge aus einer festgelegten Quelle laufen in diesen Ablauf.                  |

Mehrere Filter gelten gemeinsam. Wähle daher zuerst den Status und ergänze nur dann weitere Bedingungen, wenn sie im Test eindeutig funktionieren.

### Auslöser nur bei einer Rückerstattung im Standort

Der Workflow startet nur, wenn die Rückerstattung über den vorgesehenen Zahlungsablauf im eigenen Standort ausgelöst wird. Eine Rückerstattung, die ausschließlich direkt bei einem externen Zahlungsdienst veranlasst wird, erzeugt laut Quelle kein Workflow-Ereignis.

Das ist wichtig für deine Kommunikation: Versprich keine automatische Bestätigung, wenn der Vorgang außerhalb des Standorts ausgeführt wurde. Prüfe in diesem Fall die Transaktion und informiere die betroffene Person über den abgestimmten manuellen Weg.

Jeder einzelne Rückerstattungsversuch ist ein eigenes Ereignis. Werden für denselben Kontakt mehrere Rückerstattungen ausgelöst, kann der Workflow daher mehrfach starten. Lege die Folgeaktion so an, dass sie jeden Vorgang eindeutig zuordnet, statt eine frühere Aufgabe oder Nachricht blind zu überschreiben.

### Filter und Folgeaktion passend kombinieren

Für eine kundenbezogene Bestätigung verwendest du den Filter **Status = erfolgreich**. Für einen fehlgeschlagenen Versuch baust du einen getrennten Pfad mit **Status = fehlgeschlagen** und einer internen Aufgabe. So wird eine Erfolgsmeldung nicht bei einem fehlgeschlagenen Vorgang vorbereitet.

Als Herkunftsarten sind unter anderem Termine, Zahlungslinks, Rechnungen und manuell erfasste Vorgänge bestätigt. Kombiniere diese Auswahl bei Bedarf mit **Art = vollständig** oder **Art = teilweise**. Beginne mit einem einzigen klaren Filter und ergänze weitere nur, wenn dein Test den gewünschten Ablauf zeigt.

In E-Mails, Aufgaben und internen Hinweisen kannst du die zum Rückerstattungsereignis verfügbaren dynamischen Angaben aus dem Bereich für Zahlungen verwenden. Prüfe im Test, ob Vorgangskennung, Ergebnis, Art und Betrag tatsächlich aus dem konkreten Ereignis stammen. Fehlt eine Angabe, entfernst du sie aus der Nachricht statt einen unklaren Platzhalter zu versenden.

### Praxisbeispiel: Zwei sichere Wege

Ein Team möchte nach einer erfolgreichen Teilrückerstattung eine kurze Bestätigung vorbereiten und bei einem Fehler sofort intern nachfassen:

1. Es erstellt zwei getrennte Wege nach dem Auslöser **Rückerstattung**.
2. Der erste Weg filtert auf **erfolgreich** und **teilweise**. Er nutzt nur geprüfte Angaben aus dem konkreten Vorgang für eine sachliche Bestätigung.
3. Der zweite Weg filtert auf **fehlgeschlagen**. Er erstellt eine interne Aufgabe mit Kontakt, Ergebnis und Vorgangskennung.
4. Das Team testet beide Fälle mit einem Testkontakt.
5. Anschließend prüft es im Ausführungsverlauf, ob jeder Versuch genau einen passenden Weg gestartet hat.

Damit bleibt eine fehlgeschlagene Rückerstattung eine interne Prüfaufgabe und wird nicht versehentlich als erfolgreiche Bestätigung behandelt.

## Folgeaktionen bewusst wählen

Nach einem bestätigten Ereignis kann der Workflow zum Beispiel:

* eine interne Aufgabe für die zuständige Person erstellen,
* eine interne E-Mail senden,
* eine interne Notiz oder Kennzeichnung setzen,
* mit einer Wenn/Dann-Verzweigung Erfolg und Fehler in getrennte Wege leiten,
* verfügbare Zahlungsangaben in einer internen Nachricht bereitstellen.

### Zahlungsangaben in Folgeaktionen auswählen

Bei einer wiederkehrenden Zahlung kann die sichtbare Auswahl unter anderem Herkunft, Währungssymbol und Währungscode, Zwischensumme, Nachlass, Steueranteil, Gesamtsumme, Erstellzeitpunkt, Gutschein-Code sowie Kennung und Status der Vereinbarung bereitstellen. Bei einer Rückerstattung stehen zusätzlich zur Herkunft insbesondere Vorgangskennung, Kennung der Rückerstattung, Rückerstattungsbetrag, Status und Art zur Auswahl.

Verwende nur Angaben, die dein Team im jeweiligen Folge-Schritt wirklich braucht. Nicht jede Angabe ist in jedem Ereignis gefüllt. Prüfe deshalb eine interne Nachricht mit einem Testkontakt, bevor sie an eine betroffene Person geht. Besonders Betrag, Produkt und Ergebnisstatus müssen zum konkreten Vorgang passen.

## Test: Der sichere Ablauf vor der Aktivierung

Teste jeden Workflow vollständig, statt nur zu prüfen, ob der Auslöser gespeichert werden kann.

1. Notiere den Workflownamen, die Filter und das erwartete Ergebnis.
2. Aktiviere nur den Workflow, den du testen möchtest.
3. Führe mit dem Testkontakt einen passenden, sicheren Vorgang aus.
4. Öffne den **Ausführungsverlauf**.
5. Prüfe, ob der richtige Kontakt gestartet ist.
6. Vergleiche Produkt, Status, Betrag und Quelle mit den gesetzten Filtern.
7. Prüfe jede Folgeaktion: Aufgabe, interne Nachricht, Kennzeichnung oder Verzweigung.
8. Korrigiere bei einer Abweichung zuerst die Filter.
9. Wiederhole den Test nach jeder Änderung.

Für Rückerstattungen solltest du mindestens einen Erfolgs- und einen Fehlerfall getrennt testen. So vermeidest du, dass eine Erfolgsmeldung bei einem fehlgeschlagenen Vorgang vorbereitet wird.

## Häufige Probleme und ihre Lösung

### Der Workflow startet nicht

Prüfe, ob der Workflow aktiv ist, der richtige Auslöser gewählt wurde und die Zahlungsanbindung verbunden ist. Kontrolliere dann jeden Filter gegen den tatsächlichen Testvorgang. Entferne zum Eingrenzen vorübergehend nicht benötigte Filter und teste erneut.

### Der falsche Vorgang startet den Workflow

Die Filter sind zu allgemein. Begrenze den Ablauf zuerst über Status oder Produkt. Füge weitere Einschränkungen nur hinzu, wenn ein Test zeigt, dass sie die richtigen Ereignisse zuverlässig trennen.

### Eine Nachricht enthält unpassende Zahlungsangaben

Prüfe die verwendeten dynamischen Angaben mit dem Testkontakt. Stelle sicher, dass sie im jeweiligen Ereignis vorhanden sind und dass der Workflow nur bei dem vorgesehenen Status startet.

### Eine Rückerstattung ist fehlgeschlagen

Verwende für einen Fehlerfall einen getrennten Weg. Informiere zunächst das zuständige Team und prüfe den Vorgang im Zahlungsbereich. Eine Bestätigung an die betroffene Person sollte erst folgen, wenn der Erfolg eindeutig feststeht.

### Bei PayPal fehlt eine erwartete Folgeaktion

Für PayPal ist in diesem Funktionsumfang nur das Anlegen einer wiederkehrenden Zahlung bestätigt. Plane spätere Statuswechsel dort nicht als automatischen Ablauf ein, ohne sie mit einem eigenen Test belegt zu haben.

## Klare Grenzen dieser Anleitung

Diese Anleitung beschreibt nur die hier bestätigten Auslöser für wiederkehrende Zahlungen und Rückerstattungen. Sie ersetzt keine Prüfung von Zahlungsvorgängen, keine individuelle Rechts- oder Steuerberatung und keine Vorgabe darüber, wann eine Rückerstattung erfolgen soll.