Technischer Beitrag
Erste Schritte mit der Payment-Gateway-Integration
Um eine Zahlungsanwendung in Betrieb zu nehmen, müssen mindestens zwei verschiedene Arten der Integration beherrscht werden: Zunächst muss die erforderliche Hardware integriert werden (d. h. das Kartenlesegerät sowie das Gerät, mit dem es verbunden ist). Anschließend muss die Anbindung an ein zahlungsseitiges Backend erfolgen – beispielsweise an ein Online-Payment-Gateway (die Instanz, die eine Transaktion autorisiert und zur Abrechnung weiterleitet).
In früheren Beiträgenhabe ich ausführlich über die Hardware-Integration als Teil dieses Prozesses gesprochen – ein Aspekt, der sich als weniger komplex erweist, als man erwarten könnte. Denn bei ID TECH Kartenlesegeräten steht unser Universal SDK zur Verfügung, mit dem Geräte aus einer High-Level-Sprachumgebung heraus angesprochen werden können. Alternativ ist auch eine reine JavaScript-Lösung möglich, sofern Node JS in der Architektur eingesetzt wird. In jedem Fall ist die Kommunikation mit ID TECH Geräten kein besonders großer Aufwand.
Die entscheidende Frage lautet jedoch: Wie werden die vom Kartenlesegerät ausgelesenen Chip- oder Magnetstreifendaten in eine autorisierte Transaktion umgewandelt?
In der Regel ist der Kreditkartenverarbeiter, der die Anfragen abwickeln soll, bereits bekannt. Die eigentliche Herausforderung besteht daher darin herauszufinden, welche SDK-Unterstützung der Verarbeiter oder das Gateway für die Abwicklung von Online-Anfragen bereitstellt.
Die meisten Gateways und Verarbeiter bieten ein Entwicklerprogramm oder ein Online-Entwicklerportal an, über das SDKs für die Entwicklung von Zahlungsanwendungen bezogen werden können. Diese SDKs ermöglichen in der Regel die Erstellung von Frontend- und Backend-Komponenten für den Zugriff auf die Zahlungs-APIs des Verarbeiters. Die Zahlungs-APIs wiederum unterstützen die Übermittlung von MagStripe-Daten und/oder ICC-Daten (Chipkartendaten) über das Netzwerk an ein Backend für die Echtzeit-Autorisierung.
Die Zahlungsautorisierung ist nur eine von mehreren Online-Anfragetypen, die voraussichtlich unterstützt werden müssen. Einige weitere Anfragetypen sind in der nachfolgenden Tabelle aufgeführt.
Anfragetyp
Beschreibung
Auth
Zahlungsautorisierung anfordern
Conf
Eine vorherige Autorisierungsanfrage bestätigen
Offline
Eine Offline-EMV-Transaktion abrechnen
PreAuth
Kartendaten mit einem geringen Transaktionsbetrag auf Gültigkeit prüfen
Refund
Eine bereits abgerechnete Transaktion erstatten
Test
Verbindung zum Prozessor testen
VoiceReferralNotification
Den Prozessor über das Ergebnis einer Sprachautorisierungsanfrage informieren
Void
Wird verwendet, um eine noch nicht abgerechnete Transaktion zu stornieren
Wenn Sie die SDK-Dokumentation Ihres Zahlungsprozessors studieren, werden Sie feststellen, dass für jeden Transaktionstyp eine Vielzahl unterschiedlicher Ergebnis- und/oder Fehlercodes gilt. Wie lässt sich das Verhalten bei all diesen möglichen Fehlertypen testen? Die Antwort: Die meisten Prozessoren verwenden ein Schema, bei dem der Centbetrag einer Transaktion auf einen bestimmten Wert gesetzt werden kann, um in einer Test-Sandbox-Umgebung einen bestimmten Fehler auszulösen. (Wenn beispielsweise der Fehlercode für „Betrag zu hoch" 1243 lautet, kann der SDK es Ihnen ermöglichen, diesen spezifischen Fehler durch Einreichen einer Testtransaktion im Betrag von 12,43 $ auszulösen.) Einzelheiten entnehmen Sie bitte der SDK-Dokumentation Ihres Anbieters.
Viele Zahlungsprozessoren bieten vorzertifizierte (semi-integrierte) „In-App"-Lösungen an, mit denen Sie verschlüsselte Kartendaten mehr oder weniger transparent direkt an das Backend weiterleiten können – und Ihre Zahlungsanwendung damit außerhalb des PCI-Geltungsbereichs halten. Andere hingegen setzen voraus, dass Sie sich selbst um Fragen des Geltungsbereichs kümmern. In diesem Fall werden Sie verschlüsselte Kartendaten wahrscheinlich über das Netzwerk an Ihren eigenen, durch eine Firewall geschützten Server übertragen, wo die Kartendaten (mithilfe eines HSM) entschlüsselt werden, bevor sie an einen Acquirer oder ein Gateway weitergeleitet werden.
EIN BEISPIEL
Genug der allgemeinen Übersicht. Lassen Sie uns darüber sprechen, was es in der Praxis bedeutet, eine Integration mit einem Zahlungs-Backend durchzuführen.
Dieses konkrete Beispiel trifft natürlich nicht auf alle Fälle zu – kein einzelnes Beispiel kann das –, aber es vermittelt Ihnen einen guten Eindruck davon, was Sie bei der Integration mit einem Backend typischerweise erwartet.
In diesem Fall hatte ich die Aufgabe, eine Demo-App für ein „virtuelles Terminal" zu entwickeln, die Transaktionsdaten an CreditCall Testserver, um eine Live-Autorisierung für EMV-Transaktionen zu erhalten. CreditCall verfügt über einen Backend-Server-API, auf den per HTTPS über deren ChipDNA Direct APIzugegriffen werden kann, die sich wiederum mithilfe eines SDK in Java, C++, Perl oder anderen Sprachen „entwickeln lässt". Ich habe mich für die Java-Version entschieden.
Auf der ChipDNA Direct -Website habe ich mich für ein Entwicklerkonto registriert und erhielt schnell per E-Mail die Zugangsdaten für den CreditCall-Testserver. Ich habe außerdem das Java-SDK von CreditCall heruntergeladen und begonnen, mir den Beispielcode anzusehen. Mein Ziel war es, zu verstehen, wie EMV-Transaktionen zur Autorisierung eingereicht werden. Glücklicherweise zeigte eine der Beispielcode-Dateien, ExampleAuthEMV.java, genau die Art von Code, die ich benötigte.
Ich machte mich daran, zwei Java-Klassen zu schreiben: eine Servlet-Klasse zur Verarbeitung von HTTP-Anfragen eines browserbasierten Frontends sowie eine „Worker"-Klasse, die die vom Servlet erfassten Browser-Daten an das CreditCall-Backend weiterleitet. Erstere umfasste am Ende etwa 250 Zeilen Java-Code, Letztere 92 Zeilen.
Den Code für die Servlet-Klasse werde ich hier nicht zeigen, da es sich weitgehend um Standard-Java-Servlet-Code handelt – mit dem Unterschied, dass er TLV-Werte (die per AJAX als Formularfeldwerte übermittelt werden) zur Laufzeit in ein java.util.Hashtable-Objekt einfügt. Diese Hashtable wird dann an die statische authorize()-Methode meiner Worker-Klasse übergeben. Die Worker-Klasse verwendet die SDK-Hilfsklassen (Bibliotheksklassen) des CreditCall ChipDNA Direct, um ein com.creditcall.Request-Objekt zu erstellen, das anschließend an ein Client-Objekt übergeben wird, welches wiederum den CreditCall-Server aufruft. Hier ist der Code:
Dieser Code ist so knapp und selbsterklärend, dass er kaum weiterer Erläuterung bedarf. Das Praktische daran ist, dass die CreditCall- Request und Client -Klassen die Erstellung der notwendigen XML-Dokumente übernehmen, die letztendlich an den CreditCall-Server gesendet werden. Als Entwickler müssen Sie sich zu keinem Zeitpunkt selbst mit rohem XML befassen, es verarbeiten, parsen oder darum kümmern – ganz so, wie es sein sollte.
Bitte beachten Sie, dass Sie Ihre Testkonto-Zugangsdaten in den Zeilen 18 und 19 angeben müssen. (Die oben gezeigten Zugangsdaten sind fiktiv. Verwenden Sie den Code nicht unverändert!) In Zeile 69 legen Sie die URL des CreditCall-Endpunkts fest. Zeile 72 führt den eigentlichen ausgehenden HTTPS-Aufruf aus.
Der CreditCall-Server ist hinsichtlich der TLV-Tags, die Sie in Ihren Transaktionsdaten übermitteln, nicht besonders wählerisch – solange Sie diejenigen Tags einschließen, die wesentliche Kartendaten enthalten (also beispielsweise: Tags 5A und 57 für kontaktbehaftetes EMV; Tag 56 für kontaktlos; sowie 9F26 und 9F27 mit den Kryptogramm-Informationen). Als Antwort auf Ihre EMV-Daten gibt der CreditCall-Server in der Regel TLVs für die Tags 8A, 89 und 91 zurück, optional auch 71 oder 72 (falls Skripte an die Chipkarte übermittelt werden müssen). Der gewünschte Autorisierungscode befindet sich in Tag 89.
Durch Ausprobieren habe ich festgestellt, dass die CreditCall-Server-Applikation eine Transaktion nicht ohne Weiteres ablehnt, nur weil die Karte ein AAC-Kryptogramm liefert. (Den Kryptogrammtyp können Sie ermitteln, indem Sie die obersten Bits von Tag 9F27 prüfen. Nullen stehen für AAC, also eine Ablehnung.) Das ist jedoch nicht überraschend, denn die Empfehlung der Karte ist genau das: eine Empfehlung. Die endgültige Genehmigung oder Ablehnung einer EMV-Transaktion liegt in der Regel beim Acquirer. Die Entscheidung der Karte kann – und wird häufig – überstimmt.
Wie Sie sehen, lernt man beim Experimentieren mit diesen Dingen viele interessante Details über EMV. Nichts ist besser geeignet, um Payment-App-Code zu verifizieren, als eine Live-Autorisierung!
Suchen Sie weitere Hinweise zu EMV-Transaktionen? Besuchen Sie unsere Development Home -Seite in der ID TECH Knowledge Base. Laden Sie unser EMV-Entwicklungs-Whitepaperherunter. Oder rufen Sie einen unserer Experten gebührenfrei an, um mit einem Evaluierungskit loszulegen: