Saferpay FAQ: Einführung 3-D Secure 2.0

Saferpay FAQ: Einführung 3-D Secure 2.0

Relevante Informationen für Entwickler

Zusammenfassung

Am 14. September 2019 traten die regulatorischen technischen Standards (RTS) im Rahmen der Zweiten EU-Zahlungsdiensterichtlinie PSD2 (Payment Services Directive) in Kraft. Diese fordern vor allem die starke Kundenauthentifizierung (Zwei-Faktor-Authentifizierung) beim Bezahlen im Internet. Um dieser Forderung nachzukommen, haben die Kartenorganisationen Visa und Mastercard gemeinsam mit EMVCo das 3-D Secure Sicherheitsverfahren weiterentwickelt: 3-D Secure 2.0 ist PSD2 konform und gilt sowohl für EU-Länder als auch für die Schweiz. Gemäss Vorgaben der Kartenorganisationen muss 3DS 2.0 von allen Online-Händlern unterstützt werden.

Worldline stellt Ihnen für Saferpay immer die aktuellste 3-D Version zur Verfügung. Derzeit wird die Version 3-D Secure 2.1 verwendet (Folgend nur „3-D Secure 2“ genannt).

 

 

Besteht meinerseits Handlungsbedarf für 3-D Secure 2?

Dies hängt davon ab, ob Sie schon mit der aktuellen Saferpay JSON API oder noch mit einer der alten Schnittstellen arbeiten. Im Saferpay Backoffice wird Ihnen in der Journalansicht unter https://www.saferpay.com/BO/Commerce/JournalOverview in der Spalte „Anwendung“ angezeigt, über welche Schnittstelle die jeweilige Transaktion abgewickelt wurde:

Bei den Transaktionsdetails im Saferpay Backoffice finden Sie auch die Info, über welche Schnittstelle die Transaktion autorisiert, verbucht oder storniert wurde. 

 

 

 

Wie erkenne ich, welche Schnittstelle ich benutze?

Unter Online Support / Schnittstellenverwendung sehen Sie, über welche Schnittstellen Ihre Systeme zuletzt Verbindungen zu Saferpay aufgebaut haben. 



Mögliche Werte sind:

Abkürzung Bezeichnung Besteht Handlungsbedarf?
AI Saferpay Client Application Interface Umstieg auf JSON API
API JSON API NEIN
HI HTTPS Interface Umstieg auf JSON API
PP/AI/HI Payment Page / Saferpay Client Application Interface / HTTPS Interface Umstieg auf JSON API
PP/API Payment Page / JSON API NEIN
BO Saferpay Backoffice NEIN
BP Saferpay Backoffice Batch Processing NEIN

Ich arbeite schon mit der JSON API. Besteht meinerseits Handlungsbedarf?

Es besteht Ihrerseits kein Handlungsbedarf. 3-D Secure 2 wird aktuell als Pilot ausgerollt und steht Ihnen in Kürze automatisch zur Verfügung.

 

Ich arbeite noch mit einer alten Schnittstelle (https Interface oder Saferpay Client). Besteht meinerseits Handlungsbedarf?

3-D Secure 2 wird nur von der JSON API unterstützt. Die alten Schnittstellen unterstützen den neuen Standard nicht und werden in diesem Zusammenhang Ende 2020 deaktiviert. Ein Umstieg auf die JSON API ist deswegen zwingend erforderlich, auch wenn Ihr System keine 3-D Secure-Funktionalität nutzt. Informationen zum Umstieg finden Sie im Kapitel Umstieg auf JSON API

 

Ich bin Neukunde. Muss ich für die Nutzung von 3-D Secure 2 etwas tun?

Da Sie als Neukunde bereits die Saferpay Schnittstelle JSON API einsetzen, müssen Sie nichts unternehmen. Die Umstellung von 3-D Secure 1 auf 3-D Secure 2 erfolgt automatisch durch Saferpay. Weiterführende Informationen zum Integrationsprozess finden Sie in unserem Integrationsleitfaden

 

Umstieg auf die Saferpay JSON API

Die Technologie wandelt sich in vielerlei Hinsicht. Auch Schnittstellen sind davon betroffen. Wenn Sie einen Webshop betreiben und Zahlungsmittel oder andere Bezahlmethoden anbieten, ist es wichtig, dass auch die Schnittstellen neue Anforderungen mittragen. Mit der Anpassung Ihrer Schnittstelle auf die Saferpay JSON API stellen Sie sicher, dass Ihre Autorisierungen von Zahlungen zwischen Ihrem System und der Zahlungslösung von Worldline auch zukünftig reibungslos funktionieren. Zusätzlich profitieren Sie von weiteren Sicherheitsmechanismen, vielen Zahlungsmitteln und einer vereinfachten Integration.

Für die Umstellung Ihrer Schnittstelle kontaktieren Sie am besten den technischen Betreuer Ihres Webshops oder Ihrer Applikationen mit Anbindung zu Saferpay.

Sofern Ihr Shop zur Anbindung an Saferpay ein Plug-in verwendet, bietet unser Partner Customweb unter https://www.sellxed.com/shop/de/chf/extensions/module/payment-service-provider/saferpay.html aktuelle Saferpay-Module für viele Shopsysteme an.

Sollten Sie eine individuelle Implementierung nutzen, so finden Sie die allgemeine Dokumentation zur Saferpay JSON API unter https://saferpay.github.io/sndbx/index.html.

Die technische Dokumentation mit einer strukturierten Auflistung aller Requests, deren Container und Parameter sowie entsprechende Beispielcodes finden Sie unter: http://saferpay.github.io/jsonapi/.

Alle benötigten Informationen zur Saferpay Testumgebung (inklusive der Möglichkeit, einen individuellen Test Account zu erstellen) finden Sie auf unserer Test Account Supportseite

 

Gegenüberstellung Funktionen und Parameter

Grundsätzlich enthält unsere Dokumentation alle zur Implementierung der JSON API notwendigen Informationen. Hilfsweise hier jedoch noch einige Informationen zu den alten Schnittstellen im Vergleich zur JSON API.

 
Alte Schnittstelle JSON API Bemerkung
CreatePayInit PaymentPage/Initialize  
CreatePayInit (SCD) Alias/Insert  
CreatePayComplete (ACTION=Settlement) Transaction/Capture  
CreatePayComplete (ACTION=Cancel) Transaction/Cancel  
CreatePayComplete (ACTION=CloseBatch) Batch/Close  
ACCOUNTID=401860-17795278 CustomerId=401860
TerminalId=17795278
Die AccountId setzt sich aus CustomerId und TerminalId, getrennt durch einen Bindestrich, zusammen.
Execute (ACTION=Debit) Transaction/Authorize oder Transaction/AuthorizeDirect  
Execute (ACTION=Credit) Transaction/Refund oder Transaction/RefundDirect  
CARDREFID Alias.Id  
Automatisch generierte Aliaswerte waren numerisch und wurden hochgezählt Von Saferpay generierte Aliaswerte sind alphanumerisch Die Definition der Aliase (alphanumerisch bis 40 Char Länge) ist gleich. Aliase sind schnittstellenübergreifend gültig. Mit den alten Schnittstellen generierte Aliase können über die JSON API problemlos weiterverwendet werden.
Authentisierung mit SPPASSWORD Authentisierung mit Basic Authentication oder Client Certificate  
CreatePayInit mit Formatierung der Payment Page:
Parameter
BODYCOLOR,
BODYFONTCOLOR,
FAILCOLOR,
FOOTERFONTCOLOR,
HEADCOLOR,
HEADFONTACTIVECOLOR,
HEADFONTCOLOR,
HEADFONTINACTIVECOLOR,
HEADLINECOLOR,
LINKCOLOR,
MENUCOLOR,
MENUFONTCOLOR,
MERCHANTDETAILCOLOR,
ORDERCOLOR,
PAYMENTDETAILMOUSEOVERCOLOR,
SUCCESSCOLOR,
TITLECOLOR
PaymentPage/Initialize mit dem Parameter CssUrl Alternativ kann das Design der Payment Page im Backoffice konfiguriert werden.
CreatePayInit (mit der Darstellung der AGB-Bestätigung in der Payment Page: Parameter TERMSCHECKBOXACTIVE, TERMSURL) Nicht möglich Die AGB-Bestätigung gehört zum Kaufprozess und soll auf der Webseite oder im Webshop durchgeführt und protokolliert werden, daher wird diese Funktion im Zahlungsprozess nicht mehr angeboten.

Grundlegende Beschreibung der Abläufe

Payment Page

Alte Schnittstelle

  1. Generierung des Zahlungslinks über CreatePayInit
  2. Der Shop leitet den Käufer auf die Saferpay Payment Page weiter. In diesem Schritt übernimmt Saferpay die Aufnahme der Zahlungsmitteldaten und, wenn notwendig, die Ausführung der 3DS Authentifizierung, das DCC Verfahren und anschliessend die Autorisierung der Zahlung.
  3. Die Autorisationsantwort (mit den Autorisationsdaten) ist digital signiert. Diese Signatur wird dann mit VerifyPayConfirm überprüft, um sicherzustellen, dass die Antwort auch authentisch ist.
  4. Abschliessend wird die Transaktion dann mit PayComplete verbucht.

Kontakt

Haben Sie weitere Fragen zu 3-D Secure 2 oder zum Schnittstellenwechsel? Gerne unterstützen wir Sie beim Aktualisieren Ihrer Saferpay Schnittstelle.

 

 

Anrede*
Datenschutzerklärung*
Optionale Datenschutzerklärung
*Pflichtfeld