Der folgende Inhalt geht davon aus, dass Sie die erforderliche PCI-Zertifizierung erhalten haben, um sensible Karteninhaberdaten in der Anfrage an unsere 3DS API zu verarbeiten und zu übermitteln.
Lesen Sie diesen Artikel, um mehr zu erfahren.
Bevor Sie beginnen, benötigen Sie einen Benutzernamen und ein Passwort für Web Services, damit wir Ihre Anfragen authentifizieren können
Sie können einen Webdienst-Benutzer über unsere Schnittstelle Portal erstellen. Ihr System muss diesen Benutzernamen in jeder Anfrage zusammen mit dem Passwort übermitteln. In unseren Anfragebeispielen verwenden wir einen Platzhalter-Benutzernamen und ein Passwort, die Sie vor dem Testen durch Ihre eigenen Anmeldedaten ersetzen müssen.
Wenn Sie noch keine Zugangsdaten für die Webdienste haben, klicken Sie hier, um zu erfahren, wie Sie diese konfigurieren können.
Sie müssen auch unser Support-Team kontaktieren und eine neue 3DS-API-Test-Site-Referenz anfordern, damit Sie mit dem Testen unserer 3DS-API beginnen können.
Es ist wichtig zu beachten, dass Sie bestehende Website-Referenz(s), die bereits für die Verarbeitung von Zahlungen konfiguriert sind, nicht für die Verarbeitung von Anfragen an unsere 3DS API verwenden können.
Das bedeutet, wenn Sie Authentifizierungsanfragen an unsere 3DS API und Zahlungsanfragen Autorisierung an unsere Webservices API verarbeiten, sind für jeden Anwendungsfall unterschiedliche Website-Referenzen erforderlich.
Konfiguration
Sichere Verbindung
Ihre Bibliothek muss eine sichere Verbindung zu einem der beiden Systeme herstellen:
- “https://<DOMAIN>/json/” (for JSON – recommended)
- “https://<DOMAIN>/xml/” (for XML)
Replace <DOMAIN> with a supported Webservices domain. Click here for a full list.
Alle Verbindungen zwischen Ihrem Server und Trust Payments müssen ordnungsgemäß authentifiziert und verschlüsselt werden
Trust Payments verwenden den Industriestandard für hochsichere TLS-Verschlüsselung. Wir empfehlen Ihnen, eine aktuelle SSL/TLS-Bibliotheksimplementierung für die von Ihnen gewählte Sprache zu verwenden.
Sie sollten sicherstellen, dass es über die folgenden Fähigkeiten verfügt:
- TLSv1.2 oder höhere Fähigkeiten.
- Die Server-Authentifizierung muss durch die Validierung einer Zertifikatskette bis hin zu einer bekannten, vertrauenswürdigen Certificate Authority erfolgen (siehe unten).
- Bei der Serverauthentifizierung muss geprüft werden, ob der Common Name (CN) des Serverzertifikats mit der Domäne übereinstimmt, zu der Sie eine Verbindung herstellen wollen. Wenn Common Name nicht übereinstimmt, sind Sie nicht mit Trust Payments verbunden und die Verbindung MUSS abgelehnt werden.
- Die Server-Authentifizierung muss am Ablaufdatum des Server-Zertifikats erfolgen. Alle abgelaufenen Zertifikate MÜSSEN zurückgewiesen werden.
- Ihre Bibliothek und Ihre Code-Basis müssen gepflegt werden und Sie müssen regelmäßig die neuesten Sicherheits-Patches und/oder Funktionen einspielen.
Trust Payments verwendet die Digicert Certificate Authority , um alle Zertifikate zu signieren. Ihre SSL/TLS-Bibliothek muss so konfiguriert sein, dass sie allen Digicert Zertifikaten vertraut:
https://www.digicert.com/digicert-root-certificates.htm
Hinweis: Bei den meisten aktuellen Betriebssystemen sollten die Digicert Roots-Zertifikate standardmäßig als vertrauenswürdig eingestuft und in den Vertrauensspeicher aufgenommen werden, d. h. die meisten Händler müssen nichts unternehmen, um diese Anforderung zu erfüllen. Wenn Händler jedoch nicht den eingebauten Vertrauensspeicher des Betriebssystems verwenden und stattdessen ihren eigenen Vertrauensspeicher erstellen, sollten sie alle Digicert Root-Zertifikate zu ihrem benutzerdefinierten Vertrauensspeicher hinzufügen, da unsere Zertifikate in Zukunft von jedem der aktiven Digicert Root-Zertifikate signiert werden könnten.
Ihre SSL/TLS-Richtlinie sollte eine regelmäßige Überprüfung und Aktualisierung dieser Zertifizierungsstellen vorsehen (z. B. einmal im Jahr).
Die Validierung einer Kette zu einem vertrauenswürdigen Certificate Authority bedeutet, dass Ihre Implementierung nicht geändert werden muss, wenn Trust Payments regelmäßig Serverzertifikate aktualisiert. Insbesondere sollten Sie NICHT mit einem einzelnen Zertifikatsfingerabdruck verifizieren, da dieser bei jeder Aktualisierung des Serverzertifikats aktualisiert werden muss und nicht funktioniert, wenn unser verteiltes System verschiedene Einzelzertifikate bereitstellt.
Die meisten SSL/TLS-Bibliotheksimplementierungen erfüllen alle oben genannten Anforderungen, müssen aber möglicherweise konfiguriert werden, um sie zu aktivieren. Es liegt in Ihrer Verantwortung, sicherzustellen, dass alle diese Sicherheitsanforderungen korrekt aktiviert sind; andernfalls kann die Sicherheit der Verbindungen gefährdet sein. Es liegt auch in Ihrer Verantwortung, dafür zu sorgen, dass das Betriebssystem und die Software, die für die Verbindungen verwendet werden, mit Sicherheits-Patches auf dem neuesten Stand gehalten werden.
Lastausgleich
Trust Payments setzt den DNS-Lastausgleich ein. Der DNS-Lastausgleich ist so konzipiert, dass eine einzige IP-Adresse zurückgegeben wird, die das bevorzugte Ziel für Ihren Server ist, mit dem er sich zu diesem Zeitpunkt verbindet.
Vor jeder Anfrage, die über unser 3DS API gestellt wird, müssen Sie einen DNS-Lookup für die richtige Domain in Ihrer Anwendung durchführen, um die IP eines verfügbaren Gateways zu erhalten.
Die DNS-Loadbalancer geben nicht nur eine einzige IP zurück, sondern auch eine niedrige TTL, die derzeit auf weniger als 60 Sekunden eingestellt ist. Diese TTL wurde absichtlich niedrig gehalten, um die Exposition Ihres Servers gegenüber dem gesamten Zahlungssystem zu maximieren. Eine Erhöhung dieser TTL würde diese Exposition verringern, was bedeutet, dass Sie eine IP über einen längeren Zeitraum nutzen. Alle Probleme, die auftreten könnten (geplant oder nicht), werden sich dann auf Ihre Zahlungsabwicklung auswirken.
Halten Sie sich unbedingt an die von Trust Payments vorgegebene TTL und aktualisieren Sie Ihre DNS-Einträge, wenn die TTL abläuft.
Trust Payments verfügt über eine Reihe von DNS-Servern, die für die Bereitstellung von DNS-Einträgen verwendet werden. Es ist wichtig, dass Ihr Server in der Lage ist, mit jedem dieser Server eine Verbindung für DNS-Lookups herzustellen. Wenn bei der Kommunikation mit einem DNS-Server ein DNS-Lookup fehlschlägt, müssen die anderen DNS-Server verwendet werden. Wenn Sie nicht alle DNS-Server nutzen, kann es zu Problemen bei der Auflösung von URLs des Zahlungssystems kommen.
Aus der Debug-Perspektive können Sie den folgenden Befehl ausführen, um die aktuelle Liste der verfügbaren DNS-Server zu erhalten:
- Für European Gateway:
- Windows: nslookup -type=NS securetrading.net
- Linux: dig NS securetrading.net
- Für US Gateway:
- Windows: nslookup -type=NS securetrading.us
- Linux: dig NS securetrading.us
Zeitüberschreitungen
Für den unwahrscheinlichen Fall, dass Ihr System bei der Verbindung mit uns Probleme hat, empfehlen wir Ihnen, für Ihre Lösung geeignete Timeouts zu implementieren. Betrachten Sie dieses Beispiel:
Maximale Anzahl der Wiederholungsversuche - 20
Maximale Zeitüberschreitung bei Wiederholungsversuchen - 40 Sekunden
Maximale Zeitüberschreitung bei Verbindungsversuchen - 5 Sekunden
Zeitüberschreitung beim Senden und Empfangen - 60 Sekunden
Versuchen Sie es erneut, bis:
- Die maximale Anzahl der Wiederholungsversuche ist überschritten; ODER
- Das maximale Zeitlimit für Wiederholungen würde durch einen weiteren Verbindungsversuch überschritten werden.
(Das bedeutet, dass die Verbindung nach 35-40 Sekunden nicht mehr versucht wird, da ein Versuch, der die maximale Zeitüberschreitung für Verbindungsversuche von 5 Sekunden benötigt, dazu führen würde, dass die maximale Zeitüberschreitung für Wiederholungsversuche überschritten wird)
Sobald die Verbindung hergestellt ist, lassen Sie 60 Sekunden (den Sende- und Empfangs-Timeout-Wert ) für das Senden und Empfangen der Daten verstreichen, bevor Sie die Verbindung schließen. Wenn die Verbindung aus irgendeinem Grund unterbrochen wird, nachdem die Datenübertragung begonnen hat, ist es nicht empfehlenswert, die Anfrage zu wiederholen.
Die oben vorgeschlagene Timeout-Implementierung ist eine Beispiellösung. Sie müssen die Anforderungen Ihrer eigenen Anwendung berücksichtigen und Timeouts implementieren, die Ihren Anforderungen am besten entsprechen.
Bearbeiten Sie Anfragen mit unserem 3DS API
Wir akzeptieren alle Unicode-Zeichen in Ihrer Anfrage. Die verwendete Kodierung ist UTF-8, ein Multi-Byte-Kodierungsschema. Alle Antworten von uns werden mit UTF-8 kodiert. Ihr System muss darauf vorbereitet sein, alle gültigen Antworten in dieser Kodierung zu akzeptieren.
Möglicherweise müssen Sie Ihre Firewall für unsere Webdienste-IPs öffnen.
Klicken Sie hier für eine vollständige Liste.
Um die strengen Sicherheitsanforderungen zu erfüllen, können wir bei der Nutzung unserer Cross-origin resource sharing (CORS) Dienste die Herkunft https://localhost nicht akzeptieren.
Sie müssen eine gültige Domain verwenden, die über Trust Payments erreichbar ist.
Außerdem müssen Sie das Format der Kopfzeilen verwenden, wie im folgenden Beispiel gezeigt:
{
'Content-length': '<LENGTH OF POST>',
'Content-type': 'application/json',
'Authorization': '<BASIC AUTH CREDENTIALS HERE>',
'Accept': 'text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8'
}
Content-length: <LENGTH OF POST>
Content-type: text/xml;charset=utf-8
Authorization: <BASIC AUTH CREDENTIALS HERE>
Accept: text/xmlWie man eine Kopfzeile erstellt
Alle Anfragen, die über unsere Website 3DS API an Trust Payments übermittelt werden, müssen mit einer Reihe von Kopfzeilen beginnen, die im Folgenden definiert sind. Wir verwenden diese, um eingehende Anfragen zu identifizieren und zu verwalten.
Länge des Inhalts
Content-Length muss die Länge der Bytes der Anfrage im gewählten Zeichensatz sein. Diese muss nach einer eventuellen Zeichenkodierung berechnet werden.
Art des Inhalts
Der Content-Type wird immer als:
- "application/json" (für JSON)
- "text/xml" (für XML)
charset muss der Zeichensatz des Beitrags sein, zum Beispiel "utf-8".
Jede Anfrage muss entsprechend der im Header angegebenen Zeichenkodierung korrekt kodiert sein
Unser System akzeptiert alle Unicode-Zeichen. Die Standardkodierung für JSON ist UTF-8 (ein Multi-Byte-Kodierungsschema). Die meisten JSON-Parser verarbeiten dies automatisch.
Autorisierung
"Basic", gefolgt von einer base64-Kodierung Ihrer Webdienste-Anmeldedaten im Format Benutzername:Passwort (ohne Leerzeichen).
z.B. Für den Benutzernamen webservices @example .com und das Passwort pa55word.
Base64 webservices @example .com:pa55word verschlüsseln, um d2Vic2VydmljZXNAZXhhbXBsZS5jb206cGE1NXdvcmQ= zu erhalten
Der endgültige Wert, der in die Kopfzeile aufgenommen werden muss, wäre in diesem Fall: Basic d2Vic2VydmljZXNAZXhhbXBsZS5jb206cGE1NXdvcmQ=
Akzeptieren
Das Format der Daten, die an Trust Payments übermittelt werden.
z. B. text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Zurück: Was ist 3DS API? Nächste: Umgang mit 3DS API Antworten
