e-Payment und m-Payment Autor Lars Wachsmuth Datum 29.11.2001

Inhalt e/m-Payment Einführung Zahlsysteme Geschäftsmodelle PaymentWorks X-Pay 2.1 Architektur Zahlungsablauf Komponenten PaymentWorks Mobile Anforderungen

e-Payment und m-Payment Einführung

e-Payment Zahlungssysteme Wertcoupons (Aufladung mittels Credit oder Debit) Smartcards (Hardwarechip) Electronic money (aufladbar, Vorauszahlung) Überweisung/Schecks (wie physisch) Kreditkarten

Allgemeiner Überblick Prozess elektronische Zahlungsabwicklung Clearing Netzwerke Autorisierung & Verbuchung Issuer Aquirer Abrechnung Autorisierung Konsumenten Einkauf Händler / Service-Anbieter

Geschäftsmodell Acquirer / Zahlungssystembetreiber Der Acquirer ist die Bank des Händlers Händler haben eine Vertragsbeziehung mit dem Acquirer Zahlungsabwicklung für Akzeptanzstellen von Kredit- und Zahlungskarten Breitgefächerte Akzeptanz moderner Zahlungsmittel Einheitliches Abrechnungswesen für Händler Betrieb eines Payment Gateways Geschäftsmodell basiert auf Transaktionsgebühren (Disagio) Händler Konsumenten Aquirer Issuer Clearing Netzwerke Einkauf Autorisierung Autorisierung & Verbuchung Abrechnung X-PAY products for the acquirer Twister including X-PAY Gateways X-PAY Wallet Clearing Accessors Data Base Accessors Beispiele: B+S Card Service GmbH Citibank Card Acceptance

Geschäftsmodell Issuer Der Issuer ist die Bank der Kunden Ausgabe von Kredit- , Kunden- oder EC-Karten an den Kunden Kreditgewährung bzw. Bereitstellung von Zahlungsmöglichkeiten Plastikkarten Software zur Erleichterung von e-Commerce Zahlungen (Wallet) Angebot zusätzlicher Finanzdienstleistungen (z.B. Banking) Geschäftsmodell basiert auf Grundgebühr für Karten, sowie Transaktionsgebühren für Kunden und Acquirer (Interchange) Händler Konsumenten Aquirer Issuer Clearing Netzwerke Einkauf Autorisierung Autorisierung & Verbuchung Abrechnung X-PAY products for the issuer: X-PAY Wallet Beispiele: Deutsche Bank Commerzbank

Geschäftsmodell Commerce/Payment Service Provider Commerce Service Provider (CSP) übernehmen Hardware- und Software-Hosting (Shop-Hosting) Payment Service Provider bieten neben CSP-Services auch Weiterleitung von Zahlungstransaktionen Anschluß an Online-Zahlungssysteme und Clearing-Netzwerke Betrieb des Paymentservers für den Händler Geschäftsmodell basiert auf Einnahmen für die Hosting-Dienstleistung (Miete) und Transaktionsgebühren C S P Händler Konsumenten Aquirer Issuer Clearing Netzwerke Einkauf Autorisierung Autorisierung & Verbuchung Abrechnung X-PAY products for the CSP/PSP: X-PAY Server X-PAY Server Standard Shop Cartridge Beispiele: Telecash Pago

e/m-Payment Anforderungen Einfachheit ist entscheidend für die Akzeptanz von Zahlungssystemen Einfache Verwendung von Payment-Dienstleistungen durch Kunden und Händler Einfache und kosteneffiziente Integration bei Händler und Acquirer Sicherheit der Zahlungstransaktionen ist ein zentraler Erfolgsfaktor für das Online-Shopping Unterstützung des SET™-Standards und von Weiterentwicklungen (3D-SET, 3D-SSL) wie auch alternativer Standards als Migration zu SET™(z.B. SSL) Online Verarbeitung von international verbreiteten aber auch nationalen Zahlungsmethoden Schnelle und flexible Integration neuer Zahlungsmethoden Multipayment-Fähigkeit aufgrund unterschiedlicher Eignung von Zahlungsarten hinsichtlich Zahlungshöhe

Einschub: SSL und SET 1. SSL Secure Socket Layer entwickelt von Netscape zwei neue Protokolle über der Transportschicht: SSL Record, SSL Handshake Handshake: Steuerprotokoll, Record: Datenübertragung Server ist authentisch (Zertifikat von CA) bei SSL-3 Client ebenfalls authentisch Authentifizierung erfolgt über symmetrische 2KP Datenintegrität wird geprüft Datenübertragung verschlüsselt mittels Session Key (generiert vom Client) Manko: Außerhalb der USA dürfen nur 40 Bit des Session Key verschlüsselt übertragen werden

Einschub: SSL und SET 2. SET Secure Electronic Transaction offener Standard von VISA & Mastercard zur Abwicklung von Zahlungen (www.setco.org) Zertifikat für Soft/Hardwareprodukte vergeben, die SET-Anforderungen erfüllen alle Parteien (Kunde, Händler, Gatewaybetreiber) authentisch alle Nachrichten verschlüsselt (2KP, 3KP) und signiert Zahlungsgarantie für Händler Komponenten: Wallet, MerchantServer, PaymentGateway, CA im Moment 16 zertifizierte Hersteller SET bietet wesentlich höhere Sicherheit als SSL, ist aber aufwendig zu implementieren und wird darum von vielen Anbietern nicht unterstützt

e-Payment PaymentWorks X-Pay

e-Paymentsystem - PaymentWorks X-Pay PaymentWorks X-Pay 2.1 ist eine umfassende e-Payment Softwarelösung X-Pay Java Wallet 2.1 X-Pay Server 2.1 X-Pay Gateway 2.1 PaymentWorks X-Pay unterstützt verschiedene Protokolle SET SSL (HTML-Wallet, moSET) derzeit verfügbare Zahlungsarten Kreditkarte Debitkarte Kundenkarte ZKA Geldkarte GeldKarte Add-On X-Pay Server X-Pay Wallet X-Pay Gateway Brokat Server Technologies

PaymentWorks X-Pay Produkt-Architektur

Funktionsweise How it works SET-Zahlungstransaktionen mit PaymentWorks X-Pay How it works Consumer 1 Kunde sendet Zahlungsanfrage zum Shop-Server Shop Server sendet verfügbare Zahlungsmethoden zum Kunden SET X-Pay Gateway Browser Netzwerk Clearing 4 2 Kunde wählt Zahlungsmethode Kreditkarte via SET X-Pay Wallet wird vom Webserver des Zahlungssystembetreibers geladen 1 3 2 Clearing Netzwerk Shop Server X-Pay Merchant Webserver* 3 X-Pay Wallet sendet Zahlungsanfrage zum X-Pay Server 4 X-Pay Server sendet Autorisierungs-anfrage zum X-Pay Gateway X-Pay Gateway sendet Anfrage an Clearing Netzwerk Die Antwort vom Clearing Netzwerk geht zurück zum X-Pay Gateway X-Pay Gateway sendet Antwort der Autorisierungsanfrage zum X-Pay Server X-Pay Server sendet Antwort zur Zahlung an das X-Pay Wallet Zahlungssystembetreiber CGI / RDO z.B. Shopping Card Check

PaymentWorks X-Pay Wallet Das X-Pay Java Wallet ermöglicht dem Kunden einen einfachen und sicheren Einkauf im Internet. Sicherheitsfunktionen Verwaltung von Zertifikaten und digitalen Signaturen Verschlüsselung Kundenkomfort Profile von Zahlungsinstrumenten ECML – Unterstützung / Überwachung Einkäufe Anpassung und Sicherheit durch Provider gesteuert Signed-Java Applets (Java VM 1.1) Automatischer Update Mechanismus Multi-Payment Unterstützung 4-Layer-Design Dynamischer Download von neuen Payment Kernels Technical Slide --> APPENDIX ECML: = "Electronic Commerce Modeling Language” Standard of: American Express, AOL, Brodia (formerly Transactor Networks), Compaq, CyberCash, IBM,MasterCard, Microsoft,SETCo, Sun Microsystems, Trintech, and Visa. ECML - WHAT IS IT? ECML is a standard, in order to name form fields in HTML-pages Form fields needed in online shops were named The software supporting ECML is able to recognize them and to fill them out automatically ECML is open for all. The customer opts for a single wallet and is then able to purchase at all merchants supporting ECML standard.

PaymentWorks X-Pay Server Der X-Pay Server verbindet Händler, Kunden-Wallets und Systeme der Acquirer. Umfangreiche Funktionalitäten Geteilte Zahlungen, Kredite, Rückbelastung etc. Batch Processing Einheitliche Schnittstelle zur Mall-Software SET und SSL Unterstützung SET- zertifizierter Merchant Server moSET via integriertem SSL-Support für “HTML-Wallets” “Out-of-the-box”-Connectivity für Standard Shop Software (z.B. Intershop) Hohe Vielfalt an unterstützten Plattformen und Datenbanken MS Windows NT/2000+, SUN Solaris 2.5/6, Linux, IBM AIX 4 Oracle, MS-SQL Technical Slide --> APPENDIX

PaymentWorks X-Pay Gateway Das X-Pay Gateway verbindet Händler- und Endkundensysteme mit Zahlungsnetzwerken zur Abwicklung von Zahlungen. Multi-Channel-Fähigkeit Einsatz mehrerer Gateways Internet, Web-TV… SET-zertifiziertes Payment Gateway Flexible Anbindung an Clearing Netzwerke Einsatz von Brokat Server Technologies (Twister) und verschiedener Accessoren Interoperability:

m-Payment PaymentWorks Mobile

mPayment is a key enabler Mobile Geschäftsfelder mPayment is a key enabler Quelle: McKinsey research

m-Payment - Teilnehmer und Prozess Merchants Mobile Wallet / Payment Provider Financial Service Provider Consumer Produkte/ Services Clearing/ Settlement Einleitung Payment Payment Info BestätigungPayment Payment Charging

Mobile Payment Anforderungen Was will der Kunde?? Bedienfreundlichkeit, Nutzbarkeit Verfügbarkeit Bevorzugte Bezahlmethoden Vertraulichkeit Geringe Kosten Multi-Channel Services

Mobile Payment Anforderungen Was will der Merchant?? Zugang zu vielen Kunden Verhinderung von Betrug Einfache Integration der Merchant-Software Neue und innovative Geschäftsmodelle

Mobile Payment Anforderungen Was will die Marketingabteilung des Payment Providers?? Marktanteile gewinnen Erhöhung der Erträge Kurze Zeit zum Markt Möglichkeit pre-paid-Systeme zu integrieren Maßgeschneiderte Authentifizierungsmethoden

Mobile Payment Anforderungen Was will die technische Abteilung des Payment Providers?? Einfache Auslieferung und Installation bei Merchants und Kunden Scalability, Reliability, Integrierbarkeit in existierende IT Systeme Fähigkeit Payments über verschiedene Finanz- und Clearingnetzwerke abzuwickeln

Brokat Paymentworks Mobile Architektur HTML WAP SMS IVR System Administration Consumers WTLS HTTPS ISO 8583 or others Networks Merchant Management System Routing Module Clearing Authentication Management System (AMS) Customer Administration Open Payment Kernel Financial Service Provider Shop Server* Merchant Component Merchants Merchant Billing System Virtual Customer Card Mobile Wallet / Payment Provider

Paymentflow PaymentWorks Mobile 1 Der Kunde fordert(request) eine Angebotsbeschreibung an (Bestellinformation), die den Zahlbetrag und die eindeutige Identifikation des Angebots enthält. Der erste Teil des Payment ticket (generiert durch den Merchant) wird zur Identifikation benutzt. 2 Die Bestellinformation, Betrag und der erste Teil des Payment ticket werden vom Kunden mittels eines Redirect an den Payment Provider weitergeleitet. Diese Aktion initiiert das Payment. Der Payment Provider bestätigt die Information, indem er zusätzliche Informationen bei der Merchant Component anfordert. 3 Der Payment Provider bittet den Kunden, den Payment-Prozess zu authorisieren und zu authentifizieren. 4 Jetzt schickt der Payment Provider den ersten Teil des Payment ticket, die Bestellinformation und den Betrag an den Merchant (Merchant Component) und bittet um Bestätigung (confirmation). Nach einem erfolgreichen Check der empfangenen Informationen, schickt die Merchant Component den zweiten Teil des entsprechenden Tickets (den Voucher) zusammen mit Lieferinformationen an den Payment Provider. 5 Der Payment Provider initiiert das Payment am entsprechenden Payment Backend. Abhängig vom Payment Instrument können nun verschiedene Aktionen am Payment Backend gestartet werden. Nach erfolgreichem Payment werden die Informationen aus Schritt 4 durch den Payment Provider von der Merchant Component zum Kunden weitergeleitet. 6 Der Kunde schickt den Voucher an den Merchant und erhält von diesem die bestellten Güter/Leistungen.

Anwendung in Produktion Pan-Europäisches Mobile Portal, Joint-Venture von T-Online und T-Mobile, Töchter der Deutschen Telekom Betreiber: One2One (GB), T-D1 (Deutschland), max.mobil (Österreich) (> 25 Mio. Kunden) Payment business model: T-Motion erhebt Gebühren für die Anbindung von Merchants an Payment Services Eingesetzte Lösung: PaymentWorks Mobile Clearing mit Debit and Credit Karten Micropayments mit VCC und Clearing logic Customer und Merchant self-help interfaces (Administration)

Andere Anbieter von m-Payment-Software Trintech (PayWare mAccess) 724/Tantau (MSP, WIP) IPIN (vor allem Paymentsoftware für Banken) Aether Systems (M Wallet, Wireless Banking) Jalda (Ericsson+HP, custom solutions) Qpass (Connected Commerce Platform) Trivnet (WiSP) Thyron (YES) Sonera (Mobile Pay) Paybox (Endkundenanbindung)

Danke für Ihre Aufmerksamkeit!