Unkomplizierte Integration in Deinen Checkout-Prozess!

Transaktion

Unter einer Transaktion verstehen wir den Rahmen für einen einzelnen Zahlungsvorgang mit lynck. Der eindeutige Bezeichner einer lynck Transaktion ist die orderID. Um eine möglichst einfache Beziehung zwischen Bestellung und Zahlung herzustellen, verwenden diejenigen Plugins, bei denen die Bestellnummer des Shopsystems rechtzeitig bekannt ist, diese Bestellnummer auch als orderID. In einigen Shopsystemen wird die Bestellnummer jedoch erst nach der Auswahl der Zahlungsart vergeben. In diesen Fällen wird die orderID generisch vergeben und die Verknüpfung zur Bestellung wird über einen Datenbankverweis hergestellt.

Zusätzliche OrderID (merchantReference)

Die zusätzliche OrderID heißt technisch merchantReference und ist ein Attribut einer lynck Transaktion, das selbst nach der erfolgreichen Reservierung einer Transaktion verändert werden kann. Diejenigen lynck Plugins, welche mit einer generischen orderID arbeiten, nutzen dieses Feld, um nach dem Bestellabschluss die Shop-Bestellnummer als zusätzliche OrderID bei lynck bekannt zu machen.

Reservierung

Den vorläufigen Abschluss einer lynck-Zahlung im Checkout nennen wir bei lynck die Reservierung. Eine erfolgreiche Reservierung bedeutet im Sinne von lynck, dass eine Zahlung erfolgreich durch den Käufer autorisiert wurde. Das muss aber nicht bedeuten, dass das Geld dieser Zahlung bereits geflossen ist; beim Rechnungskauf beispielsweise ist das Geld noch nicht bezahlt, aber das lynck System hat die definierten Risiko- und Bonitätschecks positiv beendet und die Bestellung kann für den Versand vorbereitet werden.

Buchung (Capture)

Damit aus einer Reservierung eine offene Forderung – inkl. der lynck Zahlungsüberwachung – wird, muss die reservierte Zahlung gebucht werden. Die lynck Plugins automatisieren diesen Prozess in der Regel auf Grundlage der Rechnungserstellung im Shop-Backend oder anhand von Bestell-Status-Übergängen. Die individuell relevanten Informationen sind deshalb auf der jeweiligen Plugin Seite zu finden.

Gutschrift (Refund)

Gebuchte Beträge können – im Sinne einer Rechnungskorrektur – durch einen Refund nachträglich reduziert oder bei Bedarf gutgeschrieben werden. Das lynck System erkennt bei diesem Prozess ganz automatisch, ob die zu dem Refund gehörende Buchung bereits bezahlt wurde und entscheidet somit eigenständig, ob die Reduzierung ausstehender Forderungen möglich ist oder ob eine Gutschrift an den Endkunden notwendig ist.

Zahlungsüberwachung (EBICS)

Ein elementarer Baustein der lynck Lösung ist die Zahlungsüberwachung. Um eingehende Zahlungen der Konto basierten Zahlungsarten Rechnung, Lastschrift und Vorkasse automatisch zuordnen zu können, wird mindestens ein lesender Zugriff auf das Händler- bzw. Debitorenkonto benötigt. Dieser Zugriff ist in der lynck Lösung über EBICS (Electronic Banking Internet Communication Standard) geregelt.

Das EBICS Protokoll definiert dabei zwei für lynck relevante Zugriffsarten. Die folgende Tabelle zeigt die relevanten Unterschiede:

Für die Integration der lynck Lösung stellt lynck eine Sandbox bereit. Die lynck Sandbox ist eine nahezu identische Kopie des Produktivsystems und bietet damit die Möglichkeit, alle Prozessabläufe zu integrieren, ohne dass echte Zahlungsvorgänge ausgelöst werden.

Bemerkung: Da beide Systeme logisch und physisch voneinander getrennt sind, sind für beide Systeme ganz eigene Accounts und Mandanten konfiguriert. Die API Zugangsdaten für Sandbox- und Produktivbetrieb sind deshalb i.d.R. nicht identisch.

Die folgende Gegenüberstellung zeigt die relevanten Unterschiede beider Systeme:

Der lynck Händler Service Bereich bietet alle notwendigen und hinreichenden Funktionen für die Verwaltung der lynck Lösung. Technisch relevant für die Plugin-Installation sind die folgenden Abschnitte.

URL Konfiguration

Die URL Konfiguration definiert die Callback Adressen, welche im Falle einer externen Umleitung (z.B. 3D Secure, Sofort. usw.) den korrekten Rückweg nach der Zahlung definieren.

Bemerkung: Jedes Plugins verwenden seine eigenen Callback Adressen. Dies ist zum einen der historischen Entwicklung der Plugins geschuldet, zum anderen auch abhängig von der jeweiligen Shopsystem-Architektur. Die korrekten Callback Adressen sind auf der jeweiligen Plugin-Seite zu finden.

Hosted Fields Konfiguration

Zur sicheren Übertragung von Kreditkarten-Daten setzt lynck auf die sog. Hosted Fields Technologie (auch Secure Fields genannt). Dabei werden die Eingabefelder der sensiblen Informationen als Iframes in die Frontend-Templates des Shops integriert. So erfolgt die Eingabe der Daten technisch gesehen direkt auf einem gesicherten lynck Server und gar nicht im Shopsystem selbst.

Für den funktionalen Einsatz der Hosted Fields wird eine JavaScript Bibliothek verwendet. Damit diese auch bei verschlüsselten SSL Verbindungen alle benötigten Ressourcen korrekt initialisieren kann, muss die Domäne des Shopsystems im gleichnamigen Abschnitt der Konfiguration korrekt hinterlegt werden:

Händlerbenachrichtigungssystem

Mit Hilfe des Händlerbenachrichtigungssystems werden Status-Informationen zu jeder lynck Transaktion als digitale Push-Benachrichtigungen versendet.

Die technischen Endpunkte für Push-Benachrichtigungen werden von den lynck Plugins bereitgestellt und zur Aktualisierung des Zahlungsstatus der Bestellungen verwendet. Die Adresse der Benachrichtigungs-URL ist auf der jeweiligen Plugin-Seite zu finden.

Das lynck System ist mandantenfähig aufgebaut. Das bedeutet, dass für jeden Account mehrere, voneinander unabhängige Anwendungen (i.d.R. Onlineshops) konfiguriert werden können.

Damit eine Konfiguration eindeutig identifiziert werden kann ist immer eine Kombination aus der Händler ID und der
Shop ID notwendig. Zu jeder Shop ID gehört darüber hinaus ein 32-stelliger Token, der sogenannte Öffentliche Schlüssel. Zur Autorisierung der Kommunikation mit der lynck API werden die Zugangsdaten mit dem Privaten Schlüssel komplettiert.

Bemerkung: Die Plugins verwenden teilweise abweichende Bezeichnungen dieser vier Zugangsdaten. Dies ist der historischen Entwicklung der Plugins geschuldet. Die jeweils verwendete Bezeichnung ist auf der jeweiligen Plugin-Seite zu finden.

Die lynck API Zugangsdaten können jederzeit im gleichnamigen Abschnitt der Shop Details im lynck Händler Service Bereich abgerufen werden.

Ein lokales Testing der lynck Lösung ist auch mit der Sandbox nur eingeschränkt möglich. Eine lynck Transaktion gilt erst dann als vollständig reserviert, wenn die AcknowledgePending Notification mit einem http/200 beantwortet wurde (siehe auch Notification Call).

Da lokale Testinstanzen für unsere Sandbox nicht erreichbar sind, sollte beim lokalen Testing eine Statusbenachrichtigungsziel-URL hinterlegt werden, die per Default mit einem http/200 antwortet. Dies tut beispielsweise die Seite https://www.example.com.

Weiterhin ist das Testen von Umleitungszahlarten in einer lokalen Umgebung nicht möglich. Zwar kann aus dem Shop bzw. der Anwendung zur Autorisierung beim Drittanbieter umgeleitet werden, jedoch kann die finale Umleitung zurück in den Shop nicht erfolgen, wenn die lokale Maschine von der lynck Sandbox aus nicht erreichbar ist.

Häufig werden Testsysteme hinter einem Verzeichnisschutz, häufig auch .htaccess Schutz genannt, betrieben. In diesem Fall erwartet der Server eine Autorisierung mit Benutzernamen und Passwort bei eingehenden Anfragen. Damit sowohl der lynck Benachrichtigungsservice, als auch die Umleitungszahlarten funktionieren, können die benötigten Zugangsdaten über die URL-Konfiguration bekannt gemacht werden.

Beispiel:
https://benutzername:passwort@mein.test.shop/success.php

Bemerkung:
Es sollte unbedingt darauf geachtet werden, dass für den Benutzernamen und das Passwort keine Sonderzeichen verwendet werden, die als Steuerzeichen einer URL interpretiert werden können (/&#.-= usw.). Sollten diese Zeichen trotzdem verwendet werden, muss das Passwort URL encoded hinterlegt werden.

Alternative Lösung:
Die .htaccess Konfiguration des Webservers erlaubt die Freischaltung spezieller IP-Adressen, die dann von der Authentifizierung ausgenommen sind. Da alle Anfragen der lynck Sandbox von derselben IP-Adresse (13.49.254.144) erfolgen, kann diese auch von der Authentifizierung ausgenommen werden.teme:

Die folgenden Testdaten gelten für die lynck Sandbox und sind damit für alle lynck Plugins nutzbar.

Lastschrift

Kreditkarte

Für ein Testing einiger Gateway-Fehler, die bei der Kreditkartenabwicklung u.U. auftreten können, haben wir auf unserer Sandbox einige spezielle Beträge zu Testzwecken definiert:

AmazonPay

PayPal

Sofort. (ehem. Sofortüberweisung)

B2B Bonitätsprüfung (Sandbox)

Die Bonitätsprüfung ist in der Regel auf der Sandbox deaktiviert. Um Tests mit den lynck SolvencyChecks auf der Sandbox durchzuführen, senden Sie bitte eine kurze Anfrage über unser Kontaktformular.

B2C Bonitätsprüfung (Sandbox)

Die folgenden Testfälle gelten für die lynck Sandbox und sind damit für alle lynck Plugins nutzbar.

Checkout

* unter Direct Bezahlart verstehen wir die Zahlungsarten Rechnung, Lastschrift und Vorkasse, also diejenigen, welche ohne eine Umleitung zu einem Drittanbieter abgeschlossen werden können.
** unter Redirect Bezahlart verstehen wir die Zahlungsarten Kreditkarte, Sofort. und PayPal, bei denen nach dem Kaufabschluss im Shop noch zu einem Drittanbieter umgeleitet werden muss.

Händler Service Bereich

Die in diesem Abschnitt aufgeführten Testfälle beziehen sich speziell auf den lynck Händler Service Bereich.

Im Abschnitt Händler Service Bereich haben wir bereits das lynck Händlerbenachrichtigungssystem kennengelernt. In diesem letzten Abschnitt werden noch einmal die wichtigsten Status einer lynck Transaktion bzw. einer Buchung erläutert.

Transaktionsstatus

Buchungsstatus

Die hier aufgeführten Status gelten innerhalb einer Buchung. Für Buchungen mit einer offenen Forderung startet der Ablauf mit dem Status PayPending, für bereits bezahlte Forderungen startet der Ablauf direkt im Status Paid.