Payment API - Medieninformatik

Payment API
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

Payment API
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

Payment API
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

Payment API
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

Payment API
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

Payment API
TransactionModule
1 1
registers
contains
1 *
TransactionListener
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

Payment API
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--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--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--Tag. 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

Payment API
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

Payment API
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--und Pay-Signature-RSA-
SHA1 sind äquivalent zu den jad Feldern MIDlet-Certificate--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

Payment API
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

Payment API
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

Payment API
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

Payment API
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

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