Beteiligte Komponenten bei SET Transaktionen (Teil 2)

Transkript

1 Beteiligte Komponenten bei SET Transaktionen (Teil 2) Im letzten Artikel, Beteiligte Komponenten bei SET Transaktionen (Teil 1), haben wir das Gateway und das Wallet kennengelernt. Jetzt kommen wir zum "Zentrum" der gesamten SET-Trilogie, dem Point Of Sale, kurz POS genannt. Die Händlersoftware (Payware) Ich werde immer wieder gefragt ob es möglich sei, diesen Teil selber zu programmieren z.b. für eine Linux-Plattform oder sich so die Kosten für die Software zu ersparen. Natürlich ist nichts unmöglich. Nach Hinterlegung einer Anmeldegebühr von US$ ,- steht es jedem frei, eine entsprechende Software zu entwickeln und deren Zertifizierung bei SETCO zu erreichen. Die notwendigen Spezifikationen gibt es bei: Der rein technische Teil umfasst: The SET Standard Book 1 Business Description The SET Standard Book 2 Programmer's Guide The SET Standard Book 3 Formal Protocol Definitions SET Glossary External Interface Guide Aber auch wenn man die Software nicht selbst entwickeln will, ist die Lektüre der oben angeführten Dokumente für Integratoren von SET empfehlenswert. Auf jeden Fall benötigt der Händler eine Software: die sogenannte Payware oder POS (Point Of Sale)-Software. Die wichtigsten Lieferanten in Europa dafür sind: Globeset, Trintech, IBM. Eine Matrix über die jeweils angebotenen Produkte, auch anderer Hersteller gibt es ebenfalls bei SETCO: Zusätzlich zu der verwendeten Software benötigt der Händler auch ein Zertifikat des Acquirers. Dieses erhält er im Zusammenhang mit seinem Händlervertrag. Im Normalfall gibt es einen Zusatzvertrag zur Abwicklung von Mail/Telefon-Order und SET-Transaktionen. (nur bei Verwendung von zertifizierter Software) POS-Systeme sind virtuelle Point-of-sale-Anwendungen, die das Händlersystem sowohl mit dem Kunden-Wallet (elektronische Brieftasche) als auch mit dem Zahlungssystem der Bank (Payment Gateway) verbinden. Sie arbeiten mit allen gängigen SET-konformen Applikationen anderer Hersteller sowie mit populären Shopsystemen zusammen, um die Autorisierung und den Zahlungsverkehr sicher abzuwickeln. Neben den neuen SET-Transaktionen (3KP), werden

2 außerdem weitere Features, wie z.b. certless (certificate-less) und walletless angeboten, sodaß der Anwender kein Zertifikat und / oder Wallet besitzen muß. Die folgende Erklärung des POS-Systems basiert auf dem Netlife/Globeset POS 1.4, ist jedoch aufgrund der Spezifikationen von SETCO für alle anderen Systeme gleichwertig. Das Netlife/Globeset POS ist erhältlich für Windows NT und Sun/Solaris (Sparc). Die API s und Adapter gibt es für C (Windows-Dll s) und Perl-scripts. Als Datenbanken kommen zum Einsatz: MS -SQL, Oracle. Auch wenn MS - Access über ODBC angesprochen wird - MS-Access ist keine aktive Datenbank (da sie ohne die nötige Jet-Engine nicht funktioniert) und ist daher für das POS nicht verwendbar. MySql kann über eine ODBC-Schnittstelle verwendet werden, es gibt jedoch keinerlei offiziellen Support. Von der Verwendung anderer Datenbanksysteme wie Progress, Sybase oder Informix rate ich wegen des nicht vorhersehbaren Integrationsaufwandes ab. Bestandteile des POS Basis des Netlife POS ist die SET-Protokollkomponente. An diese gegliedert sind Netzwerkschnittstellen, Datenbanken und zusätzliche funktionale Komponenten. Die folgende Abbildung zeigt eine Übersicht der Interaktion dieser Bestandteile. Shopping-Schnittstelle (POS Adapter)

3 Die Shopping-Schnittstelle stellt einen Mechanismus für Online-Shopping- Systeme zur Einleitung von Kauftransaktionen bereit. Mittels dieser Schnittstelle sendet das Shopping-System Bestellinformationen an das POS, das anschließend das Wallet im Browser des Kunden startet. Netlife liefert ein POS API, das die Anbindung einer Online-Shopping-Anwendung an das Netlife POS ermöglicht. Es werden auch fertige Adapter für OpenShop und InterShop angeboten. SET-Schnittstelle Die SET-Schnittstelle ermöglicht einen Zugriff auf andere SET-konforme Applikationen. Sie besteht aus einem TCP/IP-Server-Port, der SET-Nachrichten vom Kreditkarteninhaber (Wallet) empfängt, Händlerinformationen hinzufügt und sämtliche Nachrichten über das SET- Protokoll an die Schnittstelle zum Acquirer (Payment Gateway) sendet. Administrationsschnittstelle Die Administrationsschnittstelle ist eine Schnittstelle zum Netlife POS, auf die mit einem Standard-Browser zugegriffen werden kann. Diese Verbindung wird über eine SSL-Verschlüsselung geschützt. Folgende administrative Funktionen können durchgeführt werden: Start, Stop, Wiederanlauf und Überwachung des Status des POS-Servers Überprüfung der zur Verfügung stehenden Zertifikate Konfiguration der Server-Logdateien, URL-Daten, Ports und Datenbanken Konfiguration und Überwachung der aktuellen Händler Manuelle Stapel- und Transaktionsverarbeitung zur Durchführung der Zahlungsabwicklung POS-Datenbank Nach der Installation auf der Web-Site des Händlers benutzt das POS dessen Datenbank-Server, um auf mehrere Datenbanken während des Normalbetriebs zugreifen zu können. Diese sind: Transaction database Authorization database Batch database Certificate database Key database

4 Diese Datenbanken werden bei der Installation erzeugt. Händler können sie mit den Tools Dritter abfragen, um zusätzliche Berichte zu jenen des POS zu generieren. Es macht beispielsweise durchaus Sinn für eine Übernahme in die Finanzbuchhaltung mittels SQL Buchungssätze aller tatsächlich durchgeführten Transaktionen der einzelnen Kreditkartenorganisationen zu erstellen, oder auch nur eine Liste zur Saldenabstimmung zu erzeugen. Auch eine Auswertung der Transaktionen abhängig von der eigenen Kunden-Datenbank kann für Fakturierung und Warenwirtschaft notwendig sein. Datenbankstruktur Die Schlüsseltabelle (Zertifikatsregistrierung) dient zum Speichern der privaten Schlüssel des Händlers und zur Information über die Zertifikatsregistrierung. Private Schlüssel sind durch ein vom Händler bestimmtes Paßwort geschützt. Zertifikatstabellen werden zum Speichern aller Zertifikate verwendet. Transaktionstabellen dienen zum Speichern des Transaktionsstatus und werden im Zusammenhang mit der Autorisierung sowie mit Stapeltabellen benutzt. Autorisierungstabellen verwendet man zum Speichern aller Informationen zur Zahlungsautorisierung und -erfassung. In Stapeltabellen werden Stapelinformationen gespeichert (Batches). POS-Nachrichtenverlauf

5 Der Ablauf der Zahlungsverarbeitung im SET-Protokoll beruht auf Nachrichtenpaaren zwischen sowohl dem Karteninhaber und dem Händler als auch dem Händler und dem Payment Gateway. Nachfolgend wird anhand eines Diagrammes der Nachrichtenverlauf erläutert. 1. Der Kunde füllt den Warenkorb. 2. Er bestätigt die Bestellinformationen und wählt eine Bezahlungsmethode aus. Das Shopping-System erstellt eine Kickoff-Nachricht. 3. Das Shopping-System sendet die Kickoff-Nachricht an das POS. 4. Das POS erstellt eine Wakeup-Nachricht und sendet sie zurück an das Shopping-System. 5. Die Wakeup-Nachricht gelangt über den Webserver zum Browser. 6. Der Browser wurde dem SET-Standard gemäß so konfiguriert, daß er beim Erhalt der Wakeup-Nachricht das Wallet aufruft. 7. Das Wallet nimmt mittels der URL der Wakeup-Nachricht Kontakt zum POS auf. 8. Das POS antwortet auf die Anforderung der Kaufinitialisierung. 9. Das Wallet sendet eine Kaufanforderung an den Händler. 10. Das POS schickt eine Autorisierungsanforderung an das Payment Gateway. 11. Das Gateway sendet eine Autorisierungsantwort zurück zum POS. 12. Das POS sendet die Autorisierungsantwort an das Shopping-System. 13. Das POS sendet eine Erfolgs- oder Fehlermeldung an das

6 Wallet. Weil das Thema Sicherheit gerade bei Kreditkarten eine gewichtige Rolle spielt, hier noch ein paar Worte zur Verschlüsselung. Die SET Spezifikationen basieren auf folgenden Algorithmen und Mechanismen: SICHERHEITSMECHANIS MUS ALGORITHMUS STANDARD SCHLÜSSELLÄNGE Signatur RSA PKCS Bit Duale Signatur RSA Neuentwicklung 1024 Bit für SET Datenverschlüsselung DES PKCS 7 56 Bit Hashing SHA SHA-1 Asymmetrische RSA PKCS (Merchant) Verschlüsselung und 1024 (Payment Gateway) Zertifikate RSA X.509 v Soviel zum allgemeinen Teil. Wenn sich also ein Händler entschließt, seinen Kunden Kreditkartenzahlungen anzubieten, sollte er folgende Punkte beachten: (*) Der Betrieb eines POS ist mit einem gewissen finanziellen Mindestaufwand verbunden. Soferne der Shop bei einem ISP gehostet wird, sollte dieser die Installation von Fremdsoftware gestatten, die nötigen Datenbanksysteme unterstützen, Zugriff auf Log-Dateien gewähren, allenfalls Software-Updates ermöglichen. Dies ist natürlich mit laufenden Kosten verbunden (vor allem die Datenbanken). Bei Betrieb auf einem eigenen Server fallen diese Punkte weitgehend weg, es sollte natürlich ein Administrator mit dem POS-System vertraut sein. Auch wenn die angebotenen Adapter nur mehr mit Parametern versorgt werden müssen, bzw. das API für Programmierer keine Hindernissse darstellt, darf man den Integrationsaufwand nicht vernachlässigen. (*) Hat man jetzt sein POS auf einem Rechner installiert, so ist es bis zum reibungslosen Funktionieren desselben nur mehr ein ganz kleines Stück Arbeit. Eine entsprechende Datenbank ist anzulegen, um die Tabellen kümmert sich dann das POS. (*) Eine ODBC-Schnittstelle (bei SQL) ist zu definieren oder ein Oracle Client ist einzurichten.

7 (*) Das POS ist mit den Datenbankinformationen zu versorgen. (*) Der Händler mit seinen Basisdaten und den notwendigen Acquirer-Zertifikaten (von Visa und/oder Mastercard) ist anzulegen. Erhalt der Händler- und Acquirer-Zertifikate über das Gateway ist das POS betriebsbereit und mit Hilfe der zur Verfügung gestellten Demo-Applikation, der ASP-Demo, den Perl-Scripts oder dem C-Interface können SET oder 2KP Transaktionen durchgeführt werden. Nach Jetzt folgt noch die Integration in die Shop-Umgebung des Händlers mit dem entsprechenden Adapter oder einem API und ein weiterer SET-Shop ist online. Bei Verwendung eines generischen Perl-Adapters ist es auch möglich Shops auf Linux-Servern mit SET-Funktionalität auszustatten. Adapter/API: Folgende Adapter gibt es für Windows NT: ASP-Adapter Intershop-Cartridge OpenShop-Cartridge C- oder Perl- API Der Unterschied zwischen Adapter und Cartridge besteht darin, daß der Adapter universell einsetzbar ist und daher für jede Shoplösung unter ASP geeignet ist

8 (z.b.: Site/Commerce-Server von Microsoft und eigene Lösungen), wogegen die Cartridge fix mit dem dazugehörigen Produkt verbunden ist und auch die Lizenzierung abhängig von den jeweiligen Produkten erfolgt. Folgende Adapter gibt es für Sun/Solaris: Intershop-Cartridge OpenShop-Cartridge C- oder Perl- API Ein generischer Adapter besteht aus einem StoreFront-Adapter (SA) und einem POS-Adapter (PA), die auf verschiedenen Servern mit unterschiedlichen Plattformen laufen können. Das bedeutet, daß der SA in Perl unter Linux laufen kann, und mit einem PA auf WinNT kommuniziert. Transaktionen Eine Kreditkartentransaktion besteht immer aus 2 Schritten. 1. die reine Autorisierung 2. die nachfolgende Buchung, wobei der Buchungsbetrag vom Autorisierungsbetrag abweichend sein kann. Der klassische Fall für einen abweichenden Buchungsbetrag ist eine Hoteltransaktion: Der Kunde checkt im Hotel für 3 Nächte ein, es werden sofort 3.000,- autorisiert. Beim Auschecken nach 2 Nächten werden jedoch nur 2.000,- gebucht. Beim Auschecken nach 4 Nächten werden dann 4.000,- gebucht. Die Transaktion ist erst nach der erfolgten Buchung abgeschlossen, und der Händler erhält auch den tatsächlich gebuchten Betrag. Im POS erfolgt die Autorisierung immer Online (im Zuge der Einkaufstransaktion) Die Buchung (Capture) kann zu einem späteren Zeitpunkt (nach Warenversand) durchgeführt werden. Es besteht auch die Möglichkeit, Autorisierung und Buchung gleichzeitig durchzuführen. Dies ist zweckmäßig bei "virtuellen Waren" (z.b.: Software- Download oder Informationszugang) wo der Kunde seine Ware sofort erhält und auch keine Teillieferungen möglich sind. Abhängig von der Art der gebotenen Waren oder Dienstleistungen können 2 verschiedene Transaktionstypen verwendet werden. Aufgrund des Transaktionstyps wird im POS die Unterscheidung getroffen ob eine spätere Buchung möglich ist oder ob die Buchung (Capture) sofort durchgeführt wird. Für physikalischen Warenversand empfiehlt sich: Autorisierung durchführen und in einer späteren Transaktion (über Software oder POS-Administration) das dazugehörige Capture durchzuführen.

9 Für virtuelle Waren oder Dienstleistungen (Download...) empfiehlt sich: Autorisierung und Capture in einer Transaktion durchzuführen. Capture: Erst durch das Capture wird aus einer Autorisierung eine tatsächliche Transaktion, die in einem Batch über das Gateway an das Kreditkarteninstitut gesandt wird. Batch: Zu einem definierten Zeitpunkt (oder manuell) sollte periodisch ein sogenannter Batch an die Acquirer gesandt werden. Dieser Batch entspricht im realen Leben dem Kassenabschluß am Terminal und bewirkt die Auszahlung (Verrechnung) der Zahlbeträge an den Händler durch das Kreditkarteninstitut. ede Transaktion ist im POS mit allen notwendigen (bzw. vom Shop zur Verfügung gestellten) Informationen abgespeichert. J

10 Unabhängig von der TransaktionsID des Shops wird im POS eine Local ID Merchant of the transaction (LIDM genannt) gebildet. Diese LIDM begleitet die SET-Transaktion durch alle Instanzen, d.h. sie ist im Wallet (soferne verwendet) am Gateway und im Host des Kreditkarteninstitutes. Im Falle eines Einspruches oder Reklamation kann über diese LIDM die Transaktion rekonstruiert werden. Die LIDM kann neben der Shop Transaction ID natürlich auch als Referenz zu Händler-eigenen Kundendatenbanken herangezogen werden. Stornos (reversal), Gutschriften (debit) oder Betragsänderungen (adjustment) bei Teillieferungen oder Überlieferungen sind über die POS-Administration möglich. Je nach Transaktions-Anfall bietet sich natürlich die Möglichkeit eine Batch- Applikation zur Verfügung zu stellen, die unabhängig von der POS- Administration deren Funktionalitäten zur Verfügung stellt. Der Händler erhält von den Kreditkarteninstituten verschiedene Händlernummern zugeteilt unter denen er seine Transaktionen mittels Batch einreicht. Er erhält je nach Vertrag und Periodizität der Batches entsprechend seine Kontoauszüge von den Kreditkarteninstituten. Diese verschiedenen Händlernummern erleichtern die Abstimmung von 2KP-, 3KP- Transaktionen und Transaktionen in verschiedenen Währungen mit dem jeweiligen Kontoauszug. Payment-Service Wenn der Aufwand für eine eigene POS-Installation zu groß ist oder der ISP das nicht zulässt, gibt es auch noch die Möglichkeit der Miete eines POS-Services. Was ist das Payment-Service und was bringt mir dieses Service? Ganz einfach: der Händler möchte seinen Online-Kunden natürlich auch die sichere Zahlungsmöglichkeit SET TM (Secure Electronic Transaction) anbieten, findet aber, daß der Kauf einer eigenen Software (POS) zu aufwendig ist. Das Payment-Service ist funktional die gleiche Software wie das MerchantPOS, nur daß mehrere Shops ein und dasselbe Service nutzen (mieten) und trotzdem nicht auf die Daten des anderen Shopbetreibers zugreifen können. Jeder Shop hat einen eigenen Zugang zum POS, und da man sich das POS nun mit mehreren Shopbesitzern teilt bleiben die Kosten auch geringer. Vorteile Keine zusätzlichen monatlichen Providerkosten Keine eigene Domäne nötig Für jeden Shopbetreiber leistbar Keine Wartungskosten Geringere Aufwendung für Integration (tatsächlich liegt der Integrationsaufwand für das Miet-POS händlerseitig im Stunden-Bereich.) Von SET4U gibt es 3 Varianten des Payment-Services:

11 SET-light Dieses Service beinhaltet die Miete des POS und des Store Front-Adapters, die "Bezahlseite" wird von SET4U über eine sichere Verbindung zur Verfügung gestellt. Auf der Bezahlseite wird ein Logo des Händlers eingebunden, die Bezahlseite läuft allerdings auf Servern von SET4U. SET-light+ Dieses Service entspricht SET-light mit einigen "kosmetischen" Zusatzfeatures. Die "Bezahlseite" wird von SET4U nach Angaben des Händlers gestaltet oder wird vom Händler zur Verfügung gestellt. Die Seite liegt wie bei SET-light auf den Servern von SET4U. Grundsätzlich ist also mit SET-light+ eine Anpassung an die Corporate Identity (CI) möglich. Technische Voraussetzung für die Durchführung ist ein Link (SSL) von z.b. dem Button "Zur Kassa" auf die Bezahlseite. Um die Transaktionen durchzuführen benötigt die Bezahlsoftware (POS) einige Informationen wie den Betrag, Auftragsbeschreibung, Währung, die der Shop über eine sichere Verbindung an das POS übergibt. Der Ablauf einer Transaktion gestaltet sich wie folgt 1. Shop --> Store Adapter (gemietet) 2. Store Adapter --> POS 3. POS --> Kreditkartenorganisation 4. Kreditkartenorganisation --> POS 5. POS --> Store Adapter 6. Store Adapter --> Shop

12 Der Kunde erhält dann eine Bezahlseite: oder eine nach den Vorstellungen des Händlers zusammengestellte. SET-complete Dieses Service beinhaltet die Miete des POS, der Store Adapter wird vom Händler gekauft und kann daher im Shop des Händlers direkt eingebunden werden. Eine vollständige Anpassung an eine Corporate Identity ist dadurch möglich, allerdings läuft nun alles in der Web Site des Händlers. Sonst beinhaltet dieses Service die gleichen Optionen wie "SET-light". Technische Voraussetzungen: Es werden von der Bezahlseite des Händlers alle notwendigen Informationen über eine sichere Verbindung (SSL) an das POS übergeben. Der Ablauf einer Transaktion: 1. Shop (Store Adapter) --> POS 2. POS --> Kreditkartenorganisation 3. Kreditkartenorganisation --> POS 4. POS --> Store Adapter (Shop)

13 Weitere Informationen zu den hier vorgestellten 3 Services erhalten Sie bei: SET4U Payment-Service Schlußbemerkung Unabhängig von anderen Zahlungsweisen wie e-cash, cybercash, net900, und was immer die Zukunft bringen wird, ist die Zahlung mit Kreditkarten die einzig wirklich internationale Möglichkeit - und um allen Sicherheitsapekten gerecht zu werden, bietet der Einsatz von SET dem Händler derzeit den höchsten Standard. Auch wenn die Nutzung von Wallets zur Zeit nicht allzu hoch ist, ist alleine die Online-Autorisierung für den Händler von entscheidendem Vorteil gegenüber herkömmlichen MailOrder/TelefonOrder Transaktionen und die angekündigte Verwendbarkeit von MAESTRO-Karten im Rahmen von SET wird für den Händler auch ein Anreiz sein, diese Zahlungsmethode anzubieten. Shops aus aller Welt, die SET verwenden, finden sich auf goset.org Links zu anderen Sites Verwandte Artikel SET allgemein SET Teil 1