Anlage3 mbe4 Spezifikation Mobile Payment Widget v2.2

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

Mobile Payment Widget

Version 2.2

15.09.2010


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


16.1 Subscription terminate Callback ........................................................................................... 46

17 Liste Responsecodes ...................................................................................................................... 47

18 Liste Contentclasses ...................................................................................................................... 48

19 Liste Operatorids ........................................................................................................................... 49

20 Liste TAN SMS Text ........................................................................................................................ 50


1 Historie

Datum Änderung erstellte

Version

Author

15.12.2009 initial erstellt 1.0 Sten Uhlig

05.01.2010 Ergänzung 2-Phase Payment

Änderungen URLs und Ressourcen

1.1 Sten Uhlig

27.01.2010 Änderung Länge CallbackURL

Korrektur Bezeichnung „hash“

1.2 Sten Uhlig

23.02.2010 neuer Reponsecode 113

neuer Reponsecode 121

neuer Punkt „Besonderheiten im WAP/mobile WEB“

neue Validierung des Parameters Description

1.3 Sten Uhlig

10.04.2010 Erweiterung um Subscription

Bereinigung Responsecodes

2.0 Sten Uhlig

01.09.2010 Fehlerkorrekturen Parameterlisten

Erweiterung Followup Payment Parameterlisten um

subscriptiondescription, subscriptioninterval

2.1 Sten Uhlig

15.09.2010 Erweiterung synchrone Webservice Requests

Erweiterung One Phase Subscription Setup

2.2 Sten Uhlig


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


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


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.


6.1 1-Phase Single Payment

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.

Subscriber Client mbe4

Wählt „zahlen“ HTTP forward

login

amount

response

…usw

Leistungserbringung

HTTP forward

result

msisdn

…usw

Authorisierung

Buchung


6.2 2-Phase Single Payment


durch (Client übergibt Paymentparameter mit der Forward URL).


reserviert (Authorisierung).





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.


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

Hinweis:


Wählt „zahlen“ HTTP forward

login

amount

response

…usw

Leistungserbringung

HTTP forward

result

msisdn

…usw

Transaction capture

Transaction capture callback

Transaction capture response

Authorisierung

Buchung


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).


6.3 1 –Phase Subscription Setup

Followup DirectCapture Response

Subsciption terminate Response


HTTP forward

login

amount

response

…usw

Leistungserbringung

HTTP forward

result

msisdn

…usw

Subscription

Authorisierung

Buchung

Wählt „Abo abschließen“

Followup Authorize

Followup Authorize Response

Followup Authorize Callback

2a.

Fo

llow

up

pay

men

t

2-p

has

e 1

. Su

bsc

rip

tio

n S

etu

p

Leistungserbringung Transaction capture

Transaction capture Response

Authorisierung

Buchung

2b

. Fo

llow

up

pay

men

t

1-p

has

e

Followup DirectCapture

Followup DirectCapture Callback

Leistungserbringung

Authorisierung

Buchung

3.

Sub

scri

pti

on

te

rmin

ate

Wählt „Abo kündigen“ Subscription terminate

Subscription terminate Callback

Subscription

Terminierung

Transaction capture Callback


Subscription besteht aus den folgenden 3 Schritten (Schritt 2 wiederholt sich ggf. mehrfach)

1. Subscription Setup – Abschluss eines Abonnements inklusive einer initialen

Paymentransaktion


durch (Client übergibt Subscriptionparameter mit der Forward URL).


reserviert (Authorisierung), gleichzeitig final gebucht (Buchung) und das Abonnement

angelegt.






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.



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.


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.


2. mbe4 führt den Directcapture Prozess durch. Dabei wir der Paymentbetrag

reserviert (Authorize) und gebucht (Capture).



„followupdirectcapture“ Callback mit dem finalen Ergebnis der Buchung.




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.



„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


6.4 2 –Phase Subscription Setup

Followup DirectCapture Response

Subsciption terminate Response


HTTP forward

login

amount

response

…usw

Leistungserbringung

HTTP forward

result

msisdn

…usw


Transaction capture


Subscription

Authorisierung

Buchung

Wählt „Abo abschließen“

Followup Authorize

Followup Authorize Response

Followup Authorize Callback

2a.

Fo

llow

up

pay

men

t

2-p

has

e 2

. Su

bsc

rip

tio

n S

etu

p

Leistungserbringung Transaction capture


Authorisierung

Buchung

2b

. Fo

llow

up

pay

men

t

1-p

has

e

Followup DirectCapture

Followup DirectCapture Callback

Leistungserbringung

Authorisierung

Buchung

3.

Sub

scri

pti

on

te

rmin

ate

Wählt „Abo kündigen“ Subscription terminate

Subscription terminate Callback

Subscription

Terminierung

Transaction capture Callback


Subscription besteht aus den folgenden 3 Schritten (Schritt 2 wiederholt sich ggf. mehrfach)

4. Subscription Setup – Abschluss eines Abonnements inklusive einer initialen

Paymentransaktion


durch (Client übergibt Subscriptionparameter mit der Forward URL).


reserviert (Authorisierung) und das Abonnement angelegt.





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.


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


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.


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}


&hash={md5hashcode}

Parameter

IN/OU

T

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


IN tansmstext optional ^[-a-zA-Z0-9_*+()&!? :.;,öäüÖÄÜß]{10,160}$ Beispieltext: {CLIENT}: Zum Bezahlen von {AMOUNT} Euro geben Sie bitte folgende PIN ein: {PIN}. (Vorgang: {TANID})

Dieser Text wird als

TAN-SMS versendet.

Die Platzhalter in {}

werden von mbe4

bzw dem Operator

ersetzt. Die

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}[-]{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

Timestamp

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


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/

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-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}$

Timestamp


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


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}


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

Parameter

IN/OUT Bezeichnung Präsenz Format Beschreibung



mbe zugeteilt

IN Password md5

encrypted

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

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.


Timestamp

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}[-]{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

Timestamp

10.1 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


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


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-DDTHH:MM:SS.mmmZ 2009-01-01T10:00:00.000Z

Timestamp

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


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}


Transaction terminate response (HTTP GET/POST): HTTP/1.1 200 OK Content-Length: {content length} responsecode={responsecode} &description={description} &timestamp={timestamp}

Parameter




mbe zugeteilt

IN Password md5

encrypted


Password des Client


IN do mandatory ^terminate$ Fixer String

“terminate”

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

Z0-9]{1,100}$

Grund für die

Terminierung

(Freitext)

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

wird wenn der

capturing Vorgang

abgeschlossen

wurde.


Timestamp



Responsecodes)


Beschreibung


Timestamp

11.1 Transaction terminate Callback

Transaction terminate Callback


terminate an die vom Client übergebene callbackurl.

Voraussetzungen:

Transaction terminate responsecode=1


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):


HTTP/1.1 200 OK

Parameter



Request type mandatory ^terminate$ String „terminate“

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

Liste


responsecode


Timestamp

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)


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)}


&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 clientid mandatory ^[0-9]{5}$ clientid wird von mbe

zugeteilt

IN Password md5

encrypted


Password des Client


IN do mandatory ^refund$ Fixer String “refund”

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

Z0-9]{1,100}$

Grund für Refund

(Freitext)


Timestamp


Responsecodes)



Beschreibung


Timestamp

12.1 Transaction refund Callback

Transaction refund Callback


refund an die vom Client übergebene callbackurl.

Voraussetzungen:

Transaction refund responsecode=1


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


Parameter



Request type mandatory ^refund$ Fixer String

„refund“

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

Liste


responsecode


Timestamp

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}


&subscriptionid={subscriptionid} &subscriptiondescription={subscriptiondescription} &subscriptioninterval={subscriptioninterval} &timestamp={timestamp} &hash={md5hashcode}

Parameter

IN/OU

T




mbe zugeteilt


mbe zugeteilt

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

Contents (siehe Liste)


Beschreibung des

Contents


welche diese

Transaktion

beschreibt.

clienttransactionid

darf sich nie

wiederholen.


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

IN tansmstext optional ^[-a-zA-Z0-9_*+()&!? :.;,öäüÖÄÜß]{10,160}$ Beispieltext: {CLIENT}: Zum Bezahlen von {AMOUNT} Euro geben Sie bitte folgende PIN ein: {PIN}. (Vorgang: {TANID})

Dieser Text wird als

TAN-SMS versendet.

Die Platzhalter in {}

werden von mbe4

bzw dem Operator

ersetzt. Die

Gesamtlänge des

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


IN subscription

description

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

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}[-]{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

Timestamp


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


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


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




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

Timestamp

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

Parametervalidierung


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)


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



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


mbe zugeteilt

IN Password md5

encrypted


Password des Client


mbe zugeteilt

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

Subscription


Beschreibung des

Contents


welche diese

Transaktion

beschreibt.

clienttransactionid

darf sich nie

wiederholen.


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

bei

asynchronem

Aufruf

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

wird wenn der

capturing Vorgang

abgeschlossen

wurde.

IN ordertype mandatory ^web|wap$ Ordertype der

Subscription.

IN synchron mandatory

im

synchronen

modus

^true$ Sobald ein

Parametervalue für

synchron

übergeben wird

antwortet mbe4 im

synchronen Modus

(ohne Callback)


Timestamp


Responsecodes)


Beschreibung

OUT timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0-9]{1}[-]{1}(([0]{1}[0-9]{1})|([1]{1}[0-2]{1}))[-]{1}[0-3]{1}[0-

Timestamp


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


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



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


responsecode


Timestamp

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)


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}


&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 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


mbe zugeteilt

IN password md5

encrypted


Password des Client



mbe zugeteilt

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

Subscription


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.


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”


bei

asynchronem

Aufruf

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

wird wenn der

capturing Vorgang

abgeschlossen

wurde.

IN ordertype mandatory ^web|wap$ ordertype der

Subscription.


im

synchronen

modus

^true$ Sobald ein

Parametervalue für

synchron

übergeben wird

antwortet mbe4 im

synchronen Modus

(ohne Callback)

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

Timestamp


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


Responsecodes)


Beschreibung


Timestamp

15.1 Subscription followupdirectcapture Callback

Subscription followupdirectcapture CSallback


capture an die vom Client übergebene Callbackurl.

Voraussetzungen:


Subscription followupdirectcapture responsecode=1


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 transactionid mandatory ^([0-9A-F]{1,32})?$ mbe4 transactionid

Request type mandatory ^capture$ fixer String

„capture“


Liste


responsecode


Timestamp


16 Subscription terminate Request

Subscription terminate

Subscription terminate beendet ein aktives Abonnement(Subscription)

Voraussetzungen:

Aktives Abonnement(Subscription)


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 subscriptionid mandatory ^[a-zA-Z0-9]{1,32}$ subscriptionid zu der

diese FollowUp

Transaktion gehört



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

zugeteilt

IN password md5

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




IN reason mandatory ^[-

_*+()&!?:.;,&öäüÄÖÜß\sa-

zA-Z0-9]{1,100}$

Grund für die

Terminierung (Freitext)

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

IN do mandatory ^subscriptionterminate$ Fixer String

“subscriptionterminate”


bei

asynchronem

Aufruf

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

wenn der capturing

Vorgang abgeschlossen

wurde.

IN ordertype mandatory ^web|wap$ Ordertype der

Subscription.


im

synchronen

modus

^true$ Sobald ein

Parametervalue für

synchron übergeben

wird antwortet mbe4

im synchronen Modus

(ohne Callback)

IN timestamp mandatory ^[2]{1}[0]{1}[0-2]{1}[0-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

Timestamp


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


Responsecodes)


Beschreibung


Timestamp

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


keine

Subscription terminate callback request (HTTP GET/POST): https://{callbackURL}? transactionid={transactionid} &type=terminate &responsecode={responsecode} &description={description} &timestamp={timestamp}


Subscription terminate callback response (HTTP GET/POST): HTTP/1.1 200 OK

Parameter


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

Request type mandatory ^terminate$ fixer String

„terminate“


Liste


responsecode


Timestamp

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


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


19 Liste Operatorids

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

ID Operator

262-01 T-Mobile Germany

262-02 Vodafone D2 Germany

262-03 E-Plus Germany

262-07 O2 Germany


20 Liste TAN SMS Text

262-DEBITEL Debitel Germany

262-MOBILCOM Mobilcom Germany

OperatorID Text Absender

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

+491234 (BezahlCode)

262-02 Vodafone: Zum Bezahlen von xx.xx Euro bei Vendor-Name geben Sie bitte folgenden Bezahl- Code beim Händler ein: PIN (Vorgang transaction-#)

6729 (mpay)

262-03 Anbei erhalten Sie den Bezahlcode zur Bestellung eines kostpflichtigen Dienst in Höhe von xx,xx EURO: PIN

1232111

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

66245

262-DEBITEL tbd tbd

262-MOBILCOM tbd tbd

Date post:	28-Mar-2015
Category:	Documents
Upload:	majavacenovski
View:	264 times
Download:	2 times

Anlage3 mbe4 Spezifikation Mobile Payment Widget v2.2

Documents