Dieser Artikel beschreibt die Änderungen der collana pay App, veröffentlicht am 15.09.2026. Die Änderungen sind in folgenden Versionen enthalten:

• Version 28.0.2609.1090
• Version 27.0.2609.1097
• Version 26.0.2609.1099

Fehlerbehebungen

Refunds und Credits: Belege auf vollständig erstattete Zahlungen oder mit abweichender Zahlungsform werden abgelehnt

Sobald der gesamte erfasste Betrag einer Zahlung erstattet oder gutgeschrieben war, wurde jede weitere Gutschrift oder Reklamation mit Verweis auf dieselbe collana pay Transaktion ohne Prüfung gebucht – ohne Logeintrag, ohne Fehlermeldung und ohne Erstattungsanfrage. Dasselbe galt für Gutschriften, deren Zahlungsform nicht zur referenzierten Transaktion passte.

Solche Belege werden jetzt bei Freigabe und Buchung abgelehnt:

• Eine Gutschrift oder Reklamation auf eine vollständig erstattete oder gutgeschriebene Zahlung bricht mit der Meldung Total Captured Amount Already Refunded ab. Refunds und Credits werden dabei zusammen gezählt.
• Eine Gutschrift oder Reklamation, deren collana pay Zahlungsform weder zur Einrichtungszeile noch zu Zahlungsanbieter und Zahlungsart noch zum Provider-Konto der referenzierten Transaktion gehört, wird abgelehnt. Die Meldung nennt beide Zahlungsformen und den Weg zur Korrektur des Belegs.
• Zahlungsformen desselben Anbieters mit derselben Zahlungsart bleiben austauschbar, ebenso Zahlungsformen mit demselben Provider-Konto.
• Belege, deren Transaktion manuell erstattet wird, werden nicht geprüft.
• Das erneute Buchen eines Belegs, dessen eigene Erstattung bereits erfolgreich war, sowie Erstattungen über mehrere Captures funktionieren weiterhin.

Um einen Beleg zu buchen, dessen Betrag dem Kunden bereits auf anderem Weg zurückgezahlt wurde, lässt sich das Feld Refund / Credit an der collana pay Transaktion auf Manually setzen. Der Beleg wird dann ohne Erstattungsanfrage gebucht.

Beide Prüfungen lassen sich über neue Publisher überspringen (siehe Abschnitt „Neue Publisher und Integrationsevents“).

Fehler „Kein Capture gefunden“: Aktion Transaktion anzeigen öffnet die richtige Transaktion

Schlägt das Buchen einer Retoure oder Gutschrift fehl, weil kein passendes Capture gefunden wird, bietet die Fehlermeldung die Aktion Transaktion anzeigen an. Bisher lief diese Aktion selbst auf einen Fehler, weil sie auf die Transaktion der gebuchten Gutschrift zeigte, die beim fehlgeschlagenen Buchen wieder verworfen wird.

• Die Aktion öffnet jetzt die Transaktion der Retoure bzw. Gutschrift, die gerade gebucht wird.
• Lässt sich keine Transaktion ermitteln, wird die Aktion nicht angeboten.

Rollencenter: Transaktionen erscheinen nicht mehr gleichzeitig in Wartend und Fehlgeschlagen

Wurde ein fehlgeschlagener collana pay Aufruf (z. B. Import, Status, Capture, Refund) erneut angestoßen, erschien die Transaktion gleichzeitig in der Kachel Wartend und in der Kachel Fehlgeschlagen.

Die Fehlgeschlagen-Kacheln berücksichtigen jetzt den letzten Logeintrag der jeweiligen Funktion:

• Steht dieser noch aus, erscheint die Transaktion nur in der Kachel Wartend.
• Schlägt der erneute Versuch wieder fehl, kehrt sie in die Fehlgeschlagen-Kachel zurück.
• Ist der erneute Versuch erfolgreich, verschwindet sie aus beiden Kacheln.
• Kachelzähler und Drilldown-Listen verhalten sich gleich.

Rollencenter: Kacheln unter Aktive Transaktionen öffnen genau die gezählten Logeinträge

Der Drilldown der Kacheln für fehlgeschlagene, wartende und Chargeback-Transaktionen öffnete bisher eine Liste von Transaktionen. Diese Liste zeigte die letzte Aktion und den Status der gesamten Transaktion. Dadurch konnte ein fehlgeschlagener Capture als Refund mit Status OK erscheinen, und eine Kachel Fehlgeschlagen schien Einträge anderer Funktionen zu enthalten.

Die Kacheln öffnen jetzt die Logeinträge selbst:

• Jede Zeile ist der Aufruf der jeweiligen Funktion mit eigenem Status, Statustext und bei fehlgeschlagenen Aufrufen der Meldung des Zahlungsdienstleisters.
• Kachelzähler und Drilldown-Liste sind immer identisch.
• Aus einer Zeile lassen sich der Beleg und die collana pay Transaktion direkt öffnen.
• Die Kachel Wartend zählt nur noch Einträge, die seit mehr als 30 Minuten ausstehen so wie im Tooltip beschrieben.

Statusabfrage: Fehlende Logeinträge werden aus der Notification wiederhergestellt

Wurde eine Statusabfrage an collana pay gesendet, deren Transaktionslog-Eintrag jedoch nicht gespeichert werden konnte (z. B. bei einem Abbruch der Kette Import → Status unter hoher Last), scheiterte die Status-Notification bisher mit der Meldung Unknown transaction log no.

Das Verhalten wurde angepasst:

• Der Logeintrag wird aus der Notification wiederhergestellt, als vom externen System erstellt gekennzeichnet und der Transaktion zugeordnet, von der die Abfrage gestartet wurde.
• Die Notification wird anschließend regulär verarbeitet: Reservierungen und Captures werden protokolliert und der Auftrag wird wie gewohnt freigegeben.
• Notifications zu Transaktionen ohne Logeinträge werden nicht mehr als verwaist verworfen.

Statusbenachrichtigungen: Erneute Verarbeitung wird dem ausstehenden Logeintrag zugeordnet

Wird die Verarbeitung einer Statusbenachrichtigung nach dem ersten Schritt unterbrochen, verarbeitet die Aufgabenwarteschlange sie im Status Wartend erneut. Dabei wurde die Benachrichtigung bisher mit der Meldung No matching transaction found - notification not applied. abgebrochen, obwohl Transaktion und Logeintrag vorhanden waren. Der STATUS-Logeintrag blieb dann dauerhaft ausstehend, und auch eine erneute Statusanfrage endete mit demselben Ergebnis.

Das Verhalten wurde angepasst:

• Die erneute Verarbeitung ordnet die Benachrichtigung jetzt genau wie die erste Verarbeitung direkt dem mitgelieferten Logeintrag zu.
• Die Prüfung auf archivierte oder verwaiste Transaktionen greift nur noch, wenn kein Logeintrag ermittelt werden kann.

No Cart: Betragsprüfung vor dem Positionsupdate berücksichtigt externe Gutscheine

Die Betragsprüfung, die das automatische Update der Transaktionspositionen bei No-Cart-Transaktionen absichert, verwendet jetzt dieselben Verkaufszeilen wie die Update-Prüfung selbst. Ohne eine entsprechende Erweiterung ändert sich nichts.

Simulation: Reservierungsverlängerung lässt sich jetzt testen

Die Reservierungsverlängerung für eine Zahlungsform mit Kommunikation Simulation schlug bisher mit der Meldung Ungültiges Format der GUID-Zeichenfolge fehl, da die Simulation für den RESERVE-Request keine Antwort lieferte.

Der RESERVE-Request wird jetzt wie die anderen Requests simuliert. Zur Auswahl stehen:

• eine erfolgreiche Antwort mit einem neuen Ablaufdatum (Standard: 30 Tage später)
• eine abgelehnte Antwort
• ein Verbindungsfehler

Bei erfolgreicher Verlängerung wird die alte Reservierung als storniert markiert, die neue wird zur aktiven Reservierung. Existiert keine Prepare-Interaktion, erscheint eine verständliche Fehlermeldung.

Verbesserungen & Erweiterungen

Provider Account Mapping berücksichtigt die Payment Country

Die Suche nach einem passenden Provider Account berücksichtigt jetzt auch das Feld Payment Country im Provider Account Mapping. Dadurch lassen sich mehrere Provider Accounts je Währung und Provider Reference für unterschiedliche Länder einrichten.

• Das Land wird abhängig von der Finanzbuchhaltungs-Einrichtung aus der Verkaufs- oder Rechnungsadresse des Belegs ermittelt.
• Ein Mapping ohne Land dient als Fallback für beliebige Länder.
• Ein Mapping ohne Provider Reference dient als Fallback für beliebige Referenzen und erfüllt jetzt auch die Referenzprüfung bei der Freigabe.

Neue Publisher und Integrationsevents

OnBeforeBlockRefundForFullyRefundedTransaction

• Codeunit: PAY WebServ Communication HVE
• Ermöglicht das Überspringen der Prüfung, die Gutschriften und Reklamationen auf vollständig erstattete oder gutgeschriebene Zahlungen ablehnt.

OnBeforePaymentMethodMismatchError

• Codeunit: PAY General Handling HVE
• Ermöglicht das Überspringen der Prüfung, die Gutschriften und Reklamationen mit nicht passender Zahlungsform ablehnt.