Home 
Das folgende Dokument gibt Ihnen einen allgemeinen Überblick über die verschiedenen Integrationsarten und unseren Zahlungsprozess. Wenn Sie mehr über die verschiedenen Themen erfahren möchten, finden Sie in den Texten oder im Menü direkte Links. Sie führen Sie zu einer detaillierteren Beschreibung mit Beispielen.
Zahlungen zu verarbeiten bedeutet, mit sensiblen Daten umzugehen. Insbesondere wenn Sie
Kreditkarten verarbeiten, geht dies auch für Händler mit hoher Verantwortung und Pflichten einher. Insbesondere
PCI DSS ist in diesem Zusammenhang relevant.
Wenn Sie Händler sind und Kreditkartendaten verarbeiten, müssen Sie mindestens
level 4 compliant sein. Wenn Sie Kartendaten über Ihren Server speichern oder verarbeiten, steigen die Anforderungen
auf level 3 oder höher.
Unsere Plattform bietet Ihnen Sicherheit der Klasse A und ist selbstverständlich PCI Level 1 compliant.
Unser Hauptziel ist es, Sie als Händler aus dem PCI-Geltungsbereich herauszuhalten.
Um eine reibungslose und sichere Zahlungsintegration für Ihren Online-Shop zu gewährleisten,
haben wir unsere API und Beispiele so gestaltet, dass Sie auf eine level 4-konforme Weise integrieren können.
Seit der Einführung von PCI V 3.0 dürfen Händler die Zahlungsformulare nicht mehr direkt auf ihrer Website hosten. Die Formulare, in denen der Kunde seine Zahlungsdaten eingibt, müssen von einem PCI-Level-1-konformen Anbieter generiert und gehostet werden.
Es gibt zwei Möglichkeiten, die Zahlungsseiten in Ihren Webshop zu implementieren:
-
Payment-Page-Integration
-
Iframe-Integration
Der zweite Grund, warum wir das Iframe gewählt haben, ist die Abstraktion der Datenerfassung. Die Datenerfassung kann sich zwischen Prozessoren und Zahlarten unterscheiden, was den Händler zwingen würde, jede Zahlart einzeln zu integrieren. Stattdessen enthält unser Iframe alle Formularfelder zur Erfassung der Zahlungsinformationen. So kann der Händler eine einzige API für jede Zahlart verwenden.
Die Payment-Page-Integration ist eine Integration, bei der Sie den Kunden auf unsere Zahlungsseite weiterleiten, wo er die Zahlungsdaten eingibt.
Figure 1. Beispielbild einer Payment-Page-Integration
Weitere technische Informationen und Integrationsbeispiele finden Sie im Abschnitt zur Payment Page.
Wenn Sie Ihren Kunden nicht von Ihrem Shop wegleiten möchten, haben Sie auch die Möglichkeit, unsere Zahlungsseite in einem Iframe direkt in Ihren Webshop zu implementieren.
Wir haben die Zahlungsseiten so gestaltet, dass Sie das Iframe direkt in den Zahlungsprozess Ihres Webshops integrieren können, in dem die Zahlart ausgewählt wird. Das JavaScript und das Iframe selbst sind so konzipiert, dass das Absenden des Inhalts innerhalb des Iframes über eine Schaltfläche ausserhalb des Iframes im Shop ausgelöst werden kann. Das bedeutet, dass der Kunde zuerst alle Daten eingeben kann, die Händleranwendung die Bestellung erstellt und dann das Formular abgesendet wird. Auch eine Validierung kann von ausserhalb des Iframes ausgelöst werden.
Das Formular innerhalb des Frames kann mit Twig-Templates gestaltet werden. Dies ermöglicht es, das Layout an das Layout der Händleranwendung anzupassen.
Figure 2. Beispielbild einer Iframe-Integration, die direkt in den Checkout-Prozess integriert ist, in dem die Zahlart ausgewählt wird.
Weitere technische Informationen und Integrationsbeispiele finden Sie im Abschnitt zum Iframe.
Die API ist eine einheitliche Schnittstelle, um alle unterstützten Zahlarten über jeden verfügbaren Prozessor mit einem standardisierten Zahlungsprozess zu verarbeiten. Mit anderen Worten: Sobald Sie die obligatorischen Anfragen integriert haben, können Sie zusätzliche Prozessoren oder Zahlarten hinzufügen, ohne etwas an Ihrer Anwendung zu ändern. Falls Sie Zahlarten hinzufügen, die zusätzliche Informationen erfordern, die uns in Ihrer Anfrage nicht übermittelt werden, bitten wir einfach Ihren Kunden, diese zusätzlichen Informationen bereitzustellen.
Das API-Konzept vereinheitlicht die verschiedenen Integrationen der Prozessoren in einer einzigen Zahlungs-API. Um diese Vereinheitlichung zu erreichen, mussten wir eine Datenabstraktion entwickeln.
Dies hat für Sie die folgenden Vorteile:
-
Eine einzige Integration, um alle Ihre Zahlungsprozessoren anzubinden
-
Sie können Prozessoren oder Zahlarten hinzufügen, ohne Ihre Anwendung zu ändern
Die Datenabstraktion hat für Sie auch einige Auswirkungen:
-
Damit alles in die verschiedenen APIs und deren Einschränkungen passt, kann es sein, dass wir einige der Daten, die Sie uns in den Anfragen gesendet haben, ändern oder kürzen müssen, um den verschiedenen Prozessoren zu entsprechen.
-
Falls Informationen fehlen, müssen wir nach diesen zusätzlichen Informationen fragen.
Wir haben nicht nur das Datenmodell für alle Prozessoren standardisiert, sondern auch den Zahlungsprozess für jede Zahlart und jeden Prozessor.
Jede auf der Plattform durchgeführte Transaktion hält sich strikt an diesen Prozess.
Wenn eine Transaktion erstellt wird, wird sie in den Status Pending versetzt, in dem sie frei geändert werden kann.
Sie haben auch die Möglichkeit, die Transaktion zu stornieren. Sie wird dann in den Status Voided verschoben.
Sobald eine Transaktion Confirmed ist, kann sie nicht mehr geändert werden. Sobald die Verarbeitung der
Transaktion beginnt, wird die Transaktion in den Status Processing versetzt.
Aus Processing kann die Zahlung entweder direkt in fail übergehen, oder wenn die Zahlung erfolgreich ist, wird sie
auf Authorized gesetzt, oder falls die Zahlung direkt erfasst wird, wird sie in den Status Completed
verschoben. Sobald wir wissen, dass die Zahlung garantiert oder auf Ihrem Konto eingegangen ist, setzen wir den
Status der Transaktion auf Fulfill. Falls die Zahlung innerhalb eines definierten Zeitraums
(abhängig von den Eigenschaften einer Zahlart) nicht eingegangen oder nicht garantiert ist, verschieben wir die Transaktion
nach Decline. Es kann auch sein, dass wir Sie um eine Entscheidung bitten müssen, ob Sie die Transaktion auf Fulfill oder Decline
setzen möchten.
Die Status Decline, Voided, Failed oder Fulfill sind Endstatus und geben Ihnen einen klaren Hinweis darauf, ob
beispielsweise die Waren im Fall physischer Güter versendet oder der Download im Fall
digitaler Güter freigegeben werden soll.
Die Standardisierung ist ein starkes Werkzeug für Sie als Händler, weil sie den Prozess für Ihre Integration standardisiert, unabhängig davon, welche Zahlart Sie integrieren. Dies bringt jedoch auch einige Einschränkungen oder Auswirkungen mit sich, die Sie kennen sollten:
-
Einige Zahlungsintegrationen erfordern, dass Sie die Rechnungen, die Sie an den Kunden senden, dynamisch anpassen. Daher haben wir auch eine Dokumentvorlagen-Engine und eine E-Mail-Integration eingebaut, mit der Sie diese Dokumente direkt an Ihren Kunden senden können.
-
Es ist nur ein endgültiger Abschluss möglich. Sie können die Positionen in Ihrer Transaktion ändern, aber sobald die Transaktion abgeschlossen ist, kann sie nicht mehr geändert werden.
Unsere Zahlungsseiten sind standardmässig vollständig responsiv und für Mobilgeräte optimiert.
Wir wissen jedoch, dass eine nahtlose Integration in das Design des Webshops entscheidend für das Einkaufserlebnis Ihres Kunden ist. Daher haben wir einen Ressourceneditor entwickelt, mit dem Sie die Vorlage der Zahlungsseite direkt und vollständig anpassen können. Detailliertere Informationen über die von uns verwendete Template-Sprache und Beispiele finden Sie in der Ressourcendokumentation.
Figure 3. Der Ressourceneditor ermöglicht es Ihnen, das Erscheinungsbild der Zahlungsseite innerhalb der Anwendung zu gestalten.
Wenn Sie mehrere Connectoren für eine Zahlart haben, können Sie Transaktionen durch die Anwendung von Bedingungen routen. Bedingungen helfen Ihnen auch zu definieren, wann eine Zahlart generell für Ihren Kunden sichtbar ist.
Wir stellen einen umfangreichen Satz verschiedener Bedingungen bereit, die ein Händler auswählen und konfigurieren kann. Eine Liste aller verfügbaren Bedingungen finden Sie hier
Basierend auf der ausgewählten Bedingung müssen Sie weiter festlegen, wann und wie diese Bedingung angewendet werden soll. Das Konzept der Bedingungen ist praktisch und ermöglicht Ihnen sehr komplexe Entscheidungsbäume, die andernfalls in Ihre Anwendung programmiert werden müssten.
Beispiel
Sie haben zwei Prozessorverträge. Einen, mit dem Sie Kreditkartentransaktionen ohne 3-D Secure verarbeiten können, und einen anderen Vertrag mit 3-D Secure. Um Ihr Risiko und Betrug zu minimieren, möchten Sie jede Transaktion ausserhalb von Grossbritannien und über 30 GBP mit dem Terminal verarbeiten, das 3-D Secure erfordert. Jede Transaktion unter 30 GBP innerhalb von Grossbritannien kann ohne 3-D Secure verarbeitet werden. Um dies zu erreichen, können Sie 2 Bedingungen einrichten und auf Ihre Connector-Konfiguration anwenden:
-
Erstellen Sie einen Länderfilter für die Rechnungs- und Lieferadresse und setzen Sie ihn auf Grossbritannien.
-
Erstellen Sie einen Betragsfilter für unter 30 GBP.
-
Wenden Sie den Filter auf die Connector-Konfiguration für den Prozessor ohne 3-D Secure an.
Sie können mehrere Bedingungen auf eine Connector-Konfiguration anwenden. Die Bedingungen können dann auch verwendet werden, um den Connector auszuwählen, der die Transaktion schliesslich verarbeitet.
Beispiel
Sie haben zwei Zahlungsprozessoren. Ein Prozessor wird für Europa und einer für die USA verwendet, um Karten zu verarbeiten. Sie möchten Bestellungen mit einer US-Rechnungs- und Lieferadresse über den US-Prozessor verarbeiten und den Rest über Ihren europäischen Prozessor. Um dies zu erreichen, können Sie die Connectoren für die beiden Prozessoren erstellen.
-
Erstellen Sie eine Länderbedingung für die Rechnungs- und Lieferadresse, setzen Sie sie auf USA und wenden Sie die Bedingungen auf den US-Prozessor an.
-
Erstellen Sie eine Länderbedingung für die Rechnungs- und Lieferadresse, setzen Sie sie auf alles ausser USA und wenden Sie sie auf den europäischen Prozessor an.
Alle Connector-Konfigurationen sind nach ihrer Priorität sortiert. Wenn ein bestimmter Connector nicht funktioniert, versuchen wir den nächsten. Wenn z.B. ein Prozessor offline ist, versuchen wir einfach den nächsten. Wir versuchen auch den nächsten, wenn die Transaktion von einem der Prozessoren abgelehnt wird.
Wiederkehrende Produkte werden für Händler zunehmend interessant. Die Handhabung von Abonnements ist jedoch komplex und erfordert eine ausgereifte und leistungsfähige Plattform, um abgelaufene Kreditkarten, Mahnprozesse usw. zu handhaben.
Wir bieten einen abstrahierten Service für die Abwicklung wiederkehrender Zahlungen. Der Service übernimmt die Aktualisierung der Zahlungsinformationen (z.B. Kreditkartendaten) und die Fehlerbehandlung.
Wir können eine wiederkehrende Zahlung auf drei verschiedene Arten durchführen:
1) Tokenisierung: Wir verwenden einen zuvor erstellten Token der Zahlungsinformationen, um den Kunden zu belasten. Z.B. verwenden wir für Kreditkarten einen Token, der mit einer gespeicherten Karte verknüpft ist.
2) Asynchrone Belastung: Einige Zahlarten benötigen keine Benutzerinteraktion. In dieser Situation können wir den Kunden trotzdem belasten.
3) Synchrone Belastung: Wir senden beispielsweise per E-Mail einen Link, der auf unsere Zahlungsseite verweist, und bitten den Kunden, auf dieser Seite die Zahlungsinformationen anzugeben, die wir benötigen, um ihn zu belasten.
Sie können diese drei Methoden in einem Charge Flow anwenden. Jeder Charge Flow besteht aus verschiedenen Stufen. Auf jeder Stufe versuchen wir alle drei Methoden in der oben angegebenen Reihenfolge, um den Kunden zu belasten. Die Anzahl und das Intervall dieser Stufen werden vom Händler gesteuert. Dies gibt die Flexibilität, den Kunden mehrmals daran zu erinnern, die Zahlungsinformationen zu aktualisieren, bevor eine Transaktion schliesslich entweder als erfolgreich oder als fehlgeschlagen markiert wird.
Die Plattform kümmert sich um die verschiedenen Fehlerfälle oder die Aktualisierung der Zahlarten. Alles, was ein Händler
tun muss, ist, unseren charge endpoint zu verwenden und die customerID und den zu belastenden Betrag anzugeben. Basierend auf dem
konfigurierten Charge Flow versuchen wir, den Kunden zu belasten. Nach den definierten Zeiträumen informiert ein Webhook
Ihre Anwendung darüber, ob die Transaktion erfolgreich war oder ob das Abonnement gestoppt werden muss.
Beispiel
Der Kunde bezahlt das erste Mal über die reguläre Zahlungsseite und erstellt mit dieser ersten Zahlung einen Token. Die Händleranwendung kann diesen Token zum Kunden speichern. Für nachfolgende Transaktionen übergibt die Anwendung diesen Token an unseren Service. Sobald die zum Token gespeicherten Zahlungsdaten nicht mehr gültig sind, sollen mehrere Erinnerungen an den Kunden gesendet werden, um diese Informationen zu aktualisieren. Da jedoch typischerweise das Konto nicht über ausreichende Mittel verfügt, möchten wir die Belastung nach 5 Tagen erneut versuchen, bevor wir beginnen, den Kunden zu erinnern.
Der von uns bereitgestellte Service kümmert sich um den gesamten Prozess. Daher können der Charge Flow und die Charge-Flow-Stufen auf folgende Weise angewendet werden:
-
Die erste Stufe versucht einfach, den Kunden mit dem Token zu belasten. Im Fehlerfall soll keine E-Mail-Nachricht gesendet werden. Die Stufe ist auf 5 Tage festgelegt. D.h. wir wechseln nach 5 Tagen zur nächsten Stufe.
-
Die zweite Stufe versucht erneut, den Kunden mit dem Token zu belasten. Im Fehlerfall wird eine E-Mail mit einem Zahlungslink gesendet. Die Stufe legt auch die Zeit bis zum Wechsel zur dritten Stufe fest.
-
Die dritte Stufe versucht erneut, den Kunden mit dem Token zu belasten. Falls dies erneut fehlschlägt, senden wir erneut eine E-Mail-Nachricht mit dem Link, diesmal jedoch mit einer strengeren Formulierung.
-
Nach der dritten Stufe definieren wir keine weitere Stufe, und daher gilt die Transaktion als fehlgeschlagen.
Es ist auch möglich, mehrere Charge Flows zu erstellen und sie basierend auf Bedingungen auf die verschiedenen Fälle anzuwenden. Die Anzahl der Stufen ist nicht beschränkt.
Weitere Informationen finden Sie im Abschnitt über Charge Flows und Tokenisierung.
Wir investieren auch viel Zeit, um bessere After-Sale-Analysen anzubieten. Um Ihnen detailliertere Statistiken über die Konversionsraten Ihrer Zahlungen zu geben, haben wir das Konzept der Transaktionsgruppen eingeführt.
Transaktionen werden basierend auf der gesendeten customerID in Transaktionsgruppen gruppiert. Transaktionen werden in
Transaktionsgruppen gruppiert. Gewöhnliche Tools führen ihre Analysen basierend auf der Anzahl der Versuche auf der Zahlungsseite durch und
vergleichen dann erfolgreiche mit fehlgeschlagenen Transaktionen. Eine interessante Information wäre jedoch, dies
pro Kunde zu analysieren und die Transaktionen in Transaktionsgruppen zu gruppieren. Dies ermöglicht es, mehrere Versuche eines
Kunden zu identifizieren, die über einen bestimmten Zeitraum verteilt sein können, wenn ein Kunde mehrmals versucht zu bezahlen, und eine
Transaktion schliesslich als erfolgreich zu markieren, auch wenn beim ersten Versuch mit Kreditkarte die Zahlung nicht erfolgreich war, er es aber schliesslich
geschafft hat, über ein anderes Zahlungsmittel wie Rechnung zu bezahlen.
|
Important
|
Transaktionen werden nach der customerID gruppiert. Falls die customerID nicht angegeben wird (NULL), wird
jede Transaktion als separate Transaktionsgruppe behandelt.
|
Alle gruppierten Transaktionen können angezeigt werden unter: Space > Zahlung > Transaktionsgruppen.
Wenn Sie mehr Informationen über die verschiedenen Versuche erhalten möchten, können Sie die Transaktionsgruppen öffnen, um alle zugehörigen Transaktionen anzuzeigen. Sie haben auch die Möglichkeit, fehlgeschlagene, erfolgreiche oder ausstehende Transaktionsgruppen zu filtern, indem Sie die Filter oben anwenden.