Sie sind auf Seite 1von 50

Mobile Payment Widget

Version 2.2

15.09.2010

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 1
Inhaltsverzeichnis

1 Historie .............................................................................................................................................4
2 Überblick ..........................................................................................................................................5
2.1 Begrifflichkeiten .......................................................................................................................5
2.2 Bestellwege ..............................................................................................................................5
2.3 Billingverfahren (1-Phase Single Payment / 2-Phase Single Payment / Subscription) .............5
2.4 Integration aus Client-Sicht ......................................................................................................6
3 URLs und Ressourcen .......................................................................................................................6
4 Zeichensatz / Encoding .....................................................................................................................6
5 Besonderheiten im WAP/mobile WEB .............................................................................................7
6 Ablauf – Einsatz des mbe4 Mobile Payment Widgets ......................................................................7
6.1 1-Phase Single Payment ...........................................................................................................8
6.2 2-Phase Single Payment ...........................................................................................................9
6.3 1 –Phase Subscription Setup ................................................................................................. 11
6.4 2 –Phase Subscription Setup ................................................................................................. 14
7 Client Authentification .................................................................................................................. 15
7.1 Widget HTTP forward ............................................................................................................ 15
7.2 Methoden capture, terminate, refund, followupauthorize, followupdirectcapture,
subscriptionterminate ....................................................................................................................... 16
8 Payment Authorisierung ............................................................................................................... 16
9 Single Payment HTTP Forward Client->mbe4 ............................................................................... 17
9.1 Single Payment HTTP forward mbe4 -> Client ...................................................................... 19
10 Transaction capture Request ........................................................................................................ 21
10.1 Transaction capture Callback ................................................................................................ 23
11 Transaction terminate Request ..................................................................................................... 24
11.1 Transaction terminate Callback ............................................................................................. 26
12 Transaction refund Request .......................................................................................................... 27
12.1 Transaction refund Callback .................................................................................................. 29
13 Subscription Setup HTTP Forward Client->mbe4 .......................................................................... 30
13.1 Subscription Setup HTTP forward mbe4 -> Client ................................................................. 33
14 Subscription followupauthorize Request ...................................................................................... 35
14.1 Subscription followupauthorize Callback .............................................................................. 38
15 Subscription followupdirectcapture Request................................................................................ 39
15.1 Subscription followupdirectcapture Callback ....................................................................... 42
16 Subscription terminate Request .................................................................................................... 44

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 2
16.1 Subscription terminate Callback ........................................................................................... 46
17 Liste Responsecodes...................................................................................................................... 47
18 Liste Contentclasses ...................................................................................................................... 48
19 Liste Operatorids ........................................................................................................................... 49
20 Liste TAN SMS Text ........................................................................................................................ 50

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 3
1 Historie

Datum Änderung erstellte Author


Version

15.12.2009 initial erstellt 1.0 Sten Uhlig

05.01.2010 Ergänzung 2-Phase Payment 1.1 Sten Uhlig

Änderungen URLs und Ressourcen

27.01.2010 Änderung Länge CallbackURL 1.2 Sten Uhlig

Korrektur Bezeichnung „hash“

23.02.2010 neuer Reponsecode 113 1.3 Sten Uhlig

neuer Reponsecode 121

neuer Punkt „Besonderheiten im WAP/mobile WEB“

neue Validierung des Parameters Description

10.04.2010 Erweiterung um Subscription 2.0 Sten Uhlig

Bereinigung Responsecodes

01.09.2010 Fehlerkorrekturen Parameterlisten 2.1 Sten Uhlig

Erweiterung Followup Payment Parameterlisten um


subscriptiondescription, subscriptioninterval

15.09.2010 Erweiterung synchrone Webservice Requests 2.2 Sten Uhlig

Erweiterung One Phase Subscription Setup

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 4
2 Überblick

mbe4 ist die Paymentplattform der mobile business engine Gmbh „mbe“.

mbe4 ist eine aggregierende Schnittstelle für das Bezahlverfahren „Factoring“ der deutschen
Mobilfunknetzbetreiber.

Das mbe4 Mobile Payment Widget bietet eine leicht in existierende Web- und Wap – Systeme zu
integrierende Erweiterung der mbe4 Mobile Payment Plattform.

2.1 Begrifflichkeiten
Im Folgenden werden die Begriffe Subscriber und Client verwendet.

 mbe4 = die mbe Billing Plattform.


 Subscriber = Mobilfunkkunde, Endkunde dessen Account belastet werden soll.
 Client = Diensteanbieter, VASP oder Mediator, welcher sich an das hier beschriebene
Paymentinterface anbindet.
 APN Access Point Name - ist der Name eines Anschlusspunktes in einem GPRS-Backbone,
welcher Zugang zu einem externen Paket-Datennetz ermöglicht.
 Single Payment – „Einzelkauf“ Paymenttransaktion die nicht innerhalb einer Subsription
abläuft. Der Subscriber authorisiert jede einzelne Transaktion.
 Subscription/Abo – Paymentmodell zur Abbildung eine Abonnements . Der Subscriber
authorisiert die Subscription im Rahmen der ersten Transaktion. Folgetransaktionen
(followup Payments) können ohne die nochmalige Zustimmung des Subscribers durchgeführt
werden.

2.2 Bestellwege
Unterstützt werden die folgenden Kommunikationswege zum Subscriber:

 WEB
 WAP (= mobile Web)

2.3 Billingverfahren (1-Phase Single Payment / 2-Phase Single Payment / Subscription)


Aktuell steht das Paymentverfahren „Factoring“ zur Verfügung.

mbe4 unterstützt dabei wahlweise

 1-Phase Single Payment


o Ablauf der Transaktion besteht aus einem einzigen Schritt.
o Authorisierung der Zahlung und Buchung der Zahlung werden in einem Schritt/Aufruf
durchgeführt.
o Die Leistungserbringung durch den Client kann erst nach der Buchung erfolgen.
 2-Phase Single Payment

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 5
o Authorisierung der Zahlung und Buchung der Zahlung werden in 2 getrennten
Schritten/Aufrufen durchgeführt.
o Die Leistungserbringung durch den Client erfolgt nach der Authorisierung und vor
der Buchung.

 Subscription
o Subscription steht für ein Abonnementmodell und somit für mehrere
Einzelzahlungen
o Eine Subscription beinhaltet die 3 Teile
 Subscription Setup (abschließen des Abos inklusive erster Zahlung)
 Followup Payments (Einzug der Zahlungen – wiederholt sich zyklisch bis zur
Subscription Termination)
 Subscription Termination (Abonnement beenden/kündigen)
o Subscription Setup kann als 1-Phase oder 2-Phase eingerichtet werden
o Followup Payments können wahlweise 1-Phase oder 2-Phase durchgeführt werden.

2.4 Integration aus Client-Sicht


Das mbe4 Mobile Payment Widget kann

 als Popup
 als IFrame
 als Weiterleitung

in existierende Websysteme eingebunden werden.

mbe4 übernimmt den gesamten Ablauf der Paymenttransaktion.

Die Parameter werden als HTTPS GET Parameter übergeben.

Alle Werte müssen daher URL-Encoded sein.

3 URLs und Ressourcen

URL: http(s)://billing.mbe4.de

Es können Services für Test- und Wirkbetrieb bereitgestellt werden.

Testservices können als „Auto Refund Services“ erstellt werden. Erfolgreich abgeschlossene
(captured) Transaktionen werden in diesem Fall automatisch zurückgebucht (refunded).

4 Zeichensatz / Encoding

 Zu verwendendes Character Encoding gültig für alle Methoden: UTF-8

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 6
 HTTP GET Parameter müssen URL-encoded übermittelt werden

5 Besonderheiten im WAP/mobile WEB

Im mobile WEB/WAP kann mbe4 die Subscriberid(MSISDN) eines Subscribers automatisch erkennen.
Der SMS Handshake kann damit entfallen. Dieses Feature kann für jeden einzelnen Service von mbe
an- bzw. abgeschaltet werden.

Die automatische Subscriberid-Erkennung funktioniert nur wenn der Subscriber über das
GSM/GPRS/UMTS-Netz eines deutschen MNO mit dem Internet verbunden ist. Über WLAN
verbundene Endgeräte werden nicht automatisch erkannt.

Um automatische Subscriberid-Erkennung zu ermöglichen darf die ZielURL billing.mbe4.de nur per


http (nicht per https) verwendet werden!

Bestimmte mobile Endgeräte haben Beschränkungen in der Länge von URLs. Sollen alle Endgeräte
bedient werden sollte die URL für den Forward Client->mbe4 auf 250 Zeichen beschränkt werden!

6 Ablauf – Einsatz des mbe4 Mobile Payment Widgets

Die folgenden Diagramme beschreiben den Ablauf einer Paymentransaktion aus Clientsicht in den
Varianten 1-Phase, 2-Phase und Subscription.

(Voraussetzung: Subscriber hat Ware im Web(shop) ausgewählt und wählt mbe4 Mobile Payment
Widget als Zahlverfahren.)

Hinweis: Ein Service der mbe4 Plattform ist jeweils für eine der Paymentvarianten populiert. Ein
Service kann demnach nicht für unterschiedliche Paymentvarianten verwendet werden.

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 7
6.1 1-Phase Single Payment

Subscriber Client mbe4

Wählt „zahlen“ HTTP forward


 login
 amount
 response Authorisierung
 …usw Buchung
HTTP forward
 result
Leistungserbringung  msisdn
 …usw

1. Client führt einen HTTP Forward des Subscriber(-Browsers) auf die mbe4 Widget URL
durch (Client übergibt Paymentparameter mit der Forward URL).
2. mbe4 führt den Kunden durch den Paymentprozess. Dabei wir der Paymentbetrag
reserviert (Authorisierung) und gleichzeitig final gebucht (Buchung).
3. mbe4 führt ein HTTP Forward des Subscriber(-Browsers) auf die vom Client mitgelieferte
URL durch (mbe4 übergibt Resultparameter mit der Forward URL).

Bei positivem Result


4. Client erbringt Leistung (liefert Content an Subscriber aus).

Bei negativem Result


4. Client informiert den Subscriber über das fehlgeschlagene Payment.

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 8
6.2 2-Phase Single Payment

Subscriber Client mbe4

Wählt „zahlen“ HTTP forward


 login
 amount
 response
Authorisierung
 …usw

HTTP forward
 result
Leistungserbringung  msisdn
 …usw

Transaction capture
Transaction capture response
Buchung

Transaction capture callback

1. Client führt einen HTTP Forward des Subscriber(-Browsers) auf die mbe4 Widget URL
durch (Client übergibt Paymentparameter mit der Forward URL).
2. mbe4 führt den Kunden durch den Paymentprozess. Dabei wir der Paymentbetrag
reserviert (Authorisierung).
3. mbe4 führt ein HTTP Forward des Subscriber(-Browsers) auf die vom Client mitgelieferte
URL durch (mbe4 übergibt Resultparameter mit der Forward URL).

Bei positivem Result


4. Client erbringt Leistung (liefert Content an Subscriber aus).
5. Client sendet einen „Transaction capture“ Request um den reservierten Betrag final zu
buchen. mbe4 antwortet mit einem (ggf. vorläufigen) Ergebnis.
6. Im Falle eines asynchronen Aufrufes sendet mbe4 (zeitasynchron) einen „Transaction
capture“ Callback mit dem finalen Ergebnis der Buchung.

Bei negativem Result


4. Client informiert den Subscriber über das fehlgeschlagene Payment.

Hinweis:

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 9
Der Provider EPlus unterstützt „2Phase Payment“ nicht im vollen Umfang. EPlus
Transaktionen werden daher im Zuge der Widgetkommunikation nicht nur
authorisiert(authorized) sondern gebucht(captured).

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 10
6.3 1 –Phase Subscription Setup

Subscriber Client mbe4

Wählt „Abo abschließen“ HTTP forward


 login
 amount Subscription
 response Authorisierung
1. Subscription Setup

 …usw
Buchung
HTTP forward
 result
Leistungserbringung  msisdn
 …usw

Followup Authorize
2a. Followup payment

Followup Authorize Response


Authorisierung
Followup Authorize Callback
2-phase

Leistungserbringung Transaction capture


Transaction capture Response
Buchung
Transaction capture Callback
2b. Followup payment

Followup DirectCapture
Followup DirectCapture Response
Authorisierung
1-phase

Followup DirectCapture Callback Buchung

Leistungserbringung

Wählt „Abo kündigen“ Subscription terminate


3. Subscription
terminate

Subsciption terminate Response


Subscription
Terminierung
Subscription terminate Callback

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 11
Subscription besteht aus den folgenden 3 Schritten (Schritt 2 wiederholt sich ggf. mehrfach)

1. Subscription Setup – Abschluss eines Abonnements inklusive einer initialen


Paymentransaktion

1. Client führt einen HTTP Forward des Subscriber(-Browsers) auf die mbe4 Widget URL
durch (Client übergibt Subscriptionparameter mit der Forward URL).
2. mbe4 führt den Kunden durch den Paymentprozess. Dabei wir der Paymentbetrag
reserviert (Authorisierung), gleichzeitig final gebucht (Buchung) und das Abonnement
angelegt.
3. mbe4 führt ein HTTP Forward des Subscriber(-Browsers) auf die vom Client mitgelieferte
URL durch (mbe4 übergibt Resultparameter mit der Forward URL).

Bei positivem Result


4. Client erbringt Leistung (liefert Content an Subscriber aus).

Bei negativem Result


4. Client informiert den Subscriber über den fehlgeschlagene Subscription Setup Vorgang.

2. FollowUp Payments – Einzug der Abogebühren - wahlweise als 1-Phase oder 2-Phase
Transaktion
a. 2-Phase
1. Client sendet “followupauthorize” Request an mbe4.
2. mbe4 führt den Authorisierungsprozess durch. Dabei wir der Paymentbetrag
reserviert (Authorisierung).
3. mbe4 antwortet mit einem (ggf. vorläufigen) Ergebnis.
4. Im Falle eines asynchronen Aufrufes sendet mbe4 (zeitasynchron) einen
„followupauthorize“ Callback mit dem finalen Ergebnis der Authorisierung.

Bei positivem Result


5. Client erbringt Leistung (liefert Content an Subscriber aus).
6. Client sendet einen „Transaction capture“ Request um den reservierten Betrag
final zu buchen. mbe4 antwortet mit einem vorläufigen Ergebnis.
7. mbe4 sendet (zeitasynchron) einen „Transaction capture“ Callback mit dem
finalen Ergebnis der Buchung.

Bei negativem Result


5. Client speichert Informationen über fehlgeschlagenes Followup Payment. Der
Client kann das Abonnement beenden oder die Followup Transaktion zu einem
späteren Zeitpunkt wiederholen.

b. 1-Phase
1. Client sendet “followupdirectcapture” Request an mbe4.

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 12
2. mbe4 führt den Directcapture Prozess durch. Dabei wir der Paymentbetrag
reserviert (Authorize) und gebucht (Capture).
3. mbe4 antwortet mit einem (ggf. vorläufigen) Ergebnis.
4. Im Falle eines asynchronen Aufrufes sendet mbe4 (zeitasynchron) einen
„followupdirectcapture“ Callback mit dem finalen Ergebnis der Buchung.

Bei positivem Result


5. Client erbringt Leistung (liefert Content an Subscriber aus).

Bei negativem Result


5. Client speichert Informationen über fehlgeschlagenes Followup Payment. Der
Client kann das Abonnement beenden oder die Followup Transaktion zu einem
späteren Zeitpunkt wiederholen.

3. Subscription terminate – Abonnement beenden


1. Client sendet “subscriptionterminate” Request an mbe4. mbe4 antwortet mit einem
(ggf. vorläufigen) Ergebnis.
2. mbe4 führt den Terminierungsprozess des Abonnements durch.
3. mbe4 antwortet mit einem (ggf. vorläufigen) Ergebnis.
4. Im Falle eines asynchronen Aufrufes sendet mbe4 (zeitasynchron) einen
„subscriptionterminate“ Callback mit dem finalen Ergebnis.

HINWEIS: mbe4 bleibt hinsichtlich der Subscriptions „stateless“

 mbe4 hält keine Informationen über Abonnement s und deren Status.


 die Abonnementverwaltung liegt in der Verantwortung des Client.
 mbe4 erzeugt keine Followup-Payments

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 13
6.4 2 –Phase Subscription Setup

Subscriber Client mbe4

Wählt „Abo abschließen“ HTTP forward


 login
 amount
 response
2. Subscription Setup

Subscription
 …usw
Authorisierung
HTTP forward
 result
Leistungserbringung  msisdn
 …usw

Transaction capture
Transaction capture Response
Buchung

Transaction capture callback

Followup Authorize
2a. Followup payment

Followup Authorize Response


Authorisierung
Followup Authorize Callback
2-phase

Leistungserbringung Transaction capture


Transaction capture Response
Buchung
Transaction capture Callback
2b. Followup payment

Followup DirectCapture
Followup DirectCapture Response
Authorisierung
1-phase

Followup DirectCapture Callback Buchung

Leistungserbringung

Wählt „Abo kündigen“ Subscription terminate


3. Subscription
terminate

Subsciption terminate Response


Subscription
Terminierung
Subscription terminate Callback

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 14
Subscription besteht aus den folgenden 3 Schritten (Schritt 2 wiederholt sich ggf. mehrfach)

4. Subscription Setup – Abschluss eines Abonnements inklusive einer initialen


Paymentransaktion

5. Client führt einen HTTP Forward des Subscriber(-Browsers) auf die mbe4 Widget URL
durch (Client übergibt Subscriptionparameter mit der Forward URL).
6. mbe4 führt den Kunden durch den Paymentprozess. Dabei wir der Paymentbetrag
reserviert (Authorisierung) und das Abonnement angelegt.
7. mbe4 führt ein HTTP Forward des Subscriber(-Browsers) auf die vom Client mitgelieferte
URL durch (mbe4 übergibt Resultparameter mit der Forward URL).

Bei positivem Result


8. Client erbringt Leistung (liefert Content an Subscriber aus).
9. Client sendet einen „Transaction capture“ Request um den reservierten Betrag final zu
buchen. mbe4 antwortet mit einem (ggf. vorläufigen) Ergebnis.
10. Im Falle eines asynchronen Aufrufes sendet mbe4 (zeitasynchron) einen „Transaction
Capture“ Callback mit dem finalen Ergebnis der Buchung.

Bei negativem Result


6. Client informiert den Subscriber über den fehlgeschlagene Subscription Setup Vorgang.

5. FollowUp Payments – Einzug der Abogebühren - wahlweise als 1-Phase oder 2-Phase
Transaktion

Identisch zu 1-Phase Subscription Setup – FollowUp Payments!

6. Subscription terminate – Abonnement beenden

Identisch zu 1-Phase Subscription Setup – Subscription terminate!

HINWEIS: mbe4 bleibt hinsichtlich der Subscriptions „stateless“

 mbe4 hält keine Informationen über Abonnement s und deren Status.


 die Abonnementverwaltung liegt in der Verantwortung des Client.
 mbe4 erzeugt keine Followup-Payments

7 Client Authentification

7.1 Widget HTTP forward

Der Client ist verpflichtet mit jedem Forward einen Username und einen Hashcode zu übermitteln.
Anhand dieser Parameter wird sichergestellt, dass der Forward vom Client initiiert ist und die
Parameter korrekt übermittelt wurden (Signierung). Dazu ermittelt der Recipient des Requests den

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 15
Hashcode auf identische Weise und vergleicht die Ergebnisse. Ein Request darf nur verarbeitet
werden, wenn die Hashcodes identisch sind.

Der Hashcode wird wie folgt erstellt:

md5(Password+Parametervalue1+Parametervalue2+Parametervalue3…usw)

+ (plus) steht dabei für die nahtlose Aneinanderreihung der Values.

Der Zeichensatz der Values muss UTF-8 sein.

Das Password wird von mbe generiert und dem Client mitgeteilt.

Die Values dürfen nicht URL-encoded sein.

Die Reihenfolge der Parameter ist relevant und muss der hier spezifizierten Reihenfolge entsprechen.

7.2 Methoden capture, terminate, refund, followupauthorize, followupdirectcapture,


subscriptionterminate

Hierbei handelt es sich um Aufrufe von Methoden des mbe4 Webservices.

Die Kommunikation zwischen Client und mbe4 erfolgt IP-Safe per HTTPS.

 Der Client teilt mbe4 die freizuschaltenden IP-Adressen mit.


 mbe4 nimmt Requests ausschließlich von diesen IP-Adressen entgegen.
 mbe4 verarbeitet ausschließlich https Requests.

Der Client ist verpflichtet bei jedem Aufruf Username und Password zu übermitteln. Dem Client
werden Username und Password von mbe zugeteilt.

Das Password darf nicht im Klartext sondern muss MD5 encrypted übermittelt werden.

8 Payment Authorisierung

mbe4 ermittelt den Bestellweg des Subscribers automatisch und steuert die Paymenttransaktion.

Befindet sich der Subscriber im WAP, ermittelt mbe4 die Subscriberid des Subscribers automatisch.
Ist die Ermittlung der Subscriberid erfolgreich können die folgenden WAP-Paymentschritte
durchgeführt werden:

 Der Kunde wird in einem von mbe4 bereitgestellten Dialog aufgefordert den
Transaktionsdetails zuzustimmen.
 Stimmt der Kunde der Zahlung zu, sendet mbe4 einen Request an den zuständigen
Mobilfunknetzbetreiber.

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 16
Um automatische Subscriberid-Erkennung zu ermöglichen darf die ZielURL billing.mbe4.de nur
per http (nicht per https) verwendet werden. mbe4 leitet den Kunden vor Durchführung der
Transaktion an eine https-gesicherte URL weiter.

Befindet sich der Subscriber im WEB oder konnte die Subscriberid des Subscribers nicht ermittelt
werden wird dieser im WEB-Payment Verfahren behandelt.

 Der Kunde wird in einem mbe4 Dialog aufgefordert seine SubscriberId einzugeben.
 Dem Subscriber wird eine SMS mit einem One-Time-TAN zugestellt.
 Der Subscriber gibt den TAN im mbe4 Dialog ein und authorisiert damit die
Paymenttransaktion.
 mbe4 sendet einen Request an den zuständigen Mobilfunknetzbetreiber.

Konnte die Subscriberid des Subscribers nicht ermittelt werden und WEB Payment ist für den Service
des Clients deaktiviert, wird der Subscriber an die CallbackURL zurückgeleitet. Die übermittelten
Parameter enthalten eine entsprechende Fehlermeldung.

9 Single Payment HTTP Forward Client->mbe4

Der Subscriber wählt „zahlen“.

Client leitet den Subscriber an die mbe4 Payment Widget SinglePayment URL weiter.

Voraussetzungen:

 Subscriber hat Gut ausgewählt und klickt „zahlen“


 clienttransactionid ist unique

Folgeschritte:

 Im Falle eines vorläufigen Ergebnisses - warten auf http forward auf callbackURL

HTTP forward:

http(s)://billing.mbe4.de/widget?
username={username}
&clientid={clientid}
&serviceid={serviceid}
&contentclass={contentclass}
&description={description}
&clienttransactionid={clienttransactionid}
&amount={amount}
&callbackurl={callbackurl}
&timestamp={timestamp}

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 17
&hash={md5hashcode}

Parameter

IN/OU Bezeichnung Präsenz Format Beschreibung


T

IN username mandatory ^[-a-zA-Z0-9_]{10,30}$ Username des Client

IN clientid mandatory ^[0-9]{5}$ clientid wird von


mbe zugeteilt

IN serviceid mandatory ^[0-9]{5}$ serviceid wird von


mbe zugeteilt

IN contentclass mandatory ^[0-9]{1,2}$ Klassifizierung des


Contents (siehe Liste)

IN description mandatory ^.{1,100}$ verbale


Beschreibung des
Contents

IN clienttransactionid mandatory ^[-a-zA-Z0-9_]{1,95}$ unique id des Client


welche diese
Transaktion
beschreibt.
clienttransactionid
darf sich nie
wiederholen.

IN amount mandatory ^[1-9]{1}[0-9]{0,4}$ Betrag in EUR Cent

IN callbackurl mandatory ^http.{12,150}$ URL an die mbe4


nach asynchronem
Abschluss forwarded

IN tanid optional ^[a-zA-Z0-9]{1,16}$ Text der in der TAN


SMS den aktuellen
TAN näher
beschreibt um
Abgrenzungen bei
mehreren aktuell
gültigen TANs
gewährleisten zu
können

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 18
IN tansmstext optional ^[-a-zA-Z0-9_*+()&!? Dieser Text wird als
:.;,öäüÖÄÜß]{10,160}$ TAN-SMS versendet.
Die Platzhalter in {}
Beispieltext:
werden von mbe4
{CLIENT}: Zum Bezahlen von
{AMOUNT} Euro geben Sie bitte bzw dem Operator
folgende PIN ein: {PIN}. ersetzt. Die
(Vorgang: {TANID}) Gesamtlänge des
Textes darf nach
Ersetzung der
Platzhalter 160
Zeichen nicht
überschreiten.

IN timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0-9]{1}[- Timestamp


]{1}(([0]{1}[0-9]{1})|([1]{1}[0-
2]{1}))[-]{1}[0-3]{1}[0-
9]{1}[T]{1}[0-2]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[.]{1}[0-9]{3}[Z]{1}$

Format:
YYYY-MM-
DDTHH:MM:SS.mmmZ

Beispiel:
2009-01-01T10:00:00.000Z

IN hash mandatory ^[a-zA-Z0-9]{32}$ Siehe Kapitel


Parameter-
validierung

9.1 Single Payment HTTP forward mbe4 -> Client

Nach Abschluss von Authorisierung und Paymenttransaktion bzw. nach vorzeitigem Abbruch leitet
mbe4 den Subscriber per http forward an die vom Client übergebene CallbackURL weiter.

Voraussetzungen:

 http forward an des Subscribers vom Client an mb4


 endgültiger Status der Paymenttransaktion wurde erreicht

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 19
Mögliche Folgeschritte:

 Auslieferung des Contents (Diensterbringung) durch den Client

HTTP forward:

https://{callbackURL}?
transactionid={transactionid}
&clienttransactionid={clienttransactionid}
&responsecode={responsecode}
&description={description}
&subscriberid={subscriberid}
&operatorid={operatorid}
&timestamp={timestamp}
&hash={md5hashcode}

Parameter

Request/ Bezeichnung Präsenz Format Beschreibung


Response

Request transactionid ^[0-9]{1,10}$ mbe transactionid

Request clienttransactionid mandatory ^[-a-zA-Z0-9_]{1,95}$ Unique id des Client


welche diese
Transaktion beschreibt.
clienttransactionid darf
sich nie wiederholen.

Request responsecode mandatory ^[0-9]{1,6}$ 0=OK … (siehe Liste


Responsecodes)

Request description mandatory ^.{1,100}$ Responsecode


Beschreibung

Request subscriberid mandatory ^491[5-7]{1}[0-9]{8,9}$ MSISDN des Subscribers

Request operatorid ^[-0-9a-zA-Z]{1-20}$ Operator siehe Liste

Request timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0- Timestamp


9]{1}[-]{1}(([0]{1}[0-
9]{1})|([1]{1}[0-2]{1}))[-
]{1}[0-3]{1}[0-
9]{1}[T]{1}[0-2]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[.]{1}[0-
9]{3}[Z]{1}$

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 20
Format:
YYYY-MM-
DDTHH:MM:SS.mmmZ

Beispiel:
2009-01-
01T10:00:00.000Z

Request hash mandatory ^[a-zA-Z0-9]{32}$ siehe Kapitel


Parametervalidierung

10 Transaction capture Request

Transaction capture

Transaction capture schliesst einen 2-Phase Paymentvorgang ab und belastet den Account des
Subscribers.

Voraussetzungen:

 Two phase service


 Responsecode=0 der Authorisierung
 Diensterbringung war erfolgreich

Mögliche Folgeschritte:

 Im Falle eines vorläufigen Ergebnisses - Warten auf Transaction capture Callback

Transaction capture request(HTTP GET/POST):

https://billing.mbe4.de/http/transaction?
transactionid={transactionid}
&username={username}
&clientid={clientid}
&password={md5(password)}
&do=capture
&callbackurl={callbackurl}
&timestamp={timestamp}

Transaction capture response (HTTP GET/POST):

HTTP/1.1 200 OK
Content-Length: {content length}

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 21
responsecode={responsecode}
&description={description}
&timestamp={timestamp}

Parameter

IN/OUT Bezeichnung Präsenz Format Beschreibung

IN username mandatory ^[-a-zA-Z0-9_]{10,30}$ Username des Client

IN clientid mandatory ^[0-9]{5}$ clientid wird von


mbe zugeteilt

IN Password md5 mandatory ^[a-zA-Z0-9]{32}$ md5 verschlüsseltes


encrypted Password des Client

IN transactionid ^[0-9]{1,10}$ mbe transactionid

IN do mandatory ^capture$ Fixer String


“capture”

IN callbackurl mandatory ^http.{12,150}$ URl die aufgerufen


wird wenn der
capturing Vorgang
abgeschlossen
wurde.

IN timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0-9]{1}[- Timestamp


]{1}(([0]{1}[0-9]{1})|([1]{1}[0-
2]{1}))[-]{1}[0-3]{1}[0-
9]{1}[T]{1}[0-2]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-9]{1}[:]{1}[0-
5]{1}[0-9]{1}[.]{1}[0-9]{3}[Z]{1}$

Format:
YYYY-MM-DDTHH:MM:SS.mmmZ

Beispiel:
2009-01-01T10:00:00.000Z

OUT responsecode mandatory ^[0-9]{1,6}$ 0=OK … (siehe Liste


Responsecodes)

OUT description mandatory ^.{1,100}$ Responsecode


Beschreibung

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 22
OUT timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0-9]{1}[- Timestamp
]{1}(([0]{1}[0-9]{1})|([1]{1}[0-
2]{1}))[-]{1}[0-3]{1}[0-
9]{1}[T]{1}[0-2]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-9]{1}[:]{1}[0-
5]{1}[0-9]{1}[.]{1}[0-9]{3}[Z]{1}$

Format:
YYYY-MM-DDTHH:MM:SS.mmmZ

Beispiel:
2009-01-01T10:00:00.000Z

10.1 Transaction capture Callback

Transaction capture callback

mbe4 sendet einen Callback bei Statusänderungen der Transaktion im Rahmen des Transaction
capture an die vom Client übergebene callbackurl.

Voraussetzungen:

 Transaction capture responsecode=1

Mögliche Folgeschritte:

 Transaction refund

Transaction capture callback request (HTTP GET/POST):

https://{callbackURL}?
transactionid={transactionid}
&type=capture
&responsecode={responsecode}
&description={description}
&timestamp={timestamp}

Transaction capture callback response (HTTP GET/POST):

HTTP/1.1 200 OK

Parameter

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 23
Request/Response Bezeichnung Präsenz Format Beschreibung

Request transactionid mandatory ^([0-9A-F]{1,32})?$ mbe transactionid

Request type mandatory ^capture$ String capture

Request responsecode mandatory ^[0-9]{3}$ responsecode Siehe


Liste

Request description mandatory ^.{1,100}$ Beschreibung des


responsecode

Request timestamp mandatory YYYY-MM- Timestamp


DDTHH:MM:SS.mmmZ

2009-01-
01T10:00:00.000Z

11 Transaction terminate Request

Transaction terminate

Transaction terminate terminiert eine angelegte aber noch nicht mit Transaction capture
abgeschlossene Transaktion.

Voraussetzungen:

 Two phase service


 Aktive nicht abgeschlossene Transaktion

Mögliche Folgeschritte:

 Im Falle eines vorläufigen Ergebnisses - warten auf terminate Callback

Transaction terminate request (HTTP GET/POST):

https://billing.mbe4.de/http/transaction?
transactionid={transactionid}
&username={username}
&clientid={clientid}
&password={md5(password)}
&do=terminate
&reason={reason}
&callbackurl={callbackurl}
&timestamp={timestamp}

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 24
Transaction terminate response (HTTP GET/POST):

HTTP/1.1 200 OK
Content-Length: {content length}

responsecode={responsecode}
&description={description}
&timestamp={timestamp}

Parameter

IN/OUT Bezeichnung Präsenz Format Beschreibung

IN username mandatory ^[-a-zA-Z0-9_]{10,30}$ Username des Client

IN clientid mandatory ^[0-9]{5}$ clientid wird von


mbe zugeteilt

IN Password md5 mandatory ^[a-zA-Z0-9]{32}$ md5 verschlüsseltes


encrypted Password des Client

IN transactionid ^[0-9]{1,10}$ mbe transactionid

IN do mandatory ^terminate$ Fixer String


“terminate”

IN reason optional ^[-_*+()&!?:.;,&öäüÄÖÜß\sa-zA- Grund für die


Z0-9]{1,100}$ Terminierung
(Freitext)

IN callbackurl mandatory ^http.{12,150}$ URl die aufgerufen


wird wenn der
capturing Vorgang
abgeschlossen
wurde.

IN timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0-9]{1}[- Timestamp


]{1}(([0]{1}[0-9]{1})|([1]{1}[0-
2]{1}))[-]{1}[0-3]{1}[0-
9]{1}[T]{1}[0-2]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-9]{1}[:]{1}[0-
5]{1}[0-9]{1}[.]{1}[0-9]{3}[Z]{1}$

Format:
YYYY-MM-DDTHH:MM:SS.mmmZ

Beispiel:
2009-01-01T10:00:00.000Z

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 25
OUT responsecode mandatory ^[0-9]{1,6}$ 0=OK … (siehe Liste
Responsecodes)

OUT description mandatory ^.{1,100}$ Responsecode


Beschreibung

OUT timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0-9]{1}[- Timestamp


]{1}(([0]{1}[0-9]{1})|([1]{1}[0-
2]{1}))[-]{1}[0-3]{1}[0-
9]{1}[T]{1}[0-2]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-9]{1}[:]{1}[0-
5]{1}[0-9]{1}[.]{1}[0-9]{3}[Z]{1}$

Format:
YYYY-MM-DDTHH:MM:SS.mmmZ

Beispiel:
2009-01-01T10:00:00.000Z

11.1 Transaction terminate Callback

Transaction terminate Callback

mbe4 sendet einen Callback bei Statusänderungen der Transaktion im Rahmen des Transaction
terminate an die vom Client übergebene callbackurl.

Voraussetzungen:

 Transaction terminate responsecode=1

Mögliche Folgeschritte:

 keine

Transaction terminate callback request (HTTP GET/POST):

https://{callbackURL}?
transactionid={transactionid}
&type=terminate
&responsecode={responsecode}
&description={description}
&timestamp={timestamp}

Transaction terminate callback response (HTTP GET/POST):

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 26
HTTP/1.1 200 OK

Parameter

Request/Response Bezeichnung Präsenz Format Beschreibung

Request transactionid mandatory ^([0-9A-F]{1,32})?$ mbe transactionid

Request type mandatory ^terminate$ String „terminate“

Request responsecode mandatory ^[0-9]{3}$ responsecode siehe


Liste

Request description mandatory ^.{1,100}$ Beschreibung des


responsecode

Request timestamp mandatory YYYY-MM- Timestamp


DDTHH:MM:SS.mmmZ

2009-01-
01T10:00:00.000Z

12 Transaction refund Request

Transaction refund

Mit Transaction refund kann eine abgeschlossene Transaktion zurückgebucht werden.

Voraussetzungen:

 Transaction “capture” oder Transaction “directcapture” hat responsecode=0 gemeldet (2-


Phase)
 Oder widget forward mit responsecode=0 (1-Phase)

Mögliche Folgeschritte:

 Im Falle eines vorläufigen Ergebnisses - warten auf refund Callback

Transaction refund request (HTTP GET/POST):

https://billing.mbe4.de/http/transaction?
transactionid={transactionid}
&username={username}
&clientid={clientid}
&password={md5(password)}

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 27
&do=refund
&reason={reason}
&timestamp={timestamp}

Transaction refund response (HTTP GET/POST):

HTTP/1.1 200 OK
Content-Length: {content length}

responsecode={responsecode}
&description={description}
&timestamp={timestamp}

Parameter

IN/OUT Bezeichnung Präsenz Format Beschreibung

IN username mandatory ^[-a-zA-Z0-9_]{10,30}$ Username des Client

IN clientid mandatory ^[0-9]{5}$ clientid wird von mbe


zugeteilt

IN Password md5 mandatory ^[a-zA-Z0-9]{32}$ md5 verschlüsseltes


encrypted Password des Client

IN transactionid ^[0-9]{1,10}$ mbe transactionid

IN do mandatory ^refund$ Fixer String “refund”

IN reason optional ^[-_*+()&!?:.;,&öäüÄÖÜß\sa-zA- Grund für Refund


Z0-9]{1,100}$ (Freitext)

IN timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0-9]{1}[- Timestamp


]{1}(([0]{1}[0-9]{1})|([1]{1}[0-
2]{1}))[-]{1}[0-3]{1}[0-
9]{1}[T]{1}[0-2]{1}[0-9]{1}[:]{1}[0-
5]{1}[0-9]{1}[:]{1}[0-5]{1}[0-
9]{1}[.]{1}[0-9]{3}[Z]{1}$

Format:
YYYY-MM-DDTHH:MM:SS.mmmZ

Beispiel:
2009-01-01T10:00:00.000Z

OUT responsecode mandatory ^[0-9]{1,6}$ 0=OK … (siehe Liste


Responsecodes)

OUT description mandatory ^.{1,100}$ Responsecode

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 28
Beschreibung

OUT timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0-9]{1}[- Timestamp


]{1}(([0]{1}[0-9]{1})|([1]{1}[0-
2]{1}))[-]{1}[0-3]{1}[0-
9]{1}[T]{1}[0-2]{1}[0-9]{1}[:]{1}[0-
5]{1}[0-9]{1}[:]{1}[0-5]{1}[0-
9]{1}[.]{1}[0-9]{3}[Z]{1}$

Format:
YYYY-MM-DDTHH:MM:SS.mmmZ

Beispiel:
2009-01-01T10:00:00.000Z

12.1 Transaction refund Callback

Transaction refund Callback

mbe4 sendet einen Callback bei Statusänderungen der Transaktion im Rahmen des Transaction
refund an die vom Client übergebene callbackurl.

Voraussetzungen:

 Transaction refund responsecode=1

Mögliche Folgeschritte:

 keine

Transaction refund callback request (HTTP GET/POST):

https://{callbackURL}?
transactionid={transactionid}
&type=terminate
&responsecode={responsecode}
&description={description}
&timestamp={timestamp}

Transaction refund callback response (HTTP GET/POST):

HTTP/1.1 200 OK

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 29
Parameter

Request/Response Bezeichnung Präsenz Format Beschreibung

Request transactionid mandatory ^([0-9A-F]{1,32})?$ mbe transactionid

Request type mandatory ^refund$ Fixer String


„refund“

Request responsecode mandatory ^[0-9]{3}$ Responsecode siehe


Liste

Request description mandatory ^.{1,100}$ Beschreibung des


responsecode

Request timestamp mandatory YYYY-MM- Timestamp


DDTHH:MM:SS.mmmZ

2009-01-
01T10:00:00.000Z

13 Subscription Setup HTTP Forward Client->mbe4

Der Subscriber wählt „Abo abschließen“.

Client leitet den Subscriber an die mbe4 Payment Widget URL weiter.

Voraussetzungen:

 Subscriber hat Gut ausgewählt und klickt „Abo abschließen“


 clienttransactionid ist unique
 subscriptionid ist unique

Folgeschritte:

 warten auf http forward auf callbackURL

HTTP forward:

http(s)://billing.mbe4.de/widget?
username={username}
&clientid={clientid}
&serviceid={serviceid}
&contentclass={contentclass}
&description={description}
&clienttransactionid={clienttransactionid}
&amount={amount}
&callbackurl={callbackurl}

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 30
&subscriptionid={subscriptionid}
&subscriptiondescription={subscriptiondescription}
&subscriptioninterval={subscriptioninterval}
&timestamp={timestamp}
&hash={md5hashcode}

Parameter

IN/OU Bezeichnung Präsenz Format Beschreibung


T

IN username mandatory ^[-a-zA-Z0-9_]{10,30}$ Username des Client

IN clientid mandatory ^[0-9]{5}$ clientid wird von


mbe zugeteilt

IN serviceid mandatory ^[0-9]{5}$ serviceid wird von


mbe zugeteilt

IN contentclass mandatory ^[0-9]{1,2}$ Klassifizierung des


Contents (siehe Liste)

IN description mandatory ^.{1,100}$ verbale


Beschreibung des
Contents

IN clienttransactionid mandatory ^[-a-zA-Z0-9_]{1,95}$ unique id des Client


welche diese
Transaktion
beschreibt.
clienttransactionid
darf sich nie
wiederholen.

IN amount mandatory ^[1-9]{1}[0-9]{0,4}$ Betrag in EUR Cent

IN callbackurl mandatory ^http.{12,150}$ URL an die mbe4


nach asynchronem
Abschluss forwarded

IN tanid optional ^[a-zA-Z0-9]{1,16}$ Text der in der TAN


SMS den aktuellen
TAN näher

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 31
beschreibt um
Abgrenzungen bei
mehreren aktuell
gültigen TANs
gewährleisten zu
können

IN tansmstext optional ^[-a-zA-Z0-9_*+()&!? Dieser Text wird als


:.;,öäüÖÄÜß]{10,160}$ TAN-SMS versendet.
Die Platzhalter in {}
Beispieltext:
werden von mbe4
{CLIENT}: Zum Bezahlen von
{AMOUNT} Euro geben Sie bzw dem Operator
bitte ersetzt. Die
folgende PIN ein: {PIN}. Gesamtlänge des
(Vorgang: {TANID}) Textes darf nach
Ersetzung der
Platzhalter 160
Zeichen nicht
überschreiten.

IN subscriptionId mandatory ^[a-zA-Z0-9]{1,32}$ unique id des Client


welche diese
Subscription
beschreibt.
subscriptionId darf
sich nie wiederholen.

IN subscription mandatory ^[a-zA-Z0-9 \.,!?\-]{1,20}$ Verbale


description Beschreibung des
Abonnements

IN subscriptioninterval mandatory ^[0-9]{1,3}$ zeitlicher Abstand


zweier Payment-
transaktionen
innerhalb des
Abonnements in
Tagen

IN timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0-9]{1}[- Timestamp


]{1}(([0]{1}[0-9]{1})|([1]{1}[0-
2]{1}))[-]{1}[0-3]{1}[0-
9]{1}[T]{1}[0-2]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[.]{1}[0-9]{3}[Z]{1}$

Format:
YYYY-MM-
DDTHH:MM:SS.mmmZ

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 32
Beispiel:
2009-01-01T10:00:00.000Z

IN hash mandatory ^[a-zA-Z0-9]{32}$ Siehe Kapitel


Parameter-
validierung

13.1 Subscription Setup HTTP forward mbe4 -> Client

Nach Abschluss von Authorisierung und Paymenttransaktion bzw. nach vorzeitigem Abbruch leitet
mbe4 den Subscriber per http forward an die vom Client übergebene CallbackURL weiter.

Voraussetzungen:

 http forward an des Subscribers vom Client an mb4


 endgültiger Status der Paymenttransaktion wurde erreicht

Mögliche Folgeschritte:

 Auslieferung des Contents (Diensterbringung) durch den Client


 Im 2Phase Falle: nachfolgendes Senden eines „capture“ Request

HTTP forward:

https://{callbackurl}?
transactionid={transactionid}
&clienttransactionid={clienttransactionid}
&responsecode={responsecode}
&description={description}
&subscriberid={subscriberid}
&operatorid={operatorid}
&subscriptionid={subscriptionid}
&timestamp={timestamp}
&hash={md5hashcode}

Parameter

Request/ Bezeichnung Präsenz Format Beschreibung

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 33
Response

Request transactionid mandatory ^[0-9]{1,10}$ mbe transactionid

Request clienttransactionid mandatory ^[-a-zA-Z0-9_]{1,95}$ unique id des Client


welche diese
Transaktion beschreibt.
clienttransactionid darf
sich nie wiederholen.

Request responsecode mandatory ^[0-9]{1,6}$ 0=OK … (siehe Liste


Responsecodes)

Request description mandatory ^.{1,100}$ Responsecode


Beschreibung

Request subscriberid mandatory ^491[5-7]{1}[0-9]{8,9}$ MSISDN des Subscribers

Request operatorid mandatory ^[-0-9a-zA-Z]{1-20}$ Operator siehe Liste

Request subscriptionid mandatory ^[a-zA-Z0-9]{1,32}$ Unique id des Client


welche diese
Subscription
beschreibt.

Request timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0- Timestamp


9]{1}[-]{1}(([0]{1}[0-
9]{1})|([1]{1}[0-2]{1}))[-
]{1}[0-3]{1}[0-
9]{1}[T]{1}[0-2]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[.]{1}[0-
9]{3}[Z]{1}$

Format:
YYYY-MM-
DDTHH:MM:SS.mmmZ

Beispiel:
2009-01-
01T10:00:00.000Z

Request hash mandatory ^[a-zA-Z0-9]{32}$ siehe Kapitel


Parametervalidierung

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 34
14 Subscription followupauthorize Request

Subscription followupauthorize

Subscription followupauthorize stößt eine 2-Phase Paymentransaktion im Rahmen eines


Abonnements(Subscription) an.

Voraussetzungen:

 Aktives ungekündigtes Abonnement (Subscription)

Mögliche Folgeschritte:

 Im Falle eines vorläufigen Ergebnisses - Warten auf followupauthorize Callback

Subscription followupauthorize request(HTTP GET/POST):

https://billing.mbe4.de/http/transaction?
subscriptionid ={subscriptionid}
&subscriptiondescription={subscriptiondescription}
&subscriptioninterval={subscriptioninterval}
&username={username}
&clientid={clientid}
&password={md5(password)}
&serviceid={serviceid}
&contentclass={contentclass}
&description={description}
&clienttransactionid={clienttransactionid}
&amount={amount}
&subscriberid={subscriberid}
&do=followupauthorize
&callbackurl={callbackurl}
&ordertype={ordertype}
&timestamp={timestamp}

Subscription followupauthorize response (HTTP GET/POST):

HTTP/1.1 200 OK
Content-Length: {content length}

responsecode={responsecode}
&description={description}
&timestamp={timestamp}

Parameter

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 35
IN/OUT Bezeichnung Präsenz Format Beschreibung

IN subscriptionid mandatory ^[a-zA-Z0-9]{1,32}$ subscriptionid zu


der diese FollowUp
Transaktion gehört

IN subscriptiondescription mandatory ^[a-zA-Z0-9 \.,!?\-]{1,20}$ Verbale


Beschreibung der
Subscription (muss
dem Parameter des
SubscriptionSetup
entsprechen)

IN subscriptioninterval mandatory ^[0-9]{1,3}$ Subscriptioninterval


identisch zu
Subscriptionsetup

IN username mandatory ^[-a-zA-Z0-9_]{10,30}$ Username des


Client

IN clientid mandatory ^[0-9]{5}$ clientid wird von


mbe zugeteilt

IN Password md5 mandatory ^[a-zA-Z0-9]{32}$ md5 verschlüsseltes


encrypted Password des Client

IN serviceid mandatory ^[0-9]{5}$ serviceid wird von


mbe zugeteilt

IN contentclass mandatory ^[0-9]{1,2}$ Contentclass der


Subscription

IN description mandatory ^.{1,100}$ verbale


Beschreibung des
Contents

IN clienttransactionid mandatory ^[-a-zA-Z0-9_]{1,95}$ unique id des Client


welche diese
Transaktion
beschreibt.
clienttransactionid
darf sich nie
wiederholen.

IN amount mandatory ^[1-9]{1}[0-9]{0,4}$ Betrag in EUR Cent


Subscription (muss
dem Parameter des
SubscriptionSetup
entsprechen)

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 36
IN subscriberid mandatory ^491[5-7]{1}[0-9]{8,9}$ MSISDN des
Subscribers

IN do mandatory ^followupauthorize$ Fixer String


“followupauthorize”

IN callbackurl mandatory ^http.{12,150}$ URl die aufgerufen


bei wird wenn der
asynchronem capturing Vorgang
Aufruf abgeschlossen
wurde.

IN ordertype mandatory ^web|wap$ Ordertype der


Subscription.

IN synchron mandatory ^true$ Sobald ein


im Parametervalue für
synchronen synchron
modus übergeben wird
antwortet mbe4 im
synchronen Modus
(ohne Callback)

IN timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0- Timestamp


9]{1}[-]{1}(([0]{1}[0-
9]{1})|([1]{1}[0-2]{1}))[-
]{1}[0-3]{1}[0-
9]{1}[T]{1}[0-2]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[.]{1}[0-9]{3}[Z]{1}$

Format:
YYYY-MM-
DDTHH:MM:SS.mmmZ

Beispiel:
2009-01-
01T10:00:00.000Z

OUT responsecode mandatory ^[0-9]{1,6}$ 0=OK … (siehe Liste


Responsecodes)

OUT description mandatory ^.{1,100}$ Responsecode


Beschreibung

OUT timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0- Timestamp


9]{1}[-]{1}(([0]{1}[0-
9]{1})|([1]{1}[0-2]{1}))[-
]{1}[0-3]{1}[0-

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 37
9]{1}[T]{1}[0-2]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[.]{1}[0-9]{3}[Z]{1}$

Format:
YYYY-MM-
DDTHH:MM:SS.mmmZ

Beispiel:
2009-01-
01T10:00:00.000Z

14.1 Subscription followupauthorize Callback

Subscription followupauthorize callback

mbe4 sendet einen Callback bei Statusänderungen der Transaktion im Rahmen des Subscription
followupauthorize an die vom Client übergebene callbackurl.

Voraussetzungen:

 Subscription followupauthorize responsecode=1

Mögliche Folgeschritte:

 Transaction capture

Subscription followupauthorize Callback Request (HTTP GET/POST):

https://{callbackURL}?
transactionid={transactionid}
&type=authorize
&responsecode={responsecode}
&description={description}
&timestamp={timestamp}

Subscription followupauthorize Callback Response (HTTP GET/POST):

HTTP/1.1 200 OK

Parameter

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 38
Request/Response Bezeichnung Präsenz Format Beschreibung

Request transactionid mandatory ^([0-9A-F]{1,32})?$ mbe4 TransactionId

Request type mandatory ^authorize$ String „authorize“

Request responsecode mandatory ^[0-9]{3}$ Responsecode


Siehe Liste

Request description mandatory ^.{1,100}$ Beschreibung des


responsecode

Request timestamp mandatory YYYY-MM- Timestamp


DDTHH:MM:SS.mmmZ

2009-01-
01T10:00:00.000Z

15 Subscription followupdirectcapture Request

Subscription followupdirectcapture

Subscription followupdirectcapture stößt eine 1-Phase Transaktion im Rahmen eines


Abonnements(Subscription) an.

Voraussetzungen:

 Aktives ungekündigtes Abonnement (Subscription)

Mögliche Folgeschritte:

 Im Falle eines vorläufigen Ergebnisses - Warten auf followupdirectcapture callback

Subscription followupdirectcapture request(HTTP GET/POST):

https://billing.mbe4.de/http/transaction?
subscriptionid ={subscriptionid}
&subscriptiondescription={subscriptiondescription}
&subscriptioninterval={subscriptioninterval}
&username={username}
&clientid={clientid}
&password={md5(password)}
&serviceid={serviceid}
&contentclass={contentclass}

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 39
&description={description}
&clienttransactionid={clienttransactionid}
&amount={amount}
&subscriberid={subscriberid}
&do=followupdirectcapture
&callbackurl={callbackurl}
&ordertype={ordertype}
&timestamp={timestamp}

Subscription followupdirectcapture response (HTTP GET/POST):

HTTP/1.1 200 OK
Content-Length: {content length}

responsecode={responsecode}
&description={description}
&timestamp={timestamp}

Parameter

IN/OUT Bezeichnung Präsenz Format Beschreibung

IN subscriptionid mandatory ^[a-zA-Z0-9]{1,32}$ Subscriptionid zu


der diese FollowUp
Transaktion gehört

IN subscriptiondescription mandatory ^[a-zA-Z0-9 \.,!?\-]{1,20}$ Verbale


Beschreibung der
Subscription (muss
dem Paremeter des
SubscriptionSetup
entsprechen)

IN subscriptioninterval mandatory ^[0-9]{1,3}$ Subscriptioninterval


identisch zu
Subscriptionsetup

IN username mandatory ^[-a-zA-Z0-9_]{10,30}$ Username des


Client

IN clientid mandatory ^[0-9]{5}$ clientid wird von


mbe zugeteilt

IN password md5 mandatory ^[a-zA-Z0-9]{32}$ md5 verschlüsseltes


encrypted Password des Client

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 40
IN serviceid mandatory ^[0-9]{5}$ serviceid wird von
mbe zugeteilt

IN contentclass mandatory ^[0-9]{1,2}$ Contentclass der


Subscription

IN description mandatory ^.{1,100}$ verbale


Beschreibung des
Contents

IN clienttransactionid mandatory ^[-a-zA-Z0-9_]{1,95}$ Unique id des Client


welche diese
Transaktion
beschreibt.
clienttransactionid
darf sich nie
wiederholen.

IN amount mandatory ^[1-9]{1}[0-9]{0,4}$ Betrag in EUR Cent


Subscription (muss
dem Parameter des
SubscriptionSetup
entsprechen)

IN subscriberid mandatory ^491[5-7]{1}[0-9]{8,9}$ MSISDN des


Subscribers

IN do mandatory ^followupauthorize$ Fixer String


“followupauthorize”

IN callbackurl mandatory ^http.{12,150}$ URl die aufgerufen


bei wird wenn der
asynchronem capturing Vorgang
Aufruf abgeschlossen
wurde.

IN ordertype mandatory ^web|wap$ ordertype der


Subscription.

IN synchron mandatory ^true$ Sobald ein


im Parametervalue für
synchronen synchron
modus übergeben wird
antwortet mbe4 im
synchronen Modus
(ohne Callback)

IN timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0- Timestamp


9]{1}[-]{1}(([0]{1}[0-

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 41
9]{1})|([1]{1}[0-2]{1}))[-
]{1}[0-3]{1}[0-
9]{1}[T]{1}[0-2]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[.]{1}[0-9]{3}[Z]{1}$

Format:
YYYY-MM-
DDTHH:MM:SS.mmmZ

Beispiel:
2009-01-
01T10:00:00.000Z

OUT responsecode mandatory ^[0-9]{1,6}$ 0=OK … (siehe Liste


Responsecodes)

OUT description mandatory ^.{1,100}$ Responsecode


Beschreibung

OUT timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0- Timestamp


9]{1}[-]{1}(([0]{1}[0-
9]{1})|([1]{1}[0-2]{1}))[-
]{1}[0-3]{1}[0-
9]{1}[T]{1}[0-2]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[.]{1}[0-9]{3}[Z]{1}$

Format:
YYYY-MM-
DDTHH:MM:SS.mmmZ

Beispiel:
2009-01-
01T10:00:00.000Z

15.1 Subscription followupdirectcapture Callback

Subscription followupdirectcapture CSallback

mbe4 sendet einen Callback bei Statusänderungen der Transaktion im Rahmen des Transaction
capture an die vom Client übergebene Callbackurl.

Voraussetzungen:

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 42
 Subscription followupdirectcapture responsecode=1

Mögliche Folgeschritte:

 keine

Subscription followupdirectcapture Callback Request (HTTP GET/POST):

https://{callbackURL}?
transactionid={transactionid}
&type=capture
&responsecode={responsecode}
&description={description}
&timestamp={timestamp}

Subscription followupdirectcapture Callback Response (HTTP GET/POST):

HTTP/1.1 200 OK

Parameter

Request/Response Bezeichnung Präsenz Format Beschreibung

Request transactionid mandatory ^([0-9A-F]{1,32})?$ mbe4 transactionid

Request type mandatory ^capture$ fixer String


„capture“

Request responsecode mandatory ^[0-9]{3}$ responsecode Siehe


Liste

Request description mandatory ^.{1,100}$ Beschreibung des


responsecode

Request timestamp mandatory YYYY-MM- Timestamp


DDTHH:MM:SS.mmmZ

2009-01-
01T10:00:00.000Z

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 43
16 Subscription terminate Request

Subscription terminate

Subscription terminate beendet ein aktives Abonnement(Subscription)

Voraussetzungen:

 Aktives Abonnement(Subscription)

Mögliche Folgeschritte:

 Im Falle eines vorläufigen Ergebnisses - warten auf subscriptionterminate Callback

Subscription terminate request (HTTP GET/POST):

https://billing.mbe4.de/http/transaction?
subscriptionid ={subscriptionid}
&username={username}
&clientid={clientid}
&password={md5(password)}
&serviceid={serviceid}
&clienttransactionid={clienttransactionid}
&reason={reason}
&subscriberid={subscriberid}
&do=subscriptionterminate
&callbackurl={callbackurl}
&ordertype=web
&timestamp={timestamp}

Subscription terminate response (HTTP GET/POST):

HTTP/1.1 200 OK
Content-Length: {content length}

responsecode={responsecode}
&description={description}
&timestamp={timestamp}

Parameter

IN/OUT Bezeichnung Präsenz Format Beschreibung

IN subscriptionid mandatory ^[a-zA-Z0-9]{1,32}$ subscriptionid zu der


diese FollowUp
Transaktion gehört

IN username mandatory ^[-a-zA-Z0-9_]{10,30}$ Username des Client

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 44
IN clientid mandatory ^[0-9]{5}$ clientid wird von mbe
zugeteilt

IN password md5 mandatory ^[a-zA-Z0-9]{32}$ md5 verschlüsseltes


encrypted Password des Client

IN serviceid mandatory ^[0-9]{5}$ serviceid wird von mbe


zugeteilt

IN clienttransactionid mandatory ^[-a-zA-Z0-9_]{1,95}$ Unique id des Client


welche diese
Transaktion beschreibt.
clienttransactionid darf
sich nie wiederholen.

IN reason mandatory ^[- Grund für die


_*+()&!?:.;,&öäüÄÖÜß\sa- Terminierung (Freitext)
zA-Z0-9]{1,100}$

IN subscriberid mandatory ^491[5-7]{1}[0-9]{8,9}$ MSISDN des Subscribers

IN do mandatory ^subscriptionterminate$ Fixer String


“subscriptionterminate”

IN callbackurl mandatory ^http.{12,150}$ URl die aufgerufen wird


bei wenn der capturing
asynchronem Vorgang abgeschlossen
Aufruf wurde.

IN ordertype mandatory ^web|wap$ Ordertype der


Subscription.

IN synchron mandatory ^true$ Sobald ein


im Parametervalue für
synchronen synchron übergeben
modus wird antwortet mbe4
im synchronen Modus
(ohne Callback)

IN timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0- Timestamp


9]{1}[-]{1}(([0]{1}[0-
9]{1})|([1]{1}[0-2]{1}))[-
]{1}[0-3]{1}[0-9]{1}[T]{1}[0-
2]{1}[0-9]{1}[:]{1}[0-5]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[.]{1}[0-9]{3}[Z]{1}$

Format:
YYYY-MM-
DDTHH:MM:SS.mmmZ

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 45
Beispiel:
2009-01-01T10:00:00.000Z

OUT responsecode mandatory ^[0-9]{1,6}$ 0=OK … (siehe Liste


Responsecodes)

OUT description mandatory ^.{1,100}$ Responsecode


Beschreibung

OUT timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0- Timestamp


9]{1}[-]{1}(([0]{1}[0-
9]{1})|([1]{1}[0-2]{1}))[-
]{1}[0-3]{1}[0-9]{1}[T]{1}[0-
2]{1}[0-9]{1}[:]{1}[0-5]{1}[0-
9]{1}[:]{1}[0-5]{1}[0-
9]{1}[.]{1}[0-9]{3}[Z]{1}$

Format:
YYYY-MM-
DDTHH:MM:SS.mmmZ

Beispiel:
2009-01-01T10:00:00.000Z

16.1 Subscription terminate Callback

Subscription terminate callback

mbe4 sendet einen Callback bei Statusänderungen der Transaktion im Rahmen des Subscription
terminate an die vom Client übergebene Callbackurl.

Voraussetzungen:

 Subscription terminate responsecode=1

Mögliche Folgeschritte:

 keine

Subscription terminate callback request (HTTP GET/POST):

https://{callbackURL}?
transactionid={transactionid}
&type=terminate
&responsecode={responsecode}
&description={description}
&timestamp={timestamp}

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 46
Subscription terminate callback response (HTTP GET/POST):

HTTP/1.1 200 OK

Parameter

Request/Response Bezeichnung Präsenz Format Beschreibung

Request transactionid mandatory ^([0-9A-F]{1,32})?$

Request type mandatory ^terminate$ fixer String


„terminate“

Request responsecode mandatory ^[0-9]{3}$ responsecode Siehe


Liste

Request description mandatory ^.{1,100}$ Beschreibung des


responsecode

Request timestamp mandatory YYYY-MM- Timestamp


DDTHH:MM:SS.mmmZ

2009-01-
01T10:00:00.000Z

17 Liste Responsecodes

Statuscode Beschreibung

0 OK

1 NOT FINAL – request was processed successfully


but the answer is not final.

(e.g. a TAN was sent to the subscriber and tan


received must be called)

2 authorization failed

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 47
3 capture failed

4 terminate failed

5 refund failed

6 prepair failed

7 transaction failed

8 subscription terminate failed

101 invalid parameter

109 transaction in wrong status

110 wrong PIN

111 too many PIN attempts - transaction closed

112 subscriber aborted transaction

113 no route to operator

121 subscriberid unascertainable

126 sending TAN SMS failed

150 subscriptionid unknown

151 subscriptionid not unique

152 subscription terminated

200 internal server error

201 system currently unavailable

18 Liste Contentclasses
ContentClass Beschreibung

1 News/Info

2 Chat/Flirt

3 Game

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 48
4 Klingelton

5 Bild/Logo

6 Videoclip

7 Music File

8 Lokalisierung

9 Voting

10 Gewinnspiel

11 Portal Zugang

12 Software

13 Dokument

14 Ticket

15 Horoskop

16 Freizeit

17 Unterwegs

18 Finanzen

19 Shopping

20 E-Mail

21 Spende

19 Liste Operatorids

ID Operator

262-01 T-Mobile Germany

262-02 Vodafone D2 Germany

262-03 E-Plus Germany

262-07 O2 Germany

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 49
262-DEBITEL Debitel Germany

262-MOBILCOM Mobilcom Germany

20 Liste TAN SMS Text

OperatorID Text Absender

262-01 [Client]: Zum Bezahlen von [x.x] Euro geben Sie +491234
bitte folgenden Bezahl-Code ein: PIN (Vorgang (BezahlCode)
transaction-#)

262-02 Vodafone: Zum Bezahlen von xx.xx Euro bei 6729


Vendor-Name geben Sie bitte folgenden Bezahl- (mpay)
Code beim Händler ein: PIN (Vorgang
transaction-#)

262-03 Anbei erhalten Sie den Bezahlcode zur 1232111


Bestellung eines kostpflichtigen Dienst in Höhe
von xx,xx EURO: PIN

262-07 Zum Bezahlen von xx,xx Euro für ihren Service 66245
Description bei Vendor-Name geben Sie bitte
Bezahlcode PIN ein. Mit der Eingabe lösen Sie
einen Zahlungsvorgang aus.

262-DEBITEL tbd tbd

262-MOBILCOM tbd tbd

mobile business engine GmbH – mbe 4 - Payment Interface – Mobile Payment Widget 50