Card Processing. Merchant Specification. Version 3.5.0

Version 3.5.0

This document has been created by the Wirecard AG. Its contents may be changed without prior notice. External web links are provided for information only. Wirecard does not claim liability for access to and correctness of the referenced content. COPYRIGHT The information contained in this document is intended only for the person or entity to which it is addressed and contains confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact Wirecard AG and delete the material from any computer. Copyright 2008 Wirecard AG All rights reserved. Printed in Germany / European Union Version 3.5.0 Last Updated: July 2009 TRADEMARKS The Wirecard logo is a registered trademark of Wirecard AG. Other trademarks and service marks in this document are the sole property of the Wirecard AG or their respective owners. CONTACT INFORMATION For questions relating to this document please contact: Wirecard Technologies AG Bretonischer Ring 4 D-85630 Grasbrunn Germany phone: +49 89 4424 0640 e-mail: support@wirecard.com 2 Version 3.5.0

Card Processing Contents 1 Introduction...5 1.1 Audience... 5 1.2 Document Conventions...5 1.3 Software Requirements...5 1.4 References...5 1.5 Revision History...6 2 Overview...7 2.1What is XML... 7 2.2 XML Messages...7 2.3 Secure Data Transfer...8 3 XML Messaging...9 3.1 Request Format... 9 3.2 Response Format... 10 4 Test Gateway...12 4.1 Test Access...12 4.2 Error Messages...12 4.3 Test Cards...13 5 Transaction Modes and Methods... 14 5.1 Demo...14 5.2 Live...16 5.3 Single Transaction...17 5.4 Recurring Transaction...17 5.5 Installment Transaction... 21 5.6 Implementation...22 5.7 Revoking Recurring and Installment Transactions...22 Version 3.5.0 3

6 Transaction Types... 23 6.1 Preauthorization... 24 6.2 Capture Preauthorization... 32 6.3 Preauthorization Supplement... 36 6.4 Capture Preauthorization Supplement... 39 6.5 Authorization... 44 6.6 Authorization Check... 52 6.7 Capture Authorization... 54 6.8 Purchase... 59 6.9 Notification... 70 6.10 Bookback... 73 6.11 Reversal... 77 6.12 Original Credits... 81 6.13 Query... 86 6.14 Refund... 91 6.15 Standard Response Message... 96 7 Address Verification Service... 98 7.1 AVS Response Message... 98 7.2 Wirecard AVS Response Codes... 99 7.3 Wirecard Response Code Mapping... 99 8 Glossary... 101 Appendix A: Error Codes... 105 Appendix B: AVS Codes... 120 Appendix C: Airline Market Segment... 121 Appendix D: Car Rental Market Segment... 124 Appendix E: Fleet Card Market Segment... 128 Appendix F: Hotel Market Segment... 130 Appendix G: Travel Market Segment... 134 Appendix H: XML Extensions... 136 Appendix I: Purchasing Process... 138 Appendix J: ASCII Characters... 139 4 Version 3.5.0

Card Processing 1 Introduction 1.1 Audience This specification is intended to be read by the technical staff in the merchant s organization responsible for implementing and administering the XML-based card processing interface. It is assumed that the reader has a working knowledge of the programming languages discussed in this specification. 1.2 Document Conventions This document uses the following conventions: The monospace font is used for example code and code listings, file names, commands, path names, directory names, Hypertext Markup Language (HTML) tags, and any text that must be typed on the screen. The italic font is used in code to represent placeholder parameters (variables) that should be replaced with an actual value, or items that require emphasis. Brackets ([]) are used to enclose optional parameters. A slash (/) is used to separate directories in a path and to indicate a blank or closing XML parameter. 1.3 Software Requirements To implement the XML interface for standard card processing, the following requirements must be met: Internet connection supporting SFTP Working knowledge of XML SSL server supporting 128-bit (or stronger) encryption 1.4 References 3-D Secure Card Processing - Specification (Wirecard documentation) HTTPS Gateway - Specification (Wirecard documentation) Introducing 3-D Secure - White Paper (Wirecard documentation) Uniform Resource Identifier (URI): Generic Syntax (RFC 2396) UTF-8, a transformation format of ISO 10646 (RFC 2279) Version 3.5.0 5

1.5 Revision History This specification is periodically updated to reflect the modifications made to the card processing interface. With each revision a new entry is added to the table below, including the date of and the reason for the version change. Additionally, vertical revision bars are placed in the margins to indicate the changes in the text. Date Version Comments 2007-07-19 2.0.0 New transaction type (Authorization Check) added and CREDIT_CARD_DATA fields CardStartYear, CardStartMonth, CardIssueNumber added to Preauthorization Request. Some minor editorial changes. New transaction mode (Installment Transaction) and related error codes added. 2007-09-04 2.1.0 Airline Market and Travel Market segments (Appendices C and F) updated with different tax (VAT) type fields and identifiers. Query request updated. 2007-10-09 2.2.0 Authorization Code removed from Capture, Refund, Bookback, etc Only required in Notification Requests. Some minor changes. 2007-10-31 2.3.0 Elements in Airline Market and Travel Market segments (Appendices C and F) updated. New code added in Error Messages (Appendix A). 2007-11-05 2.3.1 Minor changes. 2007-11-29 2.4.0 Transaction Type Capture removed from notice. Data Type for Address fields changed to ANS (alphanumeric and special characters). 2008-03-04 2.5.0 Single/Initial Request examples updated. Card Start Date & Card Issue Number for Switch/Solo/Maestro changed to optional. 2008-04-07 3.0.0 Chapter 7 on AVS incorporated. Query date format updated. 2008-05-14 3.0.1 VAT field settings changed form mandatory to conditional - with comment "relevant for AirPlus Acceptance UATP transactions only". FareBasis data type changed from a6 to an6. 2008-07-22 3.0.2 Note added to Refund examples. 2008-09-01 3.1.0 DTD Reference (xsi:nonamespaceschemalocation="wirecard.xsd") removed from XML examples and Appendix D (Car Rental market segment) incorporated. 2008-09-22 3.1.1 minor updates. 2008-10-15 3.2.0 Section 6.12 (Original Credits) added. Sections 6.10 (Bookback) and 6.14 (Refund) updated. Some minor updates. 2008-11-05 3.2.1 Section 6.12 (Original Credits) updated. 2009-02-10 3.3.0 Phone number format updated. Cross references incorporated. 2009-06-30 3.4.0 <FunctionResult>ACK</FunctionResult> in XML samples changed to <FunctionResult>PENDING</FunctionResult>. IP address format description changed. Error code 20001 included. CountryCode in OCT request table included. Section 4.3 (Test Cards) incorporated. Section 5 updated. Description of parameter <State> rewritten. 2009-08-14 3.5.0 Error Codes (Appendix A) updated. Example of Reversal Succcessful response (Section 6.11.2) corrected. 6 Version 3.5.0

Card Processing 2 Overview 2.1 What is XML XML, the extensible Markup Language, is designed to carry data in predefined tags. It does not replace HTML, the HyperText Markup Language, but complements it. XML picks up where HTML leaves off. It allows specific markup to be created for specific data. HTML doesn t clearly distinguish markups. Markup for look and links gets mixed in with data. If you change the look of HTML markups, links may be lost. If you change link markups, the look may be lost. This is not the case with XML. Unlike HTML, the extensible Markup Language is not only flexible but also easy to customize and maintain. 2.2 XML Messages This section describes the structure, format, and definition of XML messages. These are defined as a set of fields containing the following parameters: name of the XML message element setting of the XML message element (see also description below) data type defining the structure of the element 2.2.1 Required Settings The exchange of XML messages is based on certain requirements. If these are not met, the XML request/response communication will fail. It is therefore imperative that the message elements are defined as required (see the request message elements described in Chapter 6. The request elements are defined as mandatory, optional, or conditional. Mandatory A mandatory (man.) message is necessary to ensure the proper routine and posting of an XML message. Any mandatory message element not included as requested will cause the process request type to be rejected. Optional The inclusion or omission of an optional (opt.) message field is at the discretion of the merchant. A transaction request is also processed if an optional field is missing. Conditional A conditional (con.) message field must be included in some instances. Its omission may cause the process request type to be rejected. Version 3.5.0 7

2.2.2 Notations The following notations define the data type formats of message elements. Notation Description a alphabetic A-Z, a-z n numeric digits, 0-9 an alphanumeric characters as alphabetic and special characters ans alphanumeric and special characters DD Day, 01 through 31 MM Month, 01 to 12 YY Year, 00-99 where 00=2000, 01=2001, etc. hh hour, 00 to 23 mm minute, 00 to 59 ss second, 00 to 59 3 Fixed length of 3 bytes..17 Variable length up to a maximum of 17 bytes. c collection of elements 2.2.3 UTF-8 Character Encoding As credit cards are accepted from customers around the world, the XML text messages of credit card transactions may contain data in different languages. To cater to these cross-border card transactions, merchants are advised to configure their system to send XML text messages in the 8-bit Unicode Transformation Format (UTF-8), a variable-length character encoding described in ISO/IEC 10646. UTF-8 is designed for multilingual environments, allowing letters, symbols, numbers, and ideograms from around the world to be converted and consistently represented by computers. While the bit patterns of the ASCII characters are sufficient to exchange transaction data in English, most other languages based on the Latin alphabet use additional symbols (umlauts) which are not covered by standard ASCII, such as ü, ä ö or ß (German), ñ (Spanish) and å (Swedish and other Nordic languages). For example, the text message of a credit card transaction from the German cardholder "Günter Groß" will read "G?nter Gro?" and instead of receiving a clear description like "Gebühren für Gäste" in the usage field the system will receive "Geb?hren f?r G?ste". To avoid such garbled text messages, it is imperative that merchants use UTF-8 encoding. NOTE: All field length values in this specification are byte values! The actual number of characters allowed in a field may be less than the given byte value as certain UTF-8 characters are represented using more than one byte. 2.3 Secure Data Transfer To guard confidentiality, cardholder and transaction data is sent over the Internet using HTTP over SSL (HTTPS) at a standard 128-bit encryption. For more information, see the Wirecard system specification HTTPS Gateway, describing how to set up a secure connection to the Wirecard processing environment. 8 Version 3.5.0

Card Processing 3 XML Messaging At the highest level, the Wirecard XML structure represents payment or risk management requests and responses. These are submitted, one at a time, as Wirecard Business XML [WIRECARD_BXML] documents. 3.1 Request Format The high-level structure of a Wirecard Business XML document looks like this: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>Job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_XYZ> </FNC_CC_ XYZ> </W_JOB> </W_REQUEST> </WIRECARD_BXML> The tag <BusinessCaseSignature> identifies the merchant of record for the transaction within the Wirecard system. Note that the merchant of record may be different than the submitting party in a delegated processing model. The tag <FNC_CC_XYZ> represents a function call resulting in the processing of certain submitted information encapsulated by the <FNC_CC_XYZ></FNC_CC_XYZ> tag-pair. A <W_JOB></W_JOB> tag-pair may include up to 10 different function calls performing a variety of operations as shown below: <W_JOB> <JobID>Job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</ BusinessCaseSignature > <FNC_CC_ABC> </FNC_CC_ ABC> <FNC_CC_DEF> </FNC_CC_ DEF> <FNC_CC_GHI> </FNC_CC_ GHI> </W_JOB> A <FNC_CC_XYZ></FNC_CC_XYZ> tag pair may include up to 5 transactions of the same type. Version 3.5.0 9

3.2 Response Format Each request [<W_REQUEST></W_REQUEST>] submission produces a corresponding XML response document containing results for each submitted transaction request. The high-level structure of a response looks like this: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID> Job 1</JobID> <FNC_CC_ XYZ> </FNC_CC_ XYZ> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> For tracking purposes three unique identification levels are defined and allow the user to correlate request and response data. From these three levels, only the second and third are tracked by Wirecard. The first level is for the merchant only. <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>user-assigned job-id</jobid> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_TRANSACTION> <FunctionID>user-assigned function-id</functionid> <CC_TRANSACTION mode="demo"> <TransactionID>unique user-assigned transaction-id</transactionid> <CountryCode>DE</CountryCode> <CommerceType></CommerceType> <Amount minorunits="2">50000</amount> <Currency>EUR</Currency> <Usage>DE</Usage> <CREDIT_CARD_DATA> <CreditCardNumber>4200000000000000</CreditCardNumber> <CVC2>1234</CVC2> <ExpirationYear>2009</ExpirationYear> <ExpirationMonth>01</ExpirationMonth> <CardHolderName>John Doe</CardHolderName> </CREDIT_CARD_DATA> <CONTACT_DATA> <IPAddress>192.168.1.1</IPAddress> </CONTACT_DATA> </CC_TRANSACTION> </FNC_CC_TRANSACTION> </W_JOB> </W_REQUEST> </WIRECARD_BXML> 10 Version 3.5.0

Card Processing The assigned IDs are not necessarily unique in the Wirecard system and serve only for tracking purposes on the user-side. The unique Wirecard system-wide transaction key is the GuWID (Globally unique Wirecard ID) which is returned as a processing results of a transaction: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>Job1</JobID> <FNC_CC_ TRANSACTION> <FunctionID> Transaction 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C0098854100980113920</GuWID> <AuthorizationCode>975023</AuthorizationCode> <StatusType>INFO</StatusType> <FunctionResult>ACK</FunctionResult> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_TRANSACTION> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> NOTE: Please store the GuWID returned by the Wirecard system to enable easy and fast processing of transaction related customer service requests! Version 3.5.0 11

4 Test Gateway Merchants planning to integrate the Wirecard platform can test the integration on a dedicated test gateway. It is basically identical to the live HTTPS gateway with the exception that none of the submitted payment requests actually trigger a movement of moneys. As part of the Wirecard quality assurance, merchants are requested to perform several tests on the test gateway in cooperation with the Wirecard support organization prior to connecting to the live HTTPS Gateway. This is to ensure a smooth and flawless communication and transaction data flow between the integrating company and Wirecard. You can send test transactions to our system with varying amounts and in any currency using any of the transaction types described in this specification. 4.1 Test Access To set up your test access please refer to the system specification HTTPS Gateway. 4.2 Error Messages When sending test transactions to our system you can create specific error messages. To do so, please use card number 4200000000000000 and flag the transaction with the mode type demo. 1. Amounts below EUR 1000.00 or any other currency will generate an acknowledgement (ACK) with the response status error code 9500. 2. Amounts between EUR 1000.02 and EUR 1000.98 are reserved for response codes in the ACM error code range. Amount: 100002-02 Call Voice Authorization Number. Amount: 100003-03 Invalid Merchant Number. Amount: 100004-04 Retain Card. Amount: 100005-05 Authorization Declined. Amount: 100006-06 Error in Sequence Number. Amount: 100009-09 Wait Command.... Amount: 100098-98 Date and Time Not Plausible. Example: The amount of EUR 1000.02 ( <Amount>100002<Amount> ) will produce response code 02: <Type>REJECTED</Type> <Number>02</Number> <Message>Call voice authorization number.</message> Any failure not specified by the Wirecard system will produce error code 250: <Type>REJECTED</Type> <Number>250</Number> <Message>System Error.</Message> For a complete list of ACM error codes, see Appendix A. 12 Version 3.5.0

Card Processing 4.3 Test Cards Several Visa test cards are available for demo purposes to simulate real transactions. By using any of the test card numbers from the table below, merchants can generate defined transactions with the response codes and messages shown. The card numbers are provided courtesy of VISA for Product Integration Testing (PIT) only. They have no issuer assigned and are generated as follows: First 6 digits are the Bank Identification Number (BIN): 401200 2 digits test number 4 digits Response Code (only the last two are used) 4 digits (Luhn check fulfillment) Please use the following parameters in your demo XML request: Test No. Card No. Exp. Date CVV2 Code Resp. Code Resp. Message 1 4012000100000007 01/19 007 00 Approved or completed successfully 2 4012000200020004 01/19 004 02 Call Voice-authorization number; Initialization Data 3 4012000300030002 01/19 002 03 Invalid merchant number 4 4012000400040000 01/19 999 04 Retain card 5 4012000500050008 01/19 008 05 Authorization declined 6 4012000600120008 01/19 008 12 Invalid transaction 7 4012000700130006 01/19 006 13 Invalid amount 8 4012000800140004 01/19 004 14 Invalid card 9 4012000900210004 01/19 004 21 No action taken 10 4012001000300000 01/19 999 30 Format Error 11 4012001100330006 01/19 006 33 Card expired 12 4012001200340004 01/19 004 34 Suspicion of Manipulation (CVC2) 13 4012001300400005 01/19 005 40 Requested function not supported 14 4012001300430002 01/19 002 43 Stolen Card, pick up 15 4012001500560004 01/19 004 56 Card not in authorizer's database 16 4012001600580001 01/19 001 58 Terminal ID unknown 17 4012001700620004 01/19 004 62 Restricted Card 18 4012001800910008 01/19 008 91 Card issuer temporarily not reachable 19 4012001900920006 01/19 006 92 The card type is not processed by the authorization center 20 4012002000960009 01/19 009 96 Processing temporarily not possible Version 3.5.0 13

5 Transaction Modes and Methods Merchants can post payment transactions to the Wirecard processing platform using different modes and methods. The use of two distinct transaction mode helps merchants distinguish between demo transaction and live transaction. In addition to defining a particular mode, merchants can select a transaction method (single transaction, recurring transaction or installment transaction) to signal to the system that the transaction request is to be treated as a one-off payment transaction or that the card data is to be processed and stored with reference for future (related) payment request. The following Chapter discusses these modes and methods in detail. 5.1 Demo Merchants who process with Wirecard for the first time are connected to the payment processing platform in Demo mode. This is to ensure that while testing the card processing XML interface the posted transactions are not accidently routed to the Acquiring Bank for settlement. When a transaction is sent in demo mode using demo card data (see Section 4.3), the Wirecard system automatically verifies if the merchant is configured in demo mode. If the merchant s business case is not configured in demo mode, the system generates a response message with a message tag informing the merchant that the request could not be processes in demo mode as requested. In the parameter tag <CC_TRANSACTION> the merchant can add the attribute <mode= demo >. This attribute must be provided if the merchant wishes to test the card processing interface using a real credit card data instead of the demo data provided in Section 4.3. Request Example attribute mode defines if transaction is sent as simulated transaction or live transaction <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>example ID Purchase J1</JobID> <BusinessCaseSignature>123</BusinessCaseSignature> <FNC_CC_PREAUTHORIZATION> <FunctionID>example ID Purchase F1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>Authorization Initial 1</TransactionID> <Amount>1000</Amount> <Currency>EUR</Currency> <CountryCode>DE</CountryCode> <Usage>Y6162</Usage> <RECURRING_TRANSACTION> <Type>Initial</Type> </RECURRING_TRANSACTION> <CREDIT_CARD_DATA> <CardHolderName>John Doe</CardHolderName> <CreditCardNumber>5500000000000000</CreditCardNumber> <ExpirationYear>2010</ExpirationYear> <ExpirationMonth>12</ExpirationMonth> <CVC2>471</CVC2> </CREDIT_CARD_DATA> 14 Version 3.5.0

Card Processing <CORPTRUSTCENTER_DATA> <ADDRESS> <FirstName>John</FirstName> <LastName>Doe</LastName> <Address1>550 South Winchester blvd.</address1> <Address2>P.O. Box 850</Address2> <City>San Jose</City> <ZipCode>95128</ZipCode> <State>CA</State> <Country>US</Country> <Phone>+1(1)8323933406</Phone> <Email>John.Doe@email.com</Email> </ADDRESS> <PERSONINFO> <BirthDate>1982-04-17</BirthDate> </PERSONINFO> </CORPTRUSTCENTER_DATA> <CONTACT_DATA> <IPAddress>127.0.0.1</IPAddress> </CONTACT_DATA> </CC_TRANSACTION> </FNC_CC_PREAUTHORIZATION> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Response Example <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>example ID Purchase J1</JobID> <FNC_CC_PREAUTHORIZATION> <FunctionID>example ID Purchase J1 F1</FunctionID> <CC_TRANSACTION> <TransactionID>Authorization Initial 1</TransactionID> <PROCESSING_STATUS> <GuWID>C822947124395249138105</GuWID> <AuthorizationCode>076427</AuthorizationCode> <Info>THIS IS A DEMO TRANSACTION USING CREDIT CARD NUMBER 550000****0000. NO REAL MONEY WILL BE TRANSFERED.</Info> <StatusType>INFO</StatusType> <FunctionResult>ACK</FunctionResult> <TimeStamp>2009-06-02 16:21:31</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_PREAUTHORIZATION> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> Version 3.5.0 15

5.2 Live When a new merchant has successfully tested his XML interface with the processing platform, the merchant s business case is configured for live processing which means the payment transaction is no longer simulated in demo mode but the data is fully processed and settled by the acquiring bank. Any amount posted in live mode with parameter <Amount> to the Wirecard system will be treated as a real transaction with complete settlement. Response Example The following is a response to a request sent with demo card data on an XML interface configured for live processing: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance" xsi:nonamespaceschemalocation="wirecard.xsd"> <W_RESPONSE> <W_JOB> <JobID>ACCEPTANCE-TEST</JobID> <FNC_CC_TRANSACTION> <FunctionID>GZS-PAGO</FunctionID> <CC_TRANSACTION> <TransactionID>1</TransactionID> <PROCESSING_STATUS> <GuWID>C895978124540997772104</GuWID> <AuthorizationCode></AuthorizationCode> <Info>THIS IS A DEMO TRANSACTION USING CREDIT CARD NUMBER 420000****0000. NO REAL MONEY WILL BE TRANSFERED.</Info> <StatusType>INFO</StatusType> <FunctionResult>NOK</FunctionResult> <ERROR> <Type>DATA_ERROR</Type> <Number>24998</Number> <Message>Demo-card or demo-mode transactions are not allowed without demo terminal mode.</message> <Advice>Inspect your card number or remove attribute mode=''demo'' of tag 'CC_TRANSACTION'</Advice> </ERROR> <TimeStamp>2009-06-19 13:12:57</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_TRANSACTION> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 16 Version 3.5.0

Card Processing 5.3 Single Transaction A single transaction entails a one-off charge to a payment card account. It is typically used by Internet shoppers who place a single, one-time order with a merchant. 5.4 Recurring Transaction In contrast to the above, a recurring transaction describes a payment where the cardholder s account is periodically charged for a repeated delivery and use of a product or service (subscription, membership fee, etc.) over time. A recurring transaction consists of an initial request (which is identical in form and content to a single request) and one or several repeated transaction request messages. The initial request message (which in most cases is an Authorization) contains all relevant card and cardholder data, while the subsequent repeated message (which can be another Authorization, or a Capture or a Purchase) simply references an identifier (the Global Unique Wirecard ID) which is returned with the response message to the initial request. Example: INITIAL/SINGLE Request - Authorization The following is an example of a full-length initial request message containing all card and cardholder data in the CC_TRANSCATION collection element. shows method (defined in attribute type) <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <Amount minorunits="2">50000</amount> <Currency>EUR</Currency> <CountryCode>DE</CountryCode> <Usage>OrderNo-FT345S71 Thank you</usage> <RECURRING_TRANSACTION> <Type>Initial</Type> </RECURRING_TRANSACTION> <CREDIT_CARD_DATA> <CreditCardNumber>4200000000000000</CreditCardNumber> <CVC2>001</CVC2> <ExpirationYear>2009</ExpirationYear> <ExpirationMonth>01</ExpirationMonth> <CardHolderName>John Doe</CardHolderName> </CREDIT_CARD_DATA> <CONTACT_DATA> <IPAddress>192.168.1.1</IPAddress> </CONTACT_DATA> <CORPTRUSTCENTER_DATA> <ADDRESS> <FirstName>John</FirstName> <LastName>Doe</LastName> <Address1>550 South Winchester blvd.</address1> <City>San Jose</City> <ZipCode>95128</ZipCode> <State>CA</State> <Country>US</Country> <Phone>+1(202)555-1234</Phone> <Email>John.Doe@email.com</Email> </ADDRESS> </CORPTRUSTCENTER_DATA> </CC_TRANSACTION> Version 3.5.0 17

Example: REPEATED Request Authorization The following is an example of a shortened recurring request type Repeated which omits all card and cardholder data in the CC_TRANSCATION collection element and only references the Global Unique Wirecard ID (GuWID). <FNC_CC_AUTHORIZATION> <FunctionID>authorization 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <GuWID>C328668112556109425394</GuWID> <RECURRING_TRANSACTION> <Type>Repeated</Type> </RECURRING_TRANSACTION> </CC_TRANSACTION> </FNC_CC_AUTHORIZATION> NOTE: If the payment card data of a customer has changed, all data must be resubmitted in form of an initial transaction. The system will generate a new reference GuWID which must be used for all subsequent transactions by this cardholder. 5.4.1 Available Transaction Types It is possible to use the recurring functionality with the transaction types: Purchase Authorization Preauthorization Refund All other transactions like Capture, Bookback and Reversal are always processed as Single. Any recurring data that may be included in these XML request messages is simply ignored. 5.4.2 Permissible Changes It is also possible to send a repeated transaction containing the elements <Amount> and <Currency>, if the entered data differs from the input in the Initial transaction request message. This option is recommended for merchants who offer goods or services in different prices ranges. Example: <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <GuWID>C328668112556109425394</GuWID> <Amount>10000</Amount> <Currency>USD</Currency> 18 Version 3.5.0

Card Processing 5.4.3 Recurring Transaction Flow Merchants can decide themselves at any time which transaction type they wish to place in the recurring process (Authorization, Capture Authorization, Preauthorization, Capture Preauthorization or Purchase) meaning that an initial Authorization can also be followed by Purchase (as repeated transaction) instead of a Capture, referencing the GUWID of the initial request (in this case Authorization). A typical transaction flow using transaction type Purchase for a subscription may look like this: SHOPPER MERCHANT WIRECARD subscription with monthly payments shopper sends a subscription test message with payment details merchant sends Authorization request message* Wirecard returns Authorization response message with GuWID 1 first month payment merchant sends new Authorization, or Purchase or Capture request message with GuWID 1 Wirecard returns response message with GuWID 2 second month payment merchant sends new Authorization, or Purchase or Capture request message with GuWID 1 Wirecard returns response message with GuWID 3 xxx month payment merchant sends new Authorization, or Purchase or Capture request message with GuWID 1 Wirecard returns response message with GuWID xxx * merchant stores shopper s personal data and sends card details to Wirecard Fig. 1: Recurring transaction flow for subscriptions Version 3.5.0 19

Starting with an initial Authorization request, a typical recurring transaction flow using different transaction types may look like this: SHOPPER MERCHANT WIRECARD Order 1 350 Order 2 450 Order 3 175 shopper submits first online order with payment details shopper submits second online order with payment details shopper submits third online order with payment details merchant sends Authorization request message * Wirecard returns Authorization response message with GuWID 1 merchant sends new Authorization request message with GuWID 1 Wirecard returns Authorization response message with GuWID 2 merchant sends new Authorization request message with GuWID 1 Wirecard returns Authorization response message with GuWID 3 Order 4 new product end of week settlement shopper submits fourth online order with payment details merchant sends Capture Authorization with GuWID 1 Wirecard returns Capture Authorization response merchant sends Capture Authorization with GuWID 2 Wirecard returns Capture Authorization response merchant sends Capture Authorization with GuWID 3 Wirecard returns Capture Authorization response merchant sends a Purchase request message Wirecard returns Purchase response message with GuWID 4 * merchant stores shopper s personal data and sends card details to Wirecard Fig. 2: Recurring transaction flow for new product and transaction type 20 Version 3.5.0

Card Processing 5.5 Installment Transaction Unlike recurring transactions, this mode allows customers to pay with their charge card for products and services in multiple installments, over a period of time agreed between the cardholder and the merchant. See also the Glossary for a definition of this transaction mode. For example, if a product is priced at 2000 Euros, the merchant can charge a down payment of 1000 Euros to the card at the time of the online purchase followed by one or several installments of a predefined amount. NOTE: Installment transactions are not supported by all acquirers. If a merchant posts a transaction using this payment mode and the acquirer does not support it, the request is flagged, processes and forwarded to the acquirer as a standard purchase transaction. 5.5.1 Initial and Repeated Installments can be posted as initial and repeated requests for the transaction types Preauthorization, Authorization and Purchase. While the initial request carries all product, contact, cardholder and card details, the repeated installment include only the amount and currency as well as reference identifier to the initial transaction, called GuWID (Global unique Wirecard ID). Example: Initial Purchase Request <?xml version= 1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="<http://www.w3.org/1999/xmlschema-instance>"> <W_REQUEST> <W_JOB> <JobID>ACCEPTANCE-TEST</JobID> <BusinessCaseSignature>770</BusinessCaseSignature> <FNC_CC_PURCHASE> <FunctionID>FirstData-KAAI</FunctionID> <CC_TRANSACTION> <TransactionID>6.1.1</TransactionID> <CommerceType>eCommerce</CommerceType> <Amount>100</Amount> <Currency>EUR</Currency> <CountryCode>DE</CountryCode> <INSTALLMENT_PAYMENT> <Type>Initial</Type> </INSTALLMENT_PAYMENT> <CREDIT_CARD_DATA> <CreditCardNumber>414901****0147</CreditCardNumber> <CVC2>147</CVC2> <ExpirationYear>2009</ExpirationYear> <ExpirationMonth>12</ExpirationMonth> <CardHolderName>John Doe</CardHolderName> </CREDIT_CARD_DATA> <CONTACT_DATA> <IPAddress>192.168.1.1</IPAddress> </CONTACT_DATA> </CC_TRANSACTION> </FNC_CC_PURCHASE> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Version 3.5.0 21

Example: Repeated Purchase Request The following is an example of installment request type Repeated containing no card or carholder data. <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>ACCEPTANCE-TEST</JobID> <BusinessCaseSignature>770</BusinessCaseSignature> <FNC_CC_PURCHASE> <FunctionID>FirstData-KAAI</FunctionID> <CC_TRANSACTION> <TransactionID>6.1.1</TransactionID> <CommerceType>eCommerce</CommerceType> <Amount>100</Amount> <Currency>EUR</Currency> <CountryCode>DE</CountryCode> <INSTALLMENT_PAYMENT> <Type>Repeated</Type> </INSTALLMENT_PAYMENT> <CONTACT_DATA> <IPAddress>192.168.1.1</IPAddress> </CONTACT_DATA> </CC_TRANSACTION> </FNC_CC_PURCHASE> </W_JOB> </W_REQUEST> </WIRECARD_BXML> 5.6 Implementation Merchants who wish to post recurring and installment transactions please contact the Wirecard Technical Support at support@wirecard.com for implementation requirements. 5.7 Revoking Recurring and Installment Transactions Cardholders can instruct their issuers to reject recurring and installment payments charged to their card. This they can do for goods and services purchased globally or for a particular merchant. In this case all transactions will be automatically flagged accordingly by the issuing bank and rejected by the Wirecard system. The transaction response message sent to the merchant will return error code 78 or 79. For more details see these codes defined in the Error Code List in Appendix A. 22 Version 3.5.0

Card Processing 6 Transaction Types The Wirecard platform processes the following transaction types: Preauthorization Capture Preauthorization Preauthorization Supplement Capture Preauthorization Supplement Authorization Authorization Check Capture Authorization Purchase Notification Bookback Reversal Original Credits Query Refund Request and Responses For every submitted transaction request, the Wirecard system returns a response message, regardless of the outcome of the transaction process (one for a failed process and one for a successful process). Included in every response message is a collection element field called Function name which, depending on the type of transaction processed and its outcome can have different values. Instead of listing the response message elements with each transaction type described in this Chapter, they are referenced by hypertext link from every response example. NOTE: It is important that merchants analyse all incoming XML response messages to verify if the transaction has been processed successfully. The outcome of a transaction is presented in the <PROCESSING_STATUS> element of the response message. See Section 6.53 - Authorization Error Response for an example. Supported Characters All text entered in the request element fields JobID, FunctionID, and TransactionID must conform to the ASCII character codes 32 to 126 (with the exception of code 39). The characters in this ASCII code range are known as printable characters, representing letters, digits, punctuation marks, and a few miscellaneous symbols. Code 32 denotes the space between words, as produced by the large space-bar of a keyboard. All other ASCII codes in the number range from 0 to 31 (known as control characters or non-printing character) are not supported. For more details see Appendix J. Version 3.5.0 23

6.1 Preauthorization A Preauthorization is no guarantee of payment. It only confirms that the card exists and that funds are available at the time of Preauthorization to cover a purchase amount. The funds are not credited at this time but the Preauthorization reduces the available credit limit for that card, so in a sense the funds are reserved for the purchase. If necessary, the initial reserved amount can be altered by using a preauthorization supplementary transaction. To settle the originally preauthorized amount, use the CAPTURE_PREAUTHORIZATION function. The amount settled may be less than the amount authorized. An amount higher than the authorized may also be captured but there is no guarantee. It depends on the acquirer whether a higher amount may be captured and how much higher it can be. Please bear in mind that a preauthorization can be captured multiple times depending on the acquiring process and the protocol used to settle the amount. NOTE: Merchants should verify the timeframe for which the acquirer guarantees the reservation of a preauthorized amount on a credit card. In most cases this timeframe is seven (7) days. For reasons of liability in the context of chargebacks, Wirecard, recommends to agree on a timeframe in the acquiring contract. 6.1.1 Preauthorization Request Message The preauthorization request may contain the following elements: Element Sett. Data Type Description W_REQUEST man. c This is a collection of Card Preauthorization message elements and their values. W_JOB man. c This is a collection of elements that defines a job within the request. The job may comprise of multiple transactions. JobID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<JobID> </JobID>) must be provided in the request. Omitting this element will result in a response error. See Appendix J for permissible characters. BusinessCaseSignature man. an..16 This is the unique merchant identifier against which the request is made. FNC_CC_PREAUTHORI ZATION man. c This is a collection of transaction data elements and their values. FunctionID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself ( <FunctionID> </FunctionID>) must be provided in the request. Omitting this element will result in a response error. See Appendix J for permissible characters. 24 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description CC_TRANSACTION man. c This is a collection of transaction data elements and their values. mode opt. an..32 This is the attribute defining the mode of the transaction. Possible values are: demo live TransactionID man. an..32 This is a unique ID associated with a single transaction, which is created by the merchant and submitted as part of the request. See Appendix J for permissible characters. CommerceType opt. an..23 Possible values: ecommerce MOTO CustomerPresent The default setting of this element is ecommerce. If you like to have your CommerceType set to MOTO or CustomerPresent, please contact Wirecard support to have these options activated. Amount con. n..16 This is the integer amount, defined in the smallest currency unit, for which the transaction is requested (e.g., $10.00 = 1000). The <Amount> element is mandatory for Single and Initial transaction types and if the amount of a Repeated (recurring) transaction differs from the amount of the related Initial transaction. For all other recurring transactions, this element is optional. minorunits opt. n..1 This is an attribute of the element <Amount>. It allows merchants to specify the number of decimal places for each transaction amount and currency. action opt. a..8 This is an attribute of the element <Amount>. It defines what action needs to be taken if the value of the attribute <minorunits> does not match the number of decimals defined in ISO standard 4217. The following actions are available: convert The amount is converted to the number of ISO-defined decimals validate The transaction is rejected if the value of <minorunits> does not match the number of decimals defined in ISO 4217. This is the default setting. PaymentGroupID opt. an..22 This optional identifier references transaction types of different payment methods (e.g. credit card and EFT) and represents them in a single group for easy monitoring via the ACM. Version 3.5.0 25

Element (Cont.) Sett. Data Type Description GuWID con. an..22 This is the GuWID of the associated initial transaction. It must be included if the transaction type is Repeated. Currency con. a 3 This is the ISO 4217 currency code used for the transaction. It is mandatory if the type of transaction is Single or Initial or if the currency of a Repeated transaction differs from the currency of the related Initial transaction. CountryCode con. a 2 This is the ISO 3166-1 code of the country where the transaction takes place. It is mandatory if the type of transaction is Single or Initial. Usage opt. an..256 This is the field, which is shown on the customer s card statement and can be used by the merchant for reference purposes. This feature is not supported by all the acquirers. The size of this field depends on the acquirer. Please contact Wirecard technical support for further clarification. RECURRING_TRANSA CTION opt. c This is a collection of recurrent information which simplifies the payment transaction message exchange between merchant and Wirecard. A Recurring Transaction is one that is authorized once by the cardholder for a repeated transaction by the merchant (e.g. monthly membership). This collection must be provided if the transaction is Initial or Repeated. Type man. an..8 Possible values: Single Initial Repeated To use the Recurring Transaction function it is necessary to send the first transaction as type initial (<Type>Initial</Type>) and the followup transaction as type repeated (<Type>Repeated</Type>). For type Single and Initial, CVC2 information (see CVC2 element) may be required. The type Single is used as default if the collection is not provided. CREDIT_CARD_DATA con. c This is a collection of credit card data. It is mandatory if the type of transaction is Single or Initial. CreditCardNumber man. n..20 This is a card number against which purchase is made. CVC2 con. n..4 The 3- or 4-digit security code (called CVC2, CVV2 or CID depending on the credit card brand) that appears on the back of a credit card following the card number. This code does not appear on imprints. 26 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description ExpirationYear man. YYYY The expiry year for the card against which the purchase will be made. ExpirationMonth man. MM The expiry month for the card against which the purchase will be made. CardHolderName man. a..256 Any person who opens a card account and makes purchases using a card. CardStartYear opt. YYYY This is the start year that is required for Switch/Solo/Maestro card only. CardStartMonth opt. MM This is the start month that is required for Switch/Solo/Maestro card only. CardIssueNumber opt. n..2 This is the card issue number as it appears on some Switch/Solo/Maestro cards. CONTACT_DATA opt. c This is the collection of the contact information. IPAddress opt. an..15 This is the IP address of the end user making the purchase. It must be provided in dotdecimal notation consisting of up to 15 characters in length. CORPTRUSTCENTER_ DATA con. c This is a collection of risk management related elements and values. This request level along with the related elements listed below are mandatory if the type of transaction is Single or Initial and additionally the card transaction process is to include a risk validation. ADDRESS man. c This is a collection of cardholder s billing address elements and values. It is highly recommended to provide these elements. This element is mandatory if the CORPTRUSTCENTER_DATA level is to be included in the XML request. FirstName man. an..128 This is the cardholder s first name. LastName man. an..128 This is the cardholder s last name. Address1 man. ans..256 This is the first address field of the cardholder. It is recommended to enter the street name in this field. Address2 opt. ans..256 This is the second address field of the cardholder. It is recommended to enter the street number in this field. City con. an..32 This field shows the city associated with the cardholder. ZipCode opt. an..12 This field shows the cardholder s zip code. State con. a 2 This is the state code is associated with the cardholder s credit card. It must be provided only by US and Canadian merchants accept payments from US or Canadian residents. Country opt. a 2 This is the ISO 3166-1 country code associated with the cardholder. Version 3.5.0 27

Element (Cont.) Sett. Data Type Description Phone opt. an..32 This is the cardholder s phone number. It can be provided in one of the following formats: +xxx(yyy)zzz-zzzz-ppp +xxx (yyy) zzz zzzz ppp +xxx(yyy)zzz/zzzz/ppp +xxx(yyy)zzzzzzzppp where: xxx = country code yyy = national direct dialing prefix zzzzzzz = area / city code and local number ppp = PBX extension Separators such as /, \ or - are permissible. For example, a typical international number would be +44(0)555-5555-739 indicating PBX extension 739 at phone number 555-5555 with the national prefix 0 and country code 44. For countries which do not have a national prefix, the format must be configured with or without a space in brackets. Example: +420()52-5454-742. Email con. an..256 This is the cardholder s email address. PERSONINFO opt. c This is a collection of personal information. It is required by some countries for risk assessment of payment transactions. To avoid a transaction being rejected due to risk, it is recommended to provide this information (especially for the US market). DRIVERS_LICENSE opt. c This field shows a collection of driver license information. LicenseNumber opt. an..32 In this field the debtor s driver license number is entered. State con. a 2 This is the state code is associated with the cardholder s credit card. It must be provided only by US and Canadian merchants accept payments from US or Canadian residents. Country opt. a 2 This is the ISO 3166-1 country code where the license was issued. BirthDate opt. YYYY-MM- This field shows the debtor s birth date. DD TaxIdentificationNumber opt. an..32 This is the debtor s TIN. 28 Version 3.5.0

Card Processing Example: Single / Initial Preauthorization Request <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>Job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_PREAUTHORIZATION> <FunctionID>Preauthorization 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <CommerceType>eCommerce</CommerceType> <Amount minorunits="2">1200</amount> <Currency>EUR</Currency> <CountryCode>DE</CountryCode> <Usage>OrderNo-FT345S71 Thank you</usage> <RECURRING_TRANSACTION> <Type>Initial</Type> </RECURRING_TRANSACTION> <CREDIT_CARD_DATA> <CreditCardNumber>4200000000000000</CreditCardNumber> <CVC2>001</CVC2> <ExpirationYear>2009</ExpirationYear> <ExpirationMonth>01</ExpirationMonth> <CardHolderName>John Doe</CardHolderName> </CREDIT_CARD_DATA> <CONTACT_DATA> <IPAddress>192.168.1.1</IPAddress> </CONTACT_DATA> <CORPTRUSTCENTER_DATA> <ADDRESS> <FirstName>John</FirstName> <LastName>Doe</LastName> <Address1>550 South Winchester blvd.</address1> <Address2>P.O. Box 850</Address2> <City>San Jose</City> <ZipCode>95128</ZipCode> <State>CA</State> <Country>US</Country> <Phone>+1(202)555-1234</Phone> <Email>John.Doe@email.com</Email> </ADDRESS> <PERSONINFO> <DRIVERS_LICENSE> <LicenseNumber>IL213839304</LicenseNumber> <State>IL</State> <Country>US</Country> </DRIVERS_LICENSE> <BirthDate>1967-12-01</BirthDate> <TaxIdentificationNumber>1112223333</TaxIdentificationNumber> </PERSONINFO> </CORPTRUSTCENTER_DATA> </CC_TRANSACTION> </FNC_CC_PREAUTHORIZATION> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Version 3.5.0 29

Example: Repeated Preauthorization Request <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>Job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_PREAUTHORIZATION> <FunctionID>Preauthorization 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <GuWID>C325436112551595096071</GuWID> <RECURRING_TRANSACTION> <Type>Repeated</Type> </RECURRING_TRANSACTION> </CC_TRANSACTION> </FNC_CC_PREAUTHORIZATION> </W_JOB> </W_REQUEST> </WIRECARD_BXML> 30 Version 3.5.0

Card Processing 6.1.2 Preauthorization Successful Response Please refer to Section 6.14 - Standard Response Message for the field definitions of the preauthorization successful response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_PREAUTHORIZATION> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504820</GuWID> <AuthorizationCode>153620</AuthorizationCode> <FunctionResult>ACK</FunctionResult> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_PREAUTHORIZATION> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 6.1.3 Preauthorization Error Response Please refer to Section 6.14 - Standard Response Message for the field definitions of the preauthorization error response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_PREAUTHORIZATION> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504827</GuWID> <AuthorizationCode>799961</AuthorizationCode> <StatusType>INFO</StatusType> <FunctionResult>NOK</FunctionResult> <ERROR> <Type>REJECTED</Type> <Number>05</Number> <Message>Authorization Declined.</Message> <Advice>It is not possible to book the given amount from the credit account, e. g. limit is exceeded.</advice> </ERROR> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_PREAUTHORIZATION> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> Version 3.5.0 31

6.2 Capture Preauthorization A Capture Preauthorization is similar to the Capture Authorization. For a Capture Preauthorization request, a valid GuWID from a former Preauthorization request is required. The amount settled may be less than the amount authorized. The amount remaining on the authorization is available for further captures as long as the authorization period does not expire. Please note that in some cases a pre-authorization can only be captured once. This is dependent of the acquirer policies. An amount higher than the authorized may also be captured but there is no guarantee. It depends on the acquirer whether a greater amount may be captured and how much greater this can be. The recommended value is up to 5% of the original amount. A capture of an authorization transaction (e.g. authorization, preauthorization, preauthorization supplement ) can be made up to 7 days following the original request. In exceptional cases this period may be longer (depending on the acquirer and issuing bank). Please contact Wirecard technical support for further information on the expiration period. 6.2.1 Capture Preauthorization Request Message The capture preauthorization request may contain the following elements: Element Sett. Data Type Description W_REQUEST man. c This is a collection of Card Capture Preauthorization message elements and their values. W_JOB man. c This is a collection of elements that defines a job within the request. The job may comprise of multiple transactions. JobID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<JobID> </JobID>) must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. BusinessCaseSignatu re FNC_CC_CAPTURE_ PREAUTHORIZATION man. an..16 This is the unique merchant identifier against which the request is made. man. c This is a collection of transaction data elements and their values. FunctionID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself ( <FunctionID> </FunctionID>) must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. CC_TRANSACTION man. c This is a collection of transaction data elements and their values. mode opt. an..32 This is the attribute defining the mode of the transaction. Possible values are: demo live 32 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description TransactionID man. an..32 This is a unique ID associated with a single transaction, which is created by the merchant and submitted as part of the request. SalesDate opt. YYYY-MM- DD This is the calendar date of the purchase. It is optional and can be included if the sales date is different from the date the transaction is posted for processing. It can be backdated up to 30 days. PaymentGroupID opt. an..22 This optional identifier references transaction types of different payment methods (e.g. credit card and EFT) and represents them in a single group for easy monitoring via the ACM. GuWID man. an..22 This is the Wirecard transaction ID of the previous Preauthorization request. Amount con. n..16 This is the integer amount, defined in the smallest currency unit, for which the transaction is requested (e.g., $10.00 = 1000). The <Amount> element is mandatory for Single and Initial transaction types and if the amount of a Repeated (recurring) transaction differs from the amount of the related Initial transaction. For all other recurring tranactions, this element is optional. minorunits opt. n..1 This is an attribute of the element <Amount>. It allows merchants to specify the number of decimal places for each transaction amount and currency. action opt. a..8 This is an attribute of the element <Amount>. It defines what action needs to be taken if the value of the attribute <minorunits> does not match the number of decimals defined in ISO standard 4217. The following actions are available: convert The amount is converted to the number of ISO-defined decimals validate The transaction is rejected if the value of <minorunits> does not match the number of decimals defined in ISO 4217. This is the default setting. CountryCode con. a 2 This is the ISO 3166-1 code of the country where the transaction takes place. It is conditional meaning that it must be added if this parameter is included in the corresponding Authorization /Preauthorization. Also, the country must be identical with the country mentioned in the corresponding Authorization /Preauthorization. NOTE: For some acquirers this is a mandatory request field. Version 3.5.0 33

Element (Cont.) Sett. Data Type Description Usage opt. an..256 This is the field, which is shown on the customer s card statement and can be used by the merchant for reference purposes. The usage field for the capture overrides the field value provided with the authorization. This feature is not supported by all the acquirers. The size of this field depends on the acquirer. Please contact Wirecard technical support for further clarification. COST_CENTER_DAT A opt. c This is a collection of the cost center data of an organization. EmployeeID opt. an..17 This request element helps identify the employee. DepartmentCode opt. an..17 This code describes the organization s department. CostAccountNumber opt. an..17 This field is reserved for the number defining the cost account. AccountingUnit opt. an..17 This element is reserved for accounting units. AccountNumber opt. an..17 This field shows the account number. ServiceDate opt. YYYY-MM- DD This field shows the date the service is provided (departure date), e.g. 2006-10-14. ProjectNumber opt. an..17 This is the number of the project. OrderNumber opt. an..17 This is the order number. ActionNumber opt. an..32 This is the action number. Destination opt. an..17 This element defines the travel destination. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_CAPTURE_PREAUTHORIZATION> <FunctionID>capturing 1</FunctionID> <CC_TRANSACTION mode= demo > <TransactionID>9457892347623478</TransactionID> <SalesDate>2007-04-30</SalesDate> <GuWID>C242720181323966504820</GuWID> <Amount minorunits="2">600</amount> <Usage>OrderNo-FT345S71 Thank you</usage> <COST_CENTER_DATA> <CostAccountNumber>78500</CostAccountNumber> <ServiceDate>2006-12-17</ServiceDate> </COST_CENTER_DATA> </CC_TRANSACTION> </FNC_CC_CAPTURE_PREAUTHORIZATION> </W_JOB> </W_REQUEST> </WIRECARD_BXML> 34 Version 3.5.0

Card Processing 6.2.2 Capture Preauthorization Successful Response Please refer to Section 6.14 - Standard Response Message for the field definitions of the capture preauthorization successful response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_CAPTURE_PREAUTHORIZATION> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504820</GuWID> <FunctionResult>PENDING</FunctionResult> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_CAPTURE_PREAUTHORIZATION> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 6.2.3 Capture Preauthorization Error Response Please refer to Section 6.14 - Standard Response Message for the field definitions of the capture preauthorization error response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_CAPTURE_PREAUTHORIZATION> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504827</GuWID> <StatusType>INFO</StatusType> <FunctionResult>NOK</FunctionResult> <ERROR> <Type>REJECTED</Type> <Number>21</Number> <Message>No action taken.</message> </ERROR> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_CAPTURE_PREAUTHORIZATION> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> Version 3.5.0 35

6.3 Preauthorization Supplement The preauthorization supplement function enables the user to upwardly alter the amount reserved on a card by a previous preauthorization or preauthorization supplement. A preauthorization supplement request requires a valid GuWID and acquirer Authorization Code from a former preauthorization request. Please note that this transaction type is not supported by all acquirers and that it can only be captured once. 6.3.1 Preauthorization Supplement Request Message The preauthorization supplement request may contain the following elements: Element Sett. Data Type Description W_REQUEST man. c This is a collection of Credit Card Preauthorization Supplement message elements and their values. W_JOB man. c This is a collection of elements that defines a job within the request. The job may comprise of multiple transactions. JobID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<JobID> </JobID>) must be provided in the request. Omitting the element will result in a response error. See Appendix J for permissible characters. BusinessCaseSignatur e FNC_CC_PREAUTHO RIZATION_SUPPLEME NT man. an..16 This is the unique merchant identifier against which the request is made. man. c This is a collection of transaction data elements and their values. FunctionID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself ( <FunctionID> </FunctionID>) must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. CC_TRANSACTION man. c This is a collection of transaction data elements and their values. mode opt. an..32 This is the attribute defining the mode of the transaction. Possible values are: demo live TransactionID man. an..32 This is a unique ID associated with a single transaction, which is created by the merchant and submitted as part of the request. 36 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description PaymentGroupID opt. an..22 This optional identifier references transaction types of different payment methods (e.g. credit card and EFT) and represents them in a single group for easy monitoring via the ACM. GuWID man. an.. 22 This is the Wirecard transaction ID associated with the previous Preauthorization or Preauthorization Supplement transaction. Amount man. n..16 This is the integer amount, defined in the smallest currency unit, for which the transaction is requested (e.g., $10.00 = 1000). minorunits opt. n..1 This is an attribute of the element <Amount>. It allows merchants to specify the number of decimal places for each transaction amount and currency. action opt. a..8 This is an attribute of the element <Amount>. It defines what action needs to be taken if the value of the attribute <minorunits> does not match the number of decimals defined in ISO standard 4217. The following actions are available: convert The amount is converted to the number of ISO-defined decimals validate The transaction is rejected if the value of <minorunits> does not match the number of decimals defined in ISO 4217. This is the default setting. CONTACT_DATA opt. c This is the collection of the contact information. IPAddress opt. an..15 This is the IP address of the end user making the purchase. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_PREAUTHORIZATION_SUPPLEMENT> <FunctionID>supplement 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <GuWID>C242720181323966504820</GuWID> <Amount minorunits="2">500</amount> <CONTACT_DATA> <IPAddress>192.168.1.1</IPAddress> </CONTACT_DATA> </CC_TRANSACTION> </FNC_CC_PREAUTHORIZATION_SUPPLEMENT> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Version 3.5.0 37

6.3.2 Preauthorization Supplement Successful Response Please refer to Section 6.14 - Standard Response Message for the field definitions of the preauthorization supplement successful response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_PREAUTHORIZATION_SUPPLEMENT> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504820</GuWID> <AuthorizationCode>153620</AuthorizationCode> <FunctionResult>ACK</FunctionResult> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_PREAUTHORIZATION_SUPPLEMENT> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 6.3.3 Preauthorization Supplement Error Response Please refer to Section 6.14 - Standard Response Message for the field definitions of the preauthorization supplement error response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_PREAUTHORIZATION_SUPPLEMENT> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504827</GuWID> <AuthorizationCode>799961</AuthorizationCode> <StatusType>INFO</StatusType> <FunctionResult>NOK</FunctionResult> <ERROR> <Type>REJECTED</Type> <Number>05</Number> <Message>Authorization Declined.</Message> <Advice>It is not possible supplement the original authorization, e. g. limit is exceeded.</advice> </ERROR> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_PREAUTHORIZATION_SUPPLEMENT> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 38 Version 3.5.0

Card Processing 6.4 Capture Preauthorization Supplement The capture preauthorization supplement function enables the user to capture a previously preauthorized and later upwardly altered amount by the function preauthorization supplement. To capture a former preauthorization supplement request, a valid GuWID from the respective preauthorization supplement process is required. A capture of an authorization transaction (e.g. authorization, preauthorization, preauthorization supplement ) can be made up to 7 days following the original request. In exceptional cases this period may be longer (depending on the acquirer and issuing bank). Please contact Wirecard technical support for further information on the expiration period. After a successful capturing process the previous preauthorization and preauthorization supplement are closed. 6.4.1 Capture Preauthorization Supplement Request Message The capture preauthorization supplement request may contain the following elements: Element Sett. Data Type Description W_REQUEST man. c This is a collection of Card Capture Preauthorization Supplement message elements and their values. W_JOB man. c This is a collection of elements that defines a job within the request. The job may comprise of multiple transactions. JobID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<JobID> </JobID>) must be provided in the request. Omitting the element will result in a response error. See Appendix J for permissible characters. BusinessCaseSignat ure FNC_CC_CAPTURE _PREAUTHORIZATI ON_SUPPLEMENT man. an..16 This is the unique merchant identifier against which the request is made. man. c This is a collection of transaction data elements and their values. FunctionID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<FunctionID> </FunctionID>) must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. CC_TRANSACTION man. c This is a collection of transaction data elements and their values. mode opt. an..32 This is the attribute defining the mode of the transaction. Possible values are: demo live Version 3.5.0 39

Element (Cont.) Sett. Data Type Description TransactionID man. an..32 This is a unique ID associated with a single transaction, which is created by the merchant and submitted as part of the request. SalesDate opt. YYYY-MM- DD This is the calendar date of the purchase. It is optional and can be included if the sales date is different from the date the transaction is posted for processing. It can be backdated up to 30 days. PaymentGroupID opt. an..22 This optional identifier references transaction types of different payment methods (e.g. credit card and EFT) and represents them in a single group for easy monitoring via the ACM. GuWID man. an.. 22 This is the Wirecard transaction ID of the original Preauthorization Supplement transaction. Amount con. n..16 This is the integer amount, defined in the smallest currency unit, for which the transaction is requested (e.g., $10.00 = 1000). The element is mandatory the captured amount is not equal to the authorized amount. Otherwise it is optional. minorunits opt. n..1 This is an attribute of the element <Amount>. It allows merchants to specify the number of decimal places for each transaction amount and currency. action opt. a..8 This is an attribute of the element <Amount>. It defines what action needs to be taken if the value of the attribute <minorunits> does not match the number of decimals defined in ISO standard 4217. The following actions are available: convert The amount is converted to the number of ISO-defined decimals validate The transaction is rejected if the value of <minorunits> does not match the number of decimals defined in ISO 4217. This is the default setting. CountryCode con. a 2 This is the ISO 3166-1 code of the country where the transaction takes place. It is conditional meaning that it must be added if this parameter is included in the corresponding Authorization /Preauthorization. Also, the country must be identical with the country mentioned in the corresponding Authorization /Preauthorization. NOTE: For some acquirers this is a mandatory request field. 40 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description Usage opt. an..256 This is the field, which is shown on the customer s card statement and can be used by the merchant for reference purposes. The usage field for the capture overrides the field value provided with the authorization. This feature is not supported by all the acquirers. The size of this field depends on the acquirer. Please contact Wirecard technical support for further clarification. COST_CENTER_DA TA opt. c This is a collection of the cost center data of an organization. EmployeeID opt. an..17 This request element helps identify the employee. DepartmentCode opt. an..17 This code describes the organization s department. CostAccountNumber opt. an..17 This field is reserved for the number defining the cost account. AccountingUnit opt. an..17 This element is reserved for accounting units. AccountNumber opt. an..17 This field shows the account number. ServiceDate opt. YYYY-MM- DD This field shows the date the service is provided (departure date), e.g. 2006-10-14. ProjectNumber opt. an..17 This is the number of the project. OrderNumber opt. an..17 This is the order number. ActionNumber opt. an..32 This is the action number. Destination opt. an..17 This element defines the travel destination. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_CAPTURE_PREAUTHORIZATION_SUPPLEMENT> <FunctionID>capturing supplement 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <SalesDate>2007-04-30</SalesDate> <GuWID>C242720181323966504820</GuWID> <Amount minorunits="2">1000</amount> <Usage>OrderNo-FT345S71 Thank you</usage> <COST_CENTER_DATA> <CostAccountNumber>78500</CostAccountNumber> <ServiceDate>2006-12-17</ServiceDate> </COST_CENTER_DATA> </CC_TRANSACTION> </FNC_CC_CAPTURE_PREAUTHORIZATION_SUPPLEMENT> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Version 3.5.0 41

6.4.2 Capture Preauthorization Supplement Successful Response Please refer to Section 6.14 - Standard Response Message for the field definitions of the capture preauthorization supplement successful response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_CAPTURE_PREAUTHORIZATION_SUPPLEMENT> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504820</GuWID> <FunctionResult>PENDING</FunctionResult> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_CAPTURE_PREAUTHORIZATION_SUPPLEMENT> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 42 Version 3.5.0

Card Processing 6.4.3 Capture Preauthorization Supplement Error Response Please refer to Section 6.14 - Standard Response Message for the field definitions of the capture preauthorization supplement error response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_CAPTURE_PREAUTHORIZATION_SUPPLEMENT> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504827</GuWID> <StatusType>INFO</StatusType> <FunctionResult>NOK</FunctionResult> <ERROR> <Type>REJECTED</Type> <Number>21</Number> <Message>No action taken.</message> </ERROR> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_CAPTURE_PREAUTHORIZATION_SUPPLEMENT> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> Version 3.5.0 43

6.5 Authorization During a card authorization, the transaction information is sent to Wirecard, which in turn sends the information to the cardholder s issuing financial institution. An Authorization is not a guarantee of payment. It only confirms that the card exists and that funds are available at the time of Authorization to cover a purchase amount. The funds are not credited at this time but the Authorization reduces the available credit limit for that card, so in a sense the funds are reserved for the purchase. Every card authorization request has a time limit set by the card provider. Typically, the limit ranges from three to twenty-one days. It is recommended to check with the card provider for details. If a card authorization expires before the settlement request is sent, Settlement may be denied if the cardholder s Credit limit is reached, or you may be charged a higher rate for the transaction, in line with the terms of service of the credit card company. Visa may also charge you a higher rate if a Settlement request is received more than seven days after an Authorization request. In most cases, it is safe to assume that an authorization remains valid for a period of seven days. Many merchants try to limit the time between authorization and settlement to seven days, in order to minimize settlement problems. While this is a good policy, it is not a definitive rule. Policies and rates vary between cards and financial institutions, and this information is not included in the authorization response. It is up to you to be aware of the possible consequences and decide how to handle them. The reserved amount can be settled later by a Capture request (Capture Authorization). If both the Authorization request and the Capture Request are processed in realtime, the captured amount must be identical to the amount authorized. 6.5.1 Authorization Request Message The authorization request may contain the following elements: Element Sett. Data Type Description W_REQUEST man. c This is a collection of card authorization message elements and their values. W_JOB man. c This is a collection of elements that defines a job within the request. The job may comprise of multiple transactions. JobID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<JobID> </JobID>) must be provided in the request. Omitting this element will result in a response error. See Appendix J for permissible characters. BusinessCaseSignature man. an..16 This is the unique merchant identifier against which the request is made. FNC_CC_AUTHORIZATI ON man. c This is a collection of transaction data elements and their values. 44 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description FunctionID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself ( <FunctionID> </FunctionID>) must still be provided in the XML request. Omitting this element will result in a response error. See Appendix J for permissible characters. CC_TRANSACTION man. c This is a collection of transaction data elements and their values. mode opt. an..32 This is the attribute defining the mode of the transaction. Possible values are: demo live TransactionID man. an..32 This is a unique ID associated with a single transaction, which is created by the merchant and submitted as part of the request. CommerceType opt. an..23 Possible values: ecommerce MOTO CustomerPresent The default setting of this element is ecommerce. If you like to have your CommerceType set to MOTO or CustomerPresent, please contact Wirecard support to have these options activated. PaymentGroupID opt. an..22 This optional identifier references transaction types of different payment methods (e.g. credit card and direct debit) and represents them in a single group for easy monitoring via the ACM. GuWID con. an..22 This is the GuWID of the associated initial transaction. It is mandatory if the transaction type is Repeated. Amount con. n..16 This is the integer amount, defined in the smallest currency unit, for which the transaction is requested (e.g., $10.00 = 1000). The <Amount> element is mandatory for Single and Initial transaction types and if the amount of a Repeated (recurring) transaction differs from the amount of the related Initial transaction. For all other recurring transactions, this element is optional. minorunits opt. n..1 This is an attribute of the element <Amount>. It allows merchants to specify the number of decimal places for each transaction amount and currency. Version 3.5.0 45

Element (Cont.) Sett. Data Type Description action opt. a..8 This is an attribute of the element <Amount>. It defines what action needs to be taken if the value of the attribute <minorunits> does not match the number of decimals defined in ISO standard 4217. The following actions are available: convert The amount is converted to the number of ISO-defined decimals validate The transaction is rejected if the value of <minorunits> does not match the number of decimals defined in ISO 4217. This is the default setting. Currency con. a 3 This is the ISO 4217 currency code used for the transaction. It is mandatory if the type of transaction is Single or Initial or if the currency of a Repeated transaction differs from the currency of the related Initial transaction. CountryCode con. a 2 This is the ISO 3166-1 code of the country where the transaction takes place. It is mandatory if the type of transaction is Single or Initial. Usage opt. an..256 This is the field, which is shown on the customer s card statement and can be used by the merchant for reference purposes. This feature is not supported by all the acquirers. The size of this field depends on the acquirer. Please contact Wirecard technical support for further clarification. RECURRING_TRANSAC TION opt. c This is a collection of recurrent information which simplifies the payment transaction message exchange between merchant and Wirecard. A Recurring Transaction is one that is authorized once by the cardholder for a repeated transaction by the merchant (e.g. monthly membership). This collection must be provided if the transaction is Initial or Repeated. Type man. an..8 Possible values: Single Initial Repeated To use the Recurring Transaction function it is necessary to send the first transaction as type initial (<Type>Initial</Type>) ) and the follow-up transaction as type repeated (<Type>Repeated</Type>). For type Single and Initial, CVC2 information (see CVC2 element) may be required. The type Single is used as default if the collection is not provided. 46 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description CREDIT_CARD_DATA con. c This is a collection of credit card data. It is mandatory if the type of transaction is Single or Initial. CreditCardNumber man. n..20 This is a card number against which purchase is made. CVC2 con. n..4 The 3- or 4-digit security code (called CVC2, CVV2 or CID depending on the card brand) that appears on the back of a credit card following the credit card number. This code does not appear on imprints. ExpirationYear man. YYYY The expiry year for the card against which the purchase will be made. ExpirationMonth man. MM The expiry month for the card against which the purchase will be made. CardHolderName man. a..256 Any person who opens a card account and makes purchases using a card. CardStartYear opt. YYYY This is the start year that is required for Switch/Solo/Maestro card only. CardStartMonth opt. MM This is the start month that is required for Switch/Solo/Maestro card only. CardIssueNumber opt. n..2 This is the card issue number as it appears on some Switch/Solo/Maestro cards. CONTACT_DATA opt. c This is the collection of the contact information. IPAddress opt. an..15 This is the IP address of the end user making the purchase. It must be provided in dot-decimal notation consisting of up to 15 characters in length. CORPTRUSTCENTER_ DATA con. c This is a collection of risk management related elements and values. This request level along with the related elements listed below are mandatory if the type of transaction is Single or Initial and additionally the card transaction process is to include a risk validation. ADDRESS man. c This is a collection of cardholder s billing address elements and values. It is highly recommended to provide these elements. This element is mandatory if the CORPTRUSTCENTER_DATA level is to be included in the XML request. FirstName man. an..128 This is the cardholder s first name. LastName man. an..128 This is the cardholder s last name. Address1 man. ans..256 This is the first address field of the cardholder. It is recommended to enter the street name in this field. Address2 opt. ans..256 This is the second address field of the cardholder. It is recommended to enter the street number in this field. Version 3.5.0 47

Element (Cont.) Sett. Data Type Description City con. an..32 This field shows the city associated with the cardholder. ZipCode opt. an..12 This field shows the cardholder s zip code. State con. a 2 This is the state code is associated with the cardholder s credit card. It must be provided only by US and Canadian merchants accept payments from US or Canadian residents. Country opt. a 2 This is the ISO 3166-1 country code associated with the cardholder. Phone opt. an..32 This is the cardholder s phone number. It can be provided in one of the following formats: +xxx(yyy)zzz-zzzz-ppp +xxx (yyy) zzz zzzz ppp +xxx(yyy)zzz/zzzz/ppp +xxx(yyy)zzzzzzzppp where: xxx = country code yyy = national direct dialing prefix zzzzzzz = area / city code and local number ppp = PBX extension Separators such as /, \ or - are permissible. For example, a typical international number would be +44(0)555-5555-739 indicating PBX extension 739 at phone number 555-5555 with the national prefix 0 and country code 44. For countries which do not have a national prefix, the format must be configured with or without a space in brackets. Example: +420()52-5454-742. Email con. an..256 This is the cardholder s email address. PERSONINFO opt. c This is a collection of personal information. It is required by some countries for risk assessment of payment transactions. To avoid a transaction being rejected due to risk, it is recommended to provide this information (especially for the US market). DRIVERS_LICENSE opt. c This field shows a collection of driver license information. LicenseNumber opt. an..32 In this field the debtor s driver license number is entered. State con. a 2 This is the state code is associated with the cardholder s credit card. It must be provided only by US and Canadian merchants accept payments from US or Canadian residents. Country opt. a 2 This is the ISO 3166-1 country code where the license was issued. BirthDate opt. YYYY-MM-DD This field shows the debtor s birth date. TaxIdentificationNumber opt. an..32 This is the debtor s TIN. 48 Version 3.5.0

Card Processing Example: Single / Initial Authorization Request <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_AUTHORIZATION> <FunctionID>authorization 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <CommerceType>eCommerce</CommerceType> <Amount minorunits="2">500</amount> <Currency>EUR</Currency> <CountryCode>DE</CountryCode> <Usage>OrderNo-FT345S71 Thank you</usage> <RECURRING_TRANSACTION> <Type>Initial</Type> </RECURRING_TRANSACTION> <CREDIT_CARD_DATA> <CreditCardNumber>4200000000000000</CreditCardNumber> <CVC2>001</CVC2> <ExpirationYear>2009</ExpirationYear> <ExpirationMonth>01</ExpirationMonth> <CardHolderName>John Doe</CardHolderName> </CREDIT_CARD_DATA> <CONTACT_DATA> <IPAddress>192.168.1.1</IPAddress> </CONTACT_DATA> <CORPTRUSTCENTER_DATA> <ADDRESS> <FirstName>John</FirstName> <LastName>Doe</LastName> <Address1>550 South Winchester blvd.</address1> <Address2>P.O. Box 850</Address2> <City>San Jose</City> <ZipCode>95128</ZipCode> <State>CA</State> <Country>US</Country> <Phone>+1(202)555-1234</Phone> <Email>John.Doe@email.com</Email> </ADDRESS> <PERSONINFO> <DRIVERS_LICENSE> <LicenseNumber>IL213839304</LicenseNumber> <State>IL</State> <Country>US</Country> </DRIVERS_LICENSE> <BirthDate>1967-12-01</BirthDate> <TaxIdentificationNumber>1112223333</TaxIdentificationNumber> </PERSONINFO> </CORPTRUSTCENTER_DATA> </CC_TRANSACTION> </FNC_CC_AUTHORIZATION> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Version 3.5.0 49

Example: Repeated Authorization Request <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_AUTHORIZATION> <FunctionID>authorization 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <GuWID>C328668112556109425394</GuWID> <RECURRING_TRANSACTION> <Type>Repeated</Type> </RECURRING_TRANSACTION> </CC_TRANSACTION> </FNC_CC_AUTHORIZATION> </W_JOB> </W_REQUEST> </WIRECARD_BXML> 6.5.2 Authorization Successful Response (1) Please refer to Section 6.15 - Standard Response Message for the field definitions of the authorization successful response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_AUTHORIZATION> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504820</GuWID> <AuthorizationCode>153620</AuthorizationCode> <FunctionResult>ACK</FunctionResult> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_AUTHORIZATION> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 50 Version 3.5.0

Card Processing 6.5.3 Authorization Successful Response (2) Please refer to Section 6.15 - Standard Response Message for the field definitions of the authorization successful response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_AUTHORIZATION> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504820</GuWID> <AuthorizationCode>153620</AuthorizationCode> <FunctionResult>ACK</FunctionResult> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_AUTHORIZATION> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 6.5.4 Authorization Error Response Please refer to Section 6.15 - Standard Response Message for the field definitions of the authorization error response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_AUTHORIZATION> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504827</GuWID> <AuthorizationCode>799961</AuthorizationCode> <StatusType>INFO</StatusType> <FunctionResult>NOK</FunctionResult> <ERROR> <Type>REJECTED</Type> <Number>05</Number> <Message>Authorization Declined.</Message> <Advice>It is not possible to book the given amount from the credit account, e. g. limit is exceeded.</advice> </ERROR> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_AUTHORIZATION> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> Version 3.5.0 51

6.6 Authorization Check Wirecard also supports the transaction type FNC_CC_AUTHORIZATION_CHECK. In addition to the default Luhn Check, an algorithm which verifies a credit card number against its check digit, the Authorization Check allows merchants to validate credit cards used in online transactions in real-time against the database of the card issuing bank. This transaction request type cannot be sent with the transaction mode type initial available with recurring transactions and installment transactions. The Authorization Check is almost identical to the Authorization request described in the previous section. The only thing that sets it apart from a standard Authorization is that the amount specified in this check request is not reserved for a later Capture Authorization but automatically reversed. As the name indicates, an Authorization Check is a verification of the credit card only and does not replace the standard Authorization request. NOTE: It is not permitted to perform standalone Authorization Checks. This transaction type is accepted only in connection with a subsequent Preauthorization, Authorization or Purchase. 6.6.1 Request An Authorization Check contains the same XML parameters as an Authorization request with the exception of the functionality element collection FNC_CC_AUTHORIZATION_CHECK. For a complete listing see Section 6.5.1. Element Sett. Data Type Description BusinessCaseSignature man. an..16 Same as standard Authorization request. FNC_CC_AUTHORIZATI ON_CHECK man. c This is a collection of transaction data elements and their values which can be used for real-time card validation. Example: Authorization Check Request <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>ACCEPTANCE-TEST</JobID> <BusinessCaseSignature>790</BusinessCaseSignature> <FNC_CC_AUTHORIZATION_CHECK> <FunctionID>test</FunctionID> <CC_TRANSACTION> <TransactionID>1</TransactionID> <CommerceType>eCommerce</CommerceType> <Amount>1000</Amount> <Currency>EUR</Currency> <CountryCode>DE</CountryCode> <CREDIT_CARD_DATA> <CreditCardNumber>1234****0001</CreditCardNumber> <CVC2>***</CVC2> <ExpirationYear>2009</ExpirationYear> <ExpirationMonth>12</ExpirationMonth> <CardHolderName>Joe Test</CardHolderName> </CREDIT_CARD_DATA> </CC_TRANSACTION> </FNC_CC_AUTHORIZATION_CHECK> </W_JOB> </W_REQUEST> 52 Version 3.5.0

Card Processing 6.6.2 Response </WIRECARD_BXML> The response message and the response codes are identical with those of a standard Authorization. Error Code Description Meaning 0 Successful system entry. Transaction OK 2 Call Voice Authorization Number. Voice authorization is not possible with online (Internet) transactions. 3 Invalid Merchant Number. The merchant number provided is wrong. 4 Retain Card. The card should be retained (not possible with online transactions). 5 Authorization Declined. It is not possible to book the given amount from the cedit card account (e.g. the limit may be exceeded). For a complete list of errors codes see Appendix A Version 3.5.0 53

6.7 Capture Authorization Wirecard supports two types of Capture Authorization, one which is related to a previous authorization of the captured amount (i.e. a capture request message which contains a reference to the initial Authorization request), and one which has no connection to a previous authorization and is therefore sent without reference in the XML code. After an order is shipped, the transaction can be settled. The capture process completes the transaction. The card issuing bank credits the funds to the merchant s bank account and updates the cardholder s statement. Card regulations require a merchant to ship goods before settling the funds for an order. As a result, online card transactions are handled in two p Authorization and Capture. These are time-separated processes because it takes time to prepare goods for shipment. A Capture Authorization request must include a valid GuWID referencing the previous Authorization request. The transaction amount which is to be captured must be identical to the amount authorized, if both transaction types are processed in real-time. This is different when a Capture Authorization request is posted to a scheduled batch process. Amounts captured by a time-delayed process (batch processing) may be less than the amount originally authorized. (see the Referenced Capture Authorization in the technical specification Card Batch Processing). The authorized amount remaining is still available for capture at a later stage, provided the authorization period is not exceeded. Please note that in some cases an authorization can only be captured once. This is dependent on the acquirer policies. In case of an online capture, the amount must be equal to the previously authorized amount. A capture of an authorization transaction (including preauthorization and preauthorization supplement) can be made up to 7 days following the original request. In exceptional cases this period may be longer (depending on the acquirer and issuing bank). Please contact Wirecard technical support for further information on the expiration period. 6.7.1 Capture Authorization Request Message The capture authorization request may contain the following elements: Element Sett. Data Type Description W_REQUEST man. c This is a collection of card capture authorization message elements and their values. W_JOB man. c This is a collection of elements that defines a job within the request. The job may comprise of multiple transactions. JobID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<JobID> </JobID>) must be provided in the request. Omitting this element will result in a response error. See Appendix J for permissible characters. BusinessCaseSignatur e FNC_CC_CAPTURE_A UTHORIZATION man. an..16 This is the unique merchant identifier against which the request is made. man. c This is a collection of transaction data elements and their values. 54 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description FunctionID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (FunctionID> </FunctionID>) must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. CC_TRANSACTION man. c This is a collection of transaction data elements and their values. mode opt. an..32 This is the attribute defining the mode of the transaction. Possible values are: demo live TransactionID man. an..32 This is a unique ID associated with a single transaction, which is created by the merchant and submitted as part of the request. SalesDate opt. YYYY-MM- DD This is the calendar date of the purchase. It is optional and can be included if the sales date is different from the date the transaction is posted for processing. It can be backdated up to 35 days. PaymentGroupID opt. an..22 This optional identifier references transaction types of different payment methods (e.g. credit card and EFT) and represents them in a single group for easy monitoring via the ACM. GuWID man. an..22 This is the Wirecard transaction ID of the previous Authorization. Amount con. n..16 This is the integer amount, defined in smallest currency unit, for which the transaction is requested (e.g., $10.00 = 1000). The element is mandatory if the captured amount is not equal to the authorized amount. Otherwise it is optional. minorunits opt. n..1 This is an attribute of the element <Amount>. It allows merchants to specify the number of decimal places for each transaction amount and currency. action opt. a..8 This is an attribute of the element <Amount>. It defines what action needs to be taken if the value of the attribute <minorunits> does not match the number of decimals defined in ISO standard 4217. The following actions are available: convert The amount is converted to the number of ISO-defined decimals validate The transaction is rejected if the value of <minorunits> does not match the number of decimals defined in ISO 4217. This is the default setting. Version 3.5.0 55

Element (Cont.) Sett. Data Type Description CountryCode con. a 2 This is the ISO 3166-1 code of the country where the transaction takes place. It is conditional meaning that it must be added if this parameter is included in the corresponding Authorization /Preauthorization. Also, the country must be identical with the country mentioned in the corresponding Authorization /Preauthorization. NOTE: For some acquirers this is a mandatory request field. Usage opt. an..256 This is the field, which is shown on the customer s card statement and can be used by the merchant for reference purposes. The usage field for the capture overrides the field value provided with the authorization. This feature is not supported by all the acquirers. The size of this field depends on the acquirer. Please contact Wirecard technical support for further clarification. COST_CENTER_DATA opt. c This is a collection of the cost center data of an organization. EmployeeID opt. an..17 This request element helps identify the employee. DepartmentCode opt. an..17 This code describes the organization s department. CostAccountNumber opt. an..17 This field is reserved for the number defining the cost account. AccountingUnit opt. an..17 This element is reserved for accounting units. AccountNumber opt. an..17 This field shows the account number. ServiceDate opt. YYYY-MM- DD This field shows the date the service is provided (departure date), e.g. 2006-10-14. ProjectNumber opt. an..17 This is the number of the project. OrderNumber opt. an..17 This is the order number. ActionNumber opt. an..32 This is the action number. Destination opt. an..17 This element defines the travel destination. 56 Version 3.5.0

Card Processing Example: Capture Authorization Request Message <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_CAPTURE_AUTHORIZATION> <FunctionID>capture 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <SalesDate>2007-04-30</SalesDate> <GuWID>C242720181323966504820</GuWID> <Amount minorunits="2">1000</amount> <Usage>OrderNo-FT345S71 Thank you</usage> <COST_CENTER_DATA> <CostAccountNumber>78500</CostAccountNumber> <ServiceDate>2006-12-17</ServiceDate> </COST_CENTER_DATA> </CC_TRANSACTION> </FNC_CC_CAPTURE_AUTHORIZATION> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Version 3.5.0 57

6.7.2 Capture Authorization Successful Response Please refer to Section 6.15 - Standard Response Message for the field definitions of the capture authorization successful response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>ACCEPTANCE_TEST</JobID> <FNC_CC_CAPTURE_AUTHORIZATION> <FunctionID>CITI-KAAI</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>8</TransactionID> <PROCESSING_STATUS> <GuWID>C305830112714411123351</GuWID> <StatusType>INFO</StatusType> <FunctionResult>PENDING</FunctionResult> <TimeStamp>2005-09-19 17:32:22</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_CAPTURE_AUTHORIZATION> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 6.7.3 Capture Authorization Error Response Please refer to Section 6.15 - Standard Response Message for the field definitions of the capture authorization error response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_CAPTURE_AUTHORIZATION> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504827</GuWID> <StatusType>INFO</StatusType> <FunctionResult>NOK</FunctionResult> <ERROR> <Type>REJECTED</Type> <Number>21</Number> <Message>No action taken.</message> </ERROR> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_CAPTURE_AUTHORIZATION> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 58 Version 3.5.0

Card Processing 6.8 Purchase A purchase request both authorizes and settles the requested amount against the card indicated. Through authorizing, the Transaction request confirms that the card exists and that funds are available at the time of Authorization to cover the transaction amount. The funds are not credited at this time but the Authorization reduces the available credit limit for that card, so in a sense the funds are reserved for the purchase. Through settlement, the purchase request completes the transaction - the issuing financial institution credits the merchant s bank account with the funds for the purchase and updates the cardholder s statement. NOTE: It is not permitted to perform standalone Authorization Checks. They are accepted only in connection with a subsequent Preauthorization, Authorization, Capture or Purchase transaction. 6.8.1 Purchase Request Message The purchase request may contain the following elements: Element Sett. Data Type Description W_REQUEST man. c This is a collection of Card Transaction message elements and their values. W_JOB man. c This is a collection of elements that defines a job within the request. The job may comprise of multiple transactions. JobID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<JobID> </JobID>) must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. BusinessCaseSigna ture FNC_CC_PURCHA SE man. an..16 This is the unique merchant identifier against which the request is made. man. c This is a collection of transaction data elements and their values. FunctionID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<FunctionID> </FunctionID>) must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. CC_TRANSACTIO N man. c This is a collection of transaction data elements and their values. mode opt. an..32 This is the attribute defining the mode of the transaction. Possible values are: demo live Version 3.5.0 59

Element (Cont.) Sett. Data Type Description TransactionID man. an..32 This is a unique ID associated with a single transaction, which is created by the merchant and submitted as part of the request. See Appendix J for permissible characters. SalesDate opt. YYYY-MM- DD This is the calendar date of the purchase. It is optional and can be included if the sales date is different from the date the transaction is posted for processing. It can be backdated up to 30 days. CommerceType opt. an..23 Possible values are: ecommerce MOTO CustomerPresent The default setting of this element is ecommerce. If you like to have your CommerceType set to MOTO or CustomerPresent, please contact Wirecard support to have these options activated. Amount con. n..16 This is the integer amount, defined in the smallest currency unit, for which the transaction is requested (e.g., $10.00 = 1000). The <Amount> element is mandatory for Single and Initial transaction types and if the amount of a Repeated (recurring) transaction differs from the amount of the related Initial transaction. For all other recurring transactions, this element is optional. minorunits opt. n..1 This is an attribute of the element <Amount>. It allows merchants to specify the number of decimal places for each transaction amount and currency. action opt. a..8 This is an attribute of the element <Amount>. It defines what action needs to be taken if the value of the attribute <minorunits> does not match the number of decimals defined in ISO standard 4217. The following actions are available: convert The amount is converted to the number of ISOdefined decimals validate The transaction is rejected if the value of <minorunits> does not match the number of decimals defined in ISO 4217. This is the default setting. PaymentGroupID opt. an..22 This optional identifier references transaction types of different payment methods (e.g. credit card and EFT) and represents them in a single group for easy monitoring via the ACM. GuWID con. an..22 This is the GuWID of an associated initial transaction. It is mandatory if the transaction type is Repeated. 60 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description Currency con. a 3 This is the ISO 4217 currency code used for the transaction. It is mandatory if the type of transaction is Single or Initial or if the currency of a Repeated transaction differs from the currency of the related Initial transaction. CountryCode con. a 2 This is the ISO 3166-1 code of the country where the transaction takes place. It is mandatory if the type of transaction is Single or Initial. Usage opt. an..256 This is the field, which is shown on the customer s card statement and can be used by the merchant for reference purposes. This feature is not supported by all the acquirers. The size of this field depends on the acquirer. Please contact Wirecard technical support for further clarification. RECURRING_TRA NSACTION opt. c This is a collection of recurrent information which simplifies the payment transaction message exchange between merchant and Wirecard. A Recurring Transaction is one that is authorized once by the cardholder for a repeated transaction by the merchant (e.g. monthly membership). This collection must be provided if the transaction is Initial or Repeated. Type man. an..8 Possible values: Single Initial Repeated To use the Recurring Transaction function it is necessary to send the first transaction as type initial (<Type>Initial</Type>) ) and the follow-up transaction as type repeated (<Type>Repeated</Type>). For type Single and Initial, CVC2 information (see CVC2 element) may be required. The type Single is used as default if the collection is not provided. CREDIT_CARD_DA TA con. c This is a collection of credit card data. It is mandatory if the type of transaction is Single or Initial. CreditCardNumber man. n..20 This is a card number against which purchase is made. CVC2 opt. n..4 The 3- or 4-digit security code (called CVC2, CVV2 or CID depending on the credit card brand) that appears on the back of a credit card following the credit card number. This code does not appear on imprints. ExpirationYear man. YYYY The expiry year for the card against which the purchase will be made. ExpirationMonth man. MM The expiry month for the card against which the purchase will be made. CardHolderName man. a..256 Any person who opens a card account and makes purchases using a bank card. Version 3.5.0 61

Element (Cont.) Sett. Data Type Description CardStartYear opt. YYYY This is the start year that is required for Switch/Solo/Maestro card only. CardStartMonth opt. MM This is the start month that is required for Switch/Solo/Maestro card only. CardIssueNumber opt. n..2 This is the card issue number as it appears on some Switch/Solo/Maestro cards. CONTACT_DATA opt. c This is the collection of the contact information. IPAddress man. an..15 This is the IP address of the end user making the purchase. It must be provided in dot-decimal notation consisting of up to 15 characters in length. CORPTRUSTCENT ER_DATA con. c This is a collection of risk management related elements and values. This request level along with the related elements listed below are mandatory if the type of transaction is Single or Initial and additionally the card transaction process is to include a risk validation. ADDRESS man. c This is a collection of cardholder s billing address elements and values. It is highly recommended to provide these elements. This element is mandatory if the CORPTRUSTCENTER_DATA level is to be included in the XML request. FirstName man. an..128 This is the cardholder s first name. LastName man. an..128 This is the cardholder s last name. Address1 man. ans..256 This is the first address field of the cardholder. It is recommended to enter the street name in this field. Address2 opt. ans..256 This is the second address field of the cardholder. It is recommended to enter the street number in this field. City man. ans..32 This field shows the city associated with the cardholder. ZipCode man. an..12 This field shows the cardholder s zip code. State con. a 2 This is the state code is associated with the cardholder s credit card. It must be provided only by US and Canadian merchants accept payments from US or Canadian residents. Country man. a 2 This is the ISO 3166-1 country code associated with the cardholder. 62 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description Phone opt. an..32 This is the cardholder s phone number. It can be provided in one of the following formats: +xxx(yyy)zzz-zzzz-ppp +xxx (yyy) zzz zzzz ppp +xxx(yyy)zzz/zzzz/ppp +xxx(yyy)zzzzzzzppp where: xxx = country code yyy = national direct dialing prefix zzzzzzz = area / city code and local number ppp = PBX extension Separators such as /, \ or - are permissible. For example, a typical international number would be +44(0)555-5555-739 indicating PBX extension 739 at phone number 555-5555 with the national prefix 0 and country code 44. For countries which do not have a national prefix, the format must be configured with or without a space in brackets. Example: +420()52-5454-742. Email opt. an..256 This field contains the cardholder s email address. PERSONINFO opt. c This is a collection of personal information. It is required by some countries for risk assessment of payment transactions. To avoid a transaction being rejected due to risk, it is recommended to provide this information (especially for the US market). DRIVERS_LICENS E opt. c This field shows a collection of driver license information. LicenseNumber opt. an..32 In this field the debtor s driver license number is entered. State con. a 2 This is the state code is associated with the cardholder s credit card. It must be provided only by US and Canadian merchants accept payments from US or Canadian residents. Country opt. a 2 This is the ISO 3166-1 country code where the license was issued. BirthDate opt. YYYY-MM- This field shows the debtor s birth date. DD TaxIdentificationNu mber opt. an..32 This is the debtor s TIN. COST_CENTER_D ATA opt. c This is a collection of the cost center data of an organization. EmployeeID opt. an..17 This request element helps identify the employee. DepartmentCode opt. an..17 This code describes the organization s department. CostAccountNumbe r opt. an..17 This field is reserved for the number defining the cost account. AccountingUnit opt. an..17 This element is reserved for accounting units. AccountNumber opt. an..17 This field shows the account number. Version 3.5.0 63

Element (Cont.) Sett. Data Type Description ServiceDate opt. YYYY-MM- DD This field shows the date the service is provided (departure date), e.g. 2006-10-14. ProjectNumber opt. an..17 This is the number of the project. OrderNumber opt. an..17 This is the order number. ActionNumber opt. an..32 This is the action number. Destination opt. an..17 This element defines the travel destination. 64 Version 3.5.0

Card Processing Example: Single / Initial Purchase Request <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_PURCHASE> <FunctionID>transaction 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <SalesDate>2007-04-30</SalesDate> <CommerceType>eCommerce</CommerceType> <Amount minorunits="2">500</amount> <Currency>EUR</Currency> <CountryCode>DE</CountryCode> <Usage>OrderNo-FT345S71 Thank you</usage> <RECURRING_TRANSACTION> <Type>Initial</Type> </RECURRING_TRANSACTION> <CREDIT_CARD_DATA> <CreditCardNumber>4200000000000000</CreditCardNumber> <CVC2>001</CVC2> <ExpirationYear>2009</ExpirationYear> <ExpirationMonth>01</ExpirationMonth> <CardHolderName>John Doe</CardHolderName> </CREDIT_CARD_DATA> <CONTACT_DATA> <IPAddress>192.168.1.1</IPAddress> </CONTACT_DATA> <CORPTRUSTCENTER_DATA> <ADDRESS> <FirstName>John</FirstName> <LastName>Doe</LastName> <Address1>550 South Winchester blvd.</address1> <Address2>P.O. Box 850</Address2> <City>San Jose</City> <ZipCode>95128</ZipCode> <State>CA</State> <Country>US</Country> <Phone>+1(202)555-1234</Phone> <Email>John.Doe@email.com</Email> </ADDRESS> <PERSONINFO> <DRIVERS_LICENSE> <LicenseNumber>IL213839304</LicenseNumber> <State>IL</State> <Country>US</Country> </DRIVERS_LICENSE> <BirthDate>1967-12-01</BirthDate> <TaxIdentificationNumber>1112223333</TaxIdentificationNumber> </PERSONINFO> </CORPTRUSTCENTER_DATA> <COST_CENTER_DATA> <CostAccountNumber>78500</CostAccountNumber> <ServiceDate>2006-12-17</ServiceDate> </COST_CENTER_DATA> </CC_TRANSACTION> </FNC_CC_PURCHASE> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Version 3.5.0 65

Example: Repeated Purchase Request <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_PURCHASE> <FunctionID>transaction 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <GuWID>C328668112556109425394</GuWID> <RECURRING_TRANSACTION> <Type>Repeated</Type> </RECURRING_TRANSACTION> <COST_CENTER_DATA> <CostAccountNumber>78500</CostAccountNumber> </COST_CENTER_DATA> </CC_TRANSACTION> </FNC_CC_PURCHASE> </W_JOB> </W_REQUEST> </WIRECARD_BXML> 6.8.2 Purchase Request Message With Multiple References The purchase with multiple references may contain the following elements. This section contains the element definitions that differ from the regular purchase. Please refer to the section above for details of those elements. Element Sett. Data Type Description W_REQUEST man. c This is a collection of Card Transaction message elements and their values. CREDIT_CARD_DATA opt. c This is a collection of consumer s account detail elements and values. Existence of this element in the request means, the account information contained in the credit card data overrides the individual account information in the referenced transactions. In other words the sale transaction will be submitted with the account information contained in this element. PaymentGroupID opt. an..22 This optional identifier references transaction types of different payment methods (e.g. credit card and EFT) and represents them in a single group for easy monitoring via the ACM. GuWID man. an 22 This is the reference transaction for the previous authorization. There can be references to one or many previous authorizations. 66 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description Amount con. n..16 This is the integer amount, defined in the smallest currency unit, for which the direct debit is requested (e.g., $10.00 = 1000). This element is used for partial settlements where there is only one reference transaction submitted with the request. It is mandatory for Single and Initial transaction types and if the amount of a Repeated (recurring) transaction differs from the amount of the related Initial transaction. For all other recurring transaction types, this element is optional. minorunits opt. n..1 This is an attribute of the element <Amount>. It allows merchants to specify the number of decimal places for each transaction amount and currency. action opt. a..8 This is an attribute of the element <Amount>. It defines what action needs to be taken if the value of the attribute <minorunits> does not match the number of decimals defined in ISO standard 4217. The following actions are available: convert The amount is converted to the number of ISO-defined decimals validate The transaction is rejected if the value of <minorunits> does not match the number of decimals defined in ISO 4217. This is the default setting. Currency opt. a 3 This is the ISO 4217 currency code used for the direct debit transaction. This currency code is used to validate that the currency of the referenced transactions is the same as this currency code. CountryCode opt. a 2 This is the ISO 3166-1 code of the country where the transaction takes place. This country code is used to validate that the currency of the referenced transactions is the same as this country code. In case only referenced purchases are passed, they must belong to the same card account, same currency, same business case signature and same country. An error will be generated if any of these validations is failed. However, the account information can be overridden by supplying the optional CREDIT_CARD_DATA elements. Version 3.5.0 67

Example: Purchase Request with Multiple References <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_PURCHASE> <FunctionID>Aggregated Transaction 123543</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <Amount minorunits="2">500</amount> <Currency>EUR</Currency> <CountryCode>DE</CountryCode> <Usage>Music Download-FT345S71 Thank you</usage> <RECURRING_TRANSACTION> <Type>Single</Type> </RECURRING_TRANSACTION> <CREDIT_CARD_DATA> <CreditCardNumber>4200000000000000</CreditCardNumber> <CVC2>001</CVC2> <ExpirationYear>2009</ExpirationYear> <ExpirationMonth>01</ExpirationMonth> <CardHolderName>John Doe</CardHolderName> </CREDIT_CARD_DATA> <GuWID>F211900138123480412155</GuWID> <GuWID>F211900138123480412153</GuWID> <GuWID>F211900138123480412156</GuWID> <GuWID>F211900138123480412158</GuWID> <CONTACT_DATA> <IPAddress>192.168.1.1</IPAddress> </CONTACT_DATA> <CORPTRUSTCENTER_DATA> <ADDRESS> <FirstName>John</FirstName> <LastName>Doe</LastName> <Address1>550 South Winchester blvd.</address1> <Address2>P.O. Box 850</Address2> <City>San Jose</City> <ZipCode>95128</ZipCode> <State>CA</State> <Country>US</Country> <Phone>+1(202)555-1234</Phone> <Email>John.Doe@email.com</Email> </ADDRESS> </CORPTRUSTCENTER_DATA> </CC_TRANSACTION> </FNC_CC_PURCHASE> </W_JOB> </W_REQUEST> </WIRECARD_BXML> 68 Version 3.5.0

Card Processing 6.8.3 Purchase Successful Response Please refer to Section 6.15 - Standard Response Message for the field definitions of the purchase successful response. Example: Successful Purchase Response <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_PURCHASE> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504820</GuWID> <FunctionResult>PENDING</FunctionResult> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_PURCHASE> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 6.8.4 Purchase Error Response Please refer to Section 6.15 - Standard Response Message for the field definitions of the purchase error response. Example: Failed Purchase Response <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_PURCHASE> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504827</GuWID> <StatusType>INFO</StatusType> <FunctionResult>NOK</FunctionResult> <ERROR> <Type>REJECTED</Type> <Number>05</Number> <Message>Authorization Declined.</Message> <Advice>It is not possible to book the given amount from the credit account, e. g. limit is exceeded.</advice> </ERROR> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_PURCHASE> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> Version 3.5.0 69

6.9 Notification A notification request is typically sent when an authorization-based transaction (Authorization, Pre-Authorization, Purchase) has been rejected with error code 02: Call Voice-authorization number. In this case, the merchant must contact his acquirer s voice authorization center by phone and request a voice authorization number. The acquirer refers the request to cardholder s bank (issuer). When the issuer has authorized the transaction, the acquirer gives the merchant an authorization code which the merchant then includes in his notification request. If the request (and authorization code) is processed successfully the transaction is approved. 6.9.1 Notification Request Message The notification request may contain the following elements: Element Sett. Data Type Description W_REQUEST man. c This is a collection of card capture authorization message elements and their values. W_JOB man. c This is a collection of elements that defines a job within the request. The job may comprise of multiple transactions. JobID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<JobID> </JobID>) must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. BusinessCaseSignature man. an..16 This is the unique merchant identifier against which the request is made. FNC_CC_NOTIFICATIO N man. c This is a collection of transaction data elements and their values. FunctionID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<FunctionID> </FunctionID>) must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. CC_TRANSACTION man. c This is a collection of transaction data elements and their values. mode opt. an..32 This is the attribute defining the mode of the transaction. Possible values are: demo live TransactionID man. an..32 This is a unique ID associated with a single transaction, which is created by the merchant and submitted as part of the request (see also Appendix J). 70 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description SalesDate opt. YYYY-MM- DD This is the calendar date of the purchase. It is optional and can be included if the sales date is different from the date the transaction is posted for processing. It can be backdated up to 30 days. PaymentGroupID opt. an..22 This optional identifier references transaction types of different payment methods (e.g. credit card and EFT) and represents them in a single group for easy monitoring via the ACM. GuWID man. an.. 22 This is the Wirecard transaction ID of the original failed Authorization. It is allowed to use the notification request only if the previous transaction failed with error code 02 Call Authorization Center. AuthorizationCode man. an..10 This is a numerical or alphanumerical code provided by the card issuer in the Authorization Call verifying that the original transaction request See also Glossary. Usage opt. an..256 This is the field, which is shown on the customer s card statement and can be used by the merchant for reference purposes. The usage field for the capture overrides the field value provided with the authorization. This feature is not supported by all the acquirers. The size of this field depends on the acquirer. Please contact Wirecard technical support for further clarification. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_NOTIFICATION> <FunctionID>capture 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <SalesDate>2007-04-30</SalesDate> <GuWID>C242720181323966504820</GuWID> <AuthorizationCode>575023</AuthorizationCode> <Usage>OrderNo-FT345S71 Thank you</usage> </CC_TRANSACTION> </FNC_CC_NOTIFICATION> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Version 3.5.0 71

6.9.2 Notification Successful Response Please refer to Section 6.15 - Standard Response Message for the field definitions of the capture authorization successful response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_NOTIFICATION> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504820</GuWID> <AuthorizationCode>153620</AuthorizationCode> <FunctionResult>PENDING</FunctionResult> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_NOTIFICATION> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 6.9.3 Notification Error Response Please refer to Section 6.15 - Standard Response Message for the field definitions of the capture authorization error response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_NOTIFICATION> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504827</GuWID> <AuthorizationCode>799961</AuthorizationCode> <StatusType>INFO</StatusType> <FunctionResult>NOK</FunctionResult> <ERROR> <Type>REJECTED</Type> <Number>21</Number> <Message>No action taken.</message> </ERROR> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_NOTIFICATION> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 72 Version 3.5.0

Card Processing 6.10 Bookback In the event that you wish to refund a customer, use the Bookback request to credit the funds back to the payment card. Depending on the acquiring bank this may be possible for up to three months following the transaction. In some cases, a Bookback may have already been initiated by the card company as a result of a chargeback request from the cardholder. A chargeback is a refusal of the cardholder s bank to accept a transaction presented by the merchant s processor. This occurs when a customer disputes a card purchase. The merchant may be asked for proof of Authorization. The end result may be that the merchant s account is debited for the transaction. It is recommended that merchants check their chargeback records before processing a Bookback transaction. To post a Bookback request, a valid GuWID from a former Capture or Purchase (debit) transaction is required. It is only possible to credit an amount less than or equal to the initial transaction using the same currency as with the original transaction. A bookback is listed separately on the cardholder s card statement. NOTE: The use of the Bookback functionality is subject to constraints imposed by our risk management system. Contact your account representative to learn more about Bookback transactions. 6.10.1 Bookback Request Message The Bookback request may contain the following elements: Element Sett. Data Type Description W_REQUEST man. c This is a collection of Card Bookback message elements and their values. W_JOB man. c This is a collection of elements that defines a job within the request. The job may comprise of multiple transactions. JobID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<JobID> </JobID>) must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. BusinessCaseSignatur e man. an..16 This is the unique merchant identifier against which the request is made. FNC_CC_BOOKBACK man. c This is a collection of transaction data elements and their values. FunctionID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<FunctionID> </FunctionID>) must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. Version 3.5.0 73

Element (Cont.) Sett. Data Type Description CC_TRANSACTION man. c This is a collection of transaction data elements and their values. mode opt. an..32 This is the attribute defining the mode of the transaction. Possible values are: demo live TransactionID man. an..32 This is a unique ID associated with a single transaction, which is created by the merchant and submitted as part of the request. PaymentGroupID opt. an..22 This optional identifier references transaction types of different payment methods (e.g. credit card and EFT) and represents them in a single group for easy monitoring via the ACM. GuWID man. an.. 22 This is the Wirecard transaction ID of the original debit transaction. Amount con. n..16 This is the integer amount, defined in the smallest currency unit, for which the transaction is requested (e.g., $10.00 = 1000). This element is mandatory for transactions where the amount differs from the captured amount.otherwise it is optional. minorunits opt. n..1 This is an attribute of the element <Amount>. It allows merchants to specify the number of decimal places for each transaction amount and currency. action opt. a..8 This is an attribute of the element <Amount>. It defines what action needs to be taken if the value of the attribute <minorunits> does not match the number of decimals defined in ISO standard 4217. The following actions are available: convert The amount is converted to the number of ISO-defined decimals validate The transaction is rejected if the value of <minorunits> does not match the number of decimals defined in ISO 4217. This is the default setting. Usage opt. an..256 This is the field, which is shown on the customer s credit card statement and can be used by the merchant for reference purposes. This feature is not supported by all the acquirers. The size of this field depends on the acquirer. Please contact Wirecard technical support for further clarification. CREDIT_CARD_DATA opt. c This is a collection of credit card data. ExpirationYear man. YYYY The expiry year for the card against which the original purchase was made. This needs to be used in case the card is expired in between the original debit transaction and the bookback transaction. 74 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description ExpirationMonth man. MM The expiry month for the card against which the original purchase was made. This needs to be used in case the card is expired in between the original debit transaction and the bookback transaction. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_BOOKBACK> <FunctionID>reversal 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <GuWID>C242720181323966504820</GuWID> <Amount minorunits="2">500</amount> <Usage>Refund of orderno-ft345s71</usage> </CC_TRANSACTION> </FNC_CC_BOOKBACK> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Version 3.5.0 75

6.10.2 Bookback Successful Response Please refer to Section 6.15 - Standard Response Message for the field definitions of the bookback successful response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_BOOKBACK> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504820</GuWID> <FunctionResult>PENDING</FunctionResult> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_BOOKBACK> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 6.10.3 Bookback Error Response Please refer to Section 6.15 - Standard Response Message for the field definitions of the bookback error response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_BOOKBACK> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504827</GuWID> <StatusType>INFO</StatusType> <FunctionResult>NOK</FunctionResult> <ERROR> <Type>DATA_ERROR</Type> <Number>20071</Number> <Message>Expiration date invalid.</message> <Advice>Expiration date must not be exceeded.</advice> </ERROR> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_BOOKBACK> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 76 Version 3.5.0

Card Processing 6.11 Reversal The reversal function enables the user to cancel a previous request. A reversal of a monetary transaction (e.g. transaction, capture, bookback, notification, refund ) is only allowed on the same calendar day as of the original request. We recommend to send in reversals not later than 23:00 / 11:00 pm acquirer time to ensure proper processing by the acquirers. The reversed transactions do not appear on the cardholder s card statement. A reversal of an authorization transaction (e.g. authorization, preauthorization, preauthorization supplement ) can be made up to 14 days following the original request. Please contact Wirecard technical support for further information on the expiration period. For a reversal request, a valid GuWID from a previous request is required. The amount defined in the reversal request has to match the amount given in the respective request that needs to be cancelled. NOTE: A reversal of a capture reactivates the original authorization, preauthorization or preauthorization supplement resulting in reduced credit limit of the credit card. To free reserved amounts on a credit card please cancel all authorizations, preauthorizations and pre-authorizations supplements) related to this card. 6.11.1 Reversal Request Message The Reversal request may contain the following elements: Element Sett. Data Type Description W_REQUEST man. c This is a collection of Reversal message elements and their values. W_JOB man. c This is a collection of elements that defines a job within the request. The job may comprise of multiple transactions. JobID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<JobID> </JobID>) must be provided in the request. Omitting the element will result in a response error. See Appendix J for permissible characters. BusinessCaseSignat ure man. an..16 This is the unique merchant identifier against which the request is made. FNC_CC_REVERSAL man. c This is a collection of transaction data elements and their values. FunctionID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<FunctionID> </FunctionID>) must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. CC_TRANSACTION man. c This is a collection of transaction data elements and their values. Version 3.5.0 77

Element (Cont.) Sett. Data Type Description mode opt. an..32 This is the attribute defining the mode of the transaction. Possible values are: demo live TransactionID man. an..32 This is a unique ID associated with a single transaction, which is created by the merchant and submitted as part of the request (see also Appendix J). PaymentGroupID opt. an..22 This optional identifier references transaction types of different payment methods (e.g. credit card and EFT) and represents them in a single group for easy monitoring via the ACM. GuWID man. an..22 This is the Wirecard transaction ID of the original transaction that needs to be reversed. Amount con. n..16 An amount can be provided only for pending transactions to reduce the amount which is to be captured.this element is an integer defined in the smallest currency unit, for which the transaction is requested (e.g., $10.00 = 1000). It is used for validation only. It is typically mandatory (optional only with recurring transactions of the same amount). minorunits opt. n..1 This is an attribute of the element <Amount>. It allows merchants to specify the number of decimal places for each transaction amount and currency. action opt. a..8 This is an attribute of the element <Amount>. It defines what action needs to be taken if the value of the attribute <minorunits> does not match the number of decimals defined in ISO standard 4217. The following actions are available: convert The amount is converted to the number of ISOdefined decimals validate The transaction is rejected if the value of <minorunits> does not match the number of decimals defined in ISO 4217. This is the default setting. 78 Version 3.5.0

Card Processing Example: Reversal Request <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_REVERSAL> <FunctionID>reversal 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <GuWID>C242720181323966504820</GuWID> </CC_TRANSACTION> </FNC_CC_REVERSAL> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Version 3.5.0 79

6.11.2 Reversal Successful Response Please refer to Section 6.15 - Standard Response Message for the field definitions of the reversal successful response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_REVERSAL> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504820</GuWID> <FunctionResult>ACK</FunctionResult> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_REVERSAL> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 6.11.3 Reversal Error Response Please refer to Section 6.15 - Standard Response Message for the field definitions of the reversal error response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_REVERSAL> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504827</GuWID> <StatusType>INFO</StatusType> <FunctionResult>NOK</FunctionResult> <ERROR> <Type>REJECTED</Type> <Number>21</Number> <Message>No action taken.</message> </ERROR> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_REVERSAL> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 80 Version 3.5.0

Card Processing 6.12 Original Credits An Original Credit is a transaction type used to credit funds (remittances, payouts, claims, dividends or winnings) to a card, provided the merchant s acquiring bank and the beneficiary s card issuing bank participate in this scheme. For the purpose of processing, an original credit is referred to OCT (Original Credit Transaction) in the Wirecard environment. Original credits (Visa and MasterCard) are supported by Wirecard Bank (acquirer) andwirecard Technologies processing system. This transaction type may, however, not be available to all merchants. NOTE: The use of Original Credits is restricted by and subjected to national laws and Visa and MasterCard regulations. imposed by our risk management system. If you wish to this service, please contact your sales representative or Wirecard Customer Services. 6.12.1 OCT Request Message An OCT request can be posted as a referenced or non-referenced XML transaction type and may include the following mandatory, optional or conditional elements: Element Sett. Data Type Description W_REQUEST man. c This is a collection of Card Refund message elements and their values. W_JOB man. c This is a collection of elements that defines a job within the request. The job may comprise of multiple transactions. JobID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<JobID> </JobID>)must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. BusinessCaseSignature man. an..16 This is the unique merchant identifier against which the request is made. FNC_CC_OCT man. c This is a collection of transaction data elements and their values. FunctionID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<FunctionID> </FunctionID>) must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. CC_TRANSACTION man. c This is a collection of transaction data elements and their values. Version 3.5.0 81

Element(Cont.) Sett. Data Type Description mode opt. an..32 This is the attribute defining the mode of the transaction. Possible values are: demo live TransactionID man. an..32 This is a unique ID associated with a single transaction, which is created by the merchant and submitted as part of the request. Amount con. n..16 This is the integer amount, defined in the smallest currency unit, for which the transaction is requested (e.g., $10.00 = 1000). The <Amount> element is mandatory for Single and Initial transaction types and if the amount of a Repeated (recurring) transaction differs from the amount of the related Initial transaction. For all other recurring transactions, this element is optional. minorunits opt. n..1 This is an attribute of the element <Amount>. It allows merchants to specify the number of decimal places for each transaction amount and currency. action opt. a..8 This is an attribute of the element <Amount>. It defines what action needs to be taken if the value of the attribute <minorunits> does not match the number of decimals defined in ISO standard 4217. The following actions are available: convert The amount is converted to the number of ISO-defined decimals validate The transaction is rejected if the value of <minorunits> does not match the number of decimals defined in ISO 4217. This is the default setting. GuWID con. an..22 This is the Global unique Wirecard ID used in referenced requests.non-referenced requests include only the collection element CREDIT_CARD_DATA. Currency con. a 3 This is the ISO 4217 currency code used for the transaction. It is mandatory if the type of transaction is Single or Initial or if the currency of a Repeated transaction differs from the currency of the related Initial transaction. CountryCode opt. a 2 This is the ISO 3166-1 code of the country where the transaction takes place. It is mandatory if the type of transaction is Single or Initial. 82 Version 3.5.0

Card Processing Element(Cont.) Sett. Data Type Description Usage opt. an..256 This is the field, which is shown on the customer s card statement and can be used by the merchant for reference purposes. This feature is not supported by all the acquirers. The size of this field depends on the acquirer. Please contact Wirecard technical support for further clarification. CREDIT_CARD_DATA con. c This is a collection of credit card data. It is mandatory for all non-referenced OCT requests. CreditCardNumber man. n..20 This is a card number against which purchase is made. ExpirationYear man. YYYY The expiry year for the card against which the purchase will be made. ExpirationMonth man. MM The expiry month for the card against which the purchase will be made. CardHolderName man. a..256 Any person who opens a card account and makes purchases using a card. Example: OCT Request - Referenced The prime element of this request type is a unique identifier called GuWID which ties this credit request to a previous card transaction. <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>ACCEPTANCE_TEST</JobID> <BusinessCaseSignature>793</BusinessCaseSignature> <FNC_CC_OCT> <FunctionID>XCOM-e-commerce</FunctionID> <CC_TRANSACTION> reference to <TransactionID>6.2.2.3.85.R</TransactionID> related <GuWID>C813690122390611064461</GuWID> transaction <Amount>1000</Amount> <Currency>EUR</Currency> <CountryCode>DE</CountryCode> </CC_TRANSACTION> </FNC_CC_OCT> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Version 3.5.0 83

Example: OCT Response - Referenced <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>ACCEPTANCE_TEST</JobID> <FNC_CC_OCT> <FunctionID>XCOM-e-commerce</FunctionID> <CC_TRANSACTION> <TransactionID>6.2.2.3.85.R</TransactionID> <PROCESSING_STATUS> <GuWID>C897759122458567984915</GuWID> <AuthorizationCode>639782</AuthorizationCode> <StatusType>INFO</StatusType> <FunctionResult>PENDING</FunctionResult> <TimeStamp>2008-10-21 12:41:19</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_OCT> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> reference to credit card Example: OCT Request - Non-Referenced A non-referenced request message contains no GuWID but instead the number of a card to which the amount is to be remitted. <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>ACCEPTANCE_TEST</JobID> <BusinessCaseSignature>793</BusinessCaseSignature> <FNC_CC_OCT> <FunctionID>XCOM-e-commerce</FunctionID> <CC_TRANSACTION> <TransactionID>6.2.2.3.85.R</TransactionID> <Amount>1000</Amount> <Currency>EUR</Currency> <CountryCode>DE</CountryCode> <CREDIT_CARD_DATA> <CreditCardNumber>4126410000000002</CreditCardNumber> <ExpirationYear>2019</ExpirationYear> <ExpirationMonth>02</ExpirationMonth> <CardHolderName>VISA-I</CardHolderName> </CREDIT_CARD_DATA> </CC_TRANSACTION> </FNC_CC_OCT> </W_JOB> </W_REQUEST> </WIRECARD_BXML> 84 Version 3.5.0

Card Processing Example: OCT Response - Non-Referenced The response message to a non-referenced request is identical to that of a referenced request. <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>ACCEPTANCE_TEST</JobID> <FNC_CC_OCT> <FunctionID>XCOM-e-commerce</FunctionID> <CC_TRANSACTION> <TransactionID>6.2.2.3.85.R</TransactionID> <PROCESSING_STATUS> <GuWID>C8977591224585679843245</GuWID> <AuthorizationCode>639782</AuthorizationCode> <StatusType>INFO</StatusType> <FunctionResult>PENDING</FunctionResult> <TimeStamp>2008-10-21 12:41:19</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_OCT> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> Version 3.5.0 85

6.13 Query With the Query Request function the user can obtain information about the status of a transaction. For example, he can query the status of a captured amount that was previously displayed with the Function Result PENDING to make sure that the transaction has been processed successfully and now returns the Function Result ACK in the Query response message. To send the Query Request, the user must provide the GuWID returned with the former Capture response message or Reference Transaction ID, which originates in the transaction ID sent by the merchant. NOTE: A query request can be posted with only one ID. This can be either a ReferenceTransactionID or a GuWID. Both IDs can not be queries at the same time. 6.13.1 Query Request Elements The Query request may contain a combination of the following elements: Element Sett. Data Type Description W_REQUEST man. c This is a collection of Query message elements and their values. W_JOB man. c This is a collection of elements that defines a job within the request. The job may consist of multiple transactions. BusinessCaseSign ature man. an..16 This is the unique merchant identifier against which the request is made. FNC_CC_QUERY man. c This is a collection of transaction data elements and their values. type opt. an..10 This is the attribute defining the type of the FNC_CC QUERY collection. The only possible value is details (with this type specified in the query request, the response returns a message detailing all the parameter fields of the original transaction response (see detailed Query Response). This attribute can be used only in combination with a GuWID. CC_TRANSACTIO N ReferenceTransact ionid StartTime opt. YYYY-MM- DD hh:mm:ss EndTime opt. YYYY-MM- DD hh:mm:ss man. c This is a collection of transaction data elements and their values. opt. an..32 This is the transaction ID sent by the merchant with the original transaction request. This field indicated the start date and time of the original transaction. It must be included to query any transaction older than 15 minutes. If it is not provided, the Wirecard system will automatically search within the range of the last 15 minutes. This field indicated the end date and time of the query. It must be included to query any transaction older than 15 minutes. GuWID opt. an..22 This is the Wirecard transaction ID of the original transaction. 86 Version 3.5.0

Card Processing Example 1: Query Request - based on GuWID <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_QUERY> <CC_TRANSACTION> <GuWID>C242720181323966504820</GuWID> </CC_TRANSACTION> </FNC_CC_QUERY> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Example 2: Query Request (detailed) - based on GuWID <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_QUERY type="detail"> <CC_TRANSACTION> <GuWID>C242720181323966504820</GuWID> </CC_TRANSACTION> </FNC_CC_QUERY> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Example 3: Query Request - based on ReferenceTransactionID (near past) <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_QUERY> <CC_TRANSACTION> <ReferenceTransactionID>WTQ-6354552</ReferenceTransactionID> </CC_TRANSACTION> </FNC_CC_QUERY> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Example 4: Query Request - based on ReferenceTransactionID (history search) <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_QUERY> <CC_TRANSACTION> <ReferenceTransactionID>WTQ-6354552</ReferenceTransactionID> <StartTime>2007-08-07 17:30:00</StartTime> <EndTime>2007-08-07 17:30:00</EndTime> </CC_TRANSACTION> </FNC_CC_QUERY> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Version 3.5.0 87

6.13.2 Query Response Messages Please refer to Section 6.15 - Standard Response Message for the field definitions of query response messages. Example 1: Query Response - based on GuWID <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>ACCEPTANCE-TEST</JobID> <FNC_CC_QUERY> <FunctionID>ATOS-B AND S</FunctionID> <CC_TRANSACTION> <TransactionID>31</TransactionID> <PROCESSING_STATUS> <GuWID>C885511118700326859262</GuWID> <Info>THIS IS A TEST</Info> <StatusType>INFO</StatusType> <FunctionResult>PENDING</FunctionResult> <TimeStamp>2007-08-13 13:07:48</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_QUERY> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> Example 2: Query Response (detailed) - based on GuWID <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>ACCEPTANCE-TEST</JobID> <FNC_CC_QUERY type="detail"> <FunctionID>ATOS-B AND S</FunctionID> <CC_TRANSACTION> <TransactionID>1</TransactionID> <PaymentGroupID>C885511118700326859262</PaymentGroupID> <TransactionType>CaptureAuthorization</TransactionType> <TransactionType>1</TransactionType> <CommerceType>eCommerce</CommerceType> <Amount>2005</Amount> <Currency>EUR</Currency> <CountryCode>DE</CountryCode> <Usage>DE1823737</Usage> <CREDIT_CARD_DATA> <CreditCardNumber>5413****0422</CreditCardNumber> <ExpirationYear>2007</ExpirationYear> <ExpirationMonth>12</ExpirationMonth> <CardHolderName>MCC 42</CardHolderName> </CREDIT_CARD_DATA> <PROCESSING_STATUS> <GuWID>C885511118700326859262</GuWID> <StatusType>INFO</StatusType> <FunctionResult>NOK</FunctionResult> <ERROR> <Type>REJECTED</Type> <Number>12</Number> <Message>Invalid transaction.</message> </ERROR> <TimeStamp>2007-08-13 13:07:48</TimeStamp> 88 Version 3.5.0

Card Processing </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_QUERY> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> Example 3: Query Response - based on ReferenceTransactionID (near past) <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>ACCEPTANCE-TEST</JobID> <FNC_CC_QUERY> <FunctionID>ATOS-B AND S</FunctionID> <CC_TRANSACTION> <TransactionID>31</TransactionID> <PROCESSING_STATUS> <GuWID>C885511118700326859262</GuWID> <Info>THIS IS A TEST</Info> <StatusType>INFO</StatusType> <FunctionResult>PENDING</FunctionResult> <TimeStamp>2007-08-13 13:07:48</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_QUERY> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> Example 4: Query Response - based on ReferenceTransactionID (history search) <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>ACCEPTANCE-TEST</JobID> <FNC_CC_QUERY> <FunctionID>ATOS-B AND S</FunctionID> <CC_TRANSACTION> <TransactionID>31</TransactionID> <PROCESSING_STATUS> <GuWID>C885511118700326859262</GuWID> <Info>THIS IS A TEST</Info> <StatusType>INFO</StatusType> <FunctionResult>PENDING</FunctionResult> <TimeStamp>2007-08-13 13:07:48</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_QUERY> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> Version 3.5.0 89

6.13.3 Query Error Response This query response is returned, if the original transaction was declined. Please refer to Section 6.15 - Standard Response Message for the field definitions of the query error response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_QUERY> <FunctionID>Query 5</FunctionID> <CC_TRANSACTION > <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504827</GuWID> <StatusType>INFO</StatusType> <FunctionResult>NOK</FunctionResult> <ERROR> <Type>REJECTED</Type> <Number>05</Number> <Message>Authorization Declined.</Message> <Advice>It is not possible to book the given amount from the credit account, e. g. limit is exceeded.</advice> </ERROR> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_QUERY> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 90 Version 3.5.0

Card Processing 6.14 Refund The Refund transaction type can be used to credit funds to a payment card. It is listed separately on the payment card statement The funds can be credited as a standalone transaction (with no connection to a previous settlement) or to reimburse a consumer for a returned product or service. Although it is supported by Wirecard s core system it is disabled for general use. If you wish to use it, please contact Customer Services. Refund may be triggered by the card company as a result of a chargeback request from the cardholder. A chargeback is a refusal of the cardholder s bank to accept a transaction presented by the merchant s processor. This occurs when a customer disputes a card purchase. The merchant may be asked for proof of Authorization. The end result may be that the merchant s account is debited for the transaction. It is recommended that merchants check their chargeback records before processing a Refund transaction. A Refund request is similar to the Bookback request, except that it does not necessarily require a valid GuWID from a previous Capture transaction. NOTE: The use of Refund functionality is restricted and subjected to constraints imposed by our risk management system. Contact your account representative if you want to learn more about Refund transactions. This functionality may not be available to all the customers. 6.14.1 Refund Request Message The refund request may contain the following elements: Element Sett. Data Type Description W_REQUEST man. c This is a collection of Card Refund message elements and their values. W_JOB man. c This is a collection of elements that defines a job within the request. The job may comprise of multiple transactions. JobID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<JobID> </JobID>)must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. BusinessCaseSignature man. an..16 This is the unique merchant identifier against which the request is made. FNC_CC_REFUND man. c This is a collection of transaction data elements and their values. FunctionID opt. an..32 This ID is reserved for merchant system data and can be used for tracking purposes. Although it is optional meaning that it does not have to contain data, the element itself (<FunctionID> </FunctionID>) must still be provided in the XML request. Omitting the element will result in a response error. See Appendix J for permissible characters. Version 3.5.0 91

Element(Cont.) Sett. Data Type Description CC_TRANSACTION man. c This is a collection of transaction data elements and their values. mode opt. an..32 This is the attribute defining the mode of the transaction. Possible values are: demo live TransactionID man. an..32 This is a unique ID associated with a single transaction, which is created by the merchant and submitted as part of the request. CommerceType opt. an..23 Possible values: ecommerce MOTO CustomerPresent The default setting of this element is ecommerce. If you like to have your CommerceType set to MOTO or CustomerPresent, please contact Wirecard support to have these options activated. Amount con. n..16 This is the integer amount, defined in the smallest currency unit, for which the transaction is requested (e.g., $10.00 = 1000). The <Amount> element is mandatory for Single and Initial transaction types and if the amount of a Repeated (recurring) transaction differs from the amount of the related Initial transaction. For all other recurring transactions, this element is optional. minorunits opt. n..1 This is an attribute of the element <Amount>. It allows merchants to specify the number of decimal places for each transaction amount and currency. action opt. a..8 This is an attribute of the element <Amount>. It defines what action needs to be taken if the value of the attribute <minorunits> does not match the number of decimals defined in ISO standard 4217. The following actions are available: convert The amount is converted to the number of ISO-defined decimals validate The transaction is rejected if the value of <minorunits> does not match the number of decimals defined in ISO 4217. This is the default setting. PaymentGroupID opt. an..22 This optional identifier references transaction types of different payment methods (e.g. credit card and EFT) and represents them in a single group for easy monitoring via the ACM. GuWID con. an..22 This is the GuWID of an associated initial transaction. It is mandatory if the transaction type is Repeated. 92 Version 3.5.0

Card Processing Element(Cont.) Sett. Data Type Description Currency con. a 3 This is the ISO 4217 currency code used for the transaction. It is mandatory if the type of transaction is Single or Initial or if the currency of a Repeated transaction differs from the currency of the related Initial transaction. CountryCode con. a 2 This is the ISO 3166-1 code of the country where the transaction takes place. It is mandatory if the type of transaction is Single or Initial. Usage opt. an..256 This is the field, which is shown on the customer s card statement and can be used by the merchant for reference purposes. This feature is not supported by all the acquirers. The size of this field depends on the acquirer. Please contact Wirecard technical support for further clarification. RECURRING_TRANSA CTION opt. c This is a collection of recurring information. It enables the merchant to send a recurring transaction. A Recurring Transaction is one, that is authorized once by the cardholder, and the merchant sends it every month again (e.g. for a membership). This collection must be provided if the type of transaction is Initial or Repeated. Type man. an..8 Possible values are single, initial, and repeated. To use the Recurring Transaction function it is necessary to send the first transaction as type initial (<Type>Initial</Type>) ) and the follow-up transaction as type repeated (<Type>Repeated</Type>). For type Single and Initial, CVC2 information (see CVC2 element) may be required. The type Single is used as default if the collection is not provided. CREDIT_CARD_DATA con. c This is a collection of credit card data. It is mandatory if the type of transaction is Single or Initial. CreditCardNumber man. n..20 This is a card number against which purchase is made. ExpirationYear man. YYYY The expiry year for the card against which the purchase will be made. ExpirationMonth man. MM The expiry month for the card against which the purchase will be made. CardHolderName man. a..256 Any person who opens a card account and makes purchases using a card. CardStartYear opt. YYYY This is the start year that is required for Switch/Solo/Maestro card only. CardStartMonth opt. MM This is the start month that is required for Switch/Solo/Maestro card only. Version 3.5.0 93

Element(Cont.) Sett. Data Type Description CardIssueNumber opt. n..2 This is the card issue number as it appears on some Switch/Solo/Maestro cards. Example: Single / Initial Refund Request <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_REFUND> <FunctionID>refund 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <CommerceType>eCommerce</CommerceType> <Amount minorunits="2">1200</amount> <Currency>EUR</Currency> <CountryCode>DE</CountryCode> <Usage>Refund of orderno-ft345s71</usage> <RECURRING_TRANSACTION> <Type>Initial</Type> </RECURRING_TRANSACTION> <CREDIT_CARD_DATA> <CreditCardNumber>4200000000000000</CreditCardNumber> <ExpirationYear>2009</ExpirationYear> <ExpirationMonth>01</ExpirationMonth> <CardHolderName>John Doe</CardHolderName> </CREDIT_CARD_DATA> </CC_TRANSACTION> </FNC_CC_REFUND> </W_JOB> </W_REQUEST> </WIRECARD_BXML> Example: Repeated Refund Request <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_REFUND> <FunctionID>refund 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <GuWID>C328668112556109425394</GuWID> <RECURRING_TRANSACTION> <Type>Repeated</Type> </RECURRING_TRANSACTION> </CC_TRANSACTION> </FNC_CC_REFUND> </W_JOB> </W_REQUEST> </WIRECARD_BXML> 94 Version 3.5.0

Card Processing 6.14.2 Refund Successful Response Message Please refer to Section 6.15 - Standard Response Message for the field definitions of the refund successful response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_REFUND> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504820</GuWID> <FunctionResult>PENDING</FunctionResult> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_REFUND> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 6.14.3 Refund Error Response Message Please refer to Section 6.15 - Standard Response Message for the field definitions of the refund error response. Example: <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>job 1</JobID> <FNC_CC_REFUND> <FunctionID>function 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <PROCESSING_STATUS> <GuWID>C242720181323966504827</GuWID> <StatusType>INFO</StatusType> <FunctionResult>NOK</FunctionResult> <ERROR> <Type>REJECTED</Type> <Number>14</Number> <Message>Invalid card.</message> </ERROR> <TimeStamp>2001-01-31 20:39:24</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_REFUND> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> Version 3.5.0 95

6.15 Standard Response Message For every submitted transaction request, the Wirecard system returns a response message, regardless of the outcome of the transaction process (one for a failed process and one for a successful process). Included in every response message is a collection element field called Function name which, depending on the type of transaction processed can have one of the following values: FNC_CC_PURCHASE FNC_CC_AUTHORIZATION FNC_CC_CAPTURE_AUTHORIZATION FNC_CC_PREAUTHORIZATION FNC_CC_CAPTURE_PREAUTHORIZATION FNC_CC_PREAUTHORIZATION_SUPPLEMENT FNC_CC_CAPTURE_PREAUTHORIZATION_SUPPLEMENT FNC_CC_NOTIFICATION FNC_CC_BOOKBACK FNC_CC_OCT FNC_CC_REVERSAL FNC_CC_QUERY FNC_CC_REFUND NOTE: If the request includes risk management functionality, the response message may also contain a collection of risk management related elements and values. Element Sett. Data Type Description W_RESPONSE man. c This is a collection of Card Transaction response message elements and their values. W_JOB man. c This is a collection of elements that defines a job within the response. The job may comprise of multiple transactions. JobID opt. an..32 This ID is returned if the element was data was provided in the original XML request message. Function name man. c This is a collection of transaction data elements and their values. FunctionID opt. an..32 This ID is received as part of the request and echoed back in the response. This is the merchant system data used for tracking purposes. CC_TRANSACTION man. c This is a collection of transaction data elements and their values. mode opt. an..32 This is the attribute defining the mode of the transaction. Possible values are: demo live 96 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description TransactionID man. an..32 This is a unique ID associated with a single transaction, which is created by the merchant and submitted as part of the request. This is received as part of the request and echoed back in the response. PROCESSING_STAT US man. c This is a collection of transaction result elements and values. GuWID man. an 22 This is an alphanumeric string generated by the Wirecard system. It is required when reporting a transaction problem to Wirecard Technical Support (support@wirecard.com). StatusType man. an..32 This element describes the transaction status. For standard CC processing is returned value INFO only. FunctionResult man. a 32 The data returned in this line of the response message shows the result of the executed transaction. Valid values are: ACK (Successful transaction) NOK (Failed transaction) PENDING (successful transaction waiting to be captured) for further details see the definition pending in the Glossary. ERROR opt. c This is a collection of error result elements and values. This collection is provided only if the FunctionResult is NOK. Type man. an..32 Provides basic information about the type of error. It may have one of the following values: REJECTED- transaction was rejected by acquirer. DATA_ERROR - XML request data is not valid and could not be processed. SYSTEM_ERROR - transaction could not be processed because of a system error. CLIENT_ERROR - error on the client side. This value is returned only if the merchant uses Wirecard s locally installed XML client server software. Number man. n..5 This is the error number associated with the failure. Message opt. an..1024 This is the error message associated with the failed condition. Advice opt. an..1024 This is the system-generated guidance for correction of the failed condition. This element can be repeated if there is a need for multiple advises. TimeStamp man. YYYY-MM- DD hh:mm:ss This is CET (Central European Time) date/time of the completion of the transaction. Version 3.5.0 97

7 Address Verification Service The Address Verification System (AVS) is an advanced level of credit card security that is built in to the Wirecard credit card processing network to help thwart identity theft. When a user makes an online purchase with a credit card their billing address is required. The house number and postal code of the billing address they enter is compared to the billing address held on file by the card issuing bank. If the address does not match then the transaction can be declined. AVS is an on-demand service which is configured by Wirecard for each merchant. If AVS is configured, the customer s address data is sent together with payment transaction to an acquirer. The acquirer then sends back an AVS response code, which is represented by two characters, e.g. "5M". Wirecard supports AVS for American Express (Amex), MasterCard and Visa. Each card brand generates its own AVS return code which is then mapped by the core system to common Wirecard AVS code for representation in the transaction XML response. 7.1 AVS Response Message AVS check data can be sent with any single or initial Authorization, Preauthorization or Purchase transaction request.it is posted with the CORPTRUSTCENTER_DATA element to the Wirecard core system. The following is an example of an AVS response message: Wirecard AVS response code card brand AVS response <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_RESPONSE> <W_JOB> <JobID>ACCEPTANCE_TEST</JobID> <FNC_CC_PURCHASE> <FunctionID>AVS XCOM-e-commerce</FunctionID> <CC_TRANSACTION> <TransactionID>1</TransactionID> <PROCESSING_STATUS> <GuWID>C806922119825918638975</GuWID> <AuthorizationCode>555135</AuthorizationCode> <StatusType>INFO</StatusType> <FunctionResult>PENDING</FunctionResult> <AVS> <ResultCode>F</ResultCode> <Message>Exact Match</Message> <AuthorizationEntity>5</AuthorizationEntity> <AuthorizationEntityMessage>Response provided by issuer processor.</authorizationentitymessage> <ProviderResultCode>X</ProviderResultCode> <ProviderResultMessage>For U.S. addresses, nine-digit postal code and address match. For addresses outside U.S., postal code and address match.</providerresultmessage> </AVS> <TimeStamp>2007-12-21 18:46:26</TimeStamp> </PROCESSING_STATUS> </CC_TRANSACTION> </FNC_CC_PURCHASE> </W_JOB> </W_RESPONSE> </WIRECARD_BXML> 98 Version 3.5.0

Card Processing 7.2 Wirecard AVS Response Codes Response Code Message Description 0 Reserved Reserved F Exact Match Street address and zip code match P Partial Match Street address or zip code does not match. U AVS Unavailable Address information is unavailable or the Issuer does not support AVS E Error AVS not performed due to an error or insufficient data. N No Match Neither address nor zip code match. 2 Authorization Entity Response provided by Intermediate processor. 5 Authorization Entity Response provided by issuer processor. 7.3 Wirecard Response Code Mapping 7.3.1 American Express and AVS Mapping of American Express (Amex) AVS Response Codes: Amex Wirecard Description A P CSC and Address Match F F Full Data Match N P CSC Match U U Data Not Checked Y F All Data Match Z P CSC and Postcode Match 7.3.2 MasterCard and AVS Mapping of MasterCard AVS Response Codes: MasterCard Wirecard Description A P Partial match: address matches but postal code does not. N N Neither address nor postal code match. R E Error: Retry - system unable to process. S U AVS currently unavailable. U U No data from issuer authorization system. W P CSC and postal code match. X F For U.S. addresses, nine-digit postal code matches, address does not. For addresses outside U.S., postal code matches, address does not match. Y F For U.S. addresses only: five-digit postal code and address match. Z P For U.S. addresses only: five-digit postal code matches, address does not match. Version 3.5.0 99

7.3.3 Visa and AVS Visa applies different AVS codes for international and domestic address checks. These follow the Visa standard AVS codes. Visa Type Wirecard Description A Domestic P Address information matches but postal code does not match. B International P Street address matches, but postal code not verified. Returned for non U.S.-issued Visa card only. C International N Street address and postal code do not match. Returned for non U.S.-issued Visa cards only. D International F The match is exact: both the address and the postal codes match. No representment rights. E Domestic E AVS data is invalid or AVS is not allowed for this card type. G International U Address information is unavailable, or the issuer does not support AVS. Acquirer has representment rights. I International U Address information is unavailable, or the issuer does not support AVS. Acquirer has representment rights. N Domestic P The match is not exact, either because the postcode and/or the addresses do not match. M International U The match is exact: both the address and the postcodes match. No representment rights. P International U Postal code matches, but street address not verified. Returned for non U.S.-issued Visa cards only. R Domestic F System unavailable S Domestic N U.S. issuing bank does not support AVS. U Domestic U Address information unavailable. Returned if the U.S. bank does not support non-u.s. AVS or if the AVS in a U.S. bank is not functioning properly. W Domestic P Street address does not match, but 9-digit postal code matches X Domestic F Street address and 9-digit postal code match. Y Domestic F Street address and 5-digit postal code match. Z Domestic P Postal code information matches but address information does not match. 100 Version 3.5.0

Card Processing 8 Glossary 3-D Secure The 3-D Secure protocol underlies a new Visa and MasterCard payment service designed to enhance and validate payments made through the Internet. 3-D Secure is an authentication technology that uses Secure Sockets Layer (SSL) encryption and a Merchant Server Plug-in to pass information and query participants to authenticate the Cardholder during an on-line purchase, and to protect payment card information as it is transmitted via the Internet. 3-D Secure is based on the threedomain model with an Issuer, Acquire and Interoperability domain Access Control Server(ACS) Account holder Authentication Value (AAV) Acquirer Acquiring Bank Address Verification Service (AVS) Authorization Code Bank Identification Number (BIN) Cardholder The Access Control Server (ACS) is a component of the Issuer Domain. It authenticates a specific card number related to card transactions. A variable length, 32-byte value unique to Secure Payment Application (SPA) that is generated by the issuer's SPA server for each on-line transaction and is passed to the merchant via the Universal Cardholder Authentication Field (UCAF). It can also be passed through the CAVV field of the 3-D Secure messages. A bank or company that acquires data relating to transactions from a merchant or card acceptor for processing. A bank that receives the card transactions and then settles with the issuing banks. Bank that signs up / enables the merchant to process transactions. Checks to see that the billing address given by the customer matches the credit card. For every transaction request sent to the Wirecard system a response message is generated which includes an Authorization Code generated by the card issuing bank as proof that the transaction authorization request was acknowledged or declined. This code is helpful and can later be included in a scheduled Capture or Refund request. But as it is not required in the internal Wirecard processing flow, it can be omitted from subsequent XML request messages posted to the Wirecard system, with one exception: Notification Requests must include the original Authorization Code or a code returned by voice call from the issuer s Authorization Center. The first six digits of a Visa or MasterCard account number. This number is used to identify the card issuing institution. An individual or business that has established an account with a credit or debit card issuer. A cardholder is eligible to initiate a payment card transaction. Version 3.5.0 101

Cardholder Authentication Verification Value Card Verification Value (CVV2) Card Verification Code (CVC2, CVV2 or CID) Certificate A cryptographic value generated by the ACS to provide a way during authorization processing for VisaNet to rapidly validate the integrity of certain values copied from the Payer Authentication Response to the authorization request and to prove that authentication occurred. Three-digit security number that is printed on the back of most Visa credit cards. Requiring this number on order checkouts can reduce credit card fraud and chargeback instances significantly when used in addition to AVS protection. Numeric security code that is printed on the back of MasterCard, VISA and American Express credit cards. Requiring this number on order checkouts can reduce credit card fraud and chargeback instances significantly when used in addition to AVS protection. Certificates are an essential part of a public key crypto-system. The principle of a public key crypto-system is based on the use of so-called key pairs (a public key and a private key). It is thereby very difficult to derive the private key from the public key. The public key can be made public.the public key of the addressee is used for encrypting a message to an addressee. The addressee uses his private key to decrypt the message. Only the addressee can decrypt the message, because his public key was used to encrypt the message and only he/she has the corresponding private key. This mechanism is applied in the SSL protocol to transfer session keys as part of the 3-D Secure protocol. The private key is used during the transmission of the data, this is called a digital signature. The data can be decrypted again by means of the public key of the sender. The sender is known. This mechanism is used in the XML signature part of the 3-D Secure protocol. Certificates are the authenticated form of a public key, binding the public key to its user. The authenticity of a public key is protected by the private key from a higher authority called a CA (Certificate Authority) such as Verisign or VISA, for example. Credit Card Processor A company that performs authorization and settlement of credit card payments, usually handling several types of credit and payment cards (such as Visa, MasterCard). If merchants wish to sell their products to cardholders, they retain the services of one or more processors who handle the credit cards that the merchant wishes to accept. When a merchant retains the services of a credit card processor, it is issued a merchant ID. Holdback Installment Transaction Also referred to as a reserve. This is a fee held back from a merchant's credit card transactions to cover any possible charge backs, and other disputed charges that a merchant may encounter. Usually, after a time, the hold backs are returned to the merchant. A single purchase of a product or service which is billed at interval agreed between cardholder and merchant to a credit card account. See also the Visa Best Practice Guide for more details. 102 Version 3.5.0

Card Processing Issuing Bank Market Segment Merchant OCT Pending Point Of Sale terminal (POS) Presentment Real-Time Processing Recurring Billing Recurring Transaction Retrieval Request Reversal Also known as an "Issuer". This is the bank that maintains a consumer's credit card account and will pay out to a merchant's account when the consumer makes a credit card purchase. At the end of the month the issuing bank will bill the customer for the debt. A particular market group that has its own distinct customer profile and buyer characteristics so that it can be targeted separately from other market segments for marketing purposes. Collective term applied to retailers with online store (web shop). Original Credit Transactions (formerly CFT - Credit Funds Transfer). Collective term which includes Visa s OCT and MasterCard s Payment Transaction (PT). A card transaction is said to be pending when it is waiting to be captured by the acquiring bank. For example, the return value pending (<FunctionResult>PENDING</FunctionResult>) in a purchase transaction response message indicates that the transaction has been completed successfully and but is waiting to be processed (e.g. at the end of the day). Electronic device used by retail businesses to process card transactions. If the customer is present, they swipe or slide their card through the machine. A clearing record that an acquirer presents to an issuer through interchange, either initially (a first presentment) or after a chargeback (a re-presentment). The processing of a card transaction immediately after the purchase has been made. Real-Time is the preferred choice for Internet-based merchants. See Recurring Transaction Transactions for which a cardholder grants permission to the Merchant to periodically charge his account number for recurring goods or services.the multiple transactions are processed at predefined intervals which may not exceed more than one year between transactions. See also the Visa Best Practice Guide for more details. An issuer's request for a transaction receipt, which could include the original, a paper copy or facsimile, or an electronic version thereof. An online financial transaction used to negate or cancel a transaction that has been sent through interchange in error. Version 3.5.0 103

SSL Sales Draft Terminal ID Universal Cardholder Authentication Field XSD XML Secure Sockets Layer: A cryptographic protocol developed by Netscape Communications Company to confidentially transmit information over open networks such as the Internet. See also Transport Layer Security (TLS). SSL can be situated in the list of communication protocols such as HTTP, SMTP, Telnet, FTP, Gopher and NNTP, and the connection protocol TCP/IP. It is used by the HTTPS access method. The sockets part refers to the sockets method for the transmission of data between a Customer and a server program in a network. SSL uses the public/private key encryption system by RSA, which also implies the use of a digital certificate. A paper record evidencing the purchase of goods or services by a cardholder. In the payment card industry, a number provided to a merchant by a card processor when that merchant retains the services of that card processor to uniquely identify a terminal. Also sometimes called the terminal number. A card processor may assign several terminal IDs to a given merchant's terminals although that merchant has a single merchant ID with that processor. A universal, multi-purpose data transport infrastructure that is used to communicate authentication information among cardholder, issuer, merchant and acquirer communities. XML Schema Definition EXtensible Markup Language - an independent software tool designed to carry and transmit information. 104 Version 3.5.0

Card Processing Appendix A: Error Codes The error code is returned by the core system and uses a number element of the response XML message. The are three different error types: Data error System error Rejected While the data and system errors are generated by the payment gateway (Wirecard backend), rejected error messages are returned by an acquirer and signal a malfunctioning that originates in the Wirecard platform. The following table contains all the Wirecard error codes and descriptions that might be returned while sending transaction requests. Error Code Description Meaning 0 Successful system entry. Transaction OK. 2 Call Voice Authorization Number. Voice authorization is not possible in case of Internet payment. 3 Invalid Merchant Number. Invalid Merchant Number. 4 Retain Card. Retain Card. 5 Authorization Declined. It is not possible to book the given amount from the Credit account, e.g. limit is exceeded. 6 Error in Sequence Number. Error in sequence number while communicating with the CC company. 8 Honnor with ID The transaction was approved by additional ID processing 9 Wait Command. Wait Command. 10 Partial Approval The transaction was partially approved. Please contact the acquiring processor for further information. 12 Invalid transaction. Invalid transaction. 13 Invalid amount. Invalid amount. 14 Invalid card. Invalid card. 15 Unknown card issuer The card issuer ID provided is unknown in the payment industry. 17 Customer cancellation The cardholder cancelled the transaction. 19 Try transaction again later. The issuing system is currently unavailable. Please try again later. 20 Incorrect response (error in the issuer area) The issuing system responsed incorrectly. 21 No action taken. No action taken. 22 Stop Payment Purchase Order The subscription was stopped by the cardholder. 23 Revocation of the authorized order The cardholder rejected that authorized purchase. Version 3.5.0 105

Error Code Description Meaning 24 Revocation of all authorized orders The cardholder rejected all authorized purchases referencing to that payment. 25 Unable to locate record in file The issuing system could not reference the transaction transferred. 26 Duplicate record, previous record replaced. The validation function showed duplicate processing and rejected. 27 Edit error in file update field The issuing system could not update and rejected the processing. 28 Access to file unauthorized An unauthorized processing occurred. 29 Unable to update file The issuing system could not update and rejected the processing. 30 Format Error. Format Error. 31 Acquirirng Institution Identifier unknown The issuing institute rejected the transaction because of incorrect values. 32 Partial Reversal The transaction was partially reversed. 33 Card expired. Card expired. 34 Suspicion of Manipulation. Suspicion of Manipulation. Maybe the CVD code is wrong. 35 Cash service not available. The cash service is not enabled. 36 Cash request exeeds issuer limit. The amount exceeds the limit given. 37 Decline for CVV2 failure The CVV2 value in the transaction is invalid. 38 Number of PIN entry attempts The PIN was entered too many times. exceeded. 40 Requested function not supported. Requested function not supported 41 Lost card. The card number used is indicated as lost. 43 Stolen Card - pick up. Stolen Card, pick up. 49 Transaction not permitted to cardholder. 51 Issued funds or credit limit exceeded. The cardholder is not allowed to make requested transaction. The transaction ammout exceeds the available fund or the card s credit limit. 52 No checking account. The account used is not defined for checking account. 53 No savings account The account used is not defined as savings account 54 Expired card. The card has expired. 55 Incorrect PIN. Incorrect PIN 56 Card not in authorizer's database. Card not in authorizer's database 57 No Referencing Transaction. Referencing transaction was not carried out with the card which was used for the original transaction (e.g. reversal, booking pre-authorization,...). 58 Terminal ID Unknown. Given Terminal has no valid entry at the Credit Card Institute. 59 Suspected fraud. The issuer rejected the transaction for suspected fraud. 106 Version 3.5.0

Card Processing Error Code Description Meaning 60 Card acceptor must contact acquirer 61 Exceeds cash withdrawal floor limit. 62 Restricted Card. Restricted Card. 63 No compliance with security regulations. Response reason not specified. Please contact your acquirer. The given floor limit is exceeded. Please execute an online transaction to prove the card's balance. The card /use of card does not comply with security regulations. 64 Referencing amount too high. Transaction amount of the referencing transaction is higher than the transaction amount of the original transaction. 65 Exceeds witrhdrawal count limit. The withdrawal limited has been execeeded. 68 Response did not reach destination or received too late. 69 Blocked, first used. The transaction is from a new cardholder and the card has not been properly unblocked The response message to the initial transaction request was not received by the processing system on time. Error occurred in the card setup processing. 71 PIN not changed The online PIN change was not successful.. 72 Invalid/nonexistent To Account Error in the card processing. specified. 73 Invalid/nonexistent From Account Error in the card processing. specified. 74 Invalid/nonexistent account Error in the card processing. specified (general). 75 PIN entered incorrectly too often. PIN entered incorrectly too often. 77 PIN entry necessary. PIN entry necessary. 78 Stop Payment Order This error code pertains to recurring or installment payments. The transaction was declined or returned because the cardholder requested the issuer to stop a specific recurring or installment payment transaction. 79 Revocation of Authorization Order This error code pertains to recurring or installment payments.the transaction was declined or returned because the cardholder requested the issuer to stop a specific recurring or installment payment transaction for a specific merchant account. 80 Amount no longer available. Amount no longer available. 81 Message-flow error. Message-flow error. 82 Authorization center not available for 60 seconds. The transaction could not be authorized over a period of 60 seconds due to lack of connection to authorization centre. Version 3.5.0 107

Error Code Description Meaning 83 Authorization center not available for 300 seconds. 84 Negative CAM, dcvv, icvv, or CVV results. 85 No reason to decline a request for account number verification, address verification, CVV2 verification, or a credit voucher or merchandise return. The transaction could not be authorized over a period of 300 seconds due to lack of connection to authorization centre. The card identifying values do not match. The issuing system did not specify the reason for rejecting but could exclude some. 86 PIN Validation not possible. The PIN validation could not be accomplished. 87 Purchase Amount Only, No Cash Back Allowed. The cash back processing is not allowed. 88 Automatic re-initialization is required (terminal). 89 Automatic re-initialization is required (user). Automatic re-initialization is required (terminal). Automatic re-initialization is required (user). 90 Cryptographic failure The issuing system lead to an encryption failure. 91 Card issuer temporarily not reachable. Card issuer temporarily not reachable. 92 Card Type not Processed by Authorization Centre. 93 Transaction cannot be completed due to legal violation. 96 Processing Temporarily not possible. The card type is not processed by the authorization centre. The transaction request conflicts with applied law. Processing temporarily not possible 97 Security Breach. Security breach 98 Date and Time Not Plausible. Date and time not plausible 99 Error in PAC Encryption Detected. Error in PAC encryption detected 200 Mandatory elements are missing. Missing elements in XML-Request. 201 Terminal acquisition failure An unlocked terminal was not found within the time allotted for locking a terminal. 202 Transaction processing refused. An unlocked brick was not found within the time allotted for locking a brick. 203 Time-out while Contacting Credit Card Processor Time-out while contacting CC processor. 204 Time-out while Making Transaction Reversal Time-out while making transaction reversal. 205 Invalid Config Number Content of ConfigNumber must be hexadecimal with a size of 0 to 16 characters. 206 Invalid Business Case Signature Content of BusinessCaseSignature must be hexadecimal with a size of 0 to 16 characters. 108 Version 3.5.0

Card Processing Error Code Description Meaning 207 Invalid FunctionID Content of FunctionID must be alphanumerical with a size of 0 to 32 characters. 208 Invalid JobID Content of JobID must be alphanumerical with a size of 0 to 32 characters. 209 Invalid Content of TransactionID must be alphanumerical with a size of 0 to 32 characters. 210 Invalid CountryCode Content of CountryCode must be capital with a size of 2 characters. 211 Invalid Amount Content of Amount must be numerical with a size of 1 to 9 digits. 212 Invalid Currency Content of Currency must be capital with a size of 3 characters. 213 Invalid Credit Card Number Content of CreditCardNumber must be numerical with a size of 13 to 16 digits. 214 Invalid ExpirationYear Content of ExpirationYear must be numerical with a size of 4 digits. 215 Invalid Expiration Month Content of ExpirationMonth must be numerical with a size of 2 digits. 216 Invalid Card Holder Name Content of CardHolderName must be ASCII with a size of 1 to 80 characters. 217 Invalid IP Address Content of IPAddress must be numerical with dots with a size of 0 to 15 characters. 218 Invalid GuWID Content of GuWID must be alphanumerical with a size of 21 to 24 characters. 219 Invalid Authorization Code Authorization Code is usually numerical with 6 digits. 220 Invalid CVC number Content of CVC must be numerical with a size of 3 to 4 characters. 221 Invalid Luhn checksum Invalid Luhn checksum 222 Expired card Expiration date invalid. 223 Unknown Currency The requested currency is not listed in data base. 224 No referenced transaction Could not find referenced transaction for GuWID. 225 Invalid elements Invalid XML tag elements. 226 Invalid transaction flow Referenced transaction is of wrong type 227 Invalid transaction type This transaction type is not allowed for this specific Business Case 228 Wrong Recurring Transaction-Type Error in XML data stream (in the recurring part) 229 Invalid commerce type Content of 'CommerceType' must be one of 'ecommerce', 'MOTO' or 'CustomerPresent'. 230 Referenced transaction failed Referenced transaction type failed Version 3.5.0 109

Error Code Description Meaning 234 Invalid content Content of 'Usage' must be alphanumerical with a size of 0 to 256 characters. 235 Unequal Amount TRANS_AMOUNT must be equal to amount of referenced transaction in case of REVERSAL or CAPTURE. 236 Unequal Currency CUR_CODE must be equal to referenced transaction in case of BOOKBACK, BOOKPREAUTH, CAPTURE or 237 Unequal Authorization Code ACQ_AUTHORIZATION must be equal to authorization code of referenced transaction. 238 Unequal Country Code TRANS_COUNTRY_CODE must be equal to country code of referenced transaction. 239 Referenced amount unequal Referenced amount must be equal or less to amount of referenced Transaction in case of AMEX Capture 240 Unknown credit card type Credit card type for card no. unknown / rejected. 241 Terminal not available Terminal for the credit-card type + the currency is not available. 242 Terminal not ready Terminal for the credit card type + the currency is not ready. 243 Amount larger The sum of all bookbacks must be equal or less to amount of referenced transaction in case of 244 Amount smaller The requested amount is smaller than the minimum amount. 245 Transaction processing not possible Processing functions BOOKBACK, REFUND and REVERSAL not allowed for terminal (credit card) 246 Black listed Credit Card number. Credit Card was rejected because of suspicious pattern. 247 WD blacklist check failure. Wirecard blacklist check - failure 1. 248 WD blacklist check failure. Wirecard blacklist check - failure 2. 249 Credit restriction violation Credit restriction violation 250 System error. System error. 251 No permission to use the requested service 252 Merchant Blacklist - Reason 502 Declined by Wirecard risk management - based on merchant's blacklist (no information for cardholder!) 253 WD Blacklist Error Declined by Wirecard risk management (no information for cardholder!) 254 WD Blacklist Error 2 Declined by Wirecard risk management (no information for cardholder!) 255 Merchant Blacklist - Reason 501 Declined by Wirecard risk management - based on merchant's blacklist (no information for cardholder!) 110 Version 3.5.0

Card Processing Error Code Description Meaning 256 Entry found in OFAC Specially Designated Nationals list (SDN). Declined by Wirecard risk management (no information for cardholder!) 257 Reserved for Risk Management Declined by Wirecard risk management (no information for cardholder!) 258 Reserved for Risk Management Declined by Wirecard risk management (no information for cardholder!) 259 Reserved for Risk Management Declined by Wirecard risk management (no information for cardholder!) 260 Credit card number not allowed in demo mode 261 Credit card number not allowed outside demo mode Only demo card number is allowed for this currency in demo mode. Use of demo card number is only allowed in demo mode. 262 Unsuccessful demo run Operation failed due to use of demo card number '4200000000000'. 270 Invalid credit card. Credit card number did not pass Cybersource basic checks. 271 Invalid data. Data provided to Cybersource is not consistent with the request. 272 Missing field. Request provided to Cybersource is missing a field. 273 Missing required field(s). Request is missing a required field(s). 275 Score result exceeds Cybersource Score result exceeds the score threshold. 280 SC1-AVS has a negative result SC1 risk management declines 281 SC1-DELPHI/Score1 and AVS SC1 risk management declines have negative results 282 SC1-DELPHI/Score1 has a SC1 risk management declines negative result 283 SC1-System Error SC1 risk management declines 284 SC1-Data Error SC1 risk management declines 285 SC1-Missing required parameter SC1 risk management declines 286 SC1-No Delphi/Score1 (0) SC1 risk management declines 287 reserved for SC1 SC1 risk management declines 288 SC1 - reserved GICC SC1 risk management declines 289 SC1 - reserved for future use SC1 risk management declines 290 Unequal BC Signature The Business Case Signature has to be equal to the referencing transaction. 301 EBS blacklist check failure. EBS blacklist check failure 302 EBS scoring analysis failure. EBS scoring analysis failure 303 US AVS check failed - no match in US AVS check failure address or zip code 304 US CVV2 check failure. US CVV2 check failure 305 US blacklist check failure. US blacklist check failure 306 efalcon scoring analysis failure. efalcon scoring analysis failure 307 US Authorization Declined. US Authorization Declined Version 3.5.0 111

Error Code Description Meaning 309 US AVS check error - Parameters missing or invalid 310 US AVS check failed - address matches 311 US AVS check failed - 9 digit zip code matches 312 US AVS check failed - 5 digit zip code matches Parameters inside <ADDRESS> are checked and not found or in a wrong format. American AVS declines American AVS declines American AVS declines 314 US AVS check - address American AVS declines information is unavailable 315 US AVS check failed - system American AVS declines unable to process 316 US AVS check failed not American AVS declines supported 317 US AVS check failed - not American AVS declines supported for this industry 318 US AVS check failed - not American AVS declines performed 319 US AVS check failed - unknown American AVS declines response from issuer 320 US AVS check failed - system error American AVS declines 321 SC2 Location not found SC2 risk management declines 322 SC2 Only part of address matches SC2 risk management declines 323 SC2 Bad credit score SC2 risk management declines 324 SC2 System Error SC2 risk management declines 325 Blocked by Wirecard Declined by Wirecard risk management (no information for cardholder!) 340 Wirecard Negative List Declined by Wirecard risk management (no information for cardholder!) 351 Pick up card. Pick up card 352 Pick up card - special condition. a special condition happened, pick up the card 353 Card lost - pick up. Card was lost by cardholder 354 Stolen Card - pick up. card holder declared card as stolen 355 Do not honor card. Do not honor card 400 SFC system error Technical error at the acquirer 401 Transaction input error This error code is not uses yet. 402 Not authorized transaction This error code is not uses yet. 403 Authorization refused due to high risk 404 Authorization refused due to exceeding authorization Declined by Wirecard risk management (no information for cardholder!) The authorization of this transaction has been exceeded 405 Third party authorization failed This error code is not uses yet. 406 Credit request rejected due to This error code is not uses yet. exceeding the credit 112 Version 3.5.0

Card Processing Error Code Description Meaning 407 Canceled by Acquirer Safecharge fraud-driven cancellation / bookbacks (status changed manually). 450 XML Document Invalid There is an error in the XML data stream 451 BC signature not found The wrong Business Case Signature was used 452 Config Number not found for BC signature The wrong Business Case Signature or the wrong config.ini was used 453 Partially successful batch update Partially successful batch update 454 Batch not processed Batch not processed 455 OCT (formerly CFT) transaction is not supported 456 Attribute 'type' of a function element does not conform to the specification. Issuer / Card Organization do not support the OCT/CFT transaction. Attribute 'type' must have the value 'cft' if provided. 457 Card has not been processed yet. Card needs to be previously used by the processor before the OCT/CFT transaction can be used. 458 Inconsistent referenced transaction information found. 459 Function is not supported. 500 Time-out while using the Wirecard Time-out while using the Wirecard applet. applet. 501 Client Communication Link Failure A Problem occurred during the communication to the client 502 Client Communication Link Failureprocessed 507 General Risk Management Rejection 508 Missing input data for Risk Management 510 The country of the Issuer does not match with the country of the transaction. 511 Unknown error received from the acquirer A Problem occurred during the communication to the client General risk management rejection Missing input data for the Risk Management The country of the Issuer does not match with the country of the transaction. An unknown error is received from the acquirer. 520 The card velocity check failed. The sum of all submitted transactions exceeds the permissible limit. 521 The card velocity check failed. The sum of all authorized amounts exceeds the permissible limit. 522 A system error prevented enrollment from completing. This card is not eligible for 3-D Secure processing. Card should be accepted for payment. Merchant may not claim a liability shift on this transaction under any circumstances. Version 3.5.0 113

Error Code Description Meaning 523 Unable to verify enrollment. This card is not eligible for 3-D Secure processing. Card should be accepted for payment. Merchant may not claim a liability shift on this transaction under any circumstances. 524 Cardholder not participating. This card is eligible but not enrolled in the 3-D Secure program. It does not require authentication.merchant may claim liability shift with the ECI code if allowed by the Card Association. 525 Verification failed. Cardholder failed or cancelled 3-D Secure authentication. 526 Transaction processing refused. It is not possible to process the transaction using requested 'Recurring Type'. 527 Attribute 'minorunits' of the 'Amount' element does not conform to the specification. The attribute 'minorunits' must be one digit. 528 Amount 'minorunits' refused. The minor unit of currency 'XXX' is '?' according to ISO 4217:2001. Value '0' means that there is no minor unit for that currency, whereas values '1','2' and '3' signify a ratio of 10:1, 100:1 and 1 000:1 respectively. 538 Sales Date out of interval A capture had been attempted outside the valid sales date interval. The default interval for a capture is 35 days following the sales date. The sales date interval can be configured per business case. Please contact Wirecard customer services at support@wirecard.com if you wish to have a sales date time interval changed. 539 Card brand is not participating. The card is not eligible for 3-D Secure processing, yet it may be accepted for payment. With transactions made on this card, the merchant may, however, not claim a liability shift under any circumstances. 700 Timeout, Diagnostic successful A Timeout has happened, which went successfully through a timeout diagnostic 701 Timeout, Diagnostic failed A Timeout has happened, which failed to run through the timeout diagnostic 711 Response contained wrong Credit Response contained wrong card number Card number. 712 Response contained wrong Response contained wrong amount amount. 713 Response contained wrong Response contained wrong currency code Currency Code. 714 Response contained wrong Trace Response contained wrong trace number Number. 715 Response contained wrong Terminal ID. Response contained wrong terminal ID 114 Version 3.5.0

Card Processing Error Code Description Meaning 716 Response contained wrong Merchant Number. 717 Response contained wrong Credit Card Institute Number. Response contained wrong VU number. Response contained wrong cctiid. 850 Scoring OK Scoring passed successfully. 900 Batch transaction pending Transaction is waiting to be sent to the acquirer. 901 Batch transaction validated Transaction is waiting to be sent to the acquirer for clearing. 902 Demo batch transaction validated Transaction is waiting to be sent to the acquirer for clearing (only for demo transactions). 903 Batch transaction was cancelled Transaction was canceled manually by Wirecard. 999 Transaction is in process Transaction is in process. 9500 Demo Transaction OK Demo transaction was successful. 10000 Internal System error Internal System error. 10001 Wrong config pair Wrong config pair. 10002 Function processing not possible Function processing not possible. 10003 Job refused Job refused. 10004 Invalid Function Invalid Function. 10005 System error System error. 10006 Customer is deactivated at Server Customer is deactivated at Server. 10007 No parameters No parameters. 10008 Corrupted HTTP Stream Corrupted HTTP Stream. 10009 Wrong Parameters Wrong Parameters. 10010 XML document contains no Data XML document contains no data. 10011 Invalid transaction Invalid transaction. 10012 Encryption of XML document failed. 10013 Could not resolve the entity mapping. Please contact Wirecard customer services at support@wirecard.com for further information. Please contact Wirecard customer services at support@wirecard.com for further information. 10020 connection timeout Connection timeout. 20000 Missing elements in XML-Request. Some elements required for successful processing of a request are missing in the XML document. Please refer to the documentation for debugging. 20001 Error mapped to ACM code (GICC code) 204. Data Error. 20030 Content of ConfigNumber is not according to the given content restrictions. Content of tag ConfigNumber must be hexadecimal with a size of 0 to 16 characters. Version 3.5.0 115

Error Code Description Meaning 20031 Content of Business Case Signature is not according to the given content restrictions. 20032 Content of FunctionID is not according to the given content restrictions. 20033 Content of JobID is not according to the given content restrictions. 20050 Content of TransactionID is not according to the given content restrictions. 20051 Content of CountryCode is not according to the given content restrictions. 20052 Content of Amount is not according to the given content restrictions. 20053 Content of Currency is not according to the given content restrictions. 20054 Content of CreditCardNumber is not according to the given content restrictions. 20055 Content of ExpirationYear is not according to the given content restrictions. 20056 Content of ExpirationMonth is not according to the given content restrictions. 20057 Content of CardHolderName is not according to the given content restrictions. 20058 Content of IPAddress is not according to the given content restrictions. 20059 Content of GuWID is not according to the given content restrictions. 20060 Content of AuthorizationCode is not according to the given content restrictions. Content of tag Business Case Signature must be hexadecimal with a size of 0 to 16 characters. Content of tag Function ID must be alphanumerical with a size of 0 to 32 characters. Content of tag Job ID must be alphanumerical with a size of 0 to 32 characters. Content of tag Transaction ID must be alphanumerical with a size of 0 to 32 characters. Content of tag Country Code must be capital with a size of 2 characters. Please provide 2 capitals according to ISO 3166-1. Content of tag Amount must be numerical with a size of 1 to 9 digits. Content of tag Currency must be capital with a size of 3 characters. Content of tag Credit Card Number must be numerical with a size of 13 to 16 digits. Content of tag Expiration Year must be numerical with a size of 4 digits. Content of tag Expiration Month must be numerical with a size of 1 to 2 digits. Content of tag CardHolder Name must be ASCII with a size of 1 to 80 characters. Content of tag IP address. It must be written in dot-decimal notation consisting of up to 15 characters in length. Content of tag GuWID must be alphanumerical with a size of 21 to 24 characters. A GuWID consists of the character 'C' followed by 21 alphanumerical digits. Content of tag Authorization Code must be alphanumerical with a size of 0 to 10 characters. Authorization Code is usually numerical with 6 digits. 20061 CVC number invalid. Content of tag CVC2 must be numerical with a size of 3 to 4 characters. 116 Version 3.5.0

Card Processing Error Code Description Meaning 20062 Content of 'RECURRING_TRANSACTION/Ty pe' is not according to the given content restrictions. 20063 Content of StartYear is not according to the given content restrictions. 20064 Content of StartMonth is not according to the given content restrictions. 20065 Content of Issue is not according to the given content restrictions. 20066 Content of 'CommerceType' is not according to the given content restrictions. 20067 Content of 'Usage' is not according to the given content restrictions. Content of 'RECURRING_TRANSACTION/Type' must be one of 'Single','Initial' or 'Repeated'. Content of StartYear must be numerical with a size of 4 digits. Content of StartMonth must be numerical with a size of 2 digits. Please provide two digits in the range of 01..12. Card Issue Number is variable length and must be 1 or 2 digits long. Content of 'CommerceType' must be one of 'ecommerce','moto' or 'CustomerPresent'. Content of 'Usage' must be alphanumerical with a size of 0 to 256 characters. 20070 Credit card number invalid. The given credit card number did not pass the check digit routine for a card number [Luhn check]. 20071 Expiration date invalid. Expiration date must not be exceeded. 20072 The requested currency is not listed in data base. Please refer to documentation or Wirecard customer service for a list of valid and accepted currencies. 20073 Invalid transaction flow The requested function is not applicable for the referenced transaction. 20080 Could not find referenced transaction for GuWID %s. 20081 Content of 'TransactionType' is not according to the given content restrictions. 20100 Transaction processing not possible. 20101 Transaction processing not possible. This error usually occurs in case of preauthorizations, captures, cancellation/reversals, when a former transaction s GuWID is required but the given GuWID is unknown to the Wirecard system or was generated for a transaction which is not accessible by the business case in use. Content of 'TransactionType' must be one of the strings 'FNC_CC_TRANSACTION' or 'FNC_CC_AUTHORIZATION'. This occurs if the user tries to capture an authorization that was not successful. Please refer to Wirecard customer service in case of further questions. This occurs if the user tries to capture a preauthorization that was not successful. Please refer to Wirecard customer service in case of further questions. Version 3.5.0 117

Error Code Description Meaning 20102 Transaction processing not possible. 20103 Transaction processing not possible. 20104 Transaction processing not possible. This occurs if the user tries to capture a preauthorization supplement that was not successful. Please refer to Wirecard customer service in case of further questions. This occurs if the user tries to reverse a transaction that was not successful. Please refer to Wirecard customer service in case of further questions. This occurs if the user tries to book back a transaction that was not successful. Please refer to Wirecard customer service in case of further questions. 20105 Transaction processing refused. TRANS_AMOUNT must be equal to the amount of the referenced transaction in case of REVERSAL or CAPTURE. 20106 Transaction processing refused. CUR_CODE must be equal to the currency used for the referenced request. 20107 Transaction processing refused. ACQ_AUTHORIZATION must be equal to authorization code of referenced request. 20108 Transaction processing refused. TRANS_COUNTRY_CODE must be equal to country code of referenced request. 20109 Transaction processing refused. Credit card type for a given card number is unknown / rejected. 20110 Transaction processing refused. The terminal required for a given transaction is not available. Please contact Wirecard customer service. 20111 Transaction processing refused. The terminal required for a given transaction is not available. Please contact Wirecard customer service. 20112 Transaction processing refused. Transaction processing refused. 20113 Transaction processing refused. The amount to be booked back has to be equal to or less than the amount of the referenced transaction. 20114 The requested amount is smaller than the minimum amount. 20115 Transaction processing not possible. The requested amount is smaller than the minimum amount. Please contact Wirecard customer service. 20117 Transaction processing refused. Transaction processing refused. 20120 Transaction processing refused. Please contact Wirecard customer service. 20121 Transaction processing refused. It is not possible to process the transaction using requested 'CommerceType'. 23000 DINVALIDCARD: The credit card number did not pass basic checks 23001 DINVALIDDATA: Data provided is not consistent with the request. Please contact Wirecard customer service for further details on the rejected card. Please contact Wirecard customer service to resolve this error. 118 Version 3.5.0

Card Processing Error Code Description Meaning 23002 The request is missing a required field. 23003 The request is missing a required field. 24997 Credit card number not allowed in demo mode. 24998 Credit card number not allowed outside demo mode. Check the following fields: customer_firstname, customer_lastname, customer_email, bill_address1, bill_country, bill_city, customer_cc_number, customer_cc_expmo, customer_cc_expyr, amount. The fields bill_state and bill_zip are required if bill_country is set to "US" or "CA". See above. Only demo card numbers are allowed in demo mode. Use of demo card numbers is only allowed in demo mode. 24999 Unsuccessful demo run. Operation failed due to use of demo card number. The credit card number used simulates a not acknowledged transaction in demo mode. 25000 The transaction was rejected by acquirer. This message should not apear. Please contact Wirecard customer service. 27000 You have no permission to use the Please contact Wirecard customer service. requested service. 27001 Transaction processing refused. This error usually occurs in case of heavy load and is caused by restrictions in the processing systems of credit card acquirers. Additional terminals can be requested from the acquirer to resolve this problem. Please contact Wirecard customer service. 27002 Transaction processing refused. Please contact Wirecard customer service. 29000 System error Please contact Wirecard customer service. 29001 Transaction processing refused. Transaction processing refused. 29002 Client communication failure. Transaction processing refused. Version 3.5.0 119

Appendix B: AVS Codes As of November 2004, AVS is supported for the following countries: United States Canada United Kingdom You can look at the AVS code returned to determine exactly why the AVS check failed. The Wirecard server returns the following codes, in the AVS_CODE element, to the merchant application in response to a transaction request, with A, N, U an F indicating AVS failure: Code letter X Y A Z N U R S E B Q F W Meaning Exact. Nine-digit zip code and address match Yes. Five-digit zip code and address match Address matches, but zip code does not Five-digit zip code matches, but address does not. No part of the address matches. Address information is unavailable. Retry. System unable to process. AVS not supported. AVS not supported for this industry. AVS not performed. Unknown response from issuer/banknet switch. Different error case in wd2 core system Nine-digit zip code matches, but address does not. 120 Version 3.5.0

Card Processing Appendix C: Airline Market Segment The Wirecard platform offers vertical market solutions for the airline industry. A typical Airline Market transaction request may contain the following elements under CC_TRANSACTION: Element Sett. Data Type Description MARKET_SEGMENT man. c This is a collection of specific market segment elements and their values. name man. an..32 This attribute defines the name of the market segment above. It must be populated with "Airline". TicketIssueDate man. MMDDYYYY This is the date the ticket was issued -month, day - year (e.g. 05172006) TicketNumber man. n..11 This is the airline ticket number, including the check digit. If no airline ticket number (IATA) is used, the element field must be populated with 99999999999. PnrFileKey con. an..10 This is the file key of the Passenger Name Record (PNR). This information is mandatory for transactions with AirPlus UATP cards. AirlineName man. an..20 This is the name of the airline. AirlineCode man. n..3 This is the airline code assigned by IATA. If no IATA accounting code is used, the element field must be populated with 999. CheckDigit con. n..2 This is the airline ticket check digit. It is required only for the Diners cards. AgentCode man. n..8 This is the agency code assigned by IATA. If no IATA code is used, the element field must be populated with 99999999. AgentName man. an..26 This is the agency name. RestrictedTicket man. n 1 0 = No restriction 1 = Restricted (non-refundable) PassengerName man. an..29 This is the name of the passenger. OriginatingAirport opt. a 3 This is the originating IATA airport code. FlightNumber con. a..6 Flight number of 1st segment - DCI transactions only. NetAmountNonTaxable man. n..15 This field must contain the net amount of the transaction in the specified currency for which no tax is levied. Two decimal places are implied. If the complete amount of the transaction is not taxable, the value of this filed is equal to the gross transaction amount. VatEntry man. c This is a collection element containing various tax related parameter fields. id man. n..1 This is an attribute of the element <VatEntry>. It allows merchants to post more than one VatEntry collection with the transaction request. The indicator must be numerically incremented. Examples: <VatEntry id= 1 >, <VatEntry id= 2 >, etc. Version 3.5.0 121

Element Sett. Data Type Description NetAmountTaxable man. n..15 This field must contain the net amount of the purchase transaction in the specified currency for which the tax is levied. Two decimal places are implied. If this field contains a value greater than zero, the indicated value must differ to the content of the transaction amount. VatAmount man. n..9 This field must contain the amount of the Value Added Tax levied on the transaction amount in the specified currency. VatPercentage man. n..5 This field must contain the percentage of the Value Added Tax (with two decimal places) levied on the transaction amount. VatDeductible man. n..1 This field specifies the kind of tax. Possible values are: 0 = no VAT 1= non-deductible city tax 2 = non-deductible state or provincial tax 3 = non-deductible national tax 6 = deductible city tax 7 = deductible state or provincial tax 8 = deductible national tax OtherTaxes man. n..9 This field must contain all taxes in the specified transaction currency not included in the VAT amount fields.two decimal places are implied: Example: USD 9 = 900. Relevant for AirPlus acceptance of UATP transactions only. ITINERARY man. c This is the collection of multiple segments. Segment man. c This is a collection of segment information. This element can be repeated for multiple segments. id man. n..2 This is an attribute of the segment collection. It should be numerically incremented for the subsequent segments. CarrierCode man. a 3 This is the 2-letter airline code (e.g. LH, BA, KL) supplied by IATA for each leg of a flight. ClassOfService man. a..3 This element is used to distinguish between First Class, Business Class and Economy Class, but also used to distinguish between different fares and booking codes within the same type of service. StopOverCode con. n 1 0 = allowed 1 = not allowed LegDepartureDate man. MMDDYYYY This is the departure date for a given leg. Destination man. a 3 This is the destination airport code. IATA assigns the airport codes. FareBasis opt. an 6 This element represents a specific fare and class of service with letters, numbers, or a combination of both. 122 Version 3.5.0

Card Processing Example: <CC_TRANSACTION"> <MARKET_SEGMENT name="airline"> <TicketIssueDate>05172006</TicketIssueDate> <TicketNumber>44733454295</TicketNumber> <AirlineName>Lufthansa</AirlineName> <AirlineCode>999</AirlineCode> <CheckDigit>5</CheckDigit> <AgentCode>34456853</AgentCode> <AgentName>Sita Travels</AgentName> <RestrictedTicket>1</RestrictedTicket> <PassengerName>John Doe</PassengerName> <OriginatingAirport>MUC</OriginatingAirport> <FlightNumber>7104</FlightNumber> <NetAmountNonTaxable>2000</NetAmountNonTaxable> <VatEntry id="1"> <NetAmountTaxable>5000</NetAmountTaxable> <VatAmount>950</VatAmount> <VatPercentage>19.0</VatPercentage> <VatDeductible>8</VatDeductible> </VatEntry> <VatEntry id="2"> <NetAmountTaxable>1000</NetAmountTaxable> <VatAmount>159</VatAmount> <VatPercentage>15.9</VatPercentage> <VatDeductible>7</VatDeductible> </VatEntry> <VatEntry id="3"> <NetAmountTaxable>1000</NetAmountTaxable> <VatAmount>60</VatAmount> <VatPercentage>6</VatPercentage> <VatDeductible>6</VatDeductible> </VatEntry> <OtherTaxes>15</OtherTaxes> <ITINERARY> <Segment id="1"> <CarrierCode>LH</CarrierCode> <ClassOfService>Y</ClassOfService> <StopOverCode>1</StopOverCode> <LegDepartureDate>07262003</LegDepartureDate> <Destination>BOM</Destination> <FareBasis>YCADCA</FareBasis> </Segment> </ITINERARY> </MARKET_SEGMENT> </CC_TRANSACTION> Version 3.5.0 123

Appendix D: Car Rental Market Segment Wirecard offers credit card processing for Car Rental specific data. However, it is not available for all acquirers. Please contact your Wirecard sales representative for further details. The Car Rental Market Segment may contain the following elements under CC_TRANSACTION: Element Sett. Data Type Description MARKET_SEGMENT man. c This is a collection of specific market segment elements and their values. SUPPLIER_INFO man. an..32 This attribute defines the name of the market segment above. It must be populated with "CarRental". Supplier man. an..20 This is the name of the car rental company. Example: Acclaimed Rent-a-Car Ltd. SupplierAddress opt. an..50 This is the address associated with the car rental company: Example: 10 Sup Avenue. SupplierCity opt. an..30 This is the city associated with the car rental company. Example: Tampa SupplierState opt. a2 This is the state associated with the car rental company. Applies only to addresses in the USA and Canada. Example: FL SupplierCountry man. a2 This is the country associated with the car rental company. RENTER_INFO man. c This is a collection containing information about the person renting the vehicle. RenterName man. an..40 This is the name of the renter.example: John Doe. PICKUP_LOCATION man. c This is a collection of car pickup elements and their values. PickupLocationID opt. an..40 This is an alphanumeric value of the supplier which uniquely identifies the pickup and dropoff locations. PickupCity man. an..30 This is the city where the car is picked up. PickupState opt. a2 This is the state in which the car is picked up. PickupCountry man. a2 This is the country in which the car is picked up. PickupDate man. YYYY-MM- DD This is the date when the car is picked up: Example: 2008-08-28 PickupTime man. HH:mm 08:00 DROPOFF_LOCATION man. c This is a collection of car dropoff elements and their values. DropoffLocationID man. an..30 This is an alphanumeric value of the supplier which uniquely identifies the pickup and dropoff locations. DropoffCity opt. a2 This is the city where the car is dropped off. DropoffState man. a2 This is the state in which the car is dropped off. 124 Version 3.5.0

Card Processing Element Sett. Data Type Description DropoffCountry man. YYYY-MM- DD This is the country in which the car is dropped off. DropoffDate man. HH:mm This is the date when the car is dropped off: Example: 2008-08-28 RentalAgreementReference opt. an..30 This is the rental agreement/reservation number. RentalRate opt. n..13 This is the daily or weekly rate presented in minor units. RentalRatePeriod man. a1 The period can have one of two values: D = day W = week Maximum Free Distance opt. n..6 This is the free distance in unit of measure provided in the unit of measure attribute. RatePerDistance opt. n..13 This is the rate for distance provided in kilometres or miles. DistanceTravelled opt. an..6 This is the distance travelled form pickup location to dropoff location provided in kilometres or miles with either of the two values: M = miles K = kilometre VehicleClassCode opt. an..10 This is the vehicle class code as provided by the car rental agency. VehicleProgramCode opt. an..10 This is the vehicle program code as provided by the car rental agency. VehicleregsitrationNumber opt. an..10 This is the vehicle registration number. INSURANCE_CHARGES man. c This is a collection of insurance charges per rental. CollisionDamageWaiver opt. n..13 This is the charge for CDW insurance. It can be an amount for a deductible of full coverage contract. TheftProtection opt. n..13 This is the charge for theft protection when a car is lost, if not already included in CDW insurance. LiabilityInsurance opt. n..13 This is the charge for a liability insurance supplement. PersonalPropertyInsurance opt. n..13 This is the charge for a personal property insurance. PersonalAccidentInsurance opt. n..13 This is the charge for a personal accident insurance. OtherInsurance opt. n..13 This is the charge for other kind of insurances provided by the car rental agency or third party agencies. OTHER_CHARGES man. c This is a collection of other charges per rental. NonInsuranceCharge opt. n..13 This is the charge in case of damage or deductible charge FuelCharge opt. n..13 This is a charge for fuel. It eliminates the need to return the car with a full tank. Version 3.5.0 125

Element Sett. Data Type Description AirportCharge opt. n..13 This is a charge for picking up or dropping off a car at an airport location. DropoffCharge opt. n..13 This is a charge for dropping off a car at a location other than the pickup location. AdditionalDriverCharge opt. n..13 This is the charge for an additional driver. ExtraEquipmentCharge opt. n..13 This is the charge for extra equipment such as child seat, snow chains, winter tyres, ski rack etc. OtherCharge opt. n..13 These are miscellaneous costs which may be incurred and charged to a cardholder TAXES man. c This is a collection of taxes levied per rental. AirportTax opt. n..13 This is the special airport tax. NationalTax opt. n..13 This is the national tax StateTax opt. an..13 This is the state tax. ValueAddedTax opt. n..13 This is the standard sales tax/ value added tax (VAT). OtherTaxes opt. n..13 This field is reserved for other local taxes. NoShow man. n1 This is a value enter if a customer does not pick up the booked vehicle. The follwoing values can be used: 0 = not applicable 1 = no show (customer does not show up). The default setting is 0. CustomerServiceNumber opt. an..32 This is the customer service number. VoucherNumber opt. an..10 The is the voucher number, if available VoucherValue opt. an..13 This is the voucher value expressed in the local currency. 126 Version 3.5.0

Card Processing Example: <CC_TRANSACTION"> <MARKET_SEGMENT name="carrental"> <SUPPLIER_INFO> <Supplier>Acclaimed Rent-a-Car Co.</Supplier> <SupplierAddress>10 SupAvenue</SupplierAddress> <SupplierCity>Tampa</SupplierCity> <SupplierState>FL</SupplierState> <SupplierCountry>US</SupplierCountry> </SUPPLIER_INFO> <RENTER_INFO> <RenterName>John Doe</RenterName> </RENTER_INFO> <PICKUP_LOCATION> <PickupLocationID>Tampa/Shuttle (TPAO71)</PickupLocationID> <PickupCity>Tampa</PickupCity> <PickupState>FL</PickupState> <PickupCountry>US</PickupCountry> <PickupDate>2005-11-31</PickupDate> <PickupTime>08:00</PickupTime> </PICKUP_LOCATION> <DROPOFF_LOCATION> <DropoffLocationID>Tamarindo Beach (LIRC71)</DropoffLocation> <DropoffDate>2005-11-07</DropoffDate> <DropoffTime>08:00</DropoffTime> <DropoffCity>Guanacaste</DropoffCity> <DropoffCountry>CR</DropoffCountry> </DROPOFF_LOCATION> <RentalAgreementReference>LIRC71HAG</RentalAgreementReference> <RentalRate period="d">24900</rentalrate> <MaximumFreeDistance uom="m">500</maximumfreedistance> <RatePerDistance uom="m">211</rateperdistance> <VehicleClassCode>L</VehicleClassCode> <VehicleRegistrationNumber>CA 4545</VehicleRegistrationNumber> <INSURANCE_CHARGES> <CollisionDamageWaiver>2000</CollisionDamageWaiver> <TheftProtection>1220</TheftProtection> <LiabilityInsuranceSupplement>120</LiabilityInsuranceSupplement> <PersonalPropertyInsurance/> <PersonalAccidentInsurance/> </INSURANCE_CHARGES> <OTHER_CHARGES> <NonInsuranceCharge>2399</NonInsuranceCharge> <FuelCharge>1264</FuelCharge> <AirportCharge>1264</AirportCharge> <DropoffCharge>99</DropoffCharge> <AdditionalDriverCharge>1264</AdditionalDriverCharge> <ExtraEquipmentCharge>1264</ExtraEquipmentCharge> </OTHER_CHARGES> <TAXES> <AirportTax>985</AirportTax> <NationalTax>1185</NationalTax> <OtherTaxes>1299</OtherTaxes> </TAXES> <NoShow>0</NoShow> <VoucherNumber>672164712</VoucherNumber> <VoucherValue currency="usd">6500</vouchervalue> </MARKET_SEGMENT> </CC_TRANSACTION> Version 3.5.0 127

Appendix E: Fleet Card Market Segment The Wirecard platform offers vertical-market solutions for fleet cards. The request may contain the following elements in the CC_TRANSACTION, catering to the fleet card sector: Element Sett. Data Type Description MARKET_SEGMENT man. c This is a collection of specific market segment elements and their values. name man. an..32 This attribute defines the name of the market segment. It must be populated with FleetServices. Info opt. an..20 This is for additional information. DriverId opt. n..4 This is the drivers number. VEHICLE_INFO opt. c This is a collection of information describing the vehicle. RegistrationNumber opt. an..15 This is the registration number of the vehicle. RegistrationCountry opt. a..3 This is the country where the vehicle is registered. VehicleId opt. n..4 This is the vehicles number. Milage opt. n..6 This is the current mileage of the vehicle. ARTICLE_INFO opt. c This is a collection of multiple articles. Article opt. c This is a collection of information describing the purchased article. Id opt. n..2 This is the number of the article. ClassOfGoods opt. n..6 This is the class of goods. ArticleIdType opt. a 1 This is the type of article ID ( A =article number, B =EAN no.) ArticleId opt. n..14 This is the article id. Quantity opt. n..6 This is the quantity of the article bought. The attribute minorunits contains the number of decimals. (e.g. decimals=2 : 12.00 is sent as 1200) UnitPrice opt. n..8 This is the unit price of the article The attribute minorunits contains the number of decimals. (e.g. decimals=3 : 0.989 is sent as 989) Amount opt. n..8 This is the amount for this article. The attribute minorunits contains the number of decimals. (e.g. decimals=2 : 12.00 is sent as 1200) AmountSign opt. c..1 Sign of the amount (empty if positive, - if negative) Currency opt. a 3 This is ISO 4217 currency code used for the transaction (e.g. EUR) TOLL_INFO opt. c This is a collection of information describing toll details. BookingId opt. an..16 This is the id number of the booking. Location opt. an..38 This is the start or end of the route. Distance opt. n..4 This is the length of the route for which toll is charged. 128 Version 3.5.0

Card Processing Element Sett. Data Type Description ValidityPeriod opt. n..14 This is the start or end of the validity period in format YYYYMMDDHHMMSS Example: <CC_TRANSACTION> <MARKET_SEGMENT name="fleetservices"> <Info>Toll booking</info> <DriverId>815</DriverId> <VEHICLE_INFO> <RegistrationNumber>IM PLAN 1</RegistrationNumber> <RegistrationCountry>A</RegistrationCountry> <VehicleId>812</VehicleId> <Milage>145323</Milage> </VEHICLE_INFO> <ARTICLE_INFO> <Article id="1"> <ClassOfGoods>10</ClassOfGoods> <ArticleIdType>A</ArticleIdType> <ArticleId>123456</ArticleId> <Quantity minorunits= 2 >8700</Quantity> <UnitPrice minorunits = 3 >989</UnitPrice> <Amount minorunits = 2 >14366</Amount> <AmountSign></AmountSign> <Currency>EUR</Currency> </Article> </ARTICLE_INFO> <TOLL_INFO> <BookingId>1234567890123456</BookingId> <Location>Charlottenburg-Siemensdamm>A100</Location> <Distance>345</Distance> <ValidityPeriod>20041224170000</ValidityPeriod> </TOLL_INFO> </MARKET_SEGMENT> </CC_TRANSACTION> Version 3.5.0 129

Appendix F: Hotel Market Segment The Wirecard platform offers market solutions for the hotel industry. The request may contain the following elements in CC_TRANSACTION, catering to the hotel sector: Element Sett. Data Type Description MARKET_SEGMENT man. c This is a collection of specific market segment elements and their values. name man. an..32 The attribute "name" defines the market segment and must be populated with "Hotel". HotelCode opt. an..20 This is the hotel code. HotelName opt. an..32 This is the hotel name. RoomNumber opt. an..20 This is the room number. BookingCode opt. an..20 This is the guest's booking reference code (e.g. PNR locator). GUEST_INFO man. c This is a collection of personal information elements and their values. FirstName opt. an..20 This is the first name of the guest. LastName opt. an..20 This is the last name of the guest. CompanyName opt. an..20 This is the name of the guest s company. CheckinDate opt. YYYY-MM- This is the date of checkin. DD CheckoutDate opt. YYYY-MM- This is the date of checkout. DD Rate opt. an..20 This is the rate applying to the reservation. type man. an..32 This is the attribute that identifies the rate. NoShow opt. n 1 0 = Not applicable (customer arrived) 1 = No Show (customer did not show up) If not provided, 0 will be set as default value. AgentCode opt. n..8 This is the code for the agency initiating the reservation. AgentName opt. an..26 This is the agency name. 130 Version 3.5.0

Card Processing Element (Cont.) Sett. Data Type Description HotelPhoneNumber opt. an..32 This is the hotel's central reservation desk phone number. It can be provided in one of the following formats: +xxx(yyy)zzz-zzzz-ppp +xxx (yyy) zzz zzzz ppp +xxx(yyy)zzz/zzzz/ppp +xxx(yyy)zzzzzzzppp where: xxx = country code yyy = national direct dialing prefix zzzzzzz = area / city code and local number ppp = PBX extension Separators such as /, \ or - are permissible. For example, a typical international number would be +44(0)555-5555-739 indicating PBX extension 739 at phone number 555-5555 with the national prefix 0 and country code 44. For countries which do not have a national prefix, the format must be configured with or without a space in brackets. Example: +420()52-5454- 742. ServicePhoneNumber opt. an..32 This is the hotel's customer service phone number. For details see HotelPhoneNumber above. DailyRate opt. n..13 This is the integer amount of the daily room rate, defined in the smallest currency unit (e.g., $10.00 would be "1000"). DailyTax opt. n..13 This is the integer amount of the daily room tax, defined in the smallest currency unit (e.g., $10.00 would be "1000"). PrepaidCharge opt. n..13 This is the integer amount of prepaid expenses, defined in the smallest currency unit (e.g., $10.00 would be "1000"). PhoneCharge opt. n..13 This is the integer amount of phone charges, defined in the smallest currency unit (e.g., $10.00 would be "1000"). RoomServiceCharge opt. n..13 This is the integer amount of room service charges, defined in the smallest currency unit (e.g., $10.00 would be "1000"). BarCharge opt. n..13 This is the integer amount of bar charges, defined in the smallest currency unit (e.g., $10.00 would be "1000"). MiniBarCharge opt. n..13 This is the integer amount of minibar charges, defined in the smallest currency unit (e.g., $10.00 would be "1000"). GiftShopCharge opt. n..13 This is the integer amount of gift shop charges, defined in the smallest currency unit (e.g., $10.00 would be "1000"). LaundryCharge opt. n..13 This is the integer amount of laundry charges, defined in the smallest currency unit (e.g., $10.00 would be "1000"). Version 3.5.0 131

Element (Cont.) Sett. Data Type Description FoodCharge opt. n..13 This is the integer amount of food or beverage charges, defined in the smallest currency unit (e.g., $10.00 would be "1000"). ParkingCharge opt. n..13 This is the integer amount of parking charges, defined in the smallest currency unit (e.g., $10.00 would be "1000"). HealthClubCharge opt. n..13 This is the integer amount of health club charges, defined in the smallest currency unit (e.g., $10.00 would be "1000"). BusinessCentreCharge opt. n..13 This is the integer amount of business center charges, defined in the smallest currency unit (e.g., $10.00 would be "1000"). MovieCharge opt. n..13 This is the integer amount of movie charges, defined in the smallest currency unit (e.g., $10.00 would be "1000"). OtherServicesCharge opt. n..13 This is the integer amount of any other service charges not covered with the above elements, defined in the smallest currency unit (e.g., $10.00 would be "1000"). NOTE: Our system is case sensitive and therefore distinguishes between uppercase and lowercase letters. If you send a tag name in uppercase instead of lowercase letters or vice versa the system will silently ignore the tag data. Also typing errors will be silently ignored. The data will not be stored in our database although there is no system rejection. 132 Version 3.5.0

Card Processing Example: <CC_TRANSACTION mode="demo"> <MARKET_SEGMENT name="hotel"> <HotelCode>ABCDEFG</HotelCode> <HotelName>Airport Hotel Muenchen</HotelName> <RoomNumber>42</RoomNumber> <BookingCode>HIJKLMN</BookingCode> <GUEST_INFO> <FirstName>John</FirstName> <LastName>Doe</LastName> <CompanyName>MyCompany</Name> </GUEST_INFO> <CheckinDate>2005-11-07</CheckinDate> <CheckoutDate>2005-11-08</CheckoutDate> <Rate type= RA2 >Best available prepaid rate</rate> <NoShow>0</NoShow> <AgentCode>ABCDEFG</AgentCode> <AgentName>Sita Travels</AgentName> <HotelPhoneNumber>+49(89)111-222-333</HotelPhoneNumber> <ServicePhoneNumber>+49(89)111-222-444</ServicePhoneNumber> <DailyRate>10000</DailyRate> <DailyTax>1600</DailyTax> <PrepaidCharge>10000</PrepaidCharge> <PhoneCharge>500</PhoneCharge> <RoomServiceCharge>1000</RoomServiceCharge> <BarCharge>4500</BarCharge> <MiniBarCharge>3200</MiniBarCharge> <GiftShopCharge>5000</GiftShopCharge> <LaundryCharge>1000</LaundryCharge> <FoodCharge>3000</FoodCharge> <ParkingCharge>1500</ParkingCharge> <HealthClubCharge>10000</HealthClubCharge> <BusinessCentreCharge>25000</BusinessCentreCharge> <MovieCharge>2000</MovieCharge> <OtherServicesCharge>2500</OtherServicesCharge> </MARKET_SEGMENT> </CC_TRANSACTION> Version 3.5.0 133

Appendix G: Travel Market Segment The following card processing segment has been defined for the travel industry and contains special elements catering to travel agents: Element Sett. Data Type Description MARKET_SEGMENT man. c This is a collection of specific market segment elements and their values. IssueDate man. MMDDYYY Y This is the date of the travel ticket was issued by the agent - month, day, year (e.g. 05172006) DocumentNumber man. an..10 This is the number of the processed document. PassengerName man. an..29 This is the name of the person travelling. ServiceDescription man. an..30 Here the travel agent can specify the service rendered, e.g. booking of a flight. ServiceType opt. a..1 The following values can be entered: A (Airline) O (Other) AgentCode man. n..8 This is the agency code assigned by IATA. If no IATA code is used, the element field must be populated with 99999999. NetAmountNonTaxable man. n..15 This field must contain the net amount of the transaction in the specified currency for which no tax is levied. Two decimal places are implied. If the complete amount of the transaction is not taxable, the value of this filed is equal to the gross transaction amount. VatEntry man. c This is a collection element containing various tax related parameter fields. id man. n..1 This is an attribute of the element <VatEntry>. It allows merchants to post more than one VatEntry collection with the transaction request. The indicator must be numbered incrementally. Examples: <VatEntry id= 1 >, <VatEntry id= 2 > etc). NetAmountTaxable con. n..15 This field must contain the net amount of the purchase transaction in the specified currency for which a tax is levied. Two decimal places are implied. If this field contains a value greater than zero, the indicated value must differ to the content of the transaction amount. VatAmount con. n..9 This field must contain the amount of the Value Added Tax levied on the transaction amount in the specified currency. VatPercentage con. n..5 This field must contain the percentage with one decimal place of the Value Added Tax levied on the transaction amount. 134 Version 3.5.0

Card Processing Element Sett. Data Type Description VatDeductible con. n..1 This field specifies the kind of tax. Possible values are: 0 = no VAT 1 = non-deductible city tax 2 = non-deductible state or provincial tax 3 = non-deductible national tax 6 = deductible city tax 7 = deductible state or provincial tax 8 = deductible national tax OtherTaxes man. n..9 This field must contain all taxes in the specified transactin currency not included in the VAT amount fields.two decimal places are implied: Example: USD 9 = 900. Relevant for AirPlus acceptance of UATP transactions only. Example: <CC_TRANSACTION> <MARKET_SEGMENT name="travel"> <IssueDate>05172006</IssueDate> <DocumentNumber>PX1DFK</DocumentNumber> <PassengerName>John Doe</PassengerName> <ServiceDescription>Flight TXL MUC TXL 17Nov</ServiceDescription> <ServiceType>F</ServiceType> <AgentCode>34456853</AgentCode> <NetAmountNonTaxable>2000</NetAmountNonTaxable> <VatEntry id="1"> <NetAmountTaxable>5000</NetAmountTaxable> <VatAmount>950</VatAmount> <VatPercentage>19</VatPercentage> <VatDeductible>6</VatDeductible> </VatEntry> <VatEntryid="2"> <NetAmountTaxable>1000</NetAmountTaxable> <VatAmount>159</VatAmount> <VatPercentage>15.9</VatPercentage> <VatDeductible>7</VatDeductible> </VatEntry> <VatEntryid="3"> <NetAmountTaxable>1000</NetAmountTaxable> <VatAmount>60</VatAmount> <VatPercentage>16.50</VatPercentage> <VatDeductible>8</VatDeductible> </VatEntry> <OtherTaxes>900</OtherTaxes > </MARKET_SEGMENT> </CC_TRANSACTION> Version 3.5.0 135

Appendix H: XML Extensions In some cases, the standard XML transaction request can be modified in agreement with Wirecard to include request elements which cater to operational needs of our customers. Entity Data The interface can be complemented with the collection entity data, which replaces the business case signature. The tag <BusinessCaseSignature> must be included, but no value has to be provided. The number of parameters in the <ENTITY_DATA> collection is not limited and can be used for every business type. NOTE: An extension to the existing interface with the collection element <ENTITY_DATA> is subject to certain terms and conditions which must be in contractual agreement with Wirecard. Any customization must be approved of and developed in close collaboration with Wirecard. Example: Authorization Request <?xml version="1.0" encoding="utf-8"?> <WIRECARD_BXML xmlns:xsi="http://www.w3.org/1999/xmlschema-instance"> <W_REQUEST> <W_JOB> <JobID>Job 1</JobID> <BusinessCaseSignature/> <ENTITY_DATA> <Item id="1" name="product-code">abcdefg</item> <Item id="2" name="sales-channel">call Center</Item> <Item id="3" name="currency">eur</item> <Item id="4" name="3-ds">no</item> </ENTITY_DATA> <FNC_CC_AUTHORIZATION> <FunctionID>authorization 1</FunctionID> <CC_TRANSACTION mode="demo"> <TransactionID>9457892347623478</TransactionID> <CommerceType>eCommerce</CommerceType> <Amount minorunits="2">500</amount> <Currency>EUR</Currency> <CountryCode>DE</CountryCode> <Usage>OrderNo-FT345S71 Thank you</usage> <RECURRING_TRANSACTION> <Type>Initial</Type> </RECURRING_TRANSACTION> <CREDIT_CARD_DATA> <CreditCardNumber>4200000000000000</CreditCardNumber> <CVC2>001</CVC2> <ExpirationYear>2009</ExpirationYear> <ExpirationMonth>01</ExpirationMonth> <CardHolderName>John Doe</CardHolderName> </CREDIT_CARD_DATA> <CONTACT_DATA> <IPAddress>192.168.1.1</IPAddress> </CONTACT_DATA> </CC_TRANSACTION> 136 Version 3.5.0

Card Processing Unified Payment Management Standard payment data processing doesn t enable referencing of transactions between different payment methods. By extending the card processing XML request message with the PaymentGroupID element, merchants can easily reference between transactions initiated by different payment methods (e.g. a hotel booking or purchase where one part of the total is paid for by credit card and the other by direct debit). The PaymentGroupID is a system-generated identifier. In the Wirecard sysetm, this can typically be the Global unique Wirecard ID (GuWID) which is returned with the response message to the very first transaction request (Authentication, Pre-Authentication or Purchase). The use of PaymentGroupID is optional which means that merchants can choose to include it in all request messages (except Query) so as to consolidate transaction types of different payment methods (like credit card and direct debit) into a single transaction flow and unified representation for easy management via the web-based user interface ACM. Only the XML request message contains the PaymentGroupID element. It is not returned with the XML response message. The GuWID element, which references the previous XML request message in the payment flow of the same payment method remains in all card transaction request messages. Example: Credit Card Capture Request <W_JOB> <JobID>job 1</JobID> <BusinessCaseSignature>0123456789ABCDEF</BusinessCaseSignature> <FNC_CC_CAPTURE_PREAUTHORIZATION> <FunctionID>capturing 1</FunctionID> <CC_TRANSACTION mode= demo > <TransactionID>9457892347623478</TransactionID> <PaymentGroupID>C322649114016473243901</PaymentGroupID> <GuWID>C242720181323966504820</GuWID> <Amount minorunits="2">600</amount> <Usage>OrderNo-FT345S71 Thank you</usage> </CC_TRANSACTION> </FNC_CC_CAPTURE_PREAUTHORIZATION> </W_JOB> Version 3.5.0 137

Appendix I: Purchasing Process The diagram below illustrates a typical purchasing process (with the elements of secure cardholder authentication shown in the grey boxes). For further details on cardholder authentication see the XML interface specification 3-D Secure Card Processing. Complete Shopping Cart Obtain Card and Shipping Address Participating Card? Confirm Purchase Yes No Request Alternate Card Information Obtain Authorization From Card Agency / Gateway Yes Authenticate User Take Action No Payment Authorized? Successfully Authenticated? Yes Decline Purchase Display Purchase Confirmation/Ref # to user No 138 Version 3.5.0

Card Processing Appendix J: ASCII Characters The table below shows the ASCII characters which can be used in the XML request element fields JobID, FunctionID, and TransactionID.With the exception of code 39, the table lists the ASCII code range also known as printable characters, representing letters, digits, punctuation marks, and a few miscellaneous symbols. Code 32 denotes the space between words, as produced by the large space-bar of a keyboard. All other ASCII codes in the number range from 0 to 31 (known as non-printable characters) are not supported. ASCII Printable Characters Binary Dec Hex Glyph 0010 0000 32 20 (blank) 0010 0001 33 21! 0010 0010 34 22 " 0010 0011 35 23 # 0010 0100 36 24 $ 0010 0101 37 25 % 0010 0110 38 26 & 0010 1000 40 28 ( 0010 1001 41 29 ) 0010 1010 42 2A * 0010 1011 43 2B + 0010 1100 44 2C, 0010 1101 45 2D - 0010 1110 46 2E. 0010 1111 47 2F / 0011 0000 48 30 0 0011 0001 49 31 1 0011 0010 50 32 2 0011 0011 51 33 3 0011 0100 52 34 4 0011 0101 53 35 5 0011 0110 54 36 6 0011 0111 55 37 7 0011 1000 56 38 8 0011 1001 57 39 9 0011 1010 58 3A : 0011 1011 59 3B ; 0011 1100 60 3C < 0011 1101 61 3D = 0011 1110 62 3E > 0011 1111 63 3F? 0100 0000 64 40 @ Binary Dec Hex Glyph 0100 0001 65 41 A 0100 0010 66 42 B 0100 0011 67 43 C 0100 0100 68 44 D 0100 0101 69 45 E 0100 0110 70 46 F 0100 0111 71 47 G 0100 1000 72 48 H 0100 1001 73 49 I 0100 1010 74 4A J 0100 1011 75 4B K 0100 1100 76 4C L 0100 1101 77 4D M 0100 1110 78 4E N 0100 1111 79 4F O 0101 0000 80 50 P 0101 0001 81 51 Q 0101 0010 82 52 R 0101 0011 83 53 S 0101 0100 84 54 T 0101 0101 85 55 U 0101 0110 86 56 V 0101 0111 87 57 W 0101 1000 88 58 X 0101 1001 89 59 Y 0101 1010 90 5A Z 0101 1011 91 5B [ 0101 1100 92 5C \ 0101 1101 93 5D ] 0101 1110 94 5E ^ 0101 1111 95 5F _ 0110 0000 96 60 Version 3.5.0 139

ASCII Printable Characters (continued) Binary Dec Hex Glyph 0110 0001 97 61 a 0110 0010 98 62 b 0110 0011 99 63 c 0110 0100 100 64 d 0110 0101 101 65 e 0110 0110 102 66 f 0110 0111 103 67 g 0110 1000 104 68 h 0110 1001 105 69 i 0110 1010 106 6A j 0110 1011 107 6B k 0110 1100 108 6C l 0110 1101 109 6D m 0110 1110 110 6E n 0110 1111 111 6F o 0111 0000 112 70 p 0111 0001 113 71 q 0111 0010 114 72 r 0111 0011 115 73 s 0111 0100 116 74 t 0111 0101 117 75 u 0111 0110 118 76 v 0111 0111 119 77 w 0111 1000 120 78 x 0111 1001 121 79 y 0111 1010 122 7A z 0111 1011 123 7B { 0111 1100 124 7C 0111 1101 125 7D } 0111 1110 126 7E ~ 140 Version 3.5.0

www.wirecard.com 2009 Wirecard AG All rights reserved