Merchant Service Provider Guide for Mobilpenge Based Acquiring

Merchant Service Provider Guide for Mobilpenge Based Acquiring November 14, 2011 Version 1.07 Nets Technical Guide Copyright Nets Danmark A/S Page 1

Contents 1 Introduction... 4 1.1 Notation convention... 4 1.2 Character set... 5 1.3 Abbreviations and terms... 5 1.4 References... 5 2 Message Flows... 7 2.1 Mobile Payment... 7 2.2 Mobile Payment Related... 10 3 Protocol... 14 3.1 Transport Layer... 14 3.2 Application Layer... 14 3.3 Secure Sockets Layer... 14 4 doauthorisationrequest... 15 4.1 Message Functionality... 15 4.2 Structure... 15 4.3 Message Elements Description... 16 4.4 Example... 21 5 doauthorisationresponse... 22 5.1 Message Functionality... 22 5.2 Structure... 22 5.3 Message Elements Description... 22 5.4 Example... 24 6 docapturerequest... 25 6.1 Message Functionality... 25 6.2 Structure... 25 6.3 Message Elements Description... 25 6.4 Example... 26 7 docaptureresponse... 28 7.1 Message Functionality... 28 7.2 Structure... 28 7.3 Structure... 28 7.4 Message Elements Description... 28 7.5 Example... 30 8 doreversalrequest... 31 8.1 Message Functionality... 31 8.2 Structure... 31 8.3 Message Elements Description... 31 8.4 Example... 33 9 doreversalresponse... 34 9.1 Message Functionality... 34 9.2 Structure... 34 9.3 Message Elements Description... 34 9.4 Example... 36 10 docreditrequest... 37 10.1 Message Functionality... 37 10.2 Structure... 37 10.3 Message Elements Description... 37 10.4 Example... 38 Nets Technical Guide Copyright Nets Danmark A/S Page 2

11 docreditresponse... 40 11.1 Message Functionality... 40 11.2 Structure... 40 11.3 Message Elements Description... 40 11.4 Example... 41 12 HTTP Status Codes... 43 13 Action Codes... 44 Nets Technical Guide Copyright Nets Danmark A/S Page 3

1 Introduction This document describes a set of eight message definitions defined by Nets Holding A/S a.k.a. the Mobilpenge specification. The message definitions can be used for Mobile Payments Merchant Service Provider (MSP) to Acquirer activities via Internet using a secure protocol. This set includes the following message definitions: doauthorisationrequest This message is sent to request authorization of a mobile payment transaction. doauthorisationresponse This message is sent to return the results of a doauthorisationrequest. docapturerequest This message is sent to advise the acquirer of the outcome of a mobile payment transaction at the Merchant. docaptureresponse This message is sent to reply to a docapturerequest. doreversalrequest This message is to request the cancellation of a transaction. doreversalresponse This message is sent to return the results of a doreversalrequest. docreditrequest This message is sent to advise the acquirer of the outcome of a mobile-payment transaction at the Merchant. docreditresponse This message is sent to reply to a docreditrequest. Any merchant service provider, or merchant, can access Nets' Mobilpenge services, providing they successfully pass certification defined by Nets and signs a merchant agreement with an acquirer who has an agreement with Nets on processing of Mobilpenge transactions. 1.1 Notation convention The message definitions are presented in below format. Index Message Element <XML Tag> Mult. Represent./ Type 4.3.1 + MobileMumber <mobilenumber> [1..1] String 4.3.2 + ProcessingCode <processingcode> [1..1] - 4.3.3 ++ TransTypeCode <transtypecode> [1..1] Code Where: Nets Technical Guide Copyright Nets Danmark A/S Page 4

Column 1 indicates the message element Index number within this document. Column 2 gives the name of the message element. When an element contains sub-elements these are indented to the right and noted with a plus sign (+) per level. Column 3 contains the name of the XML tag assigned to the message element. Column 4 indicates the mandatory or optional status and the number of repetitions allowed in the Mobilpenge specification. When the first digit has the value '1', the message element is mandatory; when the value is '0' the message element is optional. The second digit indicates the number of repetitions allowed, where 'n' is used to indicate no limit is specified. Column 4 may also indicate conditional relationships between components of a message elements, for example, either component 1 or component 2 must be present, but not both (indicated in the column 4 as {Or and Or} ). Column 5 gives the data type of the message element. The Mobilpenge specification use data types defined by the World Wide Web Consortium (W3C) in XML Schema Part 2: Datatypes Second Edition. 1.2 Character set The character set issue centers on the use of the full set characters in the message elements denoting the name and address. These elements allow for the full range of global language requirements (UTF-8). Merchant service providers must be able to support the Latin character set commonly used in international communication, as follows: abcdefghijklmnopqrstuvwxyz ABCDEFGHIJKLMNOPQRSTUVWXYZ 0123456789 /-?:().,' + Cr Lf Space These rules apply to message elements containing text (free text), for example, name and address of the merchant 1.3 Abbreviations and terms Abbreviation / Tem Definition Acquirer Issuer Merchant Merchant Service Provider (MSP) An entity acquiring mobile payment transactions. An entity (financial institution) that offers the Mobilpenge payment scheme to consumers. An entity accepting payment related transactions. An entity which processes payment transactions on behalf of a Merchant. 1.4 References This document is based on and refers to the following documents: Nets Technical Guide Copyright Nets Danmark A/S Page 5

[1] DanID root certificate; https://www.certifikat.dk/export/sites/dk.certifikat.oc/da/download/rodcertifikat.html. [2] IETF RFC 2616 Hypertext Transfer Protocol HTTP/1.1; http://tools.ietf.org/html/rfc2616. [3] ISO 3166-1 Codes for the representation of names of countries and their subdivisions Part 1: Country codes; http://en.wikipedia.org/wiki/iso_3166-1. [4] ISO 3166-2 Codes for the representation of names of countries and their subdivisions Part 2: Country subdivision code; http://en.wikipedia.org/wiki/iso_3166-2. [5] ISO 4217 Codes for the representation of currencies and funds; http://en.wikipedia.org/wiki/iso_4217. [6] ISO 10646 Information technology Universal multiple-octet coded character set (UCS); http://en.wikipedia.org/wiki/iso_10646. [7] ITU-T Recommendation E.164 Assigned Country Codes; http://www.itu.int/itudoc/itu-t/ob-lists/icc/e164_763.html. [8] Ordering a DanID SSL Server certificate; https://danid.dk/export/sites/dk.danid.oc/da/erhverv/bestil_digital_signatur/bestil_ssl_server_kontro l.html. [9] W3C Web Services Addressing (WS-Addressing); http://www.w3.org/submission/ws-addressing. [10] W3C XML Schema Part 2: Datatypes Second Edition; http://www.w3.org/tr/xmlschema-2. Nets Technical Guide Copyright Nets Danmark A/S Page 6

2 Message Flows 2.1 Mobile Payment Please note, that this guide is not intended to describe or specify how the dialogue between a Merchant and a Consumer is formed, nor how the Merchant solution should be built to comply with legislation. This guide is intended to inform technical service providers of how a Mobilpenge payment flow following the order process is supported by the Mobilpenge interface, the structure of messages and responses and requirements of data formats. The guide is regularly revised, and Merchants as well as service providers must comply with changes, when announced by Nets. 2.1.1 Introduction The following mobile payment scenarios show how a consumer can pay for the purchase of goods and services from a merchant, using his/her phone. These scenarios are typically mobile payment ones without being an exhaustive list. They are supported by exchanges of messages. A mobile payment is supported by an authorization process to request the approval of the transaction. An authorization is carried out on-line by requesting an authorization to an acquirer. A completion exchange is required when the acquirer wants to be notified on-line of the outcome of the payment. The financial data of the transaction must be transferred to the acquirer (capture). This can be done through: an authorization exchange; a completion exchange. An implementation cloud use one or a combination of those operations. A completion exchange is also used to reverse a transaction which was not successfully completed (e.g. goods not on stock, cancellation of transaction by the consumer, and timeouts), but where an authorization has been previously given. An authorization is valid five calendar days from the time it was given. It is important that the completion exchange is completed before the authorization expired, since Nets will automatically decline any completion exchanges arriving late. 2.1.1.1 Scenario A1: On-line authorization with on-line capture successfully completed The consumer types correctly structured purchase order for the service or goods on the mobile phone and sends the SMS to the designated number given by the merchant. (1) Merchant service provider (or a merchant's SMS gateway) receives and parses the SMS content. (2) Merchant service provider sends purchase details to mobile phone for accept. (3,4) Receives acceptance request and sends an acceptance reply to the merchant service provider. (1,2) Merchant service provider receives the acceptance SMS and sends an authorization request Nets Technical Guide Copyright Nets Danmark A/S Page 7

(using doauthorisationrequest) to Nets. (5,6) Nets acknowledge the request has been accepted for processing. (7,8) Nets forwards the authorization request to consumer's bank. (9,10) Consumer's bank sends the authorization response to Nets. (11,12) Nets forwards the response (using doauthorisationresponse) to the merchant service provider adding Original Transaction Data. (13,14) Merchant service provider delivered the service or goods and sends it to the consumers mobile number and await the network operators delivery receipt. (3) Consumer receives the goods on his/her phone. (4) Network operator forward delivery information to merchant service provider. (2) Merchant service provider sends a capture request (using docapturerequest) to Nets including the Original Transaction Data received in the authorization response. (15,16) Nets acknowledge the request has been accepted for processing. (7,8) Nets registers the transaction for capture and sends a capture response (using docaptureresponse) to merchant service provider. (17) Merchant service provider logs the sale as completed. (18) SMS request 1 Consumer Consumer 2 3 SMS response 4 Merchant Merchant Service Service Provider Provider (Merchant) (Merchant) 5 15 doauthorisationrequest 8 14 18 docapturerequest Acknowledgment 7 16 6 doauthorisationresponse docaptureresponse 17 9 13 Nets Nets 10 Authorization Request 12 Issuer Issuer Bank Bank 11 Authorization Response ustration 1: On-line authorization with on-line capture message flow Ill 2.1.1.2 Scenario A2: Deferred payment with capture through on-line completion The consumer types correctly structured purchase order for the service or goods on the mobile phone and sends the SMS to the designated number given by the merchant. (1) Nets Technical Guide Copyright Nets Danmark A/S Page 8

Merchant service provider (or a merchant's SMS gateway) receives and parses the SMS content. (2) Merchant service provider sends purchase details to mobile phone for accept. (3,4) Receives acceptance request and sends an acceptance reply to the merchant service provider. (1,2) Merchant service provider receives the acceptance SMS and sends an authorization request (using doauthorisationrequest) to Nets. (5,6) Nets acknowledge the request has been accepted for processing. (7,8) Nets forwards the authorization request to consumer's bank. (9,10) Consumer's bank sends the authorization response to Nets. (11,12) Nets forwards the response (using doauthorisationresponse) to the merchant service provider adding Original Transaction Data. (13,14) Merchant service provider sends purchase acceptance message to the consumers mobile number and await the network operators delivery receipt. (3) Consumer receives the confirmation on his/her phone. (4) Network operator forward delivery information to merchant service provider. (2) After the shipment of the goods, the merchant service provider sends a capture request (using docapturerequest) to Nets including the Original Transaction Data received in the authorization response. (15,16) Nets acknowledge the request has been accepted for processing. (7,8) Nets registers the transaction for capture and sends a capture response (using docaptureresponse) to merchant service provider. (17) Merchant service provider logs the sale as completed. (18) Refer to Illustration 1: On-line authorization with on-line capture message flow. 2.1.1.3 Scenario A3: On-line Mobilpenge enrollment validation The consumer types correctly structured purchase order for the service or goods on the mobile phone and sends the SMS to the designated number given by the merchant. (1) Merchant service provider (or a merchant's SMS gateway) receives and parses the SMS content. (2) Merchant service provider sends request for enrollment status (using doauthorisationrequest) to the Mobilpenge provider (Nets). The request is expected to contain mobile number and a transaction amount of zero. (3,4) Nets acknowledge the request has been accepted for processing. (5,6) Nets sends an authorization response (using doauthorisationresponse) with enrollment status to merchant service provider. (7,8) Nets Technical Guide Copyright Nets Danmark A/S Page 9

2 SMS request 1 Consumer Consumer Merchant Merchant Service Service Provider Provider (Merchant) (Merchant) 3 4 doauthorisationrequest Nets Nets 6 8 Acknowledgment 5 7 doauthorisationresponse ustration 2: On-line Mobilpenge enrollment message flow Ill 2.2 Mobile Payment Related 2.2.1 Cancellation Cancellation is a service which allows a merchant to cancel a successfully completed authorization or capture transaction. A cancellation is sometimes called a manual reversal. A cancellation occurs in the following situations: If a merchant following a successful authorization is unable to dispatch the order on time, or the consumer cancel the order before services or goods have delivered, an authorization reversal (using doreversalrequest) should be sent. The amount reversed must be equivalent to the amount authorized. When involving mobile payments in particular, it is critical for the consumer's disposal of his account that the authorization is reversed. If the authorization is not reversed it can affect the consumer s possibilities of placing a replacement order. If a consumer cancel an order after services or goods have been delivered, a credit request (using docreditrequest) should be sent. 2.2.1.1 Scenario B1: Cancellation of an on-line authorization not yet captured Merchant service provider (or a merchant) sends a cancel request (using doreversalrequest) to Nets including the Original Transaction Data received in the authorization response. (1,2) Nets acknowledge the request has been accepted for processing. (3,4) Nets forwards the reversal request to consumer's bank in real time. (5) The consumer's bank carry out the reversal request in real time. (6) The consumer's bank generate and forward a reversal response to Nets in real time. (7,8) Nets forward the reversal response (using doreversalresponse) to merchant service provider. (9,10) Nets Technical Guide Copyright Nets Danmark A/S Page 10

Merchant Merchant Service Service Provider Provider (Merchant) (Merchant) 1 doreversalrequest 4 2 10 Acknowledgment 3 doreversalresponse 5 9 Nets Nets 6 Reversal Advice Request 8 Issuer Issuer Bank Bank 7 Reversal Advice Response ustration 3: Cancellation of an on-line authorization not yet captured message flow Ill 2.2.1.2 Scenario B2: Successful cancellation of an on-line captured transaction Merchant service provider (or a merchant) sends a refund request (using docreditrequest) to Nets including the Original Transaction Data received in the capture response. (1,2) Nets acknowledge the request has been accepted for processing. (3,4) Nets registers the transaction for credit and acknowledges the request (using docreditresponse) to merchants service provider. (5,6) Merchant Merchant Service Service Provider Provider (Merchant) (Merchant) 4 1 docreditlrequest 2 5 Acknowledgment 3 4 docreditresponse ustration 4: Cancellation of an on-line captured transaction message flow Nets Nets Ill 2.2.2 Rejection A rejection is sent by the Nets to the merchant service provider to indicate that the received message (request) could not be processed e.g. a malformed message, unable to process the message, amount limit exceeded, consumer not enrolled in Mobilpenge, and mobile phone number is blocked. 2.2.2.1 Scenario C1: Rejection of an on-line authorization message The consumer types correctly structured purchase order for the service or goods on the mobile phone and sends the SMS to the designated number given by the merchant. (1) Merchant service provider (or a merchant's SMS gateway) receives and parses the SMS content. (2) Nets Technical Guide Copyright Nets Danmark A/S Page 11

Merchant service provider sends purchase details to mobile phone for accept. (3,4) Receives acceptance request and sends an acceptance reply to the merchant service provider. (1,2) Merchant service provider receives the acceptance SMS and sends an authorization request (using doauthorisationrequest) to Nets. (5,6) Nets acknowledge the request has been accepted for processing. (7,8) Nets forwards the authorization request to consumer's bank. (9,10) Consumer's bank sends the authorization response to Nets. (11,12) Nets forwards the declined response (using doauthorisationresponse) to the merchant service provider adding Original Transaction Data. (13,14) Merchant service provider sends a purchase decline message to the consumers mobile number and await the network operators delivery receipt. (3) Consumer receives the rejection on his/her phone. (4) Network operator forward delivery information to merchant service provider. (2) SMS request 1 Consumer Consumer 2 3 SMS response 4 Merchant Merchant Service Service Provider Provider (Merchant) (Merchant) 5 doauthorisationrequest 8 6 14 Acknowledgment 7 doauthorisationresponse 13 Nets Nets 9 10 Authorization Request 12 Issuer Issuer Bank Bank 11 Authorization Response ustration 5: On-line authorization message flow Ill 2.2.2.2 Scenario C2: On-line authorization with no response The consumer types correctly structured purchase order for the service or goods on the mobile phone and sends the SMS to the designated number given by the merchant. (1) Merchant service provider (or a merchant's SMS gateway) receives and parses the SMS content. (2) Nets Technical Guide Copyright Nets Danmark A/S Page 12

Merchant service provider sends purchase details to mobile phone for accept. (3,4) Receives acceptance request and sends an acceptance reply to the merchant service provider. (1,2) Merchant service provider receives the acceptance SMS and sends an authorization request (using doauthorisationrequest) to Nets. (5,6) Nets acknowledge the request has been accepted for processing. (7,8) If the merchant service provider does not receive a response within 60 seconds, it is recommended that merchant service provider continue repeating the request a reasonable number of times e.g. five times. Where the repeating message must be an exact copy of the original message. (5,6) Nets acknowledge the request has been accepted for processing. (7,8) Nets forwards the authorization request to consumer's bank. (9,10) Consumer's bank sends the authorization response to Nets. (11,12) Nets forwards the response (using doauthorisationresponse) to the merchant service provider adding Original Transaction Data. (13,14) If merchant service provider receives more responses to the same transaction, the merchant service provider must be able to discard all responses, but the first. Merchant service provider sends purchase acceptance message to the consumers mobile number and await the network operators delivery receipt. (3) Consumer receives the confirmation on his/her phone. (4) Network operator forward delivery information to merchant service provider. (2) Refer to Illustration 5: On-line authorization message flow. Nets Technical Guide Copyright Nets Danmark A/S Page 13

3 Protocol 3.1 Transport Layer The transport layer is Transmission Control Protocol/Internet Protocol (TCP/IP) using the Internet. Merchant service providers must ensure a sufficient bandwidth for the Mobilpenge services to run, in real-time, with acceptable response time. To use Mobilpenge services, merchant service providers must register in Nets' firewall with two public TCP/IP addresses; one from which Mobilpenge service requests will originate and another to which Mobilpenge service responses shall be sent. 3.2 Application Layer The application layer is Simple Object Access Protocol (SOAP); a protocol specification for exchanging structured information in the implementation of Web Services. Mobilpenge relies on Extensible Markup Language (XML) for its message format and Hypertext Transfer Protocol Secure (HTTPS) for message negotiation and transmission. The Mobilpenge standard is based on asynchronous Web Services. Hence, the merchant service provider will receive an HTTP 204 acknowledgment upon acceptance of a service request and can continue with other processing rather than wait for the response. Later, when the merchant service provider does receive the response it resumes whatever processing initiated the service request. To support asynchronous operations, the merchant service provider must define a Web Services ReplyTo address specifying where the response should be sent and a Web Services MessageID to correlate the service request and service response. Please note, that the ReplyTo address must be specified using an IP address and not a DNS name. 3.3 Secure Sockets Layer The Secure Sockets Layer (SSL) is used in the HTTPS protocol to create a secure channel over an insecure network; like the Internet. This ensures reasonable protection from eavesdroppers and man-in-the-middle attacks, provided that adequate cipher suites are used and that the server certificate is verified and trusted. To use Mobilpenge services, merchant service providers must obtain a DanID SSL Server certificate as Nets enforce client certificate authentication. Furthermore, merchant service providers must use a SSL toolkit supporting below cipher suites, which are the only ones accepted by Nets: SSL_RSA_WITH_AES_256_CBC_SHA SSL_RSA_WITH_AES_128_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_RC4_128_SHA Nets Technical Guide Copyright Nets Danmark A/S Page 14

4 doauthorisationrequest 4.1 Message Functionality 4.1.1 Scope The doauthorisationrequest message is sent by the merchant service provider to the acquirer when an on-line authorization is required for a mobile payment transaction. 4.1.2 Usage The doauthorisationrequest message is used to determine if the consumer is enrolled in Mobilpenge, the consumer fulfills age requirements of the transaction (optional check), the purchase is within the daily amount limit, funds are available, get an approval but do not post to account for reconciliation, and awaits a docapturerequest message before posting to account. A doauthorisationrequest message with an amount of zero can be used to verify the consumer is enrolled in Mobilpenge. 4.1.3 Outline The doauthorisationrequest message is composed of one block of elements contains elements required by the acquirer to forward to the party allowed to deliver or decline the authorization. These include mobile phone number, merchant, payment context, transaction, and transaction details. 4.2 Structure Index Message Element <XML Tag> Mult. Represent./ Type Message root <doauthorisationrequest> [1..1] - Index Message Element <XML Tag> Mult. Represent./ Type 4.3.1 + MobileMumber <mobilenumber> [1..1] String 4.3.2 + ProcessingCode <processingcode> [1..1] - 4.3.3 ++ TransTypeCode <transtypecode> [1..1] Code 4.3.4 ++ ProcessingDebit <processingdebit> [1..1] Code 4.3.5 ++ ProcessingCredit <processingcredit> [1..1] Code 4.3.6 + AmountTransaction <amounttransaction> [1..1] Integer 4.3.7 + DateTimeLocalTransaction <datetimelocaltransaction> [1..1] DateTime 4.3.8 + PosDataCode <posdatacode> [1..1] Code 4.3.9 + FunctionCode <functioncode> [1..1] Code Nets Technical Guide Copyright Nets Danmark A/S Page 15

4.3.10 + MessageReasonCode <messagereasoncode> [1..1] Code 4.3.11 + MobileAcceptorBusinessCode <mobileacceptorbusinesscode> [1..1] Code 4.3.12 + AcquirerReferenceData <acquirerreferencedata> [1..1] String 4.3.13 + MobileAcceptorTerminalId <mobileacceptorterminalid> [1..1] String 4.3.14 + MobileAcceptorIdentificationCode <mobileacceptoridentificationcode > [1..1] String 4.3.15 + MobileAcceptorNameLocation <mobileacceptornamelocation> [1..1] - 4.3.16 ++ Name <name> [1..1] String 4.3.17 ++ Address <address> [1..1] String 4.3.18 ++ ZipCode <zipcode> [1..1] String 4.3.19 ++ City <city> [1..1] String 4.3.20 ++ RegionCode <regioncode> [1..1] Code 4.3.21 ++ CountryCode <countrycode> [1..1] Code 4.3.22 + MinimumAge <minimumage> [0..1] String 4.3.23 + CurrencyCodeTransaction <currencycodetransaction> [1..1] Code 4.3 Message Elements Description The following section identifies the elements of the doauthorisationrequest message definition. 4.3.1 MobileMumber <mobilenumber> Definition: The phone number of the consumer who is requesting an item or service. The phone number must consist of country code, national destination code (if applicable), and subscriber number as defined in. For example, the Danish phone number '12345678' must be given as '4512345678'. Data Type: Min8Max20NumericText Format: [0-9]{8,20} 4.3.2 ProcessingCode <processingcode> Definition: The processing code describes the transaction and the account type affected. Type: This message item is composed of the following processingcode elements: Index Message Element <XML Tag> Mult. Represent./ Type Nets Technical Guide Copyright Nets Danmark A/S Page 16

4.3.3 TransTypeCode <transtypecode> [1..1] Code 4.3.4 ProcessingDebit <processingdebit> [1..1] Code 4.3.5 ProcessingCredit <processingcredit> [1..1] Code 4.3.3 TransTypeCode <transtypecode> Definition: Describe the transaction. The following value must be used (reserved for future enhancement): Code Definition 00 Goods and services. 4.3.4 ProcessingDebit <processingdebit> Definition: Describe the account type affected for debits and inquiries. The following value must be used (reserved for future enhancement): Code Definition 00 Default account. 4.3.5 ProcessingCredit <processingcredit> Definition: Describe the account type affected for credits. The following value must be used (reserved for future enhancement): Code Definition 00 Default account. 4.3.6 AmountTransaction <amounttransaction> Definition: Transaction amount in the smallest unit of the currency e.g. Øre for Danish currency. Data Type: Min1Max12NumericText Format: [0-9]{1,12} Nets Technical Guide Copyright Nets Danmark A/S Page 17

4.3.7 DateTimeLocalTransaction <datetimelocaltransaction> Definition: The time for generation of the transaction (local time at which the transaction was created). Data Type: datetime Format: YYMMDDhhmmss 4.3.8 PosDataCode <posdatacode> Definition: The point of sale data code explains the terminal operating environment, the actual acquiring situation, and the output possibilities. Each byte represents a 'field'. The following value must be used (reserved for future enhancement): Code Definition M00500N000 11 Mobilpenge 4.3.9 FunctionCode <functioncode> Definition: Reason for the transaction. One of the following values must be used: Code Definition 100 Original authorization, amount accurate. 101 Original authorization, amount estimated. 4.3.10 MessageReasonCode <messagereasoncode> Definition: Transaction reason code. Reason for sending this message. The following value must be used (reserved for future enhancement): Code Definition 0000 Normal transaction. Nets Technical Guide Copyright Nets Danmark A/S Page 18

4.3.11 MobileAcceptorBusinessCode <mobileacceptorbusinesscode> Definition: Merchant category code. Code identifying the merchant business. Merchant business code must be as specified in the merchant agreement, for example: Code Definition 4814 Telecommunication service. 4816 Computer network/information service. 4.3.12 AcquirerReferenceData <acquirerreferencedata> Definition: Transaction reference/order number generated by merchant and communicated to Mobilpenge account holders on the receipt. For Mobilpenge account holders: This number enables the Mobilpenge account holders to identify the payment transaction. The number is carried through to Mobilpenge account holders on receipts and account statements by most issuers. For merchants: This number may be used on the settlement advices from the appropriate acquirer (e.g. Nets) and may be used by the merchant to reconcile his revenue. Data Type: Max23Text Format: maxlength: 23, minlength: 1 4.3.13 MobileAcceptorTerminalId <mobileacceptorterminalid> Definition: Point of interaction identification. Terminal number (assigned by Merchant). Data Type: Max8Text Format: maxlength: 8, minlength: 1 4.3.14 MobileAcceptorIdentificationCode <mobileacceptoridentificationcode> Definition: Merchant identification (assigned by the acquirer). Data Type: Max15Text Format: maxlength: 15, minlength: 1 Nets Technical Guide Copyright Nets Danmark A/S Page 19

4.3.15 MobileAcceptorNameLocation <mobileacceptornamelocation> Definition: Merchant name/address as registered by the acquirer. Type: This message item is composed of the following mobileacceptornamelocation element(s): Index Message Element <XML Tag> Mult. Represent./ Type 4.3.16 Name <name> [1..1] String 4.3.17 Address <address> [1..1] String 4.3.18 ZipCode <zipcode> [1..1] String 4.3.19 City <city> [1..1] String 4.3.20 RegionCode <regioncode> [1..1] Code 4.3.21 CountryCode <countrycode> [1..1] Code 4.3.16 Name <name> Definition: Name of the merchant as appearing on the receipt. Data Type: Max35Text Format: maxlength: 35, minlength: 1 4.3.17 Address <address> Definition: Street name of the merchant where the transaction took place. Data Type: Max70Text Format: maxlength: 70, minlength: 1 4.3.18 ZipCode <zipcode> Definition: Zip code of the merchant where the transaction took place. Data Type: Max10Text Format: maxlength: 10, minlength: 1 4.3.19 City <city> Definition: City of the merchant where the transaction took place. Nets Technical Guide Copyright Nets Danmark A/S Page 20

Data Type: Max78Text Format: maxlength: 78, minlength: 1 4.3.20 RegionCode <regioncode> Definition: Region of the merchant where the transaction took place. Use one of the two-letter subdivisions (e.g. provinces or states) codes defined in ISO 3166-2. 4.3.21 CountryCode <countrycode> Definition: Country of the merchant where the transaction took place. Use one of the three-letter country codes defined in ISO 3166-1. 4.3.22 MinimumAge <minimumage> Presence: [0..1] Definition: Age requirement for the transaction. Used to ensure that minors are blocked from age restricted content and services (reserved for future enhancement). Data Type: Min1Max3NumericText Format: [0-9]{1,3} 4.3.23 CurrencyCodeTransaction <currencycodetransaction> Definition: Currency associated with the transaction. Use one of the three-digit currency codes defined in ISO 4217. 4.4 Example <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mob="http://www.nets.eu/mobileacquirermobilpenge/" xmlns:mob1="http://www.nets.eu/mobiletypes"> <soapenv:header xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:action>http://www.nets.eu/mobileacquirermobilpenge/doauthorisation </wsa:action><wsa:replyto><wsa:address>https://129.35.212.242:443/mockmobileacquirermobilpengesoap</wsa:address></wsa:re plyto><wsa:messageid>uuid:4137d18a-3116-466b-99c0-2b6bdf148812</wsa:messageid><wsa:to>https://194.239.133.140:453/mobilpenge/paymentinterface</wsa:to></soapenv:header> <soapenv:body> <mob:doauthorisationrequest> <mobilenumber>4596969690</mobilenumber> <processingcode> <mob1:transtypecode>00</mob1:transtypecode> <mob1:processingdebit>00</mob1:processingdebit> <mob1:processingcredit>00</mob1:processingcredit> </processingcode> Nets Technical Guide Copyright Nets Danmark A/S Page 21

<amounttransaction>107</amounttransaction> <datetimelocaltransaction>110705093200</datetimelocaltransaction> <posdatacode>m00500n00011</posdatacode> <functioncode>100</functioncode> <messagereasoncode>0000</messagereasoncode> <mobileacceptorbusinesscode>4816</mobileacceptorbusinesscode> <acquirerreferencedata>21138674</acquirerreferencedata> <mobileacceptorterminalid>t2837210</mobileacceptorterminalid> <mobileacceptoridentificationcode>0017205</mobileacceptoridentificationcode> <mobileacceptornamelocation> <mob1:name>smith Radio</mob1:name> <mob1:address>boulevard 4</mob1:address> <mob1:zipcode>3266</mob1:zipcode> <mob1:city>broby</mob1:city> <mob1:regioncode>dk</mob1:regioncode> <mob1:countrycode>dnk</mob1:countrycode> </mobileacceptornamelocation> <currencycodetransaction>208</currencycodetransaction> </mob:doauthorisationrequest> </soapenv:body> </soapenv:envelope> Nets Technical Guide Copyright Nets Danmark A/S Page 22

5 doauthorisationresponse 5.1 Message Functionality 5.1.1 Scope The doauthorisationresponse message is sent by the acquirer to inform the merchant service provider of the outcome of the authorization process. 5.1.2 Usage The doauthorisationresponse message is used to indicate one of the possible outcomes of an authorization process: a successful authorization; a decline from the acquirer for financial reasons; a decline from the acquirer for technical reasons (for instance, a timeout). 5.1.3 Outline The doauthorisationresponse message is composed of one block of elements contains elements to validate the response to the doauthorisationrequest message and the result of the authorization process. These include merchant identification, transaction, transaction response, and transaction verification result. 5.2 Structure Index Message Element <XML Tag> Mult. Represent./ Type Message root <doauthorisationresponse> [1..1] - Index Message Element <XML Tag> Mult. Represent./ Type 5.3.1 + AmountTransaction <amounttransaction> [1..1] Integer 5.3.2 + DateTimeLocalTransaction <datetimelocaltransaction> [1..1] DateTime 5.3.3 + AcquirerReferenceData <acquirerreferencedata> [1..1] String 5.3.4 + ApprovalCode <approvalcode> [0..1] String 5.3.5 + ActionCode <actioncode> [1..1] Code 5.3.6 + CurrencyCodeTransaction <currencycodetransaction> [1..1] Code 5.3.7 + OriginalTransactionData <originaltransactiondata> [0..1] String 5.3 Message Elements Description The following section identifies the elements of the doauthorisationresponse message Nets Technical Guide Copyright Nets Danmark A/S Page 23

definition. 5.3.1 AmountTransaction <amounttransaction> Definition: Transaction amount in the smallest unit of the currency. Data Type: Min1Max12NumericText Format: [0-9]{1,12} 5.3.2 DateTimeLocalTransaction <datetimelocaltransaction> Definition: The time for generation of the transaction (local time at which the transaction is to be created). Data Type: datetime Format: YYMMDDhhmmss 5.3.3 AcquirerReferenceData <acquirerreferencedata> Definition: Transaction reference/order number generated by merchant and communicated to Mobilpenge account holders on the receipt. Data Type: Max23Text Format: maxlength: 23, minlength: 1 5.3.4 ApprovalCode <approvalcode> Presence: [0..1] Definition: Reference code to approved authorization generated by the Mobilpenge issuer, if the transaction is authorized. Data Type: Min6Max6NumericText Format: [0-9]{6,6} 5.3.5 ActionCode <actioncode> Definition: Code indicating the status of the transaction and the action that must be taken by the merchant. One of the action codes defined in section will be used. 5.3.6 CurrencyCodeTransaction <currencycodetransaction> Nets Technical Guide Copyright Nets Danmark A/S Page 24

Definition: Currency associated with the transaction. Use one of the three-digit currency codes defined in ISO 4217. 5.3.7 OriginalTransactionData <originaltransactiondata> Presence: [0..1] Definition: Used to store data required by the terminal operating environment to process reversal and financial advice messages following an authorization; if the transaction is authorized. Data Type: Max999Text Format: maxlength: 999, minlength: 1 5.4 Example <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mob="http://www.nets.eu/mobileacquirermobilpenge/" xmlns:mob1="http://www.nets.eu/mobiletypes"> <soapenv:header xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:to>https://129.35.212.242:443/mockmobileacquirermobilpengesoap</ws a:to><wsa:messageid>5b433e20-80a9-4e5b-8f39-3ef167d4725b</wsa:messageid><wsa:relatesto>uuid:4137d18a-3116-466b-99c0-2b6bdf148812</wsa:relatesto><wsa:action>http://www.nets.eu/mobileacquirermobilpenge/doauthorisation</wsa:action></soapen v:header> <SOAP-ENV:Body> <doauthorisationresponse xmlns="http://www.nets.eu/mobileacquirermobilpenge/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"> <amounttransaction xmlns="">107</amounttransaction> <datetimelocaltransaction xmlns="">110705093200</datetimelocaltransaction> <acquirerreferencedata xmlns="">21138674</acquirerreferencedata> <approvalcode xmlns="">093243</approvalcode> <actioncode xmlns="">000</actioncode> <currencycodetransaction xmlns="">208</currencycodetransaction> <originaltransactiondata xsi:nil="false" xmlns="">lmnvbs9uagf3dgvtr0ndqs5jcmwwkaydvr0lbcewhwyikwybbquhawegccsgaqufbwmcbglghkgbhvhcbaewcgyikwybbquhaqeezjbkmcigccs GAQUFBzABhhZodHRwOi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0ZS5jb20vcmVwb3NpdG9yeS9UaGF3dGVfU0dDX0N BLmNydDANBgkqhkiG9w0BAQUFAAOBgQCfQ89bxFApsb/isJr/aiEdLRLDLE5a+RLizrmCUi3nHX4adpaQedEkUjh5u2ONgJd8IyAPkU0Wueru9G2Jysa9zCR o1knbzipyvzwy4oa8ys+wai0or1a04se6z5nrup8pjca2nhuzunc+my+f6h/neqynv4sgqhqaibaxweehxw==</originaltransactiondata> </doauthorisationresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Nets Technical Guide Copyright Nets Danmark A/S Page 25

6 docapturerequest 6.1 Message Functionality 6.1.1 Scope The docapturerequest message is sent by a merchant service provider to notify an acquirer about the completion and final outcome of a mobile payment transaction. 6.1.2 Usage The docapturerequest message is used to inform the acquirer about the successful end of a transaction. The message includes information required for transferring to the acquirer all data needed to perform the financial settlement of the transaction (capture). 6.1.3 Outline The docapturerequest message is composed of one block of elements contains elements required by the acquirer to perform the financial settlement of the transaction (capture). These include transaction details and data from the previous transactions. 6.2 Structure Index Message Element <XML Tag> Mult. Represent./ Type Message root <docapturerequest> [1..1] - Index Message Element <XML Tag> Mult. Represent./ Type 6.3.1 + AmountTransaction <amounttransaction> [1..1] Integer 6.3.2 + DateTimeLocalTransaction <datetimelocaltransaction> [1..1] DateTime 6.3.3 + FunctionCode <functioncode> [1..1] Code 6.3.4 + AcquirerReferenceData <acquirerreferencedata> [1..1] String 6.3.5 + CurrencyCodeTransaction <currencycodetransaction> [1..1] Code 6.3.6 + OriginalTransactionData <originaltransactiondata> [1..1] String 6.3 Message Elements Description The following section identifies the elements of the docapturerequest message definition. 6.3.1 AmountTransaction <amounttransaction> Definition: Transaction amount in the smallest unit of the currency. Data Type: Min1Max12NumericText Nets Technical Guide Copyright Nets Danmark A/S Page 26

Format: [0-9]{1,12} 6.3.2 DateTimeLocalTransaction <datetimelocaltransaction> Definition: The time for generation of the transaction (local time at which the transaction is to be created). Data Type: datetime Format: YYMMDDhhmmss 6.3.3 FunctionCode <functioncode> Definition: Reason for the transaction. One of the following values must be used: Code Definition 201 Previously approved. authorization, amount the same. 202 Previously approved authorization, amount differs. 6.3.4 AcquirerReferenceData <acquirerreferencedata> Definition: Transaction reference/order number generated by merchant and communicated to Mobilpenge account holders on the receipt. Data Type: Max23Text Format: maxlength: 23, minlength: 1 6.3.5 CurrencyCodeTransaction <currencycodetransaction> Definition: Currency associated with the transaction. Use one of the three-digit currency codes defined in ISO 4217. 6.3.6 OriginalTransactionData <originaltransactiondata> Definition: Used to supply data required by the terminal operating environment to process the financial advice messages. Echo from the previous transaction response. Data Type: Max999Text Format: maxlength: 999, minlength: 1 Nets Technical Guide Copyright Nets Danmark A/S Page 27

6.4 Example <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mob="http://www.nets.eu/mobileacquirermobilpenge/"> <soapenv:header xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:action>http://www.nets.eu/mobileacquirermobilpenge/docapture</wsa: Action><wsa:ReplyTo><wsa:Address>https://129.35.212.242:443/mockMobileAcquirerMobilpengeSOAP</wsa:Address></wsa:ReplyTo> <wsa:messageid>uuid:2cb377ca-ee91-45e3-9620- a8ef37c5f0b6</wsa:messageid><wsa:to>https://194.239.133.140:453/mobilpenge/paymentinterface</wsa:to></soapenv:header> <soapenv:body> <mob:docapturerequest> <amounttransaction>107</amounttransaction> <datetimelocaltransaction>110705094500</datetimelocaltransaction> <functioncode>201</functioncode> <acquirerreferencedata>21138674</acquirerreferencedata> <currencycodetransaction>208</currencycodetransaction> <originaltransactiondata>lmnvbs9uagf3dgvtr0ndqs5jcmwwkaydvr0lbcewhwyikwybbquhawegccsgaqufbwmcbglghkgbhvhcbaewcgyikwybbqu HAQEEZjBkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0ZS5jb20vcmVwb3NpdG9ye S9 UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUFAAOBgQCfQ89bxFApsb/isJr/aiEdLRLDLE5a+RLizrmCUi3nHX4adpaQedEkUjh5u2ONgJd8IyAPkU0 Wueru9G2Jysa9zCRo1kNbzipYvzwY4OA8Ys+WAi0oR1A04Se6z5nRUP8pJcA2NhUzUnC+MY+f6H/nEQyNv4SgQhqAibAxWEEHXw== </originaltransactiondata> </mob:docapturerequest> </soapenv:body> </soapenv:envelope> Nets Technical Guide Copyright Nets Danmark A/S Page 28

7 docaptureresponse 7.1 Message Functionality 7.1.1 Scope The docaptureresponse message is sent by the acquirer to acknowledge the proper receipt of a docapturerequest. 7.1.2 Usage The docaptureresponse message is used to acknowledge the data capture process performed by the acquirer based on the data required to carry out the financial clearing and settlement of the transaction. 7.1.3 Outline The docaptureresponse message is composed of one block of elements contains elements to validate the response to the docapturerequest message and the result of the capture process. These include merchant identification, transaction, transaction response, and transaction verification result. 7.2 Structure Index Message Element <XML Tag> Mult. Represent./ Type Message root <docaptureresponse> [1..1] - Index Message Element <XML Tag> Mult. Represent./ Type 7.4.1 + AmountTransaction <amounttransaction> [1..1] Integer 7.4.2 + DateTimeLocalTransaction <datetimelocaltransaction> [1..1] DateTime 7.4.3 + AcquirerReferenceData <acquirerreferencedata> [1..1] String 7.4.4 + ActionCode <actioncode> [1..1] Code 7.4.5 + CurrencyCodeTransaction <currencycodetransaction> [1..1] Code 7.4.6 + OriginalTransactionData <originaltransactiondata> [0..1] String 7.3 Structure 7.4 Message Elements Description The following section identifies the elements of the docaptureresponse message definition. Nets Technical Guide Copyright Nets Danmark A/S Page 29

7.4.1 AmountTransaction <amounttransaction> Definition: Transaction amount in the smallest unit of the currency. Data Type: Min1Max12NumericText Format: [0-9]{1,12} 7.4.2 DateTimeLocalTransaction <datetimelocaltransaction> Definition: The time for generation of the transaction (local time at which the transaction is to be created). Data Type: datetime Format: YYMMDDhhmmss 7.4.3 AcquirerReferenceData <acquirerreferencedata> Definition: Transaction reference/order number generated by merchant and communicated to Mobilpenge account holders on the receipt. Data Type: Max23Text Format: maxlength: 23, minlength: 1 7.4.4 ActionCode <actioncode> Definition: Code indicating the status of the transaction and the action that must be taken by the merchant. One of the action codes defined in section will be used. 7.4.5 CurrencyCodeTransaction <currencycodetransaction> Definition: Currency associated with the transaction. Use one of the three-digit currency codes defined in ISO 4217. 7.4.6 OriginalTransactionData <originaltransactiondata> Presence: [0..1] Definition: Used to store data required by the terminal operating environment to process reversal and financial advice messages following this transaction; if the transaction is successful. Data Type: Max999Text Nets Technical Guide Copyright Nets Danmark A/S Page 30

Format: maxlength: 999, minlength: 1 7.5 Example <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mob="http://www.nets.eu/mobileacquirermobilpenge/"> <soapenv:header xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:to>https://129.35.212.242:443/mockmobileacquirermobilpengesoap</ws a:to><wsa:messageid>3c8491ad-9216-4abd-b767-f91d582826e3</wsa:messageid><wsa:relatesto>uuid:2cb377ca-ee91-45e3-9620- a8ef37c5f0b6</wsa:relatesto><wsa:action>http://www.nets.eu/mobileacquirermobilpenge/docapture</wsa:action></soapenv:head er> <SOAP-ENV:Body> <docaptureresponse xmlns="http://www.nets.eu/mobileacquirermobilpenge/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"> <amounttransaction xmlns="">107</amounttransaction> <datetimelocaltransaction xmlns="">110705094500</datetimelocaltransaction> <acquirerreferencedata xmlns="">21138674</acquirerreferencedata> <actioncode xmlns="">000</actioncode> <currencycodetransaction xmlns="">208</currencycodetransaction> <originaltransactiondata xsi:nil="false" xmlns="">miiditccaoqgawibagiql9+89q6rum0pmqpfqdq+mjanbgkqhkig9w0baqufadbmmqswcqydvqqgewjaqtelmcmga1uechmcvghhd3rlienvbnn 1bHRpbmcgKFB0eSkgTHRkLjEWMBQGA1UEAxMNVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0xMTEyMTgyMzU5NTlaMGgxCzAJBgDVQQIEwpDYWxp Zm9ybmlhu2ONgJd8IyAPkU0Wueru9G2Jysa9zCRo1kNbzipYvzwY4OA8Y0oR1A04Se6cA2NhUzUnC+MY+f6H/nEQyNv4SgQhqAi==</originalTransacti ondata> </docaptureresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Nets Technical Guide Copyright Nets Danmark A/S Page 31

8 doreversalrequest 8.1 Message Functionality 8.1.1 Scope The doreversalrequest message is sent by the merchant service provider to notify the acquirer that the order has been canceled by the consumer or goods cannot be delivered by the merchant. 8.1.2 Usage The doreversalrequest message is used to reverse the action of a previous authorization. The amount reversed must be equivalent to the amount authorized. It is critical for the consumer's disposal of his/her account that the authorization is reversed to release the amount reserved on his/her account. 8.1.3 Outline The doreversalrequest message is composed of one block of elements contains elements required by the acquirer to reverse a previous authorization. These include transaction details and data from the previous transactions. 8.2 Structure Index Message Element <XML Tag> Mult. Represent./ Type Message root <doreversalrequest> [1..1] - Index Message Element <XML Tag> Mult. Represent./ Type 8.3.1 + AmountTransaction <amounttransaction> [1..1] Integer 8.3.2 + DateTimeLocalTransaction <datetimelocaltransaction> [1..1] DateTime 8.3.3 + FunctionCode <functioncode> [1..1] Code 8.3.4 + MessageReasonCode <messagereasoncode> [1..1] Code 8.3.5 + AcquirerReferenceData <acquirerreferencedata> [1..1] String 8.3.6 + CurrencyCodeTransaction <currencycodetransaction> [1..1] Code 8.3.7 + OriginalTransactionData <originaltransactiondata> [1..1] String 8.3 Message Elements Description The following section identifies the elements of the doreversalrequest message definition. 8.3.1 AmountTransaction <amounttransaction> Nets Technical Guide Copyright Nets Danmark A/S Page 32

Definition: Transaction amount in the smallest unit of the currency. Data Type: Min1Max12NumericText Format: [0-9]{1,12} 8.3.2 DateTimeLocalTransaction <datetimelocaltransaction> Definition: The time for generation of the transaction (local time at which the transaction is to be created). Data Type: datetime Format: YYMMDDhhmmss 8.3.3 FunctionCode <functioncode> Definition: Reason for the transaction. One of the following values must be used (reserved for future enhancement): Code Definition 400 Full reversal. 8.3.4 MessageReasonCode <messagereasoncode> Definition: Information to acquirer the reason for the message being sent. One of the following values must be used: Code Definition 4000 Customer cancellation. 4001 Unspecified, no action taken. 4002 Suspected malfunction. 4004 Completed partially. 8.3.5 AcquirerReferenceData <acquirerreferencedata> Definition: Transaction reference/order number generated by merchant and communicated to Mobilpenge account holders on the receipt. Data Type: Max23Text Format: maxlength: 23, minlength: 1 Nets Technical Guide Copyright Nets Danmark A/S Page 33

8.3.6 CurrencyCodeTransaction <currencycodetransaction> Definition: Currency associated with the transaction. Use one of the three-digit currency codes defined in ISO 4217. 8.3.7 OriginalTransactionData <originaltransactiondata> Definition: Used to supply data required by the terminal operating environment to process the financial advice messages. Echo from the previous transaction response. Data Type: Max999Text Format: maxlength: 999, minlength: 1 8.4 Example <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mob="http://www.nets.eu/mobileacquirermobilpenge/"> <soapenv:header xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:action>http://www.nets.eu/mobileacquirermobilpenge/doreversal</wsa :Action><wsa:ReplyTo><wsa:Address>https://129.35.212.242:443/mockMobileAcquirerMobilpengeSOAP</wsa:Address></wsa:ReplyTo ><wsa:messageid>uuid:12636d34-4279-456a-a433-7e1f76cdb761</wsa:messageid><wsa:to>https://194.239.133.140:453/mobilpenge/paymentinterface</wsa:to></soapenv:header> <soapenv:body> <mob:doreversalrequest> <amounttransaction>107</amounttransaction> <datetimelocaltransaction>110705094000</datetimelocaltransaction> <functioncode>400</functioncode> <messagereasoncode>4000</messagereasoncode> <acquirerreferencedata>21138674</acquirerreferencedata> <currencycodetransaction>208</currencycodetransaction> <originaltransactiondata>lmnvbs9uagf3dgvtr0ndqs5jcmwwkaydvr0lbcewhwyikwybbquhawegccsgaqufbwmcbglghkgbhvhcbaewcgyikwybbqu HAQEEZjBkMCIGCCsGAQUFBzABhhZodHRwOi8vb2NzcC50aGF3dGUuY29tMD4GCCsGAQUFBzAChjJodHRwOi8vd3d3LnRoYXd0ZS5jb20vcmVwb3NpdG9yeS9 UaGF3dGVfU0dDX0NBLmNydDANBgkqhkiG9w0BAQUFAAOBgQCfQ89bxFApsb/isJr/aiEdLRLDLE5a+RLizrmCUi3nHX4adpaQedEkUjh5u2ONgJd8IyAPkU0 Wueru9G2Jysa9zCRo1kNbzipYvzwY4OA8Ys+WAi0oR1A04Se6z5nRUP8pJcA2NhUzUnC+MY+f6H/nEQyNv4SgQhqAibAxWEEHXw==</originalTransacti ondata> </mob:doreversalrequest> </soapenv:body> </soapenv:envelope> Nets Technical Guide Copyright Nets Danmark A/S Page 34

9 doreversalresponse 9.1 Message Functionality 9.1.1 Scope The doreversalresponse message is sent by the acquirer to acknowledge the proper receipt of a doreversalrequest. 9.1.2 Usage The doreversalresponse message is used to indicate one of the possible outcomes of an authorization reversal process: a successful authorization reversal; a decline from the acquirer for technical reasons (for instance, a timeout). 9.1.3 Outline The doreversalresponse message is composed of one block of elements contains elements to validate the response to the doreversalrequest message and the result of the credit process. These include merchant identification, transaction, transaction response, and transaction verification result. 9.2 Structure Index Message Element <XML Tag> Mult. Represent./ Type Message root <doreversalresponse> [1..1] - Index Message Element <XML Tag> Mult. Represent./ Type 9.3.1 + AmountTransaction <amounttransaction> [1..1] Integer 9.3.2 + DateTimeLocalTransaction <datetimelocaltransaction> [1..1] DateTime 9.3.3 + AcquirerReferenceData <acquirerreferencedata> [1..1] String 9.3.4 + ActionCode <actioncode> [1..1] Code 9.3.5 + CurrencyCodeTransaction <currencycodetransaction> [1..1] Code 9.3.6 + OriginalTransactionData <originaltransactiondata> [0..1] String 9.3 Message Elements Description The following section identifies the elements of the doreversalresponse message definition. 9.3.1 AmountTransaction <amounttransaction> Nets Technical Guide Copyright Nets Danmark A/S Page 35

Definition: Transaction amount in the smallest unit of the currency. Data Type: Min1Max12NumericText Format: [0-9]{1,12} 9.3.2 DateTimeLocalTransaction <datetimelocaltransaction> Definition: The time for generation of the transaction (local time at which the transaction is to be created). Data Type: datetime Format: YYMMDDhhmmss 9.3.3 AcquirerReferenceData <acquirerreferencedata> Definition: Transaction reference/order number generated by merchant and communicated to Mobilpenge account holders on the receipt. Data Type: Max23Text Format: maxlength: 23, minlength: 1 9.3.4 ActionCode <actioncode> Definition: Code indicating the status of the transaction and the action that must be taken by the merchant. One of the action codes defined in section will be used. 9.3.5 CurrencyCodeTransaction <currencycodetransaction> Definition: Currency associated with the transaction. Use one of the three-digit currency codes defined in ISO 4217. 9.3.6 OriginalTransactionData <originaltransactiondata> Presence: [0..1] Definition: Used to store data required by the terminal operating environment to process reversal and financial advice messages following this transaction; if the transaction is successful. Data Type: Max999Text Format: maxlength: 999, minlength: 1 Nets Technical Guide Copyright Nets Danmark A/S Page 36

9.4 Example <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mob="http://www.nets.eu/mobileacquirermobilpenge/"> <soapenv:header xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:to>https://129.35.212.242:443/mockmobileacquirermobilpengesoap</ws a:to><wsa:messageid>cf1b38fc-b479-42d9-962d-295f782ec1ca</wsa:messageid><wsa:relatesto>uuid:12636d34-4279-456a-a433-7e1f76cdb761</wsa:relatesto><wsa:action>http://www.nets.eu/mobileacquirermobilpenge/doreversal</wsa:action></soapenv:hea der> <SOAP-ENV:Body> <doreversalresponse xmlns="http://www.nets.eu/mobileacquirermobilpenge/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"> <amounttransaction xmlns="">107</amounttransaction> <datetimelocaltransaction xmlns="">110705094000</datetimelocaltransaction> <acquirerreferencedata xmlns="">21138674</acquirerreferencedata> <actioncode xmlns="">400</actioncode> <currencycodetransaction xmlns="">208</currencycodetransaction> <originaltransactiondata xsi:nil="false" xmlns="">thrkljewmbqga1ueaxmnvghhd3rlifnhqybdqtaefw0woteymtgwmdawmdbafw0xmteymtgymzu5ntlamggxczajbgnvbaytalvtmrmweqydvqq IEwpDYWxpZm9ybmlhMRYwFAYDVQQHFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcwFQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgk qhkig9w0baqefaaobjqawgykcgyea6pmgd5d6htffvximttdeaon4c9kcko+irtn7eoh8rqk41xxgooskfqebg+jngtxj9xvoraelgyw84u+e593y17iywqg 7tcFR39SDAqc9BkJb4SLD3muFXxzW2k6L05vuuWciKh0R73mkszeK9P4Y/bz5RiNQl/Os/CRGK1w7t0UCAwEAAaOB5zCB5DAMBgNVHRMBAf8EAjAAMDYGA1U dhwqvmc0wk6apocegjwh0dha6ly9jcmwudghhd3rl==</originaltransactiondata> </doreversalresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Nets Technical Guide Copyright Nets Danmark A/S Page 37

10 docreditrequest 10.1 Message Functionality 10.1.1 Scope The docreditrequest message is sent by a merchant service provider to notify an acquirer about the completion and final outcome of a mobile payment transaction. 10.1.2 Usage The docreditrequest message is used either to reverse a transaction which was not successfully completed (for example, cancellation of transaction by the consumer), but where a capture had been previously given. The message includes information required for transferring to the acquirer all data needed to perform the financial settlement of the transaction (credit). 10.1.3 Outline The docreditrequest message is composed of one block of elements contains elements required by the acquirer to credit the consumer. These include transaction details and data from the previous transactions. 10.2 Structure Index Message Element <XML Tag> Mult. Represent./ Type Message root <docreditrequest> [1..1] - Index Message Element <XML Tag> Mult. Represent./ Type 10.3.1 + AmountTransaction <amounttransaction> [1..1] Integer 10.3.2 + DateTimeLocalTransaction <datetimelocaltransaction> [1..1] DateTime 10.3.3 + FunctionCode <functioncode> [1..1] Code 10.3.4 + AcquirerReferenceData <acquirerreferencedata> [1..1] String 10.3.5 + CurrencyCodeTransaction <currencycodetransaction> [1..1] Code 10.3.6 + OriginalTransactionData <originaltransactiondata> [1..1] String 10.3 Message Elements Description The following section identifies the elements of the docreditrequest message definition. 10.3.1 AmountTransaction <amounttransaction> Definition: Transaction amount in the smallest unit of the currency. Nets Technical Guide Copyright Nets Danmark A/S Page 38

Data Type: Min1Max12NumericText Format: [0-9]{1,12} 10.3.2 DateTimeLocalTransaction <datetimelocaltransaction> Definition: The time for generation of the transaction (local time at which the transaction is to be created). Data Type: datetime Format: YYMMDDhhmmss 10.3.3 FunctionCode <functioncode> Definition: Reason for the transaction. The following value must be used (reserved for future enhancement): Code Definition 200 Original advice. 10.3.4 AcquirerReferenceData <acquirerreferencedata> Definition: Transaction reference/order number generated by merchant and communicated to Mobilpenge account holders on the receipt. Data Type: Max23Text Format: maxlength: 23, minlength: 1 10.3.5 CurrencyCodeTransaction <currencycodetransaction> Definition: Currency associated with the transaction. Use one of the three-digit currency codes defined in ISO 4217. 10.3.6 OriginalTransactionData <originaltransactiondata> Definition: Used to supply data required by the terminal operating environment to process the financial advice messages. Echo from the previous transaction response. Data Type: Max999Text Format: maxlength: 999, minlength: 1 Nets Technical Guide Copyright Nets Danmark A/S Page 39

10.4 Example <soapenv:envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mob="http://www.nets.eu/mobileacquirermobilpenge/"> <soapenv:header xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:action>http://www.nets.eu/mobileacquirermobilpenge/docredit</wsa:a ction><wsa:replyto><wsa:address>https://129.35.212.242:443/mockmobileacquirermobilpengesoap</wsa:address></wsa:replyto>< wsa:messageid>uuid:37ef061a-52dc-4c65-a3efa9414d734d07</wsa:messageid><wsa:to>https://194.239.133.140:453/mobilpenge/paymentinterface</wsa:to></soapenv:header> <soapenv:body> <mob:docreditrequest> <amounttransaction>107</amounttransaction> <datetimelocaltransaction>110705095000</datetimelocaltransaction> <functioncode>200</functioncode> <acquirerreferencedata>21138674</acquirerreferencedata> <currencycodetransaction>208</currencycodetransaction> <originaltransactiondata>miiditccaoqgawibagiql9+89q6rum0pmqpfqdq+mjanbgkqhkig9w0baqufadbmmqswcqydvqqgewjaqtelmcmga1uechm cvghhd3rlienvbnn1bhrpbmcgkfb0eskgthrkljewmbqga1ueaxmnvghhd3rlifnhqybdqtaefw0woteymtgwmdawmdbafw0xmteymtgymzu5ntlamggxcza JBgDVQQIEwpDYWxpZm9ybmlhu2ONgJd8IyAPkU0Wueru9G2Jysa9zCRo1kNbzipYvzwY4OA8Y0oR1A04Se6cA2NhUzUnC+MY+f6H/nEQyNv4SgQhqAi==</o riginaltransactiondata> </mob:docreditrequest> </soapenv:body> </soapenv:envelope> Nets Technical Guide Copyright Nets Danmark A/S Page 40

11 docreditresponse 11.1 Message Functionality 11.1.1 Scope The docreditresponse message is sent by the acquirer to acknowledge the proper receipt of a docreditrequest. 11.1.2 Usage The docreditresponse message is used to acknowledge the data capture process performed by the acquirer based on the data required to carry out the financial clearing and settlement of the transaction. 11.1.3 Outline The docreditresponse message is composed of one block of elements contains elements to validate the response to the docreditrequest message and the result of the credit process. These include merchant identification, transaction, transaction response, and transaction verification result. 11.2 Structure Index Message Element <XML Tag> Mult. Represent./ Type Message root <docreditresponse> [1..1] - Index Message Element <XML Tag> Mult. Represent./ Type 11.3.1 + AmountTransaction <amounttransaction> [1..1] Integer 11.3.2 + DateTimeLocalTransaction <datetimelocaltransaction> [1..1] DateTime 11.3.3 + AcquirerReferenceData <acquirerreferencedata> [1..1] String 11.3.4 + ActionCode <actioncode> [1..1] Code 11.3.5 + CurrencyCodeTransaction <currencycodetransaction> [1..1] Code 11.3.6 + OriginalTransactionData <originaltransactiondata> [0..1] String 11.3 Message Elements Description The following section identifies the elements of the docreditresponse message definition. 11.3.1 AmountTransaction <amounttransaction> Definition: Transaction amount in the smallest unit of the currency. Nets Technical Guide Copyright Nets Danmark A/S Page 41

Data Type: Min1Max12NumericText Format: [0-9]{1,12} 11.3.2 DateTimeLocalTransaction <datetimelocaltransaction> Definition: The time for generation of the transaction (local time at which the transaction is to be created). Data Type: datetime Format: YYMMDDhhmmss 11.3.3 AcquirerReferenceData <acquirerreferencedata> Definition: Transaction reference/order number generated by merchant and communicated to Mobilpenge account holders on the receipt. Data Type: Max23Text Format: maxlength: 23, minlength: 1 11.3.4 ActionCode <actioncode> Definition: Code indicating the status of the transaction and the action that must be taken by the merchant. One of the action codes defined in section will be used. 11.3.5 CurrencyCodeTransaction <currencycodetransaction> Definition: Currency associated with the transaction. Use one of the three-digit currency codes defined in ISO 4217. 11.3.6 OriginalTransactionData <originaltransactiondata> Presence: [0..1] Definition: Used to store data required by the terminal operating environment to process reversal and financial advice messages following this transaction; if the transaction is successful. Data Type: Max999Text Format: maxlength: 999, minlength: 1 Nets Technical Guide Copyright Nets Danmark A/S Page 42

11.4 Example <?xml version="1.0" encoding="utf-8"?> <SOAP-ENV:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:mob="http://www.nets.eu/mobileacquirermobilpenge/"> <soapenv:header xmlns:wsa="http://www.w3.org/2005/08/addressing"><wsa:to>https://129.35.212.242:443/mockmobileacquirermobilpengesoap</ws a:to><wsa:messageid>2bb3542e-453e-466a-afcf-b9d3ed2ab132</wsa:messageid><wsa:relatesto>uuid:37ef061a-52dc-4c65-a3efa9414d734d07</wsa:relatesto><wsa:action>http://www.nets.eu/mobileacquirermobilpenge/docredit</wsa:action></soapenv:heade r> <SOAP-ENV:Body> <docreditresponse xmlns="http://www.nets.eu/mobileacquirermobilpenge/" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance"> <amounttransaction xmlns="">107</amounttransaction> <datetimelocaltransaction xmlns="">110705095000</datetimelocaltransaction> <acquirerreferencedata xmlns="">21138674</acquirerreferencedata> <actioncode xmlns="">000</actioncode> <currencycodetransaction xmlns="">208</currencycodetransaction> <originaltransactiondata xsi:nil="false" xmlns="">miiditccaoqgawibagiql9+89q6rum0pmqpfqdq+mjqswcqydvqqgewjaqtelmcmga1uechmcvghhd3rlienvbnn1bhrthrkljewmbqga1ueaxm NVGhhd3RlIFNHQyBDQTAeFw0wOTEyMTgwMDAwMDBaFw0xMTEyMTgyMzU5NTlaMGgxCzAJBgNVBAYTAlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRYwFAYDVQQ HFA1Nb3VudGFpbiBWaWV3MRMwEQYDVQQKFApHb29nbGUgSW5jMRcwFQYDVQQDFA53d3cuZ29vZ2xlLmNvbTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYE A6PmGD5D6htffvXImttdEAoN4c9kCKO+IRTn7EOh8rqk41XXGOOsKFQebg+jNgtXj9xVoRaELGYW84u+E593y17iYwqG7tcFR39SDAqc9BkJb==</origina ltransactiondata> </docreditresponse> </SOAP-ENV:Body> </SOAP-ENV:Envelope> Nets Technical Guide Copyright Nets Danmark A/S Page 43

12 HTTP Status Codes This chapter list descriptions and interpretation of the HTTP Status Codes within the Mobilpenge standard. Status Code Status code text 204 No Content Success The server has fulfilled the request but does not need to return an entity-body, and might want to return updated meta-information. The response MAY include new or updated meta-information in the form of entity-headers, which if present SHOULD be associated with the requested variant. If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent's active document view, although any new or updated meta-information SHOULD be applied to the document currently in the user agent's active view. The 204 response MUST NOT include a message-body, and thus is always terminated by the first empty line after the header fields. 500 Internal Server Error Error The server encountered an unexpected condition which prevented it from fulfilling the request. Nets Technical Guide Copyright Nets Danmark A/S Page 44

13 Action Codes This chapter list descriptions and interpretation of the most common used Action Codes with an explanation on why a given Action Code is used. Other Action Codes can be used, and nonmentioned Action Codes must be considered as a decline. For additional information about Action Codes contact the acquirer. Action code Action Code text (for merchant use only) Action Code text (for use against Consumer) 000 Approved Approved 001 Honour with identification Decline 002 Approved for partial amount Partly Approved 060 Approved Approved 061 Approved Approved 063 Approved Approved 100 Do not honour Decline 101 Expired product agreement Decline/Expired 102 Suspected Fraud Decline 103 Merchant contact acquirer Decline 104 Restricted product Decline 105 Merchant call acquirers security department Decline 106 Allowable authentication tries exceeded Decline 107 Refer to issuer Decline 108 Refer to issuer special conditions Decline 109 Invalid merchant Decline 110 Invalid amount Decline/Amount Error 111 Invalid phone number Decline 112 Authentication data required Decline 113 Unacceptable fee Decline 114 No account of type requested Decline 115 Requested function not supported Decline 116 Not sufficient funds Decline 117 Incorrect authentication Decline Nets Technical Guide Copyright Nets Danmark A/S Page 45

118 No record Decline 119 Transaction not permitted to user Decline/Invalid Transaction 120 Transaction not permitted to device Decline/Invalid Transaction 121 Exceeds withdrawal amount limit Decline 122 Security violation Decline 123 Exceeds withdrawal frequency limit Decline 124 Violation of law Decline 160 Invalid date Decline 162 Unable to locate previous message Decline 167 Match on previous transaction not allowed Decline 200 Do not honour Decline 201 Expired agreement Decline/Expired agreement 202 Suspected fraud Decline 203 Merchant contact acquirer Decline 204 Restricted product Decline 205 Merchant call acquires security department Decline 207 Special conditions Decline 208 Lost phone Decline 209 Stolen phone Decline 400 Approved Approved 900 Advice acknowledged, no financial liability accepted. Approved 901 Advice acknowledged, financial liability accepted. Approved 902 Invalid transaction Decline/Invalid Transaction 903 Re-enter transaction Decline 904 Format error Decline/System Error 905 Acquirer not supported by switch Decline/System Error 906 Cut over in process No Reply 907 Issuer or switch inoperative No Reply 908 Transaction destination cannot find routing Decline Nets Technical Guide Copyright Nets Danmark A/S Page 46

909 System malfunction Decline/System Error 910 Issuer signed off No Reply 911 Issuer timed out No Reply 912 Issuer unavailable No Reply 945 Timeout No Reply 946 Product internal error No Reply 950 Violation of business arrangement Decline/System Error Nets Technical Guide Copyright Nets Danmark A/S Page 47