Der Zahlungslink, der die Rechnung schließt: Monobank-Acquiring im CRM
Eine Rechnung ist verschickt, der Kunde antwortet „Wie kann ich zahlen?“, und dann beginnt die Suche: Bankdaten, ein Screenshot, ein Blick ins Konto, eine Notiz im CRM. In Firmspace lässt sich aus dem Rechnungsfenster ein Zahlungslink über das eigene Acquiring-Konto der Firma erzeugen; die Bank schließt die Rechnung, wenn das Geld tatsächlich ankommt. Interessant ist nicht der Knopf, sondern die Kette der Prüfungen zwischen dem Klick und dem Status „bezahlt“.
Der Link entsteht an der Rechnung, nicht in einem separaten Zahlungsmodul. Finanzen → Rechnungen → Zahlungslink bietet nur die Anbieter an, die die Firma verbunden hat. Im ukrainischen Markt sind das monobank, LiqPay, WayForPay oder Krypto-Acquiring, in Usbekistan Payme und Click. Ist kein Anbieter verbunden, sagt das Fenster das, statt einen toten Link zu erzeugen. Das Geld geht auf das eigene Händlerkonto der Firma; Firmspace hält es nicht und leitet es nicht weiter.
Der Betrag ist der offene Rest, nicht unbedingt die gesamte Rechnung. Hat der Kunde bereits angezahlt, wird der Link über Brutto minus bezahlten Betrag erzeugt; eine bereits gedeckte Rechnung wird abgelehnt. Die Währung der Rechnung wandert in den Link. Bei monobank rechnet das CRM den Betrag in Kopeken um und ordnet UAH, EUR und USD den Währungscodes des Anbieters zu; bei einer anderen Währung lohnt der Blick vor dem Versand.
Der Link lässt sich kopieren oder direkt in eine bestehende Unterhaltung mit dem Kunden in Telegram, Viber oder WhatsApp schicken. Das Fenster listet nur Unterhaltungen, die es schon gibt, weil Messenger einem Unternehmen nicht erlauben, jemandem zuerst zu schreiben, der noch nie geschrieben hat. Das ist eine Grenze der Kanäle, nicht der Rechnung. Der Kunde bekommt eine normale Nachricht mit der URL und zahlt auf der Seite des Anbieters; Kartendaten laufen nicht durch das CRM.
Die Rückleitung ins CRM ist kein Zahlungsbeweis. Der Beweis ist der Webhook, den der Anbieter an eine URL schickt, die an den Integrationsschlüssel der Firma gebunden ist. Bei monobank ist die Anfrage mit dem privaten Schlüssel des Händlers signiert; das CRM holt den passenden öffentlichen Schlüssel bei monobank und prüft die ECDSA-Signatur über den unveränderten Body. Eine Anfrage mit falscher oder fehlender Signatur wird mit 403 abgewiesen. Ohne diese Prüfung könnte jeder ein JSON schicken, in dem „bezahlt“ steht.
Status werden wörtlich gelesen. Nur success wird zur Zahlung. failure oder reversed werden als gescheiterter Status gelesen; processing und hold sind keins von beidem: Das CRM bestätigt den Empfang und ändert nichts. Das ist der Unterschied zwischen einer Kartenreservierung und Geld, das angekommen ist; ein CRM, das eine Reservierung als Umsatz behandelt, ist schlechter als eines, das wartet. Der Webhook antwortet schnell und hängt nicht am Browser-Tab, in dem der Link entstanden ist.
Anbieter wiederholen Zustellungen, deshalb ist die Route idempotent. Sie hasht den rohen Benachrichtigungsbody und speichert diesen Fingerabdruck zusammen mit Anbieter und Firma; eine zweite Zustellung derselben Bytes trifft den eindeutigen Schlüssel und wird bestätigt, ohne den Betrag erneut zu addieren. Teilzahlungen sammeln sich in paidAmount, und die Rechnung wird erst bezahlt, wenn die Summe den Gesamtbetrag erreicht. Eine Zahlung ist ein Faktum mit Datum und lässt sich nicht in einen geschlossenen Zeitraum buchen: Die Route antwortet mit 423, der Monat bleibt gesperrt.
Eine vollständige Zahlung löst die üblichen Folgen aus, jede in einem eigenen Schritt, damit ein Fehler an einer Stelle das Geld nicht zurücknimmt: ein Audit-Eintrag, eine Zahlung im Aktivitätsverlauf des Kunden, ein Automationsereignis invoice_paid (oder invoice_partial_paid), eine Benachrichtigung in der App. Gehört die Rechnung zu einem Auftrag, wechselt der Auftrag auf bezahlt. Gehört sie zu einem Deal und ist keine weitere Rechnung dieses Deals offen, kann der Deal automatisch gewonnen werden, sofern die Firma diese Regel nicht abgeschaltet hat. Ist Checkbox verbunden und die Autofiskalisierung an, entsteht bei Kartenzahlung zusätzlich der fiskalische Beleg.
Der KI-Assistent steht auf beiden Seiten dieser Kette, aber nicht auf jeder Stufe. Er kann eine Rechnung als Entwurf anlegen, per E-Mail versenden, ein Fälligkeitsdatum ändern, eine Rechnung als bezahlt markieren und beantworten, ob eine Rechnung noch offen ist. Für den Zahlungslink hat er kein Werkzeug: Der bleibt eine bewusste Handlung im Rechnungsfenster, weil der Link eine kaufmännische Entscheidung darüber ist, wie der Kunde zahlt. Und wenn der Acquiring-Webhook die Rechnung bereits geschlossen hat, wird eine erneute Markierung abgelehnt: Die Rechnung ist nicht mehr offen.
Die ehrlichen Grenzen gehören dazu. Der Link braucht ein verbundenes Acquiring-Konto mit funktionierenden Händler-Zugangsdaten; ein abgelehnter Token stoppt die Erzeugung, bevor ein Link existiert. Der Checkout ist auf Hrywnja, Euro und US-Dollar ausgelegt, eine Rechnung in anderer Währung braucht eine Prüfung statt einer Annahme. Die Zahlung beweist sich durch die Signatur des Anbieters, nicht durch den Screenshot des Kunden. Eine Rückerstattung oder Stornierung ist ein eigenes Ereignis: Diese Route liest den Status des Anbieters und schreibt die Rechnung nicht um; die Geldseite wird dort bearbeitet, wo die Rückerstattung tatsächlich passiert.
Was sich ändert, ist die Kette kleiner manueller Schritte. Der Manager muss nicht mehr die Banking-App beobachten, um eine Rechnung als bezahlt zu markieren; der Kunde zahlt auf einer Seite, die Betrag und Referenz schon kennt. Der Assistent beantwortet weiterhin die Fragen rund um die Zahlung, und das Audit-Log zeigt, wer was getan hat. Der Link ist kein Versprechen, dass jeder Kunde zahlt, und dieser Artikel behauptet das auch nicht; er entfernt eine Stelle, an der Geld und Aufzeichnung sonst auseinanderlaufen.