Payment API. Jan Fleischhauer, Angelika Zelosko. Vertiefungsveranstaltung: Mobile Anwendungen. Fachhochschule Wiesbaden Studiengang Medieninformatik

Jan Fleischhauer, Angelika Zelosko Vertiefungsveranstaltung: Mobile Anwendungen Fachhochschule Wiesbaden Studiengang Medieninformatik 25. Februar 2008

Inhaltsverzeichnis 1 Motivation 1 2 Ablauf aus Benutzersicht 2 3 Aufbau 3 4 Architektur 4 5 Payment Informationen 5 6 Ablauf aus Entwicklersicht 8 A JAD-Datei 12 i

1 Motivation Zahlen Sie bar oder mit Karte? Demnächst könnte die Antwort auf diese Frage lauten: Weder noch. Ich zahle per Handy. Das Handy entwickelt sich immer mehr zum Multifunktionsgerät. Getreu dem Motto: Telefonieren war gestern! Jetzt ist auch Bezahlen per Mobiltelefon möglich. So kann man bei einigen regionalen Verkehrsbetrieben seine Fahrkarte über eine Software auf sein Handy laden. Nachdem sich der Kunde registriert hat, ist er berechtigt die von Handy-Ticket [1] enwickelte Software zu installieren. Die Authentifizierung findet über eine PIN statt, die beim Kauf eingegeben wird. War diese erfolgreich, bekommt der Fahrgast die Fahrkarte auf sein Handy geschickt. Dieser Service wird bereits in Hamburg, Dresden, Düsseldorf und anderen Städten angeboten. Die Vorteile hierbei liegen auf der Hand. Das ständige Bereithalten von Kleingeld für den Kauf am Automaten entfällt. Ebenso wie die Wartezeiten vor einem Fahrkartenautomat. Auch auf Seiten der Verkehrsbetriebe lassen sich Vorzüge verzeichnen. So können die Wartung und Leerung der Automaten durch vermehrtes Nutzen des Dienstes durch Fahrgäste reduziert werden. Ein weiteres Beispiel ist das Parken in der Stadt. Es stellt sich jedes Mal aufs neue als Herausforderung dar. Nach etlichen Runden der vergeblichen Parkplatzsuche schließt sich die Suche nach Kleingeld an, um beim Versuch einen Parkschein zu ziehen, festzustellen, dass der Automat defekt ist. In der Wiesbadener Innenstadt wird hierfür eine Alternative geboten. Dort wird der Park-Service von Schlauer Parken [2] angeboten. Zum Starten und Beenden eines Parkvorgangs, ruft der registrierte Benutzer eine kostenfreie Telefonnummer an. Nach dem Start-Anruf erhält der Parkende eine SMS mit der Startzeit. Die SMS nach dem Beenden-Anruf enthält die Parkdauer und die anfallenden Gebühren, welche per Lastschrift oder über ein Pre-Paid-Konto abgerechnet werden. Die minutengenaue Abrechnung erspart das eventuelle Knöllchen bei Überziehung der Parkdauer oder spart Geld, welches verlorengeht, wenn die Parkdauer kürzer als erwartet war. Dies sind nur zwei Beispiele, bei denen das Mobiltelefon als Zahlungsmittel eingesetzt wird. Ob die Abwicklung der Zahlungen per Lastschrift, Kreditkarte oder die Handyrechnung läuft, ist abhängig von der Anwendung, die sich dahinter verbirgt. Wie können nun solche mobilen Anwendungen entwickelt werden? - Durch Verwendung der Payment API. Diese ist ein optionales Paket für JavaME und wird im Java Specification Request 229 (JSR-229) [3] spezifiziert. An der Entwicklung der Payment API, sind Firmen wie Nokia, Siemens, Sony Ericsson, Symbian und andere namhafte Vertreter der Mobile Industry beteiligt. Die aktuelle Version der PAPI, 1.1.0, ist seit Januar 2006 verfügbar. Dieses Dokument soll die Funktionsweise der Payment API veranschaulichen. Hierfür schauen wir uns zunächst in Abschnitt 2 an, wie der Ablauf eines Kaufvorgangs für den Benutzer aussehen kann. Anhand von Bildern der Anwendung Bullshit-Bingo wird der Ablauf erläutert. Damit über eine mobile Anwendung Zahlungen getätigt werden können, sind neben dem Entwickler weitere Mitwirkende notwendig. Welche Personen dies genau sind und welche Aufgabe sie übernehmen sehen wir uns in Abschnitt 3 an. Nachdem klar ist, welche Schnittstellen eine Payment-Anwendung nach außen hat, bli- Jan Fleischhauer, Angelika Zelosko 1

cken wir in Abschnitt 4 in das Innere der Payment API. Dabei werden die Komponenten der Payment API vorgestellt, ebenso wie deren Zusammenspiel. Wie bei einem Kauf von Waren im Supermarkt, ist es auch in der mobilden Welt nicht anders, werden bestimmte Informationen für den Kauf eines Features benötigt. Genauso wichtig wie der Preis, ist auch die Zahlungsart, auf deren Wege der Kaufbetrag beglichen werden soll. Welche Informationen für eine Payment-Anwendung vorhanden sein müssen und wie diese beschafft werden können, wird in Abschnitt 5 beschrieben. Im letzten Abschnitt (Abschnitt 6) befassen wir uns mit dem Ablauf einer Zahlungstransaktion aus Sicht des Enwicklers. Dabei wird auf die wesentlichen Schritte, unterstützend durch Codebeispiele eingegangen. Die Codebeispiele stammen aus der Anwendung Bullshit-Bingo, aus der bereits in Abschnitt 2 Bilder gezeigt werden. 2 Ablauf aus Benutzersicht Nachfolgend wird der Ablauf einer Payment-Transaktion beschrieben. Dies geschieht anhand von Bildschirmfotos der Anwendung Bullshit-Bingo. Abbildung 1 zeigt welche Screens der Anwender im Einzelnen angezeigt bekommt, wenn er ein Leben kauft. 1) 2) Applikation Payment Module 3) 4) Payment Module Applikation Abbildung 1: Ablauf Bezahlvorgang Jan Fleischhauer, Angelika Zelosko 2

Der Anwender beabsichtigt ein Feature zu erwerben. Hierzu wählt er dieses in der Applikation aus. Nun liegt die Kontrolle nicht mehr bei der Anwendung, sondern wurde an die Payment API weitergegeben. Diese zeigt dem Benutzer seine Featurewahl und die dadurch entstehenden Kosten an. Des Weiteren besteht hier die Möglichkeit eine Zahlungsmethode auszuwählen. Danach bestätigt der User die selektierten Daten und startet damit die Transaktion. Benötigt die gewählte Zahlungsmethode Daten des Users, wie beispielsweise Kreditkartenangaben, werden diese in einem zusätzlichen Dialog abgefragt. Am Ende der Transaktion bekommt der User von der Anwendung, an die nun wieder die Kontrolle übergeben wurde, mitgeteilt, ob der Zahlungsvorgang erfolgreich war oder nicht. 3 Aufbau Um über das Handy Zahlungen zu tätigen, braucht es neben dem Benutzer, der die Anwendung bedient, noch weitere Beteiligte. Abbildung 2: Akteure und Rollen Dazu gehören, wie in Abbildung 2 zu sehen, der Anwendungsentwickler und der Softwareanbieter (Händler), von dem die Anwendung und die Features bezogen werden. Sei es das Erwerben von Leben bei einem Spiel oder der Kauf einer Fahrkarte für den Bus. Weitere wichtige Rollen übernehmen der Handy-Hersteller und der Payment Service Provider (PSP). Der Payment Service Provider kümmert sich stellvertretend für den Händler um die Abwicklung der Zahlungen, nimmt diese entgegen und prüft sie auf Korrektheit. PSP und Hersteller einigen sich über die möglichen Zahlungsarten, die über das Mobiltelefon genutzt werden können. Dementsprechend implementiert der Hersteller die Payment Jan Fleischhauer, Angelika Zelosko 3

API-Komponenten auf dem Gerät. Sobald eine Zahlung erfolgen soll, kommuniziert der Benutzer nur noch mit der Payment API. Die Anwendung kann keine Zahlung automatisch ausführen. Die Payment API erzwingt immer die Bestätigung durch den User. Dadurch wird sichergestellt, das der Entwickler den Zahlungsprozess nicht manipulieren kann. Dem Benutzer wird dadurch garantiert, dass seine Zahlungen korrekt ausgeführt werden. 4 Architektur Eine Payment-Anwendung für ein Mobiltelefon zu entwickeln macht dann Sinn, wenn in das Gerät bestimmte Komponenten vom Hersteller integriert wurden. Zu diesen zählen das Payment Module, ein oder mehrere Payment Adapter sowie die Payment API. Im Folgenden werden deren Funktionen und das Zusammenspiel erläutert. Alle Komponenten sind in Abbildung 3 dargestellt. Abbildung 3: Architektur Wer per Kreditkarte bezahlen möchte, hatte im obigen Beispiel (Abschnitt 2) die Wahl zwischen verschiedenen Instituten. Aus architektonischer Sicht laufen alle Kreditkartenzahlungen über die selbe Schnittstelle, einen bestimmten Payment Adapter. Es obliegt dem Hersteller mehrere Payment Adapter auf dem Handy zu implementieren. Neben dem Adapter für Kreditkarten, kann es z. B. einen weiteren für Premium Priced SMS geben. Alle Payment Adapter werden im Payment Module verwaltet. Die Organisation einer Transaktion findet ebenfalls im Payment Module statt. Ausgelöst wird eine Transaktion durch einen Aufruf der Payment API. Ähnlich der Architektur von UI-Elementen nutzt auch die Payment API Callbacks. Jan Fleischhauer, Angelika Zelosko 4

TransactionModule 1 1 registers contains 1 * <<interface>> TransactionListener <<interface>> TransactionRecord Abbildung 4: Payment API Klassen Über eine Instanz des TransactionModules wird eine Transaktion gestartet. Sobald diese beendet wurde, erfährt der registierte TransactionListener davon. Er bekommt dabei ein TransactionRecord übergeben, der Informationen über die abgelaufene Transaktion enthält. Abbildung 4 gibt die Beziehungen zwischen den Payment API-Klassen wieder. 5 Payment Informationen Wer Produkte oder Dienstleistungen verkaufen will, der muss offen legen was er verkaufen möchte und zu welchem Preis. Dies ist auch im Bereich des mobilen Payments nichts anders. Die Frage ist jedoch, woher die Applikation erfährt welche Produkte überhaupt verkauft werden können und was diese Kosten. Bereits ab Zeitpunkt der Installation der Anwendung kann man der Payment API diese Informationen offen legen. Dies passiert durch Schlüssel-Wert-Paare in der JAD- und manifest.mf-datei. Nachfolgend soll gezeigt werden, wie definiert wird welche Features es gibt, wie man diese kaufen kann und wie man die jeweiligen Preise angibt. Eine vollständige Version der Informationen findet sich in Anhang A. 1 Pay-Feature-0: 0 2 Pay-Feature-1: 1 Listing 1: Feature-Deklaration Obiges Listing (Listing 1) zeigt, wie man käuflich erwerbbare Features deklariert. Die Nummer im Schlüssel wird hierbei genauso wie der Wert von 0 aufsteigend durchnummeriert. Die Vergabe von Namen oder ähnlichem ist hier nicht vorgesehen. Jan Fleischhauer, Angelika Zelosko 5

1 Pay-Adapters: X-CCARD,PPSMS 2 Pay-Providers: SONERA, VISA, MASTERCARD 3 Pay-MASTERCARD-Info: X-CCARD, EUR, MASTERCARD, https:// localhost 4 Pay-VISA-Info: X-CCARD, EUR, VISA, https://localhost 5 Pay-SONERA-Info: PPSMS, EUR, 928, 99 Listing 2: Pay-Adapter und -Provider Die Definitionen für wie kann man kaufen finden sich in Listing 2. Zuerst definiert man, welche Payment Adapter man nutzen möchte. Pay-Providers hat als Wert eine Kommaseparierte Liste von Providernamen. Payprovider sind beispielweise Kreditkarteninstitute. Diese Namen finden sich in den Tags Pay-<Provider>-Info wieder. Die Namen für Pay Provider sind frei wählbar, sollten aber, da diese dem User angezeigt werden, sinnvoll sein. Die Werte für Pay-<Provider>-Info deklarieren Informationen über den Provider. Der erste Wert muss einer der Payment Adapter sein, der zweite Wert legt die Währung fest. Alle weiteren Werte sind Adapter abhängig. Im obigen Beispiel muss für einen Kreditkartenadapter der Name des Kartenanbieters sowie der Server für die Kommunikation festgelegt werden. Für den Adapter Premium Prices SMS werden die Werte für Mobile Country Code und Mobile Network Code angegeben. Mobile Country Code ist ein Code, der das Land festlegt, der Mobile Network Code legt das Netz fest. 1 Pay-MASTERCARD-Tag-0: 1.45, 1_game 2 Pay-MASTERCARD-Tag-1: 2.95, 3_games 3 Pay-SONERA-Tag-0: 1.40, 5550000, 1_GAME, 1 4 Pay-SONERA-Tag-1: 2.80, 5550000, 3_GAMES, 2 5 Pay-VISA-Tag-0: 1.50, 1_game 6 Pay-VISA-Tag-1: 3.00, 3_games Listing 3: Provider-Feature-Mapping In Listing 3 ist das Mapping von Payment Providern und Feature Ids zu sehen. Es wird definiert, was welches Feature beim jeweiligen Provider kostet. Preise für das gleiche Feature können sich, wie oben ersichtlich, von Provider zu Provider unterschieden. Die Schlüssel haben die Form Pay-<Provider>-Tag<FeatureID>. Der Werte ist der Preis, hinzu kommen Provider- (oder besser: Adapter-) abhängige Werte. Im Beispiel für Kreditkarten ist dies ein Name des Features, der bei der Abrechnung mit angegeben wird. Bei der Premium Priced SMS sind es die Nummer, an die die SMS geschickt wird, der Inhalt der Nachricht der SMS und die Anzahl der SMS, die verschickt werden. Der Betrag wird dann auf die angegebene Anzahl an SMS aufgeteilt. Dies ist beispielsweise notwendig, wenn ein Provider festlegt, dass eine SMS nur maximal 1,99 EUR kosten darf, für das Feature aber 2,80 EUR zu zahlen sind. Jan Fleischhauer, Angelika Zelosko 6

Abbildung 5: Payment Informationen Abbildung 5 zeigt, dass es zwei Möglichkeiten gibt, wie sich das Payment Modul die Payment Informationen beschafft. Zum einen gibt es die Informationen, die bereits zum Zeitpunkt der Installation zur Verfügung stehen. Diese Informationen finden sich wie bereits erwähnt in der JAD- sowie in der manifest.mf-datei wieder. Die JAD-Datei enthält allgemeine Informationen. Der User erfährt so, dass die Applikation, die er installieren möchte, sich der Payment API bedient. In der manifest.mf -Datei befinden sich die oben beschriebenen Informationen wie Payment Provider und Features. Natürlich ist es auch möglich alle Payment Informationen in der JAD-Datei zu halten. Preise unterliegen meist einem Wandel. Um diesem Fakt Rechnung zu tragen gibt es die Möglichkeit die Payment Informationen zu aktualisieren. Wie in Abbildung 5 zu sehen, stellt das Aktualisieren der Payment Informationen die zweite Variante dar, wie das Payment Module an die Daten gelangt. Die Payment API sieht für das Aktualisieren drei Strategien vor: Vor jeder Transaktion wird versucht, die Payment Informationen zu aktualisieren Über einen Update-Button bekommt der User die Möglichkeit die Aktualisierung selbst anzustoßen (vlg. Abbildung 1) In den Payment Informationen ist ein Verfallsdatum angegeben. Transaktionen, die nach diesem Datum angestoßen werden sorgen dafür, dass vor Ausführung versucht wird, die Payment Informationen zu aktualisieren Welche der drei genannten Methoden verwendet werden soll, wird erstmals beim Veröffentlichen der Applikation bestimmt. Sie kann jedoch jederzeit auf eine Andere gewechselt werden. Jan Fleischhauer, Angelika Zelosko 7

1 Pay-Update-Stamp: 2004-08-12T13:30:00Z 2 Pay-Update-URL: http://localhost/bullshitpayment/bin/bullshit.jpp 3 Pay-Cache: no Listing 4: Update Informationen Listing 4 stammt aus der manifest.mf-datei. Diese Felder dienen dazu den vorgestellten Aktualisierungsvorgang mit Hilfe einer JPP-Datei zu ermöglichen. Eine JPP-Datei hat die gleiche Struktur und die gleichen Felder wie die JAD- / manifest.mf-datei. Der Wert von Pay-Update-Stamp definiert den Zeitpunkt, zu dem die Informationen dieser Datei aktuell sind. Bei einem Update wird er mit mit dem timestamp der JPP-Datei verglichen um festzustellen, ob die Payment Informationen aktualisiert werden müssen. Unter der Pay-Update-URL muss das Payment Modul diese JPP-Datei empfangen können. Das dritte Feld, Pay-Cache definiert eine der bereits vorgestellten Aktualisierungsstrategien. Der Wert no sorgt dafür, dass automatisch vor jeder Transaktion ein Update der Payment Informationen probiert wird, yes lässt dem User die freie Wahl, wann er die Payment Informationen aktualisiert. Die dritte Möglichkeit ist, einen Timestamp einzutragen, das expiry date. Der Inhalt der JPP-Datei ersetzt im Falle eines Updates alle Paymentfelder der Midletsuite. Sie muss also alle nötigen Felder enthalten, selbst wenn sich diese Felder nicht ändern. Felder, die im Vergleich zu den bisherigen Payment Informationen nicht mehr auftauchen, werden dementsprechend gelöscht. Will man also keine Bezahlung über Mastercard mehr zulassen, so löscht man in der JPP-Datei einfach den Provider MASTERCARD und alle zugehörigen Felder. 1 Pay-Certificate-1-1: MIICFTCCAX6g[...]AbVE5mC28ciGmhjT 2 Pay-Signature-RSA-SHA1: Cg45RTqqU[...]iJpqqJFbSt5MA= Listing 5: Signatur Da der Updatevorgang von Payment Informationen sensitiv ist, muss die JPP-Datei signiert sein (s. Listing 5). Die Felder Pay-Certificate-<n>-<m>und Pay-Signature-RSA- SHA1 sind äquivalent zu den jad Feldern MIDlet-Certificate-<n>-<m>und MIDlet-Jar- RSA-SHA1. 6 Ablauf aus Entwicklersicht Bisher ist bekannt, worauf eine Payment Applikation aufbaut, woher sie ihre Preisinformationen bezieht und wie der Ablauf aus Benutzersicht aussieht. Was fehlt, ist die Sicht des Entwicklers. Um diese zu beleuchten dient das Sequenzdiagramm in Abbildung 6 und die nachfolgenden Codebeispiele. Ebenfalls in diesem Kapitel befindet sich ein vollständiges Klassendiagramm der Payment API (Abbildung 7), angesprochen werden die Teile, die typischerweise gebraucht werden. Jan Fleischhauer, Angelika Zelosko 8

Midlet TransactionListener new() TransactionModule setlistener() process() processed() Abbildung 6: Sequenzdiagramm Zahlungsprozess Kern in einer Applikation die das JSR 229 nutzt ist das TransactionModule. Der Code in Listing 6 erstellt eine Instanz des TransactionModules. Im Konstruktor übergeben werden muss das Midlet, dass das TransactionModule benutzt. Danach wird der TransactionListener gesetzt. In diesem Fall implementiert die Klasse, die das TransactionModule erstellt, auch gleich das Interface TransactionListener. 1 private TransactionModule txmodule ; 2...... 3 try { 4 txmodule = new TransactionModule ( this. bingo ) ; 5 txmodule. setlistener ( this ) ; 6 } catch ( TransactionModuleException tme) { 7 } Listing 6: TransactionModule Beim Erstellen des TransactionModules kann eine TransactionModuleException geworfen werden. Dies geschieht typischerweise dann, wenn die Payment Informationen korrupt oder unvollständig sind oder aus einem anderen Grund das Payment Module eine Verbindung zum TransactionModule verhindert. Geht alles gut steht das TransactionModule bereit um Transaktionen auszuführen. Jan Fleischhauer, Angelika Zelosko 9

1 public void startpayment ( int featureid ) { 2 try { 3 String text = ; 4 if ( featureid == FEATURE 1 GAME) { 5 text= Buy one BullShitBingo game? ; 6 } else if ( featureid == FEATURE 3 GAMES) { 7 text= Buy three BullShitBingo games? ; 8 } 9 txmodule. process ( featureid, BullShitGame Purchasing, text ) ; 10 } catch ( TransactionModuleException e ) { 11 12 } catch ( TransactionFeatureException e ) { 13 14 } catch ( TransactionListenerException e ) { 15 16 } 17 } Listing 7: Transaktion starten Wie eine Transaktion gestartet wird findet sich in Listing 7. Vor dem Starten hat man den User auswählen lassen welches Feature er kaufen möchte. Mit Hilfe der ID wird herausgefunden, um welches Feature es sich handelt und dementsprechend wird ein String erstellt. Dieser wird auf dem nachfolgenden Screen (den die Payment API erzeugt) angezeigt und macht dem User noch einmal klar, was er hier kauft. Die Methode process stößt die Transaktion dann an. Hier wird neben der Feature ID eine Überschrift für den nun erscheinende Screen sowie eben angesprochener String übergeben. Welche Methoden die Payment API insgesamt zur Verfügung stellt ist in Abbildung 7 dargestellt. TransactionModule +TransactionModule(object: Object) +setlistener(listener: TransactionListener): void +process(featureid: int, featuretitle:string, featuredescription: String):int +process(featureid: int, featuretitle:string, featuredescription: String, payload: byte[]):int +getpasttransactions(max:int):transactionrecord[] +delivermissedtransactions():void 1 1 registers contains TransactionListener 1 * TransactionRecord +processed(record:transactionrecord):void -TRANSACTION_SUCCESSFUL:int = 0 -TRANSACTION_FAILED:int = 1 -TRANSACTION_REJECTED:int = 2 +getfeatureid():int +gettransactionid():int +getfinishedtimestamp():long +getstate():int +wasmissed():boolean Abbildung 7: Payment API Jan Fleischhauer, Angelika Zelosko 10

In Listing 8 sieht man die Methode processed. Sie muss im TransactionListener implementiert sein und dient als Callback aus dem Payment Modul. Sobald die Transaktion beendet ist, wird processed gerufen, ihr Transaktionsergebnis als TransactionRecord übergeben. Aus diesem TransactionRecord lassen sich viele Informationen über die Transaktion abrufen. Das wichtigste ist die Frage, ob die Transaktion erfolgreich (TRANSAC- TION SUCCESSFUL) war oder nicht. Im Falle einer erfolgreichen Transaktion lässt sich über getfeatureid herausfinden, welches Feature denn hier erfolgreich gekauft wurde um dementsprechend z.b. dem User ein neues Leben gutzuschreiben. 1 public void processed ( TransactionRecord record ) { 2 switch ( record. getstate () ) { 3 case TransactionRecord.TRANSACTION SUCCESSFUL: 4 switch ( record. getfeatureid () ) { 5 case FEATURE 1 GAME: 6 bingo. increasegamespurchased (1) ; 7 bingo. setlastpaymentstate ( BullShitPayment. FEATURE 1 GAME) ; 8 break ; 9 case FEATURE 3 GAMES: 10 bingo. increasegamespurchased (3) ; 11 bingo. setlastpaymentstate ( BullShitPayment. FEATURE 3 GAMES) ; 12 break ; 13 } 14 break ; 15 case TransactionRecord.TRANSACTION REJECTED: 16 bingo. setlastpaymentstate ( BullShitPayment.TRANSACTION REJECTED) ; 17 break ; 18 case TransactionRecord.TRANSACTION FAILED: 19 bingo. setlastpaymentstate ( BullShitPayment.TRANSACTION FAILED) ; 20 break ; 21 } 22 bingo. paymentdone () ; 23 } Listing 8: Transaktion abgeschlossen Jan Fleischhauer, Angelika Zelosko 11

A JAD-Datei 1 Pay-Version: 1.1 2 Pay-Adapters: X-CCARD,PPSMS 3 Pay-Update-Stamp: 2004-08-12T13:30:00Z 4 Pay-Update-URL: http://localhost/bullshitpayment/bin/bullshit.jpp 5 Pay-Cache: no 6 Pay-Providers: SONERA, VISA, MASTERCARD 7 Pay-Feature-0: 0 8 Pay-Feature-1: 1 9 Pay-MASTERCARD-Info: X-CCARD, EUR, MASTERCARD, https:// localhost 10 Pay-MASTERCARD-Tag-0: 1.45, 1\_game 11 Pay-MASTERCARD-Tag-1: 2.95, 3\_games 12 Pay-SONERA-Info: PPSMS, EUR, 928, 99 13 Pay-SONERA-Tag-0: 1.40, 5550000, 1\_GAME, 1 14 Pay-SONERA-Tag-1: 2.80, 5550000, 3\_GAMES, 2 15 Pay-VISA-Info: X-CCARD, EUR, VISA, https://localhost 16 Pay-VISA-Tag-0: 1.50, 1_game 17 Pay-VISA-Tag-1: 3.00, 3_games Listing 9: Beispiel einer JAD-Datei Jan Fleischhauer, Angelika Zelosko 12

Literatur [1] Das Handy-Ticket, www.dashandyticket.de [2] Schlauer Parken in Wiesbaden, www.wiesbadener-kurier.de/region/objekt.php3?artikel id=2065451, 04.10.2005 [3] Java Specification Request 229, http://jcp.org/aboutjava/communityprocess/final/jsr229/ Jan Fleischhauer, Angelika Zelosko 13