creditor implementation guidelines emandates - core · • chapter 12: presentation of emandates on...

CONFIDENTIAL

May 2015

Copyright © Currence Services BV

All rights reserved.

Creditor Implementation Guidelines eMandates - Core Document version 1.03

Creditor Implementation Guidelines – eMandates Core Document version 1.03 - CONFIDENTIAL

Copyright © Currence Services BV of 100 All rights reserved. All rights reserved.

Terms and conditions

Terms and conditions for provision of the eMandates Creditor Integration Guide:

1 Currence Services BV (also referred to as ‘Currence’) provides these eMandates Creditor Implementation Guidelines to Creditor Banks that distribute it to (potential) Creditors and Payment Service Providers to enable them to implement eMandates.

2 Currence reserves the right to deny access to the eMandates Creditor Implementation Guidelines to (potential) Creditors and Service Providers on reasonable grounds, in consultation with the Creditor Bank with which the Creditor/Service Provider has a contract.

3 These Implementation Guidelines are explicitly and exclusively provided for the purpose mentioned above, and no other use is permitted. No rights can be derived from the information provided in this document or the accompanying notes. Currence is in no way liable for the consequences of later changes to the eMandates Standards or the eMandates Creditor Implementation Guidelines. If banks or other interested parties take decisions and/or make investments on the basis of the information that they obtain via the eMandates Creditor Implementation Guidelines, Currence accepts no liability for this in any way.

4 These implementation Guidelines are based on the information in the eMandates Standards documents. In the event of any discrepancy between the eMandates Creditor Implementation Guidelines and the eMandates Standards documents, the text in the eMandates Standards documents prevails.

For any questions concerning this document or requests for further information, please contact your Bank or Payment Service Provider.



Contents

Terms and conditions ............................................................................................................................. 2

Contents ................................................................................................................................................... 3

Tables ....................................................................................................................................................... 8

Figures .................................................................................................................................................... 10

1 General Introduction ....................................................................................................................... 11

1.1 Target audience ................................................................................................................... 11

1.2 Document structure .............................................................................................................. 11

1.3 Other references .................................................................................................................. 12

1.4 Notational conventions ......................................................................................................... 12

1.5 Definitions of online banking ................................................................................................ 12

1.6 Revisions .............................................................................................................................. 13

1.7 Changes from previous version ........................................................................................... 13

2 eMandates Overview ....................................................................................................................... 15

2.1 What is eMandates? ............................................................................................................ 15

2.2 What is eMandates Mobile? ................................................................................................. 15

2.3 Design principles .................................................................................................................. 16

2.3.1 Technical principles ................................................................................................ 16

2.3.2 Functional principles ............................................................................................... 16

2.4 The four-corner model .......................................................................................................... 17

2.4.1 The relations between these roles .......................................................................... 18

2.5 Terminology ......................................................................................................................... 19

3 eMandates protocol ........................................................................................................................ 21

3.1 General ................................................................................................................................ 21

3.1.1 Specific requirement eMandates Mobile: Redirect to Issuer can be diverted to mobile app or mobile web page of Issuer ........................................................................... 23



4 Functions of the solution ............................................................................................................... 24

4.1.1 Issuing a new eMandate ......................................................................................... 24

4.1.2 Amending an existing eMandate ............................................................................. 24

4.1.3 Cancelling an existing eMandate ............................................................................ 24

4.1.4 Debtor protection information .................................................................................. 24

4.2 Multiple signing .................................................................................................................... 25

4.3 Creditor Registration for eMandates .................................................................................... 26

4.3.1 Creditor preconditions ............................................................................................. 26

4.3.2 Creditor registration ................................................................................................ 26

4.4 ValidationReference ............................................................................................................. 27

4.5 Dispute management ........................................................................................................... 27

5 eMandates Message format ........................................................................................................... 28

5.1 General ................................................................................................................................ 28

5.2 HTTP .................................................................................................................................... 28

5.3 XML header .......................................................................................................................... 28

5.4 Character set ........................................................................................................................ 29

5.5 XML Namespace declaration ............................................................................................... 29

5.6 Message attributes ............................................................................................................... 30

5.7 Conventions for empty fields ................................................................................................ 30

5.8 Message validation .............................................................................................................. 30

6 eMandates Data dictionary ............................................................................................................. 31

6.1 eMandate IDs ....................................................................................................................... 31

6.2 General data elements ......................................................................................................... 31

6.3 eMandates ISO pain message data elements ..................................................................... 33

6.3.1 Frequency ............................................................................................................... 35

7 eMandates Directory protocol ........................................................................................................ 36

7.1 General ................................................................................................................................ 36

7.2 DirectoryRequest ................................................................................................................. 36

7.3 DirectoryResponse ............................................................................................................... 37

7.4 Presentation of the Debtor Bank selection list ..................................................................... 38



8 eMandates Transaction protocol ................................................................................................... 40

8.1 General ................................................................................................................................ 40

8.2 TransactionRequest ............................................................................................................. 40

8.2.1 Container content .................................................................................................... 41

8.2.2 Content of container element for new eMandates .................................................. 41

8.2.3 Content of container element for eMandate amendments ...................................... 44

8.3 TransactionResponse .......................................................................................................... 48

8.4 Errors when executing Transaction Protocol ....................................................................... 49

8.5 Redirect to the online banking environment (issuerAuthenticationURL) .............................. 49

8.5.1 Specific requirement eMandates Mobile: Redirect to Debtor Bank (no in-app browser) .............................................................................................................................. 49

8.6 Redirect to the Creditor environment (merchantReturnURL) ............................................... 50

8.6.1 Requirements for eMandates Mobile: redirect to the Creditor environment. .......... 50

8.7 Errors during execution of the redirect to the Debtor Bank, approving the eMandate and/or the redirect to the Creditor environment ........................................................................................ 51

8.8 Four different scenario’s for completion of eMandates Mobile transaction .......................... 51

8.8.1 Debtor is redirected from the Creditor’s (mobile) web page to the Debtor Bank’s (mobile) web page. .............................................................................................................. 52

8.8.2 Debtor is redirected from the Creditor’s (mobile) web page to the Debtor Bank’s mobile banking app ............................................................................................................. 52

8.8.3 Debtor is redirected from the Creditor’s mobile app to the Debtor Bank’s (mobile) web page ............................................................................................................................. 53

8.8.4 Debtor is redirected from the Creditor’s mobile app to the Debtor Bank’s mobile banking app ......................................................................................................................... 54

8.9 Performance and time-out of transaction message ............................................................. 55

8.10 Specific requirement eMandates Mobile: Print or e-mail confirmation message ................ 55

9 eMandates Status protocol ............................................................................................................ 56

9.1 General ................................................................................................................................ 56

9.2 StatusRequest ...................................................................................................................... 56

9.3 StatusResponse ................................................................................................................... 56

9.3.1 Content of container element for new eMandates or amendments ........................ 57

9.4 Errors during execution of Status Protocol ........................................................................... 62

9.5 Collection duty ...................................................................................................................... 62



9.6 Performance and time-out of status messages .................................................................... 63

10 Error handling ................................................................................................................................ 64

10.1 General ................................................................................................................................ 64

10.2 ErrorResponse .................................................................................................................... 64

10.3 Non-availability .................................................................................................................... 65

11 Security and certificates ............................................................................................................... 67

11.1 General principles of certificates ......................................................................................... 67

11.2 Signing eMandates messages ............................................................................................ 67

11.2.1 Signing of the ISO pain.012 acceptance report ...................................................... 68

11.3 Authentication of eMandates messages ............................................................................. 69

11.4 Creating a key pair .............................................................................................................. 69

11.4.1 Buying a certificate from a Certificate Authority ...................................................... 70

12 Presentation ................................................................................................................................... 71

12.1 General ................................................................................................................................ 71

12.2 Elektronisch machtigen via uw Bank-button ....................................................................... 71

12.3 Transaction flow .................................................................................................................. 71

12.4 Redirect to Debtor Bank ...................................................................................................... 71

12.5 Frames ................................................................................................................................ 72

12.6 New Window ....................................................................................................................... 72

12.6.1 Specific Requirements eMandates Mobile: New window or app ............................ 72

12.7 Debtor Bank list ................................................................................................................... 72

12.8 ‘Elektronisch machtigen via uw Bank’ banners and logo's .................................................. 72

12.9 Explaining eMandates to Debtors ....................................................................................... 72

12.10 Creditor front-end ................................................................................................................ 73

12.11 Debtor Bank front-end ......................................................................................................... 74

APPENDIX A: Container content overview ......................................................................................... 77

APPENDIX B: Error codes .................................................................................................................... 78

Categories ..................................................................................................................................... 78

Error codes .................................................................................................................................... 78



APPENDIX C: Message examples ........................................................................................................ 81

A. DirectoryReq ............................................................................................................................. 81

A’. DirectoryRes ............................................................................................................................. 81

B. AcquirerTrxReq for new eMandate ........................................................................................... 82

B. AcquirerTrxReq for eMandate amendment ............................................................................... 84

B’. AcquirerTrxRes ........................................................................................................................ 86

F. AcquirerStatusReq .................................................................................................................... 86

F’. AcquirerStatusRes for new eMandate ...................................................................................... 87

X’. AcquirerErrorRes ...................................................................................................................... 90

X’. AcquirerErrorRes (with namespace prefixes, but without container element) ......................... 91

APPENDIX D: XML Schema .................................................................................................................. 93



Tables

Table 1: References ................................................................................................................................ 12

Table 2: Mapping of eMandates elements to xml elements .................................................................... 19

Table 3: Message names and descriptions ............................................................................................. 22

Table 4: eMandate IDs ............................................................................................................................ 31

Table 5: Data elements in iDx messages ................................................................................................ 32

Table 6: Used data formats in the data catalogue ................................................................................... 33

Table 7: Used character codes in the data catalogue ............................................................................. 33

Table 8: eMandates data elements ......................................................................................................... 35

Table 9: eMandate.FrequencyPeriod codes ............................................................................................ 35

Table 10: Fields of the DirectoryRequest ................................................................................................ 37

Table 11: Fields of the DirectoryResponse .............................................................................................. 37

Table 12: Fields of the TransactionRequest ............................................................................................ 41

Table 13: Pain.009 message (new eMandate) ........................................................................................ 44

Table 14: Pain.010 message (amendment) ............................................................................................. 48

Table 15: Fields of the TransactionResponse ......................................................................................... 48

Table 16: Different scenario’s for the completion of an eMandates mobile transaction .......................... 52

Table 17: Scenario: Redirect from Creditor (mobile) web page to the Debtor Banks (mobile) web page ................................................................................................................................................................. 52

Table 18: Scenario: Redirect form Creditor (mobile) web page to the Debtor Banks mobile banking app ................................................................................................................................................................. 53

Table 19: Scenario: Redirect from the Creditors mobile app to the Debtor Banks (mobile) web page ... 54

Table 20: Scenario: Redirect from the Creditors mobile app to the Debtor Banks mobile banking app .. 55

Table 21: Performance requirements (for the 95th percentile*) .............................................................. 55

Table 22: Fields of the StatusRequest ..................................................................................................... 56

Table 23: Fields of the StatusResponse .................................................................................................. 57

Table 24: Pain.012 message (acceptance report) ................................................................................... 62

Table 25: Performance requirements (for the 95th percentile*) .............................................................. 63

Table 26: Fields of the ErrorResponse .................................................................................................... 64

Table 27: Pain.012 error response acceptance report ............................................................................ 65

Table 28: Container content for new eMandates ..................................................................................... 77

Table 29: Container content for eMandate amendments ........................................................................ 77



Table 30: Error code categories .............................................................................................................. 78

Table 31: Error codes .............................................................................................................................. 79

Table 32: errorDetail ................................................................................................................................ 79

Table 33: consumerMessage .................................................................................................................. 80

Table 34: Reject reason codes ................................................................................................................ 80



Figures

Figure 1: Four-corner model .................................................................................................................... 19

Figure 2: Representation of the steps in an eMandates transaction ....................................................... 21

Figure 3: Representation of the steps in an eMandates Mobile transaction ............................................ 23

Figure 4: Example of (open) dropdown list box showing the Debtor Bank list ........................................ 38

Figure 5: Example of one-off eMandate approval website or mobile app screen .................................... 75

Figure 6: Example of one-off eMandate confirmation website or mobile app screen .............................. 76



1 General Introduction

1.1 Target audience

This document provides a detailed description of the Dutch Banks’ eMandates Core solution. It is intended for those requiring detailed information about this solution.

eMandate Creditors are organisations (Creditors) that want to use eMandates and have signed an eMandate contract with a bank. Creditors are required to have a direct debit contract.

This document is intended for Creditors that want to connect to the eMandate platform of their Creditor Bank. It provides a description of all messages that are exchanged between the Creditor and the Routing Service of his Creditor Bank. The messages that are exchanged between the Routing Service of the Creditor Bank and the Validation Service of the Debtor Bank are not of importance to the Creditor, and therefore will not be discussed in this document unless they have specific relevance.

This document is not bank specific, which means that only generic specifications are mentioned in this guide. Information concerning bank specific connections that are not standard and assistance that is provided by banks to connect to eMandates are not part of this guide. Please contact your Creditor bank for any information or support on a bank specific connection or implementation.

To further support Creditors, software libraries have been developed in .NET, PHP and Java. Please contact your bank about this for more information.

1.2 Document structure

• Chapter 2: Introduction to eMandates and an overview of all parties involved in eMandates. • Chapter 3: The various messages that are exchanged within the scope of an eMandates

transaction and the overall structure of the exchanged messages • Chapter 4: Functions of the solution • Chapter 5: Message format • Chapter 6: Data dictionary • Chapter 7: Directory protocol: providing a list of participating Debtor Banks • Chapter 8: Transaction protocol: starting an eMandate transaction • Chapter 9: Status protocol: retrieving the status of the transaction and the eMandate • Chapter 10: Error handling • Chapter 11: Security and certificates • Chapter 12: Presentation of eMandates on the Creditor website • Appendices



1.3 Other references

Title Version Issued by

1.3.1.1.1.1 UNIFI (20022) ISO

SDD Implementation Guidelines 7.0 EPC

SDD Rulebook 7.0 EPC

Payments Mandate Urgent Maintenance and message XSD’s Available at http://www.iso20022.org/full_catalogue.page under ‘pain - payments initiation’

October 2014 ISO

External Code Sets spreadsheet 13 june 2014 ISO

The Base16, Base32, and Base64 Data Encodings http://www.ietf.org/rfc/rfc3548.txt

July 2003 Network Working Group

Base64 Content-Transfer-Encoding http://tools.ietf.org/html/rfc2045iDxsection-6.8

November 1996 Network Working Group

Multilingual European Subset 2 (MES-2) Unicode.org http://www.utf8-chartable.de/unicode-utf8-table.pl

15 April 2000 CEN

Open Web Application Security Project (OWASP) http://www.owasp.org

n.a. OWASP

XML Signature Syntax and Processing (Second Edition), W3C Recommendation 10 June 2008 http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/

Second edition, 10 June 2008

World Wide Web Consortium (W3C)

GUIDELINES ON ALGORITHMS USAGE AND KEY MANAGEMENT (EPC342-08)

Version 1.1 approved 23 February 2009

EPC

ITU-T RECOMMENDATION X.690 Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER) http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf

(07/2002) ITU-T

LC858 Use of encryption algorithms and key management systems for banking applications and systems

7 January 2011 NVB

TLS Protocol version 1.0 http://www.ietf.org/rfc/rfc2246.txt 1.0, January 1999

IETF

TLS Protocol version 1.1 http://www.ietf.org/rfc/rfc4346.txt 1.1, April 2006 IETF

TLS Protocol version 1.2 http://www.ietf.org/rfc/rfc5246.txt 1.2, August 2008 IETF

Table 1: References

1.4 Notational conventions

Messages and redirects are printed like this, and data elements are printed like this.

1.5 Definitions of online banking

In this document there are many references to Creditor websites and the Debtor’s online banking environment. To facilitate mobile use of the eMandates solution, these references must be supplemented with ‘….. or mobile website / mobile app’ and ‘….. or mobile banking website / mobile banking app’ where appropriate.



For every instance where internet or online related-terminology is used, please interpret this as including the mobile channel. Where mobile use of the eMandates solution leads to specific requirements for the eMandates solution, this is indicated separately in the text.

1.6 Revisions

Version Description Release date

0.99 Initial version

1.0 Version for publication 3 November 2014

1.01 Minor corrections and alignment with Dutch version of the CIG

31 December 2014

1.02 • Minor general corrections

• Corrected the format for the element ‘Maximum Amount’ - from 18 to 11 characters.

• Corrected the information on the product-name of eMandates in chapter 12

30 March 2015

1.03 • Updated the canonicalization method used for the digest to exclusive canonicalization

• Clarified the requirements for saving the mandate

• Clarified the format requirements of eMandateID

• Clarified the use of the Creditor Address

• Clarified that the DateTime in the pain.012 message is the moment of signing the eMandate.

4 May 2015

1.7 Changes from previous version

This paragraph summarizes the changes from the previous version of the Creditor Implementation Guidelines Core. Five changes were made in the current version of this document:

1. The canonicalization method that is used for the calculation of the digest has been changed from inclusive canonicalization to exclusive canonicalization. This impacts both the calculation itself and the part of the XML message where the calculation process is described.

2. The requirements for archiving the original eMandate (the ISO pain.012 message which includes the electronic signature and certificate information) have been clarified. The ISO pain.012 message can be archived after extracting it from the XML envelope, using exclusive canonicalization. Alternatively, Creditors may choose to simply archive the entire StatusResponse message.

3. The formatting requirements for the eMandateID have been clarified. Creditors must beware that eMandateID’s must be restricted to the SEPA Direct Debit character set, which is stricter than the MES-2 character set.

4. The use of the Creditor Address has been clarified. The Creditor must register his address using two address-lines, generally using the first line for information on street, number, postbus, add-ons and using the second line for postcode and city.



5. Clarified that the DateTime in the pain.012 message is the moment of signing the eMandate. The element eMandate.DateTimestamp has been placed in the pain.012 table to make this clear.



2 eMandates Overview

2.1 What is eMandates?

eMandates was developed by the Dutch banking community in order to facilitate online processes for mandates. eMandates enables direct and secure real-time1 online issuing and amendment of eMandates by Debtors to Creditors.

The main characteristics of eMandates are:

• Real-time eMandates through accepted and trusted online banking that is already familiar to Debtors;

• Real-time eMandate approval by the Debtor and real-time confirmation to the Creditor by the Creditor Bank. The Creditor receives the eMandate that has been signed by the Debtor Bank on behalf of the Debtor;

• Officially recognised as valid mandates by the participating Debtor Banks. The refund-risk period for Creditor’s SEPA Direct Debit collections is thereby reduced from 13 months to 56 days;

• Offers the flexibility to receive mandates for many different purposes (e.g. charitable donations, telephone/e-mail orders);

• Supports multiple signing in the Debtor Bank domain in case this is required for specific Debtors.

In practice, nearly every Debtor that uses online banking with one of the Debtor Banks that support eMandates can use the eMandates service.

2.2 What is eMandates Mobile?

Participating banks will also implement a mobile version of eMandates. This will be based on mobile banking services like mobile web sites or mobile apps. This is called eMandates Mobile.

The main characteristics of eMandates Mobile are:

• There are no changes in the messages sent between Debtor bank and Creditor bank and no changes in messages sent between Creditor and his/her bank compared to the standard eMandates;

• Creditors and Debtors do not need to take extra steps for a mobile eMandate transaction. The redirecting of the Debtor to the mobile banking channel is done automatically by the Debtor’s bank. For banks that support eMandates in their mobile banking app, the Debtor can choose whether to approve the eMandate using the mobile web browser or the mobile banking app.

• eMandates Mobile is based on the same mechanisms to ensure trust, security and convenience as used in a desktop environment. In cases mobile technology does not

1 Real-time signing and issuing does not always apply when multiple signing is required for the specific Debtor.



support the same technical security measures as a desktop computer the bank will implement alternative measures to compensate.

Every Debtor that uses online banking with one of the Debtor Banks that supports eMandates can also use eMandates on a mobile device (although it may be necessary for a Debtor to download and register a mobile application). Those Debtor Banks that do not (yet) have an eMandates Mobile implementation or that have an implementation that doesn’t reach the majority of Debtors will still be able to process transactions through their regular (desktop focussed) eMandate pages on a mobile device’s browser.

2.3 Design principles

2.3.1 Technical principles

eMandates is based on the following principles:

- Use of existing online banking and mobile banking products. - Communication over the Internet. - Use of open-market standards, where possible. - Merchant implementation involving the least possible complexity. - Taking measures to improve reliability, where possible. - Use of the Multilingual European Subset 2 (MES-2) standard character set. - Debtor's selection of Debtor Bank (Issuer) based on Debtor Bank name. - Safety and reliability (stability).

2.3.2 Functional principles - The eMandates Implementation Guidelines described in this document are intended for the

Core SEPA Direct Debit. - The eMandates solution facilitates the issuing of new eMandates and amendment of existing

eMandates. Creditors must offer both functionalities to their Debtors (issuing new eMandates and amending existing eMandates).

- The only reason for amending an eMandate is when the Debtor wishes to change his bank account number for Direct Debits, within the same bank or to a different bank.

- Cancellation of eMandates is not supported by the eMandates solution. The reason for this is that cancellations usually focus on ending of the subscription or contract, instead of ending of the eMandate. Cancellation of eMandates is therefore something that must be facilitated electronically by the Creditor, without a role for the Debtor Bank.

- The eMandates solution uses the ISO XML 20022 standard eMandates messages to convey eMandate- specific data. The following messages are used: pain.009.01.04 (new, also referred to as ‘issuing’), pain.010.01.04 (amendment) and pain.012.01.04 (acceptance report). The information inside the ISO XML 20022 acceptance report (pain.012) constitutes the actual eMandate. The ISO messages are placed inside the container element in the messages. The XSD’s for these ISO messages can be found at http://www.iso20022.org/full_catalogue.page, see pain – Payments initiation.

- The eMandates solution is intended for both recurring and one-off mandates.



- In the eMandates process, the eMandate information is shown to the Debtor for approval in the Debtor Bank domain.

- Each eMandate has an eMandateID that uniquely identifies it within a given CreditorID. Each Creditor is responsible for issuing his own unique eMandateID’s. Creditors must beware that eMandateID’s must be restricted to the SEPA Direct Debit character set.

- The Creditor is responsible for archiving2 the original eMandate (the ISO pain.012 message which includes the electronic signature and certificate information), together with any following amendment or cancellation information received from the Debtor (at a later stage). The ISO pain.012 message can be archived after extracting it from the XML envelope, using exclusive canonicalization. Alternatively, Creditors may choose to simply archive the entire StatusResponse message.

- The elements eMandate.Frequency and eMandate.MaxAmount have been included in the eMandate solution to facilitate the Debtor Bank’s Debtor Protection measures for Direct Debit collections. However, these elements have been included for future use and will not be used in this version of eMandates. The Creditor MAY NOT INCLUDE these fields in any of the eMandate messages.

- An approved eMandate is used by the Debtor Bank to update the Debtor’s whitelist3, but this is done only when the whitelist has already been activated by the Debtor. An inactive whitelist will not be activated by an eMandate.

- If the Creditor or MandateID is on the Debtor’s blacklist4, there are several options: o The blacklist is adjusted real-time by the Debtor and the eMandate is approved o The blacklist must first be adjusted in a separate process, so the eMandate process

will be cancelled and must be restarted at a later time

2.4 The four-corner model

The eMandates system is based on the ‘four-corner’ model. Figure 1 shows the roles in this model, along with their mutual primary relationships in the context of eMandates. The roles are those of Debtor, Creditor, Creditor Bank, Debtor Bank, Routing Service and Validation Service:

- The Creditor is the company collecting Direct Debits. This can be the actual Creditor, or a Collecting Payment Service Provider collecting Direct Debits acting on behalf of another Creditor.

2 It is expected that in the future more strict requirements will appear for electronic archiving, especially related to

protecting document integrity for a longer period of time. In the short future the regulation on electronic identification will

address the topic of eArchiving and will create a legal framework underlying timestamping services. These guidelines

will then be evaluated and used in these implementation guidelines.

3 A whitelist is a list of MandateID’s belonging to an account number. For this account number, direct debit collections are

allowed for these Mandate ID’s only.

4 A blacklist blocks an account number for Direct Debit collections. This can be a complete blockage, a blockage for a

specific CreditorID or for a specific MandateID.



- The Debtor is a consumer or company holding a bank account at the Debtor Bank, from which Core Direct Debits can be collected.

- The Creditor Bank is the bank where the Creditor has his contract for eMandate services. - The Debtor Bank is the Bank where the Debtor hold’s the bank account that he wishes to use

for eMandates. This bank account MUST be used by the Creditor for the collection of direct debits.

- Routing Service: a technical role (routing of messages) that is fulfilled by a Creditor Bank or a third party endorsed by the Creditor Bank. Wherever the term ‘Routing Service’ is mentioned in this document, please read ‘Routing Service of the Creditor Bank’.

- Validation Service: a technical role that is fulfilled by the Debtor Bank or by a third party endorsed by the Debtor bank. Wherever the term ‘Validation Service’ is mentioned, please read ‘Validation Service of the Debtor Bank’.

2.4.1 The relations between these roles Both contractual and technical relations exist between the roles. These are described below.

Contractual relations:

- Creditor – Creditor Bank: The Creditor has an eMandates contract with a Creditor Bank. The Creditor must also have a Direct Debit contract at (the same or another) Creditor Bank.

- Debtor – Debtor Bank: The Debtor has a bank account with the Debtor Bank. The identity related to this account is used for approving eMandates and subsequently, but outside the scope of the eMandates solution, settling the Direct Debits.

- Debtor - Creditor: The Debtor ‘mandates’ the Creditor by means of an eMandate. This allows the Creditor under SDD rules to withdraw funds from the Debtor’s bank account at a later stage using a Direct Debit (execution of the Direct Debit is outside the scope of the eMandates solution).

Technical relations:

- Creditor – Routing Service: The Creditor has a technical relation with the Routing Service. The Routing service offers the Creditor the possibility of sending eMandate proposals to a Validation Service. They exchange messages to this end.

- Routing Service – Validation Service: The Routing Service and Validation Service have an eMandates solution relationship. They exchange messages in this context.

- Debtor – Validation Service: The Validation Service offers the Debtor the possibility of issuing eMandates to Creditors, by approving eMandate proposals using an online banking product.



Figure 1: Four-corner model

2.5 Terminology

eMandates has been based partly on existing XML messages (of the so-called iDx standards) that are based on the iDEAL messages. To convey specific eMandates information, pain ISO messages are placed inside a container element in these existing iDx XML messages. Because the existing XML messages have some different terminology/element names, a mapping applies between the XML element names and the functional element names that are used in eMandates. Table 2 shows the mapping of functional eMandates element names to the terms used in the XML messages.

2.5.1.1.1.1 Nr. Functional eMandates element names

XML element names

1. Creditor.CreditorBankID Acquirer.acquirerID

2. Debtor.DebtorBankID Issuer.issuerID

3. eMandate.ContractID Merchant.merchantID

4. eMandate.ContractSubID Merchant.subID

5. eMandate.DateTimestamp Transaction.statusDateTimestamp

6. eMandate.TransactionID Transaction.transactionID

Table 2: Mapping of eMandates elements to XML elements

As stated in the introduction, this document will only cover the messages that are exchanged between the Creditor and the Routing Service. However, the messages that are exchanged between the Routing Service (of the Creditor Bank) and the Validation Service (of the Debtor Bank) will be briefly explained if necessary to provide a good understanding of the entire transaction.

Besides the four parties mentioned that are always involved in a transaction, additional parties can be involved. The Creditor can, for example, use a Service Provider to establish the technical



connection with his Routing Service. When a Service Provider collects funds and then distributes these funds to the ultimate Creditor, this is called a “Collecting PSP” (CPSP).



3 eMandates protocol

3.1 General

A typical eMandates transaction comprises (request-/response-) XML messaging and browser redirects, which handle the initiation, and processing of the transaction in a particular sequence, with all parties involved being informed on the status of the transaction. The steps in this transaction are shown in Figure 2.

There are three request/response message pairs (also referred to as protocols) defined within an eMandates transaction:

1. The Directory protocol: used to retrieve the most recent Debtor Bank list from the Routing Service.

2. The Transaction protocol: encompasses the eMandates-transaction process from beginning to end.

3. The Status protocol: used to request the status of a transaction from the Validation Service (via the Routing Service).

Figure 2: Representation of the steps in an eMandates transaction



A specific name (letter) has been assigned to identify each message. The following table applies:

Message Message description

A DirectoryRequest

A’ DirectoryResponse

B AcquirerTransactionRequest

B’ AcquirerTransactionResponse

F AcquirerStatusRequest

F’ AcquirerStatusResponse

X’ AcquirerErrorResponse

Redirects:

D Debtor redirect to Debtor Bank

E Debtor redirect to Creditor

Table 3: Message names and descriptions

By using the Directory protocol, the Creditor sends a DirectoryRequest to the Routing Service. This is a request in XML format to obtain the list of participating Debtor Banks from the Routing Service. The Routing Service will provide this list to the Creditor by sending back the DirectoryResponse. The Creditor will show the list of banks, which were sent in the DirectoryResponse to the Debtor. The Debtor will choose his bank from this list at the beginning of the eMandate process. The Directory protocol is explained in more detail in chapter 7.

By using the Transaction protocol the Creditor sends a TransactionRequest to the Routing Service, containing the ID of the Debtor Bank chosen by the Debtor, mandate information and other transaction details. This message also contains the MerchantReturnURL. This URL is used by the Validation Service to redirect the Debtor back to the Creditor’s website when he has completed the eMandate transaction in his Debtor Bank domain. After the Routing Service has received the message from the Creditor, he adds some pre-registered Creditor details to the message and sends a message to the Validation Service of the Debtor Bank that was selected by the Debtor. In return, the Validation Service responds with a message that contains the issuerAuthenticationURL (and other data). The Routing Service passes this issuerAuthenticationURL together with a unique TransactionID back to the Creditor via the TransactionResponse message, which is the response to the TransactionRequest. The Creditor now redirects the Debtor to the issuerAuthenticationURL, which refers to the page of the online banking portal. This takes the Debtor to his internet-banking environment where he can continue the eMandate transaction. The Debtor Bank adds Debtor information (such as IBAN and Debtor Name) to the eMandate proposal. The Debtor approves the eMandate and receives a confirmation from the Issuer. The Debtor is then redirected back to the website of the Creditor via the merchantReturnURL. The entire Transaction protocol and the 2 redirects are further described in chapter 8.

Finally the Creditor initiates the Status protocol by sending a StatusRequest message to the Routing Service. The Routing Service will request the transaction status, if necessary, from the appropriate Issuer and returns the status to the Creditor. If all steps in the transaction were



successful this status message contains the eMandate and the signature for the Creditor. Chapter 9 contains more detailed information on the Status protocol.

Instead of a regular response to the messages mentioned above, it is also possible that an ErrorResponse is returned. This can be the case if the request contains an error, or if an error occurs during the processing of the request. The ErrorResponse messages are discussed in chapter 10.

Chapter 5 describes the general format of eMandates messages. The three protocols are discussed in more detail in chapters 7, 8 and 9.

3.1.1 Specific requirement eMandates Mobile: Redirect to Issuer can be diverted to mobile app or mobile web page of Issuer

The Mobile transaction flow is almost identical to the transaction flow in a regular eMandates transaction. The only difference is the redirect to a ‘landing page’ (using the issuerAuthenticationURL) where the Debtor, using a mobile device, can choose to be redirected to the Issuer’s (mobile) web page or to the Issuer’s mobile banking app (if available).

Figure 3: Representation of the steps in an eMandates Mobile transaction



4 Functions of the solution

This part describes several specific functionalities of the eMandates-solution. All eMandate processes are initiated on the Creditor website by the Debtor. eMandate processes are never initiated from the Debtor Bank domain.

The eMandate (issuing or amendment) proposal is created by the Creditor. This eMandate proposal is not yet complete: it is completed by the Routing Service (with Creditor information) and Validation Service (Debtor information) respectively.

4.1.1 Issuing a new eMandate Issuing a new eMandate is supported through the use of the ISO pain.009 message type. The Creditor enters the mandate information in the message and this information set is then completed with Creditor information by the Routing Service, and with Debtor information by the Validation Service until the complete eMandate proposal is approved by the Debtor. Upon approval, the Debtor Bank adds an electronic signature to the eMandate on behalf of the Debtor. The signed eMandate is then retrieved by the Creditor and must be archived.

4.1.2 Amending an existing eMandate Just like with new eMandates, the process is initiated by the Debtor on the Creditor website. The only relevant change for an eMandate is when the Debtor wishes to change his account number (within the same bank or to a different bank). The process is almost identical to the process of issuing a new eMandate, but for amendments of existing eMandates, the ISO pain.010 message is used.

The ISO pain.010 message contains the same information as a pain.009 message, but it also included three referrals to the original (existing) eMandate: the original eMandateID, the Debtor IBAN and the Debtor Bank ID.

Amendments to eMandates may also be communicated by the Debtor to the Creditor through use of other channels than eMandates, but this is not recommended.

The Creditor is free to accept amendments to existing (paper) mandates through the use of the eMandates solution.

4.1.3 Cancelling an existing eMandate Cancellation of eMandates is not supported by the eMandates solution; a cancellation of an eMandate does not have to be (and can not be) done via the Debtor Bank domain, but must be cancelled directly at the Creditor. The Creditor must facilitate this through electronic (website, mail) and regular channels.

4.1.4 Debtor protection information Frequency and Maximum amount have been included in this document for future use to facilitate future Debtor protection measures by the Debtor Banks. Therefore, in any current implementation of eMandates, these elements will not be processed by the Routing Service nor by the Validation



Service. Creditors may not include these fields in current eMandates messages, as this will lead to rejection of the entire message.

4.2 Multiple signing

For Core eMandates, multiple signing may be required in the Debtor Bank domain when the Debtor is using a business account to approve the eMandate. This can’t always be done in a single session, which means the Debtor Bank has to store the eMandate proposal and make it accessible for further approval. Furthermore, multiple signing implies the following:

- Only the Debtor Bank can determine when multiple signing is required. - Only the initiator is allowed to be redirected to the Creditor website. This prevents other

signers from taking over the initiator’s session at the Creditor website. - The initiator might not return to the Creditor website and hence wouldn’t receive online

confirmation of the eMandate. The Creditors are therefore recommended to use other means of (offline) communication to inform the initiator the eMandate has (not) successfully been received.

When multiple signing is required, the transaction may need more time to enable other signers to approve the eMandate. However, it is not known beforehand (by the Creditor) whether multiple or single signing is required. Both situations need to be catered for. Therefore, the following principles apply to the use of expiration period5:

• By default, the Creditor should not set the expiration period to the transaction. In that case, the standard expiration period is 30 minutes.

• When the first Debtor logs into the Debtor Bank domain within 30 minutes, the Debtor Bank is able to determine whether multiple signing is required. When multiple signing is indeed required, the Debtor Bank automatically sets the expiration period to 7 days. In all other cases, the expiration period remains 30 minutes.

• The Creditor may always assume the expiration time to be 30 minutes and can perform a status request after 30 minutes (assuming the redirect to the Creditor has not occurred so there has not been a trigger to request the status yet)

• When multiple signing is required, the transaction gets the status ‘Pending’. The Creditor may then request the status of the transaction once every day. After 7 days, the status of the transaction becomes final (Expired) if not all required signers have approved the eMandate transaction.

• If a Creditor has an urgent need to ensure a stricter expiration period, he may choose to set the expiration period to his preferred timeframe, with a maximum of 7 days and a minimum of 1 minute. The Debtor Bank then always adheres to this expiration period (even when multiple signing is required). A possible consequence of setting the expiration period is that Debtors for which multiple signing is required may not have enough time for all signers to complete

5 Expiration period is the amount of time the Debtor has to approve the eMandate in his Debtor Bank domain before it

expires.



the transaction. We therefore strongly recommend Creditors to not set a specific expiration time.

4.3 Creditor Registration for eMandates

4.3.1 Creditor preconditions Each Creditor that wants to use the eMandates solution must have an eMandates-contract. As a pre-condition for getting this contract, a Creditor must be in possession of a Direct Debit contract at a (same or different) Creditor Bank. Only after establishing that a Creditor has a Direct Debit contract will the Creditor Bank enter into an eMandates-contract with this Creditor.

A Creditor that acts as a Collecting Payment Service Provider can collect Direct Debits for other companies. In this case, the eMandates must also be in the name and CreditorID of this CPSP (because the eMandate must be issued to the company that is collecting the Direct Debits). To make sure the Debtor recognises the eMandate, the name of the company being serviced (the ultimate Creditor) must also be mentioned on the eMandate. This is done using the element Creditor.TradeName. In the Debtor Bank domain, for approval by the Debtor this would be phrased as the eMandate being issued to ‘Creditor.Name regarding Creditor.TradeName’.

Likewise, a Creditor may have a company structure using different company labels (names) and addresses. As with the example of the Collecting Payment Service Provider, the labels can be shown on the eMandate as a tradename. In case of more than one company address, the correct address is also selected by the Routing Service for approval of the eMandate.

The Creditor registration process at the Creditor Bank facilitates selecting the right Creditor information for the eMandate by the Routing Service.

4.3.2 Creditor registration When registering for eMandates, the Creditor Bank issues an eMandate.ContractID to the Creditor. The Creditor also gets an eMandate.ContractSubID if this is required to distinguish between Creditor tradenames and/or addresses. The Creditor must register his address using two address-lines, generally using the first line for information on street, number, postbus, add-ons and using the second line for postcode and city. The exact details of the registration (process) are determined by your Creditor Bank and/or the Routing Service acting on its behalf.

In the eMandate process, the eMandate.ContractID and eMandate.ContractSubID are sent to the Routing Service by the Creditor in the eMandates request message. The Routing Service then adds specific Creditor information to this proposal based on the contractID (and when relevant also on the SubID). The Routing Service selects the right Creditor.Name, Creditor.CreditorID, Creditor.TradeName, Creditor.AddressLine1 and Creditor.AddressLine2 to add to the eMandates proposal. The Creditor is not allowed to fill out any of these elements.



4.4 ValidationReference

When the eMandate is approved by the Debtor in his Debtor Bank domain, the Validation Service generates a reference number (the ValidationService.ValidationReference). This reference is sent to the Creditor as part of the eMandate. This reference must be added to the Direct Debit collection information from the Creditor to his Creditor Bank. This reference is used by the Debtor Bank to retrieve eMandates validation information in case of a Debtor dispute.

4.5 Dispute management

In case of a dispute, the Debtor Bank has the role to check the integrity and authenticity of the eMandate. Therefore, in case of a dispute (MOI):

- The Creditor must supply either the ISO pain.012 message that represents the actual eMandate (in exclusively canonicalized form), or the entire XML file that was received in the StatusReponse (message F’). The Creditor must also supply any additional amendment information in case any changes were made outside the eMandates protocol.

- The Creditor sends this information to his Creditor bank by email. The Creditor Bank forwards this information to the Debtor Bank.

- The Debtor Bank uses the certificate information to verify the electronic signature. Thereby determining authenticity and integrity of the eMandate.



5 eMandates Message format

5.1 General

This chapter contains a description of the general message structure for the Directory protocol, the Transaction protocol and the Status protocol. The subsequent sections will describe the specific fields within the XML messages for each protocol in more detail.

Each message described in this section is an XML message conforming to the XML Schema in APPENDIX D.

A list of the ID’s and fields used and the format can be found in the data dictionary in chapter 6.

The following conventions are used to indicate whether a message element is mandatory:

− Yes The element must occur exactly once. − No The element may be left out or may occur exactly once. − Yes (1..∞) The element must occur one or more (unlimited) times.

5.2 HTTP

The following HTTP header must be used for all messages:

Data element Mandatory Explanation

content-type Yes Defines how the remainder of the content is to be interpreted. Contains the value: text/xml; charset=”utf-8”.

All messages must comply with the HTTP 1.1 standard, as defined in RFC 2616 of W3C.

For more information: http://www.w3.org/Protocols/rfc2616/rfc2616.html

Each XML request message must be sent as the body of a HTTP POST message.

Each XML response message must be sent as the body of a HTTP 200 OK message.

5.3 XML header

The following XML header must be used for all messages:

<?xml version="1.0" encoding="UTF-8"?>

Example:

<?xml version="1.0" encoding="UTF-8"?>

<DirectoryReq version="1.0.0" productID="NL:BVN:eMandatesCore:1.0" xmlns="

http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

<createDateTimestamp>2001-12-17T09:30:47Z</createDateTimestamp>

<Merchant>

<merchantID>1234123456</merchantID>

<subID>0</subID>

</Merchant>



<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">

<SignedInfo>

<CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-

sha256"/>

<Reference URI="">

<Transforms>

<Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-

signature"/>

<Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

</Transforms>

<DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

<DigestValue>VW+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</DigestValue>

</Reference>

</SignedInfo>

<SignatureValue>

IELLwKSGFMk64US23YrpZ8//hJ8DeJEtYht5knlxJvBOr8dcI+aJTBq+YtyzP9ClcK62Obs5aynHBE/GPHZShu

Mw+8WHq4fCMInOwKURgwjDOz8UYaIMqG0Ojiz8dFYGn+dH2lL0QVss4jmIIAD8MCijb27oqij6PclXw9Y9veI=

</SignatureValue>

<KeyInfo>

<KeyName>7D665C81ABBE1A7D0E525BFC171F04D276F07BF2</KeyName>

</KeyInfo>

</Signature>

</DirectoryReq>

5.4 Character set

In all eMandates messages the Unicode character set must be used. Only the MES-2 subset must be supported.

Encoding must be used as indicated in the HTTP and XML headers UTF-8 (Unicode Transformation Format).

The use of characters that are not part of the Unicode character set will not lead to a refusal of a batch or post, but the character may be changed to a space, question mark or asterisk in transit.

The Byte Order Mark (BOM) must not be used. The UTF-8 representation of the BOM is the byte sequence 0xEF,0xBB,0xBF.

5.5 XML Namespace declaration

The namespace for all messages described in this document is as follows:

http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0

All message instances must declare this namespace. Namespace declaration can be done in any way allowed by the XML standards (default namespace declaration or namespace



qualification/prefixes). All parties must be able to receive and process messages that use either of the two namespace declaration methods.

5.6 Message attributes

All XML messages must contain attributes in the root element, as shown in the table below.

Attribute Mandatory Explanation

version Yes Value must be: 1.0.0

productID Yes Value refers to the product for which the eMandates protocol is used. Must be

NL:BVN:eMandatesCore:1.0

Beware: These attributes are not specified in each message separately.

5.7 Conventions for empty fields

In eMandates an XML tag for an optional or conditional field is either:

− Present (in which case, the tag must be filled with a valid value).

− Not present at all.

− In general, XML tags without content are not allowed and will result in an error message.

An exception to this rule are several tags that are mandatory in the ISO pain messages, even though they are empty.

5.8 Message validation

All messages must be validated against the eMandates XML Schema. The schema also references the XML Digital Signature Schema that must be used to validate the Signature element. The XML Digital Signature Schema is available from W3C at the following URL: http://www.w3.org/2000/09/xmldsig#.

The eMandate messages in the container element must be validated against the pain message’s XML schema.

Attention: There are eMandate elements in the pain messages for which we use stricter requirements when it comes to being mandatory and formatting than the ISO XSD’s. These requirements can be found in the data dictionary and in the tables specifying how the ISO messages are used (e.g. in Table 13).



6 eMandates Data dictionary

This chapter describes the data-elements and ID’s that are used in the eMandates solution.

6.1 eMandate IDs

The eMandates solution relies on the identifiers described in Table 4.

6.1.1.1.1.1 Nr. 6.1.1.1.1.2 Element 6.1.1.1.1.3 Description 6.1.2 Messages 6.1.2.1.1.1 Formatting rules

1. Creditor.CreditorBankID

Creditor Bank identifier number A’, B’, F’ 4 digit-number

2. Debtor.DebtorBankID BIC of the Debtor Bank B 6.1.2.1.1.2 BIC (ISO 9362)

3. eMandate.ContractID eMandates Contract registration number of the Creditor. This ID uniquely identifies the Creditor to the Creditor Bank in the context of the contract they have for the eMandate service.

A,B,F 10 digit-number: Unique four-digit Creditor.CreditorBankID, combined with a unique combination of six numbers (issued by Creditor Bank)

4. eMandate.ContractSubID eMandate contract registration number Sub of the Creditor The subID that uniquely defines the name and address of the Creditor to be used for the eMandate

A,B,F A number from 0 to and including 999999 in which each value is related to a separate instance registered with the Creditor Bank. The default value is ‘0’.

Table 4: eMandate IDs

6.2 General data elements

The table below contains all XML data elements that appear in messages relevant to the Creditor, together with information about the format and permitted values.

Data element Attribute Messages Format Values, explanation

Root element version All AN..8 1.0.0

Root element productID All AN..35 NL:BVN:eMandatesCore:1.0

Data element Sub-element Messages Format Values, explanation

createDateTimestamp All DT ISO-8601

Directory directoryDateTimestamp A' DT ISO-8601

Directory countryNames A' AN..128

Directory Issuer issuerID A' ANS..max 11 BIC, ISO9362

Directory Issuer issuerName A' AN..max 35

Error consumerMessage X’ AN..max 512

Error container X’ Any

Error errorCode X’ CL AN..6 See Appendix B

Error errorMessage X’ AN..max 128

Error errorDetail X’ AN..max 256

Error suggestedAction X’ AN..max 512



Data element Attribute Messages Format Values, explanation

Issuer issuerAuthenticationURL B' AN..max 512

Merchant merchantReturnURL B AN..max 512 Determined by Creditor

SignedInfo Exclusive CanonicalizationMethod

All http://www.w3.org/2001/10/xml-exc-c14n#

SignedInfo Signaturemethod All http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

SignedInfo Reference URI All Must be empty

SignedInfo Reference Transforms All http://www.w3.org/2000/09/xmldsig#enveloped-signature

SignedInfo Reference Transforms http://www.w3.org/2001/10/xml-exc-c14n#

SignedInfo Reference DigestMethod All http://www.w3.org/2001/04/xmlenc#sha256

SignedInfo Reference DigestValue All Base64

SignatureValue All Base64

KeyInfo KeyName All Fingerprint of certificate

Transaction container B, F’ Any To be filled with eMandate ISO pain message

Transaction entranceCode B ANS..max 40 Determined by Creditor

Transaction expirationPeriod B RDT ISO 8601 Determined by Creditor

Transaction language B CL AN..2 ISO 639-1 Determined by Creditor

Transaction status F' CL AN..max 9 Open, Success, Failure, Cancelled, Expired Pending

Transaction statusDateTimestamp F' DT ISO 8601

Transaction transactionID B’, F, F’ PN..16 Determined by Routing Service

Transaction transactionCreateDateTimestamp

B’ DT ISO 8601 Determined by Routing Service

Table 5: Data elements in iDx messages

Notation Meaning

AN Alphanumeric, free text

ANS Alphanumeric, strict (letters and numbers only)

N Numerical

PN Numerical (padded), the contents are extended to the maximum length by leading zeros

..max # Maximum number of positions for alphanumeric and numerical values

..# Fixed number of positions for alphanumeric and numerical values

CL Code list, enumeration

DT Date time field in UTC (no daylight saving time): yyyy-MM-



ddTHH:mm:ss.SSSZ

RDT Relative date time field: PnYnMnDTnHnMnS

DEC(#1,#2) Decimal, #1 total digits, #2 fraction digits: DEC(6,2) can be 1234.56 for example

Table 6: Used data formats in the data catalogue

Message Message description

A DirectoryRequest

A’ DirectoryResponse

B AcquirerTransactionRequest

B’ AcquirerTransactionResponse

F AcquirerStatusRequest

F’ AcquirerStatusResponse

X’ AcquirerErrorResponse

Redirects:

D Debtor redirect to Debtor Bank

E Debtor redirect to Creditor

Table 7: Used character codes in the data catalogue

The characters C, G and Y are used in eMandates to refer to specific messages between the Validation Service and Routing Service. Because these are not relevant for the Creditor they are omitted from the table above.

6.3 eMandates ISO pain message data elements

Table 8 describes the data elements that are used in the eMandates ISO pain messages (009, 010 and 012), together with their formatting rules. Attention: several of these elements are added to the eMandate by the Routing Service and Validation Service. These elements are therefore not part of the Transaction Request the Creditor sends to the Routing Service. Please see chapter 8.2 for an overview of the information that is part of the Transaction Request.

Nr. 6.3.1.1.1.1 eMandates name 6.3.1.1.1.2 Description 6.3.1.1.1.3 Formatting rules

1. Creditor.AddressLine1 The Creditor’s address – line 1 • P.O. Box or street name + building +

add-on (if any)

Max70Text

2. Creditor.AddressLine2 The Creditor’s address – line 2 • Postcode • City

Max70Text

3. Creditor.Country Country of the postal address of the Creditor

[A-Z]{2,2}

4. Creditor.CreditorID Direct Debit ID of the Creditor (NL: IncassantID)

As described in AT-02 (Identifier of the Creditor) in the EPC SDD Implementation Guidelines. You will receive this from your Creditor Bank.




5. Creditor.Name Name of the Creditor Max70Text

6. Creditor.TradeName

Name of the company (or daughter- company, or label etc) for which the Creditor is processing eMandates. May only be used when meaningfully different from Creditor.Name

Max70Text

7. DateTime Date and time UTC time format (YYYY-MM- DDThh:mm:ss.sssZ) ISO 8601.

8. Debtor.AccountName Account holder name of the account that is used for the eMandate

Max70Text

9. Debtor.DebtorBankID BIC of the Debtor Bank 6.3.1.1.1.4 BIC (ISO 9362)

10. Debtor.IBAN Debtor’s bank account number IBAN (ISO 13616)

11. Debtor.SignerName Name of the person(s) signing the eMandate. May end with ‘e.a.’ in case more than 70 characters are needed for multiple signer names.

Max70Text

12. eMandate.AmendmentReason The reasoncode for amending the eMandate

Must be ‘MD16’ Means that amendment was requested by Debtor.

13. eMandate.DateTimestamp Date and time at which the eMandate has been approved by the Debtor in the Debtor Bank domain

UTC time format (YYYY-MM- DDThh:mm:ss.sssZ) ISO 8601.

14. eMandate.DebtorReference Reference ID that identifies the Debtor to the Creditor. Issued by the Creditor

Max35Text

15. eMandate.eMandateID ID that uniquely identifies the Mandate and is issued by the Creditor.

Max35Text Must be restricted to the SEPA character set

16. eMandate.FrequencyCount The number of Direct Debit collections during a specific eMandate.FrequencyPeriod.

Not allowed in current implementations

Maximum 18 digit number. No fractional digits allowed.

17. eMandate.FrequencyPeriod Period for the number (eMandate.FrequencyCount) of Direct Debit collections Not allowed in current implementations

See code list in Table 9.

18. eMandate.MaxAmount The maximum amount per Direct Debit. Not allowed in current implementations

Maximum 11 digit number, of which 2 fractional digits. Decimal separator is a dot. ActiveCurrencyCode: EUR ’EUR’

19. eMandate.PurchaseID A purchaseID that acts as a reference from eMandate to the purchase-order. Creditors are recommended to only use this element when it is meaningfully different from eMandate.Reason

Max35Text

20. eMandate.Reason Indicates the reason of the mandate Max70Text

21. eMandate.SequenceType Indicates type of eMandate: one-off Direct Debit or recurring.

‘OOFF’ or ‘RCUR’

22. eMandate.TransactionID eMandateTransaction ID. The value for this ID is taken from the Transaction.transactionID

16 digit number




23. Message.NameID Refers to the type of validation request that preceded the acceptance report

2 values: - Issuing - Amendment

24. ValidationService.ValidationReference

The reference to the eMandate validation log of the Validation Service. This reference is created by the Validation Service. This reference must be used by the Creditor to fill out the element ‘Electronic Signature’ in the Direct Debit Collection message (outside the scope of this document)

Max128Text

Table 8: eMandates data elements

6.3.1 Frequency Frequency is defined as the number of Direct Debit collections for a specific eMandateID per period. In the eMandate message, this is done by entering a specific number (eMandate.FrequencyCount) and a period (eMandate.FrequecyPeriod).

The following table shows the codes that can be used to indicate the period of the Direct Debit collections. NB: since Frequency is not allowed to be used in this implementation of eMandates, the permitted period-code list and definitions in Table 9 will be reviewed and adjusted after it is decided that Frequency will be used.

eMandate.FrequencyPeriod Code Definition

ADHO Event takes place on request or as necessary

DAIL Event takes place every day

FRTN Event takes place every two weeks

INDA Event takes place several times a day

MIAN Event takes place every six months or two times a year

MNTH Event takes place every month or once a month

QURT Event takes place every three months or four times a year

WEEK Event takes place once a week

YEAR Event takes place every year or once a year

Table 9: eMandate.FrequencyPeriod codes



7 eMandates Directory protocol

7.1 General

The Directory protocol allows a Creditor to retrieve an up to date list of participating Debtor Banks from his Routing Service, which can be presented to the Debtor. In case of changes in the list of Debtor Banks, the Directory protocol will supply the Creditor with the update of this list.

It is not allowed to perform the Directory protocol for each transaction. Since the list of Debtor Banks only changes occasionally, it is sufficient to execute the Directory protocol on a weekly basis and check if the list has changed based on the directoryDateTimestamp. If the Debtor Bank list has changed, the latest version has to be saved and used for any subsequent transaction. Routing Services will normally also inform all Creditors (e.g. by email) about changes in their Debtor Bank list. The Directory protocol should at least be executed once a week.

The Directory protocol (like the Transaction protocol and the Status protocol) consists of a HTTP POST request from the Creditor to the Routing Service, followed by a HTTP response. The DirectoryRequest is sent to the URL that is provided to the Creditor by the Routing Service for this specific purpose. This URL can be different from the one that is used for the TransactionRequest and the StatusRequest, but it can also be the same URL.

The Routing Service validates the authenticity of the message sent by the Creditor by verifying the signature in the message. To do this, the Routing Service needs the Creditor’s Certificate, including the public key. The way in which the public part of the Creditor certificate is communicated with the Routing Service varies per bank.

Please refer to Chapter 11 for more information on authentication and security.

7.2 DirectoryRequest

The DirectoryRequest consists of an XML message that is sent to the Routing Service with HTTP POST.

Table 10 shows all fields and formatting of the DirectoryRequest:

Field Name Description Format

createDateTimestamp Date and time at which the directory request message was created. DT

merchantID eMandate.ContractID as supplied to the Creditor by the Creditor Bank. If the eMandate.ContractID has less than 10 digits leading zeros are used to fill out the field.

PN...10

subID eMandate,ContractSubID, as supplied to the Creditor by the Creditor Bank, if the Creditor has requested to use this. A Creditor can request permission from the Creditor Bank to use one or more subIDs. In this way the Creditor.Tradename and relevant Creditor.Address belonging to the SubID will also be shown on the eMandate, next to the Creditor.Name. (Creditor.Name, on behalf of Creditor.TradeName).

Unless agreed otherwise with the Creditor Bank, the Creditor has to use 0 (zero) as subID by default (if no subIDs are used).

N..max 6

SignedInfo This element contains information about the signature as described in W3C XMLdsig specifications See chapter 11 for more information

*



SignatureValue Contains the electronic signature as described in W3C XMLdsig specifications. See chapter 11 for more information

*

KeyInfo 7.2.1.1.1.1 Contains information (fingerprint) about the certificate that is used for generating the digital signature, so the receiver can use the right public key for validating the signature as described in W3C XMLdsig specifications.

7.2.1.1.1.2 See chapter 11 for more information

*

Table 10: Fields of the DirectoryRequest

* SignedInfo, SignatureValue and KeyInfo are XML Signature data elements that are defined in the XML-Signature Syntax and Processing (Second Edition) W3C Recommendation 10 June 2008. The signature is described in more detail in Chapter 11. The XML Schema for XML Signatures is available from W3C at the following URL: http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/xmldsig-core-schema.xsd.

APPENDIX C shows an example of a DirectoryRequest and all other messages that are described in this document.

7.3 DirectoryResponse

The Creditor will receive the DirectoryResponse as a reply to the DirectoryRequest. This XML message contains a list of Debtor Bank names with their corresponding Debtor BankID (BIC). Debtor Banks are grouped by country. The Debtor Banks in the Creditor’s country of choice may be presented at the top in the Debtor Bank selection list, the rest are sorted alphabetically by country, then by name. Table 11 shows all fields that appear in the DirectoryResponse message.

Name Description Format

createDateTimestamp Date and time at which the response message was created. DT

acquirerID Unique four-digit identifier of the Creditor Bank (Creditor.CreditorBankID) within eMandates.

PN..4

directoryDateTimestamp The date and time on which the Directory was updated by the Routing Service.

DT

countryNames Contains the countryNames in the official languages of the country, separated by a ‘/’ symbol (e.g. ‘België/Belgique’)6.

issuerID Debtor.DebtorBankID: Bank Identifier Code (BIC) of the Debtor Bank

ANS..max 11

issuerName The name of the Debtor Bank (as this should be displayed to the Debtor in the Creditor’s Debtor Bank list).

AN..max 35

SignedInfo See 7.2 and 11.2

SignatureValue See 7.2 and 11.2

KeyInfo See 7.2 and 11.2

Table 11: Fields of the DirectoryResponse

An example of the DirectoryResponse is shown in APPENDIX C.

6 Country names need only be displayed if there are Debtor Banks from more than one country on the Debtor Bank list. If

all Debtor Banks in the list are from the same country, the country name can be omitted.



7.4 Presentation of the Debtor Bank selection list

To ensure that the Debtor experience of an eMandates transaction is consistent and recognisable through all Creditor websites; all Creditors have to comply with certain presentation standards.

All Debtor Banks in the DirectoryResponse have to be shown in a “dropdown list box”. The first element in this list is “Kies uw bank…” (Eng. “Choose your bank…”), and is selected by default. Subsequently the name of the Creditor’s country of choice is shown (either the Creditor’s own country or the country the Debtor is (expected to be) from). The names of all Debtor Banks that belong to the Creditor’s country of choice are presented next in separate elements, in the same (alphabetical) order as they are presented in the DirectoryResponse. Following this the names of other available countries are presented alphabetically, within each country the banks from that country are sorted alphabetically, in the same order as presented in the DirectoryResponse. The Creditor should generate an error message whenever one of the elements “Kies uw bank…” and countryNames elements is selected by the Debtor.

It is recommended to configure the HTML “value” field of the items in the list box to be the Debtor BankID (BIC) of the corresponding Debtor Bank, because this value is necessary for subsequent messages. An example of the Debtor Bank selection list is shown in Figure 4.

Figure 4: Example of (open) dropdown list box showing the Debtor Bank list

Creditors are not permitted to remove Debtor Banks temporarily from the Debtor Bank selection list or to grey them out.

If a Creditor learns via the eMandates Notification System (Central Reporting tool for eMandates Validation Services and Routing Services to state system non-availability) or via error messages received from the Acquiring bank that a particular Validation Service is currently not available, the Creditor may display a message on its website informing Debtors that the particular bank is not



available. In other words, it is permissible to display a message conveying such information but it is not permissible to temporarily remove or grey out the Debtor Bank concerned from the Debtor Bank selection list.



8 eMandates Transaction protocol

8.1 General

The Transaction protocol initiates the exchange of messages of the actual eMandates process. After the Debtor has chosen eMandates as a transaction method and has selected his bank, the Creditor sends a TransactionRequest to the Routing Service. Within the eMandates standards this message is referred to as the AcquirerTransactionRequest. The Routing Service replies to the TransactionRequest with a TransactionResponse. This TransactionResponse will also (among other fields) contain the issuerAuthenticationURL. This URL will redirect the browser of the Debtor to the Debtor Bank in order to let him authorise the transaction.

8.2 TransactionRequest

The XML message sent by the Creditor to the Routing Service to initiate the transaction contains the fields shown in Table 12. The eMandate information (ISO message) is put inside the container element in the Transaction Request. The definition of the ISO message for a new eMandate request (ISO pain.009.001.004) is shown in Table 13. The definition of the ISO message for an eMandate amendment request (ISO pain.010.001.004) is shown in Table 14.


createDateTimestamp Date and time at which the TransactionRequest message was created.

DT

issuerID The ID (BIC) of the Debtor Bank selected by the Debtor, as stated in the Debtor Bank list in the Directory response (Debtor.DebtorBankID).

ANS..max 11


PN...10

subID eMandate,ContractSubID, as supplied to the Creditor by the Creditor Bank, if the Creditor has requested to use this. A Creditor can request permission from the Creditor Bank to use one or more subIDs. In this way the Creditor.Tradename and relevant Creditor.Address belonging to the SubID will also be shown on the eMandate, next to the Creditor.Name. (Creditor.Name, on behalf of Creditor.TradeName).


N..max 6

merchantReturnURL Valid Creditor URL (not necessarily beginning with http:// or https://) which must redirect the Debtor from the Debtor Bank back to the Creditor website after authorisation of the transaction by the Debtor. Example: https://www.webshop.nl/processtransaction

AN..max 512

expirationPeriod Optional: The period of validity of the transaction request as stated by the Creditor measured from the receipt by the Debtor Bank. The Debtor must approve the eMandate within this period. Otherwise the Debtor Bank sets the status of the transaction to ‘Expired’. Value period according to ISO 8601: PnYnMnDTnHnMnS. Minimum value: PT1M or PT60S (1 minute); maximum value: P7D, PT168H, PT10.080M (7 days). The Creditor is recommended to leave this field empty.

RDT

language This field enables the Debtor Bank’s site to select the Debtor’s preferred language (e.g. the language selected on the Creditor’s site), if the Debtor Bank's site supports this. Code list in accordance with ISO 639-1.

CL AN..2



(Dutch = ‘nl’, English = ‘en’) If a non-supported or non-existing language is entered the standard language of the Debtor Bank is used. It is recommended to use ‘nl’ by default since not all Debtor Banks support other languages.

entranceCode The Transaction.entranceCode is an 'authentication identifier' to facilitate continuation of the session between Creditor and Debtor, even if the existing session has been lost. It enables the Creditor to recognise the Debtor associated with a (completed) transaction. The Transaction.entranceCode is sent to the Creditor in the Redirect. The Transaction.entranceCode must have a minimum variation of 1 million and should comprise letters and/or figures (maximum 40 positions). The Transaction.entranceCode is created by the Creditor.

ANS..max 40

Container This container contains the ISO pain messages. This can be a pain.009 (new eMandate) or pain.010 (amendment) message. See paragraphs 8.2.2 and 8.2.3 for details.




Table 12: Fields of the TransactionRequest

8.2.1 Container content As explained, the mandate ISO pain messages are put in the container element. The ISO message is a standardised message, so it contains elements that are not used in the eMandates solution. In the following tables, only mandatory and recommended optional elements for the eMandates solution are mentioned. The table’s columns contain the following information:

• Column 1 is the index. This index is specific for this document. • Column 2 gives the name of the message element as defined in the ISO 20022 XML

standard. When an element contains sub-elements these are indented to the right and noted with a plus sign (+) per level.

• Column 3 specifies whether the element is Mandatory or Optional

8.2.2 Content of container element for new eMandates The following table describes which elements the Creditor sends to the Routing Service in the TransactionRequest, for a new eMandate. Complex types are elements that don’t have an actual value themselves. They function as containers for sub-elements that hold the actual values.

Index ISO Message Element eMandates Requirement

1 + Message root Mandatory

2 + Group Header Mandatory. Complex type

3 ++ Message Identification Mandatory




Max35Text Format: maxLength: 35, minLength: 1

4 ++ Creation Date Time Mandatory

DateTime

5 + Mandate Mandatory

6 ++ Mandate Identification Mandatory eMandate.eMandateID

7 ++ Mandate Request Identification Mandatory

8.2.2.1.1.1 Must be: NOTPROVIDED

8 ++ Type Mandatory, Complex type

9 +++ Service Level Mandatory, Complex type

10 ++++ Code Mandatory

The identification code of the Scheme

Usage Rule: Only ‘SEPA’ is allowed.

11 +++ Local Instrument Mandatory, Complex type

12 ++++ Code Mandatory

Specifies the local instrument

Usage Rule: Only ‘CORE’ is allowed to indicate a Core

direct debit.

13 ++ Occurrences Mandatory, Complex type

14 +++ Sequence Type Mandatory eMandate.SequenceType

15 +++ Frequency Optional

Usage rule: Not allowed in current implementation

16 ++++ Type Not allowed

17 ++++ Period Mandatory (if Frequency is provided), Complex type




18 +++++ Type Mandatory (if Frequency is provided) eMandate.FrequencyPeriod

19 +++++ CountPerPeriod Mandatory (if Frequency is provided) eMandate.FrequencyCount

20 ++ Maximum Amount Optional element eMandate.MaxAmount


21 ++ Reason Optional, Complex type

22 +++ Code Not allowed

23 +++ Proprietary Mandatory (if Reason is provided) eMandate.Reason

24 ++ Creditor Mandatory

Must be empty

Usage rule: Intentionally not filled further by the Creditor,

as the Creditor information will be added by the Routing

Service

25 ++ Debtor Mandatory, Complex type

Must be empty if eMandate.DebtorReference is not

used

26 +++ Identification Optional , Complex type

27 ++++ Private Identification Optional, Complex type

28 +++++ Other Optional, Complex type

29 ++++++ ID Optional eMandate.DebtorReference

30 ++ Debtor Agent Mandatory, Complex type

31 +++ Financial Institution Identification Mandatory, Complex type




32 ++++ BICFI Mandatory Debtor.DebtorBankID

33 ++ Referred Document Optional, Complex type

Usage rule: only one occurrence is allowed

34 +++ Type Mandatory (if Referred Document is provided), complex

type

35 ++++ Code Or Proprietary Mandatory (if Referred Document is provided), complex

type

36 +++++ Code Not allowed

37 +++++ Proprietary Mandatory (if Referred Document is provided), eMandate.PurchaseID

Table 13: Pain.009 message (new eMandate)

8.2.3 Content of container element for eMandate amendments A Debtor can amend the Debtor account number of an existing eMandate through the eMandate solution. The website-process is the same as with new eMandates, but in this case the Debtor indicates which existing eMandate (eMandateID) he wishes to adjust. The original Debtor Bank ID and the original Debtor IBAN are also included in the amendment request.

The following table describes which elements the Creditor sends to the Routing Service in the TransactionRequest, for an eMandate amendment.


1 + Message root Mandatory

2 + Group Header Mandatory, Complex type

3 ++ Message Identification Mandatory


4 ++ Creation Date Time Mandatory

8.2.3.1.1.1 DateTime




5 + Underlying amendment details Mandatory, Complex type

6 ++ Amendment Reason Mandatory, Complex type

7 +++ Reason Mandatory, Complex type

8 ++++ Code Mandatory eMandate.AmendmentReason

9 ++ Mandate Mandatory, Complex type

10 +++ Mandate Identification Mandatory eMandate.eMandateID

11 +++ Mandate Request Identification Mandatory

Must be: NOTPROVIDED

12 +++ Type Mandatory, Complex type

13 ++++ Service Level Mandatory, Complex type

14 +++++ Code Mandatory

The identification code of the Scheme

Usage Rule: Only ‘SEPA’ is allowed.

15 ++++ Local Instrument Mandatory, Complex type

16 +++++ Code Mandatory

Specifies the local instrument

Usage Rule: Only ‘CORE’ is allowed to indicate a Core direct

debit.

17 +++ Occurrences Mandatory, Complex type

18 ++++ Sequence Type Mandatory eMandate.SequenceType

19 ++++ Frequency Optional





20 +++++ Type Not allowed

21 +++++ Period Mandatory (if Frequency is provided), Complex type

22 ++++++ Type Mandatory (if Frequency is provided) eMandate.FrequencyPeriod

23 ++++++ CountPerPeriod Mandatory (if Frequency is provided) eMandate.FrequencyCount

24 +++ Maximum Amount Optional eMandate.MaxAmount


25 +++ Reason Optional, Complex type

26 ++++ Code Not allowed

27 ++++ Proprietary Mandatory (if Reason is provided) eMandate.Reason

28 +++ Creditor Mandatory

Must be empty

Usage rule: Intentionally not filled further by the Creditor, as

this will be filled by the Routing Service

29 +++ Debtor Mandatory, Complex type

Must be empty if eMandate.DebtorReference is not used

30 ++++ Identification Optional, Complex type

31 +++++ Private Identification Optional, Complex type

32 ++++++ Other Optional, Complex type

33 +++++++ ID Optional eMandate.DebtorReference

34 +++ Debtor Agent Mandatory, Complex type




35 ++++ Financial Institution Identification Mandatory, Complex type

36 +++++ BICFI Mandatory Debtor.DebtorBankID

This ID differs from Debtor.DebtorBankID in nr 53, in case of a

bankswitch

37 +++ Referred Document Optional, Complex type


38 ++++ Type Mandatory (if Referred Document is provided), complex type

39 +++++ Code Or Proprietary Mandatory (if Referred Document is provided), complex type

40 ++++++ Code Not allowed

41 ++++++ Proprietary Mandatory (if Referred Document is provided) eMandate.PurchaseID

42 ++ Original Mandate Mandatory, Complex type

This element contains several mandatory elements of the

original eMandate

43 +++ Original Mandate identification Not allowed

44 +++ Original Mandate Mandatory, Complex type

45 ++++ Mandate identification Mandatory

Usage rule: This is to specify the original eMandate

identification and must be identical to data element 10. eMandate.eMandateID

46 ++++ Creditor Mandatory, Complex type (empty)

47 ++++ Debtor Mandatory, Complex type (empty)

48 ++++ Debtor Account Mandatory, Complex type

49 +++++ Identification Mandatory, Complex type




50 ++++++ IBAN Mandatory Debtor.IBAN

Usage Rule: Must contain the IBAN of the original (e)Mandate

51 ++++ Debtor Agent Mandatory, Complex type

52 +++++ Financial Institution Identification Mandatory, Complex type

53 ++++++ BICFI Mandatory Debtor.DebtorBankID

8.2.3.1.1.1.1 Usage Rule: Must contain the Debtor Bank ID of the bank of

the original (e)Mandate

Table 14: Pain.010 message (amendment)

8.3 TransactionResponse

If everything goes well the Routing Service will reply to the TransactionRequest with the TransactionResponse. Table 15 shows all fields of the TransactionResponse message. The TransactionResponse has no container, so there is no ISO message in this response (this is different in case of an ErrorResponse, see Chapter 10 on error handling).


createDateTimestamp Date and time at which TransactionResponse message was created. DT

acquirerID Unique four-digit identifier of the Creditor Bank (Creditor.CreditorBankID) within eMandates.

PN..4

issuerAuthenticationURL The complete Debtor Bank URL to which the Debtor shall be redirected by the Creditor for authentication and authorisation of the transaction.

AN..max 512

transactionID Unique 16-digit number within eMandates. The number consists of the Creditor.CreditorBankID (first four positions) and a unique number generated by the Routing Service (12 positions). This number uniquely defines each eMandate transaction. It is re-used in the StatusRequest to identify for which transaction the status is requested.

PN..16

transactionCreateDate Timestamp

Date and time at which the transaction was first registered by the Routing Service. This time can be used by Creditor, Routing Service and Validation Service for reporting on the transaction.

DT




Table 15: Fields of the TransactionResponse



8.4 Errors when executing Transaction Protocol

A number of errors may occur when executing the eMandates Transaction Protocol. These may be related to unavailability or an error within your own web environment (Creditor), the Routing Service environment or the Validation Service environment.

The following situations may occur:

1. The eMandates transaction cannot successfully be initiated.

2. You receive an error response (message ‘X’) from your Routing Service within the set time-out period.

3. You do not receive any response within the set time-out period.

In all of the above cases, the transaction protocol cannot be successfully executed. This means it is not possible for the eMandates transaction to take place at that time. Error handling is explained in more detail in chapter 10.

8.5 Redirect to the online banking environment (issuerAuthenticationURL)

After receiving the TransactionResponse the Creditor has to redirect the Debtor to the issuerAuthenticationURL of the selected Debtor Bank, as stated in the TransactionResponse message. If the Creditor’s page contains HTML frames, these will be removed by the Debtor Bank (‘frame busting’). If and when the Debtor returns to the Creditor’s website (with the merchantReturnURL), the Creditor will have to completely rebuild its own page to show confirmation of eMandate reception.

8.5.1 Specific requirement eMandates Mobile: Redirect to Debtor Bank (no in-app browser) The Creditor needs to provide the redirect to the Debtor Bank from the browser window or Creditor app where the Debtor selected the Debtor bank. If it is not possible to keep the Debtor in the same browser window then this should be communicated to the Debtor (e.g.: “You will now be redirected to the app or (mobile) website of your bank”).

In case of a transaction initiated in the mobile Creditor app, it is not allowed to present the Debtor Bank approval screens in a web view component within the Creditor’s own app (in-app browser). The complete transaction flow, up to the redirect back to the Creditor’s app, must take place in an app that is trusted by the Debtor, either the Debtor’s chosen browser or the Debtor Bank’s mobile app. Thus, the issuerAuthenticationURL must, for execution, be offered to the mobile operating system at all times. During the transaction flow it must not be possible for the Debtor to initiate another transaction through the Creditor’s original app.

Relevant details about the redirect from the Creditor to the Debtor Bank’s mobile channel:

- The Debtor Bank decides which Debtors to redirect to which channel. For example, some Debtor Banks may treat users of tablet devices the same as mobile users, while others will treat them like PC users;

- The Creditor should not intervene with the redirect, there is only one issuerAuthenticationURL for the Creditor to use in all transactions, not a separate URL for mobile eMandates transactions. The issuerAuthenticationURL should be executed by the operating system at all times;



- If the Debtor bank has integrated eMandates mobile in its mobile banking app, the Debtor is offered the option, on a ‘landing page’, to open the app or approve the eMandate via the (mobile) web page. On this ‘landing page’ the Debtor might be offered the option to download the latest version of the mobile banking app, if it is not yet installed on the Debtor’s device.

8.6 Redirect to the Creditor environment (merchantReturnURL)

After the Debtor has performed the necessary steps at the Debtor Bank he will be presented with a ‘Continue’ button that must redirect him back to the website of the Creditor with the merchantReturnURL as supplied in the TransactionRequest.

Two GET parameters are appended to this URL: the entranceCode (see paragraph 8.2) with ‘ec’ as GET parameter name, and the transactionID (see paragraph 8.3) with ‘trxid’ as GET parameter name. It is also possible for a Creditor to add additional parameters. For example, if the Creditor defines the merchantReturnURL as follows:

http://www.webshop.nl/processtransaction?producttype=electronics

The final URL will look something like:

http://www.webshop.nl/processtransaction?producttype=electronics&trxid=

0010123456789012&ec=4hd7TD9wRn76w6gGwGFDgdL7jEtb

The entranceCode field should contain a unique value, with the object of preventing message ‘sniffing’. Use of the same entranceCode each time would allow malevolent individuals to intercept the data from the merchantReturnURL and make fraudulent use of this information. This is why using unique values for the entranceCode is extremely important.

Note that a Debtor may not always use the redirect back to the Creditor environment that is offered by the Debtor Bank. Also note that in exceptional cases the Debtor Bank may be unable to match the transactionID in its system or another error occurs, which makes it impossible to redirect the Debtor back to the Creditor. In all other cases the Debtor is redirected with the parameters defined above, regardless of the final status of the transaction (success, cancelled, failed). The Creditor must then use the Status protocol (see chapter 9) to determine the status of the transaction.

8.6.1 Requirements for eMandates Mobile: redirect to the Creditor environment. After the Debtor has been authenticated in either the mobile or regular channel and has approved the transaction, he is redirected back to the Creditor as normal (using the merchantReturnURL). The merchantReturnURL usually starts with ‘https’, redirecting the Debtor back to a page on the mobile device’s browser. If the Debtor has initiated the transaction from the Creditor’s mobile app, the merchantReturnURL can be an app handler, which will redirect the Debtor directly to the Creditor app. An app handler is a call that can be used to start an app and request it to initiate a specific action. For example a Creditor’s app handler can start with ‘nl.companyname.eMandates://’ and this will open the Creditor’s app.

NB: the merchantReturnURL should always direct to a web page or app of the Creditor (or party acting on behalf of the Creditor).



8.7 Errors during execution of the redirect to the Debtor Bank, approving the eMandate and/or the redirect to the Creditor environment

The following errors may occur during execution of the redirect to the online banking environment (Debtor Bank), the execution of the eMandate transaction at the Debtor Bank and/or the redirect back to your (Creditor) environment:

• The bank page is unavailable as a result of which the Debtor cannot approve the eMandate, but the Debtor can’t be properly redirected to your confirmation page either

• The bank page is available but the Debtor cannot (after approving the eMandate or otherwise) be properly redirected to your confirmation page.

In both situations the Debtor cannot (as the result of a disturbance) return to your confirmation page in the normal way. In that case the Debtor can return to your website by using the ‘back’ button or entering the URL, for example.

If the Debtor can be identified (for example because he or she has logged into the Creditor environment or via the browser session), the advice in these situations is to check the status of the eMandates transaction (via the Status protocol) and notify the Debtor.

If the Debtor can be identified and the status can be checked but is found to still be 'open', we recommend that the Debtor is shown the following message: We haven’t received the confirmation of your eMandate from your bank yet. We will inform you as soon as we have received the confirmation.

If the Debtor can’t be identified upon return, your system should check the status of the eMandate transaction at the end of the expiration period.

In such situations, we also recommend that the status of the eMandate is reported to the Debtor – as soon as it has become final – in one of the ways indicated below:

• By e-mail.

• On your website, for example in the account of the Debtor or via the Debtor's browser session.

8.8 Four different scenario’s for completion of eMandates Mobile transaction

To give an overview of all the possible process steps and important notes when dealing with eMandates Mobile transactions, we have specified four different scenarios. There are four different scenarios because either the Debtor Bank or the Creditor or both can use a (mobile) web page or a mobile app.

Because these scenarios (could) differ from the regular (non-mobile) eMandates transactions they will be illustrated in the following paragraphs.

Paragraph Creditor Issuing Bank

8.8.1 (Mobile) web page (Mobile) web page

8.8.2 (Mobile) web page Mobile banking app



8.8.3 Mobile app (Mobile) web page

8.8.4 Mobile app Mobile banking app

Table 16: Different scenario’s for the completion of an eMandates mobile transaction

8.8.1 Debtor is redirected from the Creditor’s (mobile) web page to the Debtor Bank’s (mobile) web page.

This is currently the most common eMandates mobile scenario, as it is identical to the regular desktop eMandates transaction flow. As such there are no specific notes for use in a mobile setting, but this scenario has been added for reasons of completeness.

The Debtor starts the transaction on the Creditor’s mobile page and follows these steps:

Step Description Important note

1 The Debtor selects eMandates as the payment method.

2 The Debtor selects his Debtor Bank.

3 The Debtor is redirected to the Debtor Bank of his choice.

4 The Debtor Bank presents the Debtor Bank ‘landing page’ to the Debtor, which offers the option to complete the eMandates transaction in the Debtor Bank’s mobile banking app or in the Debtor Bank’s (mobile) web page.

5 The Debtor selects the (mobile) web page.

6 The Debtor is redirected to the Debtor Bank’s (mobile) web page where he can log in and authorize the eMandates transaction. After completion of the transaction the Debtor Bank shows the complete eMandate to the Debtor.

7 The Debtor is redirected back by the Debtor Bank, to the Creditor’s (mobile) web page using the merchantReturnURL, which was received from the Creditor.

The merchantReturnURL usually starts with https:// and contains two parameters (entranceCode and transactionID) that can be used to correctly identify the Debtor upon his return.

8 The Creditor shows the Debtor the result of the eMandates transaction.

Table 17: Scenario: Redirect from Creditor (mobile) web page to the Debtor Banks (mobile) web page

8.8.2 Debtor is redirected from the Creditor’s (mobile) web page to the Debtor Bank’s mobile banking app

The Debtor starts his customer journey on the Creditors (mobile) web page and follows the following steps:





2 The Debtor selects his Issuing Bank.



5 The Debtor selects the mobile banking app.

6 The Debtor is redirected to the Debtor Bank’s mobile banking app where he can authorize the eMandates transaction. After completion of the transaction the Debtor Bank shows the complete eMandate to the Debtor.

7 The Debtor is redirected back by the Debtor Bank, to the Creditor’s (mobile) web page using the merchantReturnURL, which was received from the Creditor.

Because the transaction takes place in the bank’s app, outside of the web-browser setting, the browser session may be lost. This means the Creditor may not be able to recognize the Debtor using the browser session.

Next to this, when redirecting the Debtor back to the Creditor from the bank-app, the merchantReturnURL is handled by the Operating System of the mobile device. The OS uses the native (default) browser to handle this URL. This discontinues the original browser session if the transaction was initiated in a non-native browser.

The merchantReturnURL starts with https:// and contains two parameters (entranceCode and transactionID) that can be used to correctly identify the Debtor upon his return.


Table 18: Scenario: Redirect form Creditor (mobile) web page to the Debtor Banks mobile banking app

8.8.3 Debtor is redirected from the Creditor’s mobile app to the Debtor Bank’s (mobile) web page

The Debtor starts his customer journey on the Creditors mobile app and follows the following steps:







It is mandatory for the Creditor to let the Operating System, which is installed on the Debtor’s mobile device, handle the issuerAuthenticationURL. See paragraph 8.5.1 for more information.


5 The Debtor selects the (mobile) web page.

6 The Debtor is redirected to the Debtor Bank’s (mobile) banking page where he can log in and authorize the eMandates transaction. After completion of the transaction the Debtor Bank shows the complete eMandate to the Debtor.

7 The Debtor is redirected back by the Debtor Bank, to the Creditor’s app using the merchantReturnURL, which was received from the Creditor.

The merchantReturnURL contains an app handler and two parameters (entranceCode and transactionID) that can be used to correctly identify the Debtor upon his return. See paragraph 8.6 for more information.


Table 19: Scenario: Redirect from the Creditors mobile app to the Debtor Banks (mobile) web page

8.8.4 Debtor is redirected from the Creditor’s mobile app to the Debtor Bank’s mobile banking app

The Debtor starts his customer journey on the Creditors mobile app and follows the following steps:





It is mandatory for the Creditor to let the Operating System, which is installed on the Debtor’s mobile device, handle the issuerAuthenticationURL. See paragraph 8.5.1 for more information.


5 The Debtor selects the mobile banking app.

6 The Debtor is redirected to the Debtor Bank’s banking app where he can log in and authorize the eMandates transaction. After completion of the



transaction the Debtor Bank shows the complete eMandate to the Debtor.

7 The Debtor is redirected back by the Debtor Bank, to the Creditor’s app using the merchantReturnURL, which was received from the Creditor.

The merchantReturnURL contains an app handler and two parameters (entranceCode and transactionID) that can be used to correctly identify the Debtor upon his return. See paragraph 8.6 for more information.


Table 20: Scenario: Redirect from the Creditors mobile app to the Debtor Banks mobile banking app

8.9 Performance and time-out of transaction message

The performance of the Debtor Bank and Routing Service systems has a direct influence on the Debtor’s user experience. Therefore eMandates sets a target time and time-out for the transaction response message. For a Creditor the relevant target time and time-out concerning the communication with its eMandates Routing Service:

Communication Target time (in seconds) Time-out (in seconds)

TransactionRequest à TransactionResponse 2.0 7.6

Table 21: Performance requirements (for the 95th percentile*)

The target time is the time (in seconds) within which the Creditor should receive a TransactionResponse message after sending a TransactionRequest. The time-out is the length of time after which the Creditor should no longer expect a response (most likely an error has occurred) and should act accordingly (for example by displaying an appropriate error message to the Debtor).

*95th percentile is a statistical term indicating that 95% of transactions in a tested sample should be within the set target time.

8.10 Specific requirement eMandates Mobile: Print or e-mail confirmation message

After a successful regular eMandates transaction the Debtor Bank will always give the Debtor the option to print the confirmation of the eMandate. However in a mobile transaction environment printing will often not be possible, so this requirement is expanded to include alternatives such as e-mailing or downloading the confirmation to/by the Debtor.



9 eMandates Status protocol

9.1 General

To verify whether an eMandate transaction was successful the Creditor will start the Status protocol by sending a StatusRequest to the Routing Service. Within the eMandates standards this message is referred to as the AcquirerStatusRequest.

To avoid unnecessary system load status requests should not be made unnecessarily, see 9.5 for more details on what is allowed. The StatusRequest message can be sent after the return of the Debtor to the Creditor’s website (after the redirect from the Debtor Bank), or after a specified amount of time as soon as the expiration period has expired (for example 5 or 10 minutes after the default expirationPeriod of 30 minutes has expired). As explained in paragraph 4.2 on Multiple signing, if the status is ‘pending’, this means the eMandate still needs to be signed by other Debtors. The Creditor may then execute the Status protocol on a daily basis. If the eMandates isn’t completed within 7 days, the status will be set to ‘expired’ by the Validation Service.

9.2 StatusRequest

Table 22 contains all fields that are part of the StatusRequest XML message. The Creditor sends this message to the Routing Service. Please refer to the clarification in paragraph 6.2 for the abbreviations in the Format column.


createDateTimestamp Date and time at which the StatusRequest message was created. DT


PN...10

subID eMandate,ContractSubID, as supplied to the Creditor by the Creditor Bank, if the Creditor has requested to use this. A Creditor can request permission from the Creditor Bank to use one or more subIDs. In this way the Creditor.Tradename and relevant Creditor.Address belonging to the SubID will also be shown on the eMandate, next to the Creditor.Name. On the eMandate, this is shown as: Creditor.Name, on behalf of Creditor.TradeName.


N..max 6

transactionID Unique 16-digit number within eMandates. The number consists of the Creditor.CreditorBankID (first four positions) and a unique number generated by the Routing Service (12 positions).

PN..16




Table 22: Fields of the StatusRequest

9.3 StatusResponse

The reply to the StatusRequest is the StatusResponse. This message is created by the Validation Service and sent to the Creditor by the Routing Service. The StatusResponse contains the fields



listed in Table 23. This message communicates the status of the transaction (related to the transactionID which was sent in the StatusRequest) to the Creditor. If the status equals “Success”, the container element is included in the response. Inside the container element are the approved eMandate (the ISO pain.012 message) and the signature on the eMandate.


createDateTimestamp Date and time at which the StatusResponse message was created. DT

acquirerID Unique four-digit identifier of the Routing Service within eMandates. PN..4

transactionID Unique 16-digit number within eMandates. The number consists of the Creditor.CreditorBankID (first four positions) and a unique number generated by the Routing Service (12 positions).

PN..16

status Indicates whether the eMandate transaction has been successful with one of the following statuses: • Success: Positive result; the eMandate has been approved by the

Debtor • Cancelled: Negative result due to cancellation by Debtor; no

transaction has been made. • Expired: Negative result due to expiration of the transaction; no

transaction has been made. • Failure: Negative result due to other reasons; no transaction has been

made. • Open: Final result not yet known. A new StatusRequest is necessary

to obtain the status. • Pending: Transaction has not yet been completed and is awaiting

multiple signing. Status may be requested daily.

CL AN..max 9

statusDateTimestamp Present If Status = Success, Cancelled, Expired or Failure (not present when status = Open or Pending) This is the date and time at which the Debtor Bank established the Transaction.status for this transaction and recorded it as part of the transaction details.

DT

container 9.3.1.1.1.1 If Transaction.status is ‘Success’, this field is included in the StatusResponse. For all other values of Transaction.status, this field is not included.

If this field is included, it contains the eMandate ISO message and the signature from the Validation Service. Both must be archived by the Creditor.




Table 23: Fields of the StatusResponse

9.3.1 Content of container element for new eMandates or amendments The following table specifies the eMandate elements in the ISO pain.012 message that is placed inside the container. The Validation Service signature is also placed inside the container, in the supplementary data of the ISO message. Please see paragraph 11.2.1 for more information. It is essential that the Creditor stores both the ISO pain.012 message and the signature (including the certificate information), at least until 13 months after the last direct debit collection related to the eMandate. The pain.012 message is nearly identical for new eMandates and for eMandate amendments. The only difference is in the field ‘Message Name Identification’; this element gets



the value ‘Issuing’ when the original TransactionRequest had a pain.009 message. It gets the value ‘Amendment’ when the original TransactionRequest had a pain.010 message.

Index ISO Message element eMandates Requirement

1. + Message root Mandatory

2. + Group Header Mandatory, Complex type

3. ++ Message Identification Mandatory


4. ++ Creation Date Time Mandatory eMandate.DateTimestamp

5. ++ Authorisation Mandatory, Complex type

6. +++ Proprietary Mandatory ValidationService.ValidationReference

7. + Underlying Acceptance Details Mandatory, Complex type

8. ++ Original Message Information Mandatory, Complex type

9. +++ Message Identification Mandatory Message Identification from the original pain.009 or pain.010

message in the TransactionRequest.

10. +++ Message Name Identification Mandatory Message.NameID

Specifies the message name identifier to which the message

refers (will have the value ‘Issuing’ or ‘Amendment’)

11. ++ Acceptance Result Mandatory, Complex type

12. +++ Accepted Mandatory Result of the Debtor validation

Usage rule: will be 1 or technical equivalent

13. ++ Original Mandate Mandatory, Complex type

14. +++ Original Mandate Mandatory




15. ++++ Mandate Identification Mandatory eMandate.eMandateID

16. ++++ Mandate Request Identification Mandatory eMandate.TransactionID

17. ++++ Type Mandatory, Complex type

18. +++++ Service Level Mandatory, Complex type

19. ++++++ Code Mandatory

The identification code of the Scheme, will be ‘SEPA’

20. +++++ Local Instrument Mandatory, Complex type

21. ++++++ Code Mandatory Specifies the Local Instrument, will be ‘Core’

22. ++++ Occurrences Mandatory, Complex type

23. +++++ Sequence Type Mandatory eMandate.SequenceType

24. +++++ Frequency Optional

Usage rule: Not used in current implementation

25. ++++ Maximum Amount Optional

Usage rule: Not used in current implementation

26. ++++ Reason Optional, Complex type

27. +++++ Proprietary Mandatory (if Reason is provided) eMandate.Reason

28. ++++ Creditor Scheme Identification Mandatory, Complex type

29. +++++ Identification Mandatory, Complex type

30. ++++++ Private Identification Mandatory, Structure element, Complex type




31. +++++++ Other Mandatory, Structure-element, Complex type

32. ++++++++ Identification Mandatory Creditor.CreditorID

33. ++++++++ Scheme Name Mandatory, Complex type

34. +++++++++ Code Mandatory

Will be ‘SEPA’

35. ++++ Creditor Mandatory, Complex type

36. +++++ Name Mandatory Creditor.Name

Usage Rule: ‘Name’ is limited to 70 characters in length.

37. +++++ Postal Address Mandatory, Complex type

38. ++++++ Country Mandatory Creditor.Country

39. ++++++ Address Line Mandatory Creditor.AddressLine1

40. ++++++ Address Line Mandatory Creditor.AddressLine2

41. ++++ Ultimate Creditor Optional, Complex type

42. +++++ Name Optional Creditor.TradeName


43. ++++ Debtor Mandatory, Complex type

44. +++++ Name Mandatory Debtor.AccountName


45. +++++ Identification Optional, Complex type




46. ++++++ Private Identification Optional, Complex type

47. +++++++ Other Optional eMandate.DebtorReference

48. ++++ Debtor Account Mandatory, Complex type

49. +++++ Identification Mandatory, Complex type

50. ++++++ IBAN Mandatory Debtor.IBAN

51. ++++ Debtor Agent Mandatory, Complex type

52. +++++ Financial Institution Identification Mandatory, Complex type

53. ++++++ BICFI Mandatory Debtor.DebtorBankID

54. ++++ Ultimate Debtor Mandatory, Complex type

55. +++++ Name Mandatory Debtor.SignerName

56. ++++ Referred Document Optional, Complex type


57. +++++ Type Mandatory (if Referred Document is provided), complex type

58. ++++++ Code Or Proprietary Mandatory (if Referred Document is provided), complex type

59. +++++++ Proprietary Mandatory (if Referred Document is provided) eMandate.PurchaseID

60. + Supplementary Data Mandatory, Complex type

61. ++ Envelope Mandatory. Usage rule: contains <Signature> element containing

enveloped Signature over entire pain.012 <Document>. Enveloped XML signature



Table 24: Pain.012 message (acceptance report)

9.4 Errors during execution of Status Protocol

When using the Status Protocol to fetch the eMandate status, errors can occur as a result of which it is impossible for you to obtain the status of the transaction at that moment. It is therefore not possible to show the Debtor the final status of the transaction at that moment.

Recommended messages to show to Debtors are defined further on in this document.

In addition to this, we recommend informing your customer how he or she will be notified of the transaction status when it is known or where he or she can obtain that information (online).

You can then try to obtain the status through your Routing Service, in accordance with the guidelines. As soon as a definitive status has been received, you can notify the Debtor of the status of transaction in the following ways, for example:

• By e-mail.

• On your website, for example in the account of the Debtor or via the Debtor's browser

session.

9.5 Collection duty

The Creditor has to initiate a StatusRequest when the Debtor returns to the page to which he was redirected by the Debtor Bank (the merchantReturnURL from the TransactionRequest). However, it is possible for the Debtor to close his browser before returning to this merchantReturnURL. It is mandatory for Creditors to perform a StatusRequest for every transaction, also in case the Debtor does not return to the Creditor’s website. The eMandates protocol prescribes a so called “collection duty” for the result of every transaction. The Creditor can comply with this “collection duty” by performing a StatusRequest for every transaction when the expiration period has passed and no final status has been retrieved yet.

If the retrieved status of a transaction is “Open”, the StatusRequest for this transaction has to be repeated after a short period of time. If the status of a transaction is “Pending”, this means the transaction is awaiting multiple signing in the Debtor Bank domain. The status can then be requested once per day.

All other statuses (Cancelled, Expired, Success and Failure) are final statuses. Since these statuses cannot change anymore, it is not necessary (and not allowed) to perform another StatusRequest. To avoid unnecessary load on the eMandates systems, Creditors shall not perform unnecessary StatusRequests.

The following actions are never allowed:

• Request the status of a transaction more than 5 times before the expiration period has

passed;

• Perform repeated StatusRequests with a time interval shorter than 60 seconds.

The following actions are not allowed after the expiration period has passed:

• Perform repeated StatusRequests with a time interval shorter than 60 minutes;



• Request the status of a transaction more than 5 times per day;

• Perform StatusRequests for transactions with a timestamp older than 14 days;

• Request the status of a transaction after the final status of the transaction has been

received;

• Stop requesting the status of a transaction before the final status of the transaction has

been received or before the timestamp is more than 14 days old.

Usually one of the final statuses or ‘Pending’ should be returned shortly after the expiration period. If the “Open” status is still returned after the expiration period, this can indicate a system failure. If this failure is not solved within 24 hours, please contact the Routing Service and stop sending StatusRequests.

Also when a Debtor does not return to your website because he does not appropriately complete or cancel the eMandates transaction, the Creditor must perform the Status Protocol after the expiration time has ended, to collect the final status at the eMandates Acquiring bank. As long as the returned status is “Open”, the status request must be repeated at least once or several times during the day (see guidelines stated above). This will provide the Creditor the opportunity to update the order status.

When the returned status is “Success” the Creditor will be able to continue the transaction with the Debtor (e.g. deliver an ordered product or service). When the Debtor returns to your website inappropriately (e.g. using browser buttons to get back from the Debtor Bank’s eMandate screens to the Creditor website) and decides to start a new eMandates transaction request, the Creditor must first try to collect the final status of the eMandates transaction that was initiated earlier, before sending a new TransactionRequest to the Routing Service.

9.6 Performance and time-out of status messages

The performance of the Debtor Bank/Validation Service and Routing Service systems has a direct influence on the Debtor’s user experience. Therefore eMandates sets a target time and time-out for the status response message. For a Creditor the relevant target time and time-out concern the communication with its eMandates Routing Service:

Table 25: Performance requirements (for the 95th percentile*)

The target time is the time (in seconds) within which the Creditor should receive a StatusResponse message after sending a StatusRequest. The time-out is the length of time after which the Creditor should no longer expect a response (most likely an error has occurred) and should act accordingly (for example by displaying an appropriate error message to the Debtor).

*95th percentile is a statistical term indicating that 95% of transactions in a tested sample should be within the set target time.

Communication Target time (in seconds) Time-out (in seconds)

StatusRequest à StatusResponse 2.0 7.6



10 Error handling

10.1 General

If an error occurs while processing a DirectoryRequest, TransactionRequest or StatusRequest, for example because a request contains a invalid value, an ErrorResponse will be returned instead of the regular response. The ErrorResponse has the same structure for all three types of requests.

10.2 ErrorResponse

Instead of the regular response (DirectoryResponse, TransactionResponse of StatusResponse) the Routing Service will return an ErrorResponse if an error occurs during the reception or processing of the request, or if the request contains values that are not allowed or do not comply with the required format. Table 26 lists the fields that appear in the ErrorResponse. The error code list, errorDetail and consumerMessage can be found in APPENDIX B.


createDateTimestamp Date and time at which the ErrorResponse message was created.

DT

errorCode Unique characteristic of the occurred error within the eMandates system. Please refer to APPENDIX B for the error code list.

CL AN..6

errorMessage Descriptive text accompanying the ErrorCode. AN..max 128

errorDetail Details of the error. As determined and described by the Routing Service.

AN..max 256

suggestedAction Suggestions aimed at resolving the problem. AN..max 512

consumerMessage A Routing Service can include a (standardised) message here, which the Creditor should show to the Debtor.

AN..max 512

container This element is used if the Routing Service detects an error inside the pain message of a Transaction Request. It will then contain the pain.012 error acceptance report. In this case, the errorCode will have the value AP3000. The pain.012 error acceptance report will contain more information about the specifics of the error (see Table 27). The errorDetail may contain more information about which element in the pain message is causing the error.




Table 26: Fields of the ErrorResponse

If the Routing Service detects an error inside the pain message (009 or 010) in the container of the Transaction Request, the ErrorResponse will contain an ISO Pain.012 error response acceptance report. This message is shown in table 27. In this case, the errorCode in Table 26 will have the value AP3000. The pain.012 error acceptance report will have the status ‘rejected’ and it will also have a Reject Reason code. See APPENDIX B for possible Reject Reasons.




1. + Message root Mandatory

2. + Group Header Mandatory, Complex type

3. ++ Message Identification Mandatory


4. ++ Creation Date Time 10.2.1.1.1.1 Mandatory

DateTime

5. + Underlying Acceptance Details Mandatory, Complex type

6. ++ Original Message Information Mandatory, Complex type

7. +++ Message Identification Mandatory

Message Identification from original message.

8. +++ Message Name Identification Mandatory

9. ++ Acceptance Result Mandatory, Complex type

10. +++ Accepted Mandatory

Result of the Debtor validation

Usage rule: will be ‘0 or technical equivalent’

11. +++ Reject Reason Usage rule: only codes from Appendix B are used

12. +++ Additional Reject Reason Information Usage rule: will be present if Reject Reason is MD02.

13. ++ Original Mandate Mandatory, Complex type

14. +++ Original Mandate Identification Mandate Identification from original message. eMandate.eMandateID

Table 27: Pain.012 error response acceptance report

10.3 Non-availability

It might be possible that one of the Debtor Banks is temporarily unavailable. In this case transactions that have to be processed by this Debtor Bank will generate an ErrorResponse (see paragraph 10.2). When the Routing Service has determined unavailability at a Debtor Bank it will



communicate this to the Debtor Bank immediately. This means that Creditor will never have to contact the Debtor Bank directly.

It might also be possible that the Routing Service itself is temporarily unavailable. In this case, unless the Creditor has more than one Routing Service, no eMandate transactions can be processed and the Routing Service will generate an ErrorResponse or time-out.

When the Creditor confirmation page is not working properly, we recommend displaying a clear error message to the Debtor.

Subsequently, we also recommend you to report the status of the eMandate transaction to the Debtor in one of the ways indicated below:

• By e-mail.

• On your website, in the Debtor's account

• On your website, as part of the session information of the order.



11 Security and certificates

11.1 General principles of certificates

For asymmetric encryption two keys are used: one public key and one private key. The public key is linked to the certificate and can be shared with anyone. The private key must be kept confidential by the owner of the certificate. The specific characteristics of the private and public part of the certificates will allow the encryption of a message with the public part while the result can be decrypted with the private part, and vice versa. It is not possible to decrypt a text with the same key that was used to encrypt it.

These specific characteristics enable two applications of certificate:

1. Encryption of a message. By encrypting a message with the public key of the receiving party the information can only be read by the recipient (who has sole knowledge of the private key).

2. Creating an electronic signature of a message. By encrypting the (hash of a) message with the private key, the recipient can determine the authenticity of the (sender of the) message by successfully decrypting the signature with the public part of the certificate. The recipient will also verify the integrity of the message to make sure the contents of the message was not changed by a third party.

The one-sided TLS connection that is used within eMandates between the Creditor and the Routing Service is based on the first application. The TLS connection uses at least 128-bit encryption based on a server side certificate of the Routing Service.

Since eMandates does not put any constraints on the communication between the Debtor and the Creditor, this can be either with or without a TLS connection. Creditors are advised, however, to always use TLS on the transaction pages of their website. The eMandates standard also uses electronic signatures to ensure the authenticity, integrity and non- repudiation of all messages with the exception of redirects. The electronic signature of the Routing Service in the StatusResponse message, for example, enables the Creditor to verify the authenticity of the transaction confirmation.

11.2 Signing eMandates messages

All messages that are sent by the Creditor to the Routing Service (DirectoryRequest, TransactionRequest and StatusRequest) have to be signed by the Creditor. Messages are signed in accordance with the "XML Signature Syntax and Processing (2nd Edition) W3C Recommendation” of 10 June 20087, with the following settings and restrictions applied:

1. The entire XML message8 must be signed.

7 http://www.w3.org/TR/xmldsig-core/ 8 XML Signature reference to the signed info URI is left blank, see example messages in APPENDIX C



2. For the purpose of generating the digest of the main message, the exclusive9 canonicalization algorithm must be used.

3. For the purpose of generating the signature value, the exclusive10 canonicalization algorithm must be used.

4. The syntax for an enveloped11 signature must be used. The signature itself must be removed from the XML message using the default transformation prescribed for this purpose.

5. For hashing purposes the SHA-25612 algorithm must be used.

6. For signature purposes the RSAWithSHA25613 algorithm must be used. RSA keys must be 2,048 bits long.

7. The public key must be referenced using a fingerprint of an X.509 certificate. The fingerprint must be calculated according to the following formula HEX(SHA-1(DER certificate)) 14.

Note: According to Base64 specifications line breaks are allowed to be inserted after each 76 characters using a CR/LF15.

In general Creditors don’t need to have extensive knowledge of RSA since most programming languages have libraries available that implement XML Digital Signature processing. It is strongly recommended to use these standard libraries. Standard functionality for creation and verification of RSAWithSHA256 digital signatures is available in commonly used software platforms, from the following versions and higher: PHP version 5.3.0, Microsoft .NET version 3.5 sp1 and Java version 1.6 u18.

This functionality may also be available in earlier versions of these platforms and in other platforms (e.g. Python, Ruby).

For information about creating the public and private key pair please refer to paragraph 11.4.

11.2.1 Signing of the ISO pain.012 acceptance report Next to the regular signing of the entire XML message, the ISO message (that is placed inside the container element) is separately signed by the Debtor Bank (only for the status ‘Success’). This Debtor Bank signature remains in place during the lifespan of the eMandate, as it is the signature that can be checked to verify integrity and authenticity of the eMandate by the Debtor Bank at a later time in case of a dispute (MOI). It is essential that this remains the Debtor Bank’s signature, as the Debtor Bank has signed the eMandate ‘on behalf of the Debtor’.

9 http://www.w3.org/2001/10/xml-exc-c14n 10 http://www.w3.org/2001/10/xml-exc-c14n 11 http://www.w3.org/TR/xmldsig-core/#sec-EnvelopedSignature 12 http://www.w3.org/2001/04/xmlenc#sha256 13 http://www.w3.org/TR/2002/REC-xmlenc-core-20021210/#sec-SHA256 14 See example messages in APPENDIX C 15 http://tools.ietf.org/html/rfc2045#section-6.8



- This signing follows the same requirements that apply to signing of the entire XML message, except for the following: Instead of referring to the certificate to be used for verifying the signature by fingerprint, the entire certificate is included in the Signature in the X509Certificate element that is contained in the X509Data element in the KeyInfo element. This is done to guarantee availability of the certificate to check the signature in case of a dispute after many years.

- The signature can only be validated when the ISO message is taken out of the XML container element, using exclusive canonicalization. Validation will fail when the ISO message is still embedded. Reason for this is the implicit reference from the signature to the <Document> element.

11.3 Authentication of eMandates messages

To ensure the status of a transaction, the Creditor has to verify the signature of the Routing Service in the Response messages.

To verify the signature in the SignatureValue field, it is recommended that Creditors use standard XML Digital Signature libraries, which are available in most (web) programming languages.

11.4 Creating a key pair

If you want to use a so-called “self signed certificate” this paragraph will explain how to do so. It is also possible to purchase a certificate at a company specialized in this field (Certificate Authority), see paragraph 11.4.1.

In order to create a public and a private key execute the following steps:

1. Download the “OpenSSL Library” from http://www.openssl.org. You can find more information on the “certificate generating utility” at: http://www.openssl.org/docs/apps/req.html. You may also generate the key pair using other software. If so please use the manual that comes with your software.

2. Generate an “RSA private key” using the following command (choose your own password for the field [privateKeyPass]):

openssl genrsa –aes-128 –out priv.pem –passout pass:[privateKeyPass] 2048

3. Create a certificate based on the “RSA private key” (use the same password as in the previous step for the field [privateKeyPass]):

openssl req –x509 –sha256 –new –key priv.pem –passin pass:[privateKeyPass]

-days 1825 –out cert.cer

4. The previous OpenSSL command will generate a certificate in X.509 format, with a validity period of 5 years (1825 days), the maximum for eMandates signing certificates.

5. The file priv.pem contains the private key. The file cert.cer contains the certificate with the public key. The Creditor has to keep the priv.pem file private, which is used in the RSA encryption. The cert.cer file has to be communicated to the Routing Service. The method of communication will depend on the Routing Service.



11.4.1 Buying a certificate from a Certificate Authority When buying a certificate from a Certificate Authority (CA), rather than generating the certificate yourself it is important to note the following: the CA signing certificate (and the rest of the certificate chain) must use hashing algorithms and key lengths that are at least as secure or better than those of the Creditor certificate.

Therefore CA-certificates used to sign certificates for electronic signatures must use at least SHA-256 for hashing and 2,048 bits for RSA keys.

Signing certificates should also have a maximum validity period of 5 years.



12 Presentation

12.1 General

There are some requirements regarding the presentation of eMandates on the Creditor’s website. The main purpose of these requirements is to create a uniform user experience for Debtors whenever they use eMandates, regardless which Creditor’s website they use. The requirements are further explained in the following paragraphs.

The front-end communication to the Debtor is based on the following primary relationships and responsibilities:

- A Debtor chooses to ‘mandate’ the Creditor for a one off or recurring Core SEPA Direct Debit by means of an eMandate.

- The Creditor offers the Debtor the possibility to choose eMandates as a method to ‘mandate’ the Creditor to execute a (one off or recurring) Direct Debit.

- The Validation Service of the Debtor Bank offers the Debtor the ability to authenticate himself and to approve the eMandate. The Debtor Bank bears primary responsibility for the eMandate approval process and for the related communication to the Debtor.

A Creditor that accepts eMandates has to place the eMandates payment method in its list of offered payment methods, in such a way that it is a logical step in the Creditor’s online process.

The eMandates payment method must be presented in the list of payment methods in such a way that it receives at least the same amount of attention as other payment methods.

12.2 Incassomachtigen via uw bank-button

It must be clear for the Debtor how and when eMandates has been chosen by the Debtor. This is achieved by displaying an eMandates button, generally on that part of the page where one of the payment methods is normally selected. The eMandates button must have the text: ‘Incassomachtigen via uw bank’.

12.3 Transaction flow

When the ‘Incassomachtigen via uw bank’ button is clicked, the Debtor should immediately be presented with the Debtor Bank selection list without any intermediate screens being displayed by the Creditor (e.g. Debtor login and/or registration screens). And when the Debtor has selected the required Debtor bank, he should be immediately redirected to the online bank environment of the selected Debtor Bank (based on the issuerAuthenticationURL the Creditor has received in the TransactionResponse).

12.4 Redirect to Debtor Bank

The Creditor needs to perform the redirect to the Debtor Bank, from the browser window where the Debtor selected the Debtor Bank. The complete page of the Creditor shall be replaced by the complete page of the selected bank. Therefore it is not allowed to open the redirect to the Debtor



Bank in a new browser window. It is however allowed to open a new window, with visible address bar, before the Debtor selects his bank from the Debtor Bank list.

12.5 Frames

Frames used on the Creditor’s site are allowed. The page of the Debtor Bank will remove these frames using a frame busting technique. This will allow the Debtor to verify whether the transaction is really taking place at the bank chosen from the Debtor Bank list. After the redirect to the Creditor the Creditor shall completely rebuild the Creditor page to show the Creditor’s confirmation of reception of the (amended) eMandate.

12.6 New Window

The eMandates transaction may take place in a new browser window, as long as the Creditor will have this window appear at (or before) the moment the Debtor chooses the transaction method. A new window is only allowed if initiated by the Debtor (no pop-ups are allowed). The complete transaction flow must take place in this window, including the Creditor’s confirmation of receiving the eMandate. The new window must also contain an address bar that allows the Debtor to check the Internet address URL and SSL-certificate of the Debtor Bank. During the transaction flow it should not be possible for the Debtor to initiate another transaction through the Creditor’s original browser window.

12.6.1 Specific Requirements eMandates Mobile: New window or app The Mobile eMandate process may redirect the Debtor to a different mobile page or app as part of the transaction. The Creditor should strive to keep the Debtor on one browser page as much as possible but it is not allowed to make use of an in-app browser in the Creditor app (see Chapter 6 for more details). In those cases where changing to another app or window is necessary (such as the redirect to the Debtor Bank) the Debtor should be informed beforehand in order to avoid confusion (e.g.: “You are being redirected to the (mobile) web site or the app of your bank”).

12.7 Debtor Bank list

The Debtor Bank list has to be presented as described in paragraph 7.4.

12.8 ‘Incassomachtigen via uw bank’ banners and logo's

Not yet available.

12.9 Explaining eMandates to Debtors

Merchants that want to provide specific help and instructions to Debtors regarding eMandates are advised to use the following text:

How does ‘Incassomachtigen via uw bank’ work?

A few simple steps is all it takes to pay using ‘Incassomachtigen via uw bank’:

• Place your order



• Select ‘Incassomachtigen via uw bank’ as your payment method

• Select your bank

• This opens the familiar (mobile) banking environment or mobile app of your own bank

• The relevant details of your eMandate will already be shown

• You approve the eMandate in the way you are accustomed to at your bank

• Your bank confirms your eMandate and you can email it or download it

• You return to this website – eMandate accepted and you can continue shopping

Dutch version

Hoe werkt ‘Incassomachtigen via uw bank?

U kunt in een paar eenvoudige stappen betalen met ‘Incassomachtigen via uw bank’

• U bestelt een product of dienst

• Selecteer ‘Incassomachtigen via uw bank’ als uw betaalmethode

• Selecteer de bank waar u de rekening heeft waar u de machtiging op wilt afgeven

• U komt direct in de (mobiele) bankieromgeving of app van uw bank

• De relevante gegevens van uw machtiging zijn al ingevuld

• Op de voor u bekende manier keurt u de machtiging goed

• Uw bank bevestigt het eMandate en u kunt het emailen of downloaden

• U keert terug naar deze website. De machtiging is geaccepteerd en u kunt weer verder winkelen

12.10 Creditor front-end

The Creditor bears primary responsibility for initiating the eMandate process and for the communication to the Debtor regarding the status of the eMandate.

- A Creditor must make sure in the design of his implementation that the eMandates solution and the start of an eMandate process are recognisable as such. The Creditor must also distinguish clearly between the process of issuing a new eMandate and the process of amending an existing eMandate.

- Creditors who accept eMandates must include the eMandates solution in their lists of payment methods (if any).

- The eMandates solution must be presented in the list of methods in such a way that it receives at least the same amount of attention as other payment methods.

- It must be clear for the Debtor that an eMandates transaction is going to start.



The Creditor must offer the Debtor two eMandate-functionalities:

1. Issuing a new eMandate A new eMandate can be issued for example when the Creditor gets a new customer (Debtor) or when an existing customer (Debtor) needs to issue a new mandate due to additional (new) products or services.

2. Amending an existing eMandate Amending an existing eMandate is done only when the Debtor wishes to change his account number (within the same Bank or to a different Bank). Other Debtor changes (such as address changes) and Creditor changes are not relevant to the eMandate.

The Creditor must clearly indicate to the Debtor whether he is issuing a new eMandate or amending an existing eMandate.

Cancelling an eMandate is done directly between Debtor and Creditor, without validation in the Debtor Bank domain.

12.11 Debtor Bank front-end

All eMandate related information (i.e. eMandate information, Debtor information, Creditor information and Signer information), with the exception of the Debtor Reference number (klantnummer), is presented to the Debtor for approval by the Validation Service.

In detail, the following information is shown to the Debtor for approval:

Creditor information

- Creditor.Name

- Creditor.TradeName (optional) - Creditor.AddressLine1

- Creditor.AddressLine2 - Creditor.Country

- Creditor.CreditorID

Debtor information

- Debtor.IBAN

- Debtor.AccountName

eMandate information

- eMandate.eMandateID

- eMandate.Reason (optional) - eMandate.SequenceType

- eMandate.FrequencyCount(optional & not in current version) - eMandate.FrequencyPeriod (optional & not in current version - eMandate.MaxAmount (optional & not in current version) - eMandate.PurchaseID (optional) - The term ‘SEPA’ must be mentioned on the eMandate



Signer-information

- Debtor.SignerName

The following screenshots show examples of Validation Service eMandate approval website or mobile app screen for one-off eMandates, with Creditor.TradeName (Figure 5), and an example of the confirmation screen following approval of the eMandate proposal by the Debtor (figure 6). Please note that these are example screens and are for illustration purposes only.

Figure 5: Example of one-off eMandate approval website or mobile app screen

After approval, the Validation Service shows the complete eMandate to the Debtor. The Debtor can print, email or save the eMandate to his computer (Figure 6). Upon the redirect from Debtor Bank to the Creditor’s website, the Creditor shows a message to the Debtor indicating whether the eMandate process was successful (e.g. “We have successfully received the eMandate / We hebben uw machtiging succesvol ontvangen” or “We have not yet received confirmation of the eMandate / We hebben nog geen bevestiging van het eMandate ontvangen”). There is no obligation for the Creditor to show the eMandate contents to the Debtor at this point.



Figure 6: Example of one-off eMandate confirmation website or mobile app screen



APPENDIX A: Container content overview

The eMandate information is in the ISO messages that are put inside the information container element. The following tables give an overview of the ISO pain message content in the container of the messages for new eMandates and for eMandate amendments.

Message Container content

B. AcquirerTrxReq pain.009.001.04

F’ AcquirerStatusRes pain.012.001.04

B’ (X) AcquirerErrorRes pain.012.001.04 (Error response version)

Table 28: Container content for new eMandates

iDx Message eMandates specific content

B. AcquirerTrxReq pain.010.001.04

F’ AcquirerStatusRes pain.012.001.04

B’ (X) AcquirerErrorRes pain.012.001.04 (Error response version)

Table 29: Container content for eMandate amendments



APPENDIX B: Error codes

Categories

The Error.errorCode is composed of: − A category (two letters) − A number (four digits) The following categories are distinguished:

Category Meaning

IX Invalid XML and all related problems. Such as incorrect encoding, invalid version, otherwise unreadable.

SO System maintenance. The errors that are communicated in the event of system maintenance or system failure. Also covers the situation where new requests are no longer being accepted but requests already submitted will be dealt with (until a certain time).

SE Security and authentication errors. Incorrect authentication methods and expired certificates.

BR Field errors. Additional information on incorrect fields.

AP Application errors. Errors relating to IDs, account numbers, time zones, transactions, currencies.

Table 30: Error code categories

Error codes

errorCode errorMessage errorDetail Occurs in

IX1100 Received XML not valid See 1) A’(X), B’(X), F’(X)

IX1200 Encoding type not UTF-8 See 1) A’(X), B’(X), F’(X)

IX1300 XML version number invalid See 1) A’(X), B’(X), F’(X)

IX1600 Mandatory value missing See 1) A’(X), B’(X), F’(X)

SO1000 Failure in system See 2) A’(X), B’(X), F’(X)

SO1100 Issuer unavailable See 3) B’(X)

SO1200 System busy. Try again later See 2) A’(X), B’(X), F’(X)

SO1400 Unavailable due to maintenance See 2) A’(X), B’(X), F’(X)

SE2000 Authentication error See 1) A’(X), B’(X), F’(X)

SE2100 Authentication method not supported See 1) A’(X), B’(X), F’(X)

BR1200 Version number invalid See 1) A’(X), B’(X), F’(X)

BR1205 ProductID invalid See 1) A’(X), B’(X), F’(X)

BR1210 Value contains non-permitted character See 1) A’(X), B’(X), F’(X)

BR1220 Value too long See 1) A’(X), B’(X), F’(X)

BR1230 Value too short See 1) A’(X), B’(X), F’(X)

BR1270 Invalid date/time See 1) A’(X), B’(X), F’(X)



errorCode errorMessage errorDetail Occurs in

BR1280 Invalid URL See 1) B’(X)

AP1100 MerchantID unknown See 1) A’(X), B’(X), F’(X)

AP1200 IssuerID unknown See 1) B’(X)

AP1300 SubID unknown See 1) A’(X), B’(X)

AP1500 MerchantID not active See 1) A’(X), B’(X), F’(X)

AP2600 Transaction does not exist See 1) F’(X)

AP2920 Expiration period is not valid See 1) B’(X)

AP3000 eMandates specific error Details of the error can be found in the ISO pain.012 error acceptance message.

See 1) A’(X), B’(X), F’(X)

Table 31: Error codes

The field errorDetail in the table above contains one of the values shown in the table below. The italic printed words shall be replaced by actual values, as indicated.

Indication errorDetail

1) Field generating error: location-reference in XML message

2) System generating error: Issuer/Acquirer

3) System generating error: Name of Issuer

Table 32: errorDetail

consumerMessage

The consumerMessage can contain 1 of four different standardised texts that are sent to the Creditor by the Routing Service. The Creditor must show the consumerMessage to the Debtor on his website.

The value of consumerMessage is specified in AcquirerErrorRes (X’) by the Acquirer based on the criteria described in the following table:



Situation Message to be shown to Debtor (English)

Message to be shown to Debtor (Dutch)

Error occurred in sending or receiving message A, A’, B, B’’

Signing an eMandate is currently not possible. Please try again later or pay using another payment method.

Het verstrekken van een online machtiging is momenteel niet mogelijk. Probeer het later nogmaals of betaal op een andere manier.

Error occurred in sending or receiving message F, F’’

The result of the online mandate process can not yet be determined

Het resultaat van de online machtiging kan nog niet worden bepaald.

Error occurred because of unavailability of Validation Service (SO1000, SO1100, SO1200 , SO1400 or no response received from Validation Service by Routing Service after sending message C)

The selected bank is currently unavailable. Please try again later or pay using another payment method

De geselecteerde bank is momenteel niet beschikbaar. Probeer het later nogmaals of betaal op een andere manier.

Error occurred because of unavailability of Validation Service (see above) AND additional information is available from the Notification System

The selected bank is currently unavailable due to maintenance until the expected time or date time from the NotificationSystem.

Please try again later or pay using another payment method.

De geselecteerde bank is momenteel niet beschikbaar i.v.m. onderhoud tot naar verwachting date time from Notification System. Probeer het later nogmaals of betaal op een andere manier.

Table 33: consumerMessage

The following Reject reason codes are used in the ISO pain.012 error acceptance message.

Code Name Definition

BE04 MissingCreditorAddress Specification of creditor's address, which is required for

mandate, is missing/not correct (formerly

IncorrectCreditorAddress).

DT01 InvalidDate Invalid date

FF01 InvalidFileFormat File format incomplete or invalid

MD01 NoMandate No Mandate

MD02 MissingMandatoryInformationInMandate Mandate related information data required by the scheme is

missing.

This code is used for all other errors that occur. Additional

Reject Reason Information must specify the details.

RC01 BankIdentifierIncorrect Bank Identifier code specified in the message has an incorrect

format

RF01 NotUniqueTransactionReference Transaction reference is not unique within the message.

RR03 Missing Creditor Name or Address Specification of the creditor’s name and/or address needed for

regulatory requirements is insufficient or missing.

Table 34: Reject reason codes

Source: ISO External Code Sets spreadsheet (subset of ISO reason codes)



APPENDIX C: Message examples

Most of the example messages given here only use the default method of namespace declaration. At the end of the appendix one example is given of a message with namespace prefixes (this message does not contain an information container, it is merely meant to signify the use of namespace prefixes). NB:

• As the XML schema in APPENDIX D only contains iDx elements and not the ISO content of the container element, the example messages will not validate against this XML schema.

• Signatures are examples and don’t validate against the messages • The examples are not necessarily related to each other.

A. DirectoryReq <?xml version="1.0" encoding="UTF-8"?>

<DirectoryReq xmlns="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"

xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xsi="http://www.w3.org/2001/XMLSchema-

instance" version="1.0.0" productID="NL:BVN:eMandatesCore:1.0">

<createDateTimestamp>2015-04-30T09:29:19.487Z</createDateTimestamp>

<Merchant>


<subID>0</subID>

</Merchant>

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod

Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /><SignatureMethod

Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /><Reference

URI=""><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"

/><Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /></Transforms><DigestMethod

Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"

/><DigestValue>Vf31O4KhV1LA6euELV3wKnsDmZvQdMIj0UIS6IS651U=</DigestValue></Reference></SignedIn

fo><SignatureValue>CZP1ZrUEAQjd779CSz4p9OS1b9GyPtUDNV9qIhb+/m74Y526XNjTfabwxXQVTlFmc8nXvVdOb4bg

v+xFq19wUw4hmwa24Dd6HgUYlgeLwW7r0YE1oFjMiuR0/X4pzBR3YUik8clJ4L//cd+34X3602t1BdHDqMar1qDCbZF6OKM

b+zN5cUuiMmKN0oiDDMLBX26r+JjuhJjhFVk80HOnHhrwFE4DIYZPkKBuTVNLk+mqBbBDSOUW8eNhc6J8cOropPN3Xo9Jgq

VfRWHrLYh3K54q21nG8sVeufqAZ9j6CbXTjjzjqGMJzGfhMEb51wVMvlfKmitVq/FkFx/wStGF0w==</SignatureValue>

<KeyInfo><KeyName>DE3025047BC3F1E2F55262C5818399198E6723F5</KeyName></KeyInfo></Signature>

</DirectoryReq>

A’. DirectoryRes <?xml version="1.0" encoding="UTF-8"?>

<DirectoryRes xmlns="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"




<Acquirer>

<acquirerID>4444</acquirerID>

</Acquirer>

<Directory>



<directoryDateTimestamp>2014-08-12T10:41:57Z</directoryDateTimestamp>

<Country>

<countryNames>Nederland</countryNames>

<Issuer>

<issuerID>TESTNL2A</issuerID>

<issuerName>Testbank</issuerName>

</Issuer>

</Country>

</Directory>







/><DigestValue>O5h5LMRi1NiqdC9DKkS/9wT6K3LnjIoWhkHTxFIIMB0=</DigestValue></Reference></SignedIn

fo><SignatureValue>MPoYLMhUNVeJLxmF0ghVaJOViRxkHiMWPwyQreXgQNCnhp2DAHurpAq2U47DYk/XmB/18ui7uW13

OXxfpeDoG/e//grOnUbI6TlLbcu3NcaMYWh80KHB53mE+Evbx/tntGrTOV4mdhZi10il61roTWH67ku04kHtDj3po0zhmec

5NYMxPDfg87uC9F/E/4hUt+jGVzyxfC96UuNa3YHCUHKfzBKKrUrImrvO+GTZpPvInJrUjr9KcSeXLBnBNhJ202URyGI/q7

9xjrDnJKZoLwwXeb3XtuMy/A67gfn9VUwgV00268QwErBGvOo+9ZLvgbvhf96J7MX/kn45lIg2jQ==</SignatureValue>


</DirectoryRes>

B. AcquirerTrxReq for new eMandate <?xml version="1.0" encoding="UTF-8"?>

<AcquirerTrxReq xmlns="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"




<Issuer>


</Issuer>

<Merchant>


<subID>000000</subID>

<merchantReturnURL>https://betaalvereniging.nl/returnPage.php?param1=true&param2=3%202</mer

chantReturnURL>

</Merchant>

<Transaction>

<expirationPeriod>PT15M</expirationPeriod>

<language>nl</language>

<entranceCode>12345ABCDE</entranceCode>

<container>

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.009.001.04"


<MndtInitnReq>

<GrpHdr>

<MsgId>Message1234567890</MsgId>



<CreDtTm>2015-04-29T13:29:51.974Z</CreDtTm>

</GrpHdr>

<Mndt>

<MndtId>1234567890</MndtId>

<MndtReqId>NOTPROVIDED</MndtReqId>

<Tp>

<SvcLvl>

<Cd>SEPA</Cd>

</SvcLvl>

<LclInstrm>

<Cd>CORE</Cd>

</LclInstrm>

</Tp>

<Ocrncs>

<SeqTp>OOFF</SeqTp>

</Ocrncs>

<Cdtr />

<Dbtr>

<Id>

<PrvtId>

<Othr>

<Id>12345-67890</Id>

</Othr>

</PrvtId>

</Id>

</Dbtr>

<DbtrAgt>

<FinInstnId>

<BICFI>TESTNL2A</BICFI>

</FinInstnId>

</DbtrAgt>

</Mndt>

</MndtInitnReq>

</Document>

</container>

</Transaction>







/><DigestValue>H7wbB6b3oMxu/Tn5MIy0ES/CbfXvrvd2uRpdhGCeFN8=</DigestValue></Reference></SignedIn

fo><SignatureValue>TjKNSx2yqTwcHJVfU4/tNb4GIoWz6mHsDQMpo6lWlg8IcJpVCocl8tG6fjNo3tLjtXeoU/zgG6qz

h2ALWI7tYPaFngjf87NqbxyW2+uVk8Uw7PA1XBWQCT3ljiZ8CyyU2KortTkNLD6WIkAjDEv6xZtz2UOs2Lc6r4Lo+l/xdor

6+A7lfl3VyE2ZoTKkTvdxfyfYNujrGhCM1ZHWA/tVzhNXOOHrOqMa8esnqxlvbamlv9003JETNLl/HewvaWYboZ4msC/D2G

WJzLEydkIal20g2GhU1V3QOxffttAadO9rZdhgy87GOB55n5wZneKlBuiIvfsAlZS1kFxVi6EL/Q==</SignatureValue>




</AcquirerTrxReq>

B. AcquirerTrxReq for eMandate amendment <?xml version="1.0" encoding="UTF-8"?>

<AcquirerTrxReq xmlns="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"




<Issuer>


</Issuer>

<Merchant>


<subID>0</subID>

<merchantReturnURL>https://betaalvereniging.nl/returnPage.php?param1=true&param2=3%202</mer

chantReturnURL>

</Merchant>

<Transaction>

<expirationPeriod>PT15M</expirationPeriod>

<language>nl</language>

<entranceCode>12345ABCDE</entranceCode>

<container>



<MndtAmdmntReq>

<GrpHdr>


<CreDtTm>2015-04-29T13:42:08.708Z</CreDtTm>

</GrpHdr>

<UndrlygAmdmntDtls>

<AmdmntRsn>

<Rsn>

<Cd>MD16</Cd>

</Rsn>

</AmdmntRsn>

<Mndt>


<MndtReqId>NOTPROVIDED</MndtReqId>

<Tp>

<SvcLvl>

<Cd>SEPA</Cd>

</SvcLvl>

<LclInstrm>

<Cd>CORE</Cd>

</LclInstrm>

</Tp>

<Ocrncs>



<SeqTp>OOFF</SeqTp>

</Ocrncs>

<Cdtr />

<Dbtr>

<Id>

<PrvtId>

<Othr>

<Id>12345-67890</Id>

</Othr>

</PrvtId>

</Id>

</Dbtr>

<DbtrAgt>

<FinInstnId>


</FinInstnId>

</DbtrAgt>

</Mndt>

<OrgnlMndt>

<OrgnlMndt>


<Cdtr />

<Dbtr />

<DbtrAcct>

<Id>

<IBAN>NL28INGB0007597526</IBAN>

</Id>

</DbtrAcct>

<DbtrAgt>

<FinInstnId>

<BICFI>INGBNL2A</BICFI>

</FinInstnId>

</DbtrAgt>

</OrgnlMndt>

</OrgnlMndt>

</UndrlygAmdmntDtls>

</MndtAmdmntReq>

</Document>

</container>

</Transaction>







/><DigestValue>vmv1mYIoaTO74oqsyoLUHhqtUPY5ulICQ3Ai9y3zhQ4=</DigestValue></Reference></SignedIn

fo><SignatureValue>Y6UvktISi0XWQtyW5Vg5RCswB34b5TK7XBZJCL42rmCfJUNkwDvfoFKVMuNVyWdEqTKuZeydTByv

ac9JlEMKyZ0qugsDpC/yTAxrcETVwk9vGXpS8044muGmMBqvvyI+p+slZYcPZ556PE0KN93RrnSe99mYBv8mdMA4n+9CqHt



J87Wow2noPOhMQv03zkSAHjcOVo8obrTL+YbtScGSjFOAQGTAsPOcnetas2sLvH7IJHZXh84hwmhqbH3PwZHgoEzJqPXPpm

RjJVu9n/mPD381sviRkz9ij3IPhZ+hqB6UWgK3H7RlxwQSqQrIDPeTm08noLaMfz+VVKtsiDqCxw==</SignatureValue>


</AcquirerTrxReq>

B’. AcquirerTrxRes

This message is identical for new eMandates and for eMandate amendments. <?xml version="1.0" encoding="UTF-8"?>

<AcquirerTrxRes xmlns="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"




<Acquirer>


</Acquirer>

<Issuer>

<issuerAuthenticationURL>https://betaalvereniging.nl/iDx?random=0143042563&trxid=1234567

890123456

</issuerAuthenticationURL>

</Issuer>

<Transaction>

<transactionID>1234567890123456</transactionID>

<transactionCreateDateTimestamp>2014-08-12T10:41:57Z</transactionCreateDateTimestamp>

</Transaction>






Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" />

<DigestValue>iyp44aDUKrzZvbrFmVWtgCGb8vk/8leNoHYpOlzeTpM=</DigestValue>

</Reference></SignedInfo>

<SignatureValue>fKyS1tBPPTKSa3am96jiFXQzepMQMVBqUxn3haQ6YDbb5Xd7t/T1sbNCQmk4lNxfTCOxAKR0Z70I4NG

rUCbOisiy9dOekMe3hA38Ug0D2IKzwqsHwG2DQZIprtiWpM9HprsIKEjTFR1UE/dPIVAht9NhMpc808anmrX/h2vxBQ/O1J

0MxRqWhisNbFtlv7tuw9iI9FctNT9I8Lu/hJrGOAfPOeDNDgZOXAQOaqJuTmpfp0qRewMLheP79/tN/u5Z1pctUVu/HUlR5

IcOvNUGpmACIF+5FWgEPJBEfWd1pB2B3TE3VPQYf1C2tYQ22qPBZPQKZNPa3nmzTGSl1BDfOg==</SignatureValue>

<KeyInfo>

<KeyName>DE3025047BC3F1E2F55262C5818399198E6723F5</KeyName>

</KeyInfo></Signature>

</AcquirerTrxRes>

F. AcquirerStatusReq This message is identical for new eMandates and for eMandate amendments. <?xml version="1.0" encoding="UTF-8"?>

<AcquirerStatusReq xmlns="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"






<Merchant>


<subID>000000</subID>

</Merchant>

<Transaction>


</Transaction>







/><DigestValue>JgE61vGdIqC1tVQTcynCIJI2M7T3m0KTeM8KJo0nq2c=</DigestValue></Reference></SignedIn

fo><SignatureValue>tlC4Pl+LBio+IkwTdXFqvilCGMl+N+0OeiuEnR736fKQclaKaLSpAkP0b56AyX7zGHdoJelyUzrJ

EwO0ke/pd24gFTlvxj/MvaYlev+tdL6/awZSG4suRuo6p6WlWJDNZoeALfLMP0CqcdctQ3pdmjOn9YrwTHJCLenLJtMgQ9U

UFREsgZSRMTmW/YyGqR3U5TI8zHsPIPA1dgXTVeDRorfzLkMtt5fhGGq5QN0Y9t5JXQPN0tIMHFfOxZGSbYIwMwB2ABBodW

Dfx+yARrOvffNUGioHTG/HO6C6fkA1aNgv9fr7q3LGpGgVU/P9htzh2ux7Cly8XYYl93t5sLD9uw==</SignatureValue>


</AcquirerStatusReq>

F’. AcquirerStatusRes for new eMandate

For an eMandate amendment, the StatusResponse message is exactly the same, except for the element <MsgNmId>, which gets the value ‘Amendment’ instead of ‘Issuing’. <?xml version="1.0" encoding="UTF-8"?>

<AcquirerStatusRes xmlns="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"




<Acquirer>


</Acquirer>

<Transaction>


<status>Success</status>

<statusDateTimestamp>2014-08-12T10:41:57Z</statusDateTimestamp>

<container>



<MndtAccptncRpt>

<GrpHdr>


<CreDtTm>2014-08-12T10:41:57Z</CreDtTm>

<Authstn>

<Prtry>53435618</Prtry>

</Authstn>



</GrpHdr>

<UndrlygAccptncDtls>

<OrgnlMsgInf>


<MsgNmId>Issuing</MsgNmId>

</OrgnlMsgInf>

<AccptncRslt>

<Accptd>1</Accptd>

</AccptncRslt>

<OrgnlMndt>

<OrgnlMndt>


<MndtReqId>1234567890123456</MndtReqId>

<Tp>

<SvcLvl>

<Cd>SEPA</Cd>

</SvcLvl>

<LclInstrm>

<Cd>CORE</Cd>

</LclInstrm>

</Tp>

<Ocrncs>

<SeqTp>OOFF</SeqTp>

</Ocrncs>

<CdtrSchmeId>

<Id>

<PrvtId>

<Othr>

<Id>NL01ZZZ12345678</Id>

<SchmeNm>

<Cd>SEPA</Cd>

</SchmeNm>

</Othr>

</PrvtId>

</Id>

</CdtrSchmeId>

<Cdtr>

<Nm>DemoCreditor</Nm>

<PstlAdr>

<Ctry>NL</Ctry>

<AdrLine>DemoStraat 1</AdrLine>

<AdrLine>DemoPostcode DemoStad</AdrLine>

</PstlAdr>

</Cdtr>

<Dbtr>

<Nm>J.D. Doe and Co</Nm>

<Id>

<PrvtId>

<Othr>



<Id>12345-67890</Id>

</Othr>

</PrvtId>

</Id>

</Dbtr>

<DbtrAcct>

<Id>

<IBAN>NL13TEST0123456789</IBAN>

</Id>

</DbtrAcct>

<DbtrAgt>

<FinInstnId>


</FinInstnId>

</DbtrAgt>

<UltmtDbtr>

<Nm>Johnny Doe</Nm>

</UltmtDbtr>

</OrgnlMndt>

</OrgnlMndt>

</UndrlygAccptncDtls>

<SplmtryData><Envlp>







<DigestValue>Rnf75CmiQK63Rr2iN68Z+Ox/xtOZbJcHoTEfZHtvdV4=</DigestValue>


<SignatureValue>Ne0mpPAnOTmHor0Cdw6gT2yuvGpKIshxz9btb5m75MzYJST+V1IuvEWOpzrd1dIhenZjvIIbPFuAVTg

tPc8GvfNNBZW5OT+LqYua7dQ818ba6lFqwJ1W3rb96e5KTVD1gJIwVfyG0bSw9ebt+7Oa3cWYz6bdSXbCaOFqvYqE2B/90s

6dJaghxEnwy8qCWTMQT0FDzGybKZR5ymK8TCVVPa2SmYH1DgB9GqTFPwZfagxZHB7uvMFuwTzCXglUsACR9jSJ12jclILdL

SM2P9thkl62m5m7ubsFNNYEi8Vo+BPFUModWgmgt/GEDuS2yKKjw5XL2gsZU3WGodM/gExpBw==</SignatureValue>

<KeyInfo><X509Data>

<X509Certificate>MIIDdzCCAl+gAwIBAgIJAKPDq86ySdQ1MA0GCSqGSIb3DQEBCwUAMFIxCzAJBgNVBAYTAk5MMQswCQ

YDVQQIDAJOTDESMBAGA1UECgwJZU1hbmRhdGVzMQswCQYDVQQLDAJRQTEVMBMGA1UEAwwMZU1hbmRhdGVzIFFBMB4XDTE0M

DQxNjEyNDk0M1oXDTI0MDQxMzEyNDk0M1owUjELMAkGA1UEBhMCTkwxCzAJBgNVBAgMAk5MMRIwEAYDVQQKDAllTWFuZGF0

ZXMxCzAJBgNVBAsMAlFBMRUwEwYDVQQDDAxlTWFuZGF0ZXMgUUEwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQD

PlrMXKxDDgCouXYzv8wMPgzOIniQ0T/HlG/W7R89sCGm6RtRcuMTMvkrP9oVbDpsncipJoVAJykHtyyfSgYpG4SLfshRU4K

GEzLPoYwvLm1ABoXrERrXNQS77pUDuULjMe578D++dPBS1syBDcDv4c9ymIs1APf/LPJ6u1Ey55PP+geeOnJmxL/LfiD5Qe

SvNRoCNTroYqHKUuvtpOo5Dl17ACF5Q3DGXesiM3AWq8dKlgJ/ax2nuGgJs5nNyU1SqTrF+XjUXKmoZ/aAnY1Zz82D2agnR

07TTCZ+XdJnKcBfKbwrCZ+gwbXeZ9J6JoU77usbpalbPLFKlxGLgCCGBAgMBAAGjUDBOMB0GA1UdDgQWBBSqaDM08prUJn6

uuJzLObl1xz4flDAfBgNVHSMEGDAWgBSqaDM08prUJn6uuJzLObl1xz4flDAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCw

UAA4IBAQBAa05iD7bZB5w9nBTHO8mxsgF7GWsXsGiDKjbDd5c6IvNLsovs60dOEfZX8SDgT/IitXp6ckUFFXuycMUQ649fm

Uqmvj/EpK06CCZaSNDCNeR+fNukxcEb7wr0uPu5itHCjsDFY2km6q9QNy8NNXvKCmlnSL4L1azDwOJl0B1TwrUabk0mhhR0

E99OHPn9w0B3UHbEWGOgABnpxsC8X/fFFaC2XTTGJF/aG/DRqppQnoowhmMTB0JQwLxoasSAjuKd6Km/bSHwanB6ha4pMwp

8OqouJ5ISuOmZHALiVOhB7VLfQukV/1ItYitFPYmHGszfqh6peYTW6Hypr/hkXemu</X509Certificate>

</X509Data></KeyInfo></Signature>



</Envlp></SplmtryData>

</MndtAccptncRpt>

</Document>

</container>

</Transaction>







<DigestValue>UkhhTF/rZlidM0+lV/zS21Ws7gn6noAp2aqr+gkfRlI=</DigestValue>


<SignatureValue>YfT4ytsUu4xvtsKhk3NTXCrP2s8zx0XXB4BoXR3B380nhQI/mPAgt1pT3FWdyToTIAMJI9v0BL1d9RQ

6xoKjkX60A9lHEn9JyV6n5wHLM/I1z39XweKOM4epT7qj1l7QEWbl8ESMg64zhVVfimhIiMkB54r5Coqtb5HFSumjCdWHx/

yvVa+2SnThedSe+WvPp3gYbK8WkKBu/2a7ojbRx2sPNopROq0XqrkWyBKmPJ9t8Qbkpf7h3Ve01NV8y6tf4g1WhgLW0NrDK

suh15kPMUN0o0EBLpqOfWeEzU9KxdkvgyNocwwlBYwF4CIyW8sS1AcNvGxq4x3F31UEmSez/A==</SignatureValue>

<KeyInfo>



</AcquirerStatusRes>

X’. AcquirerErrorRes <?xml version="1.0" encoding="UTF-8"?>

<AcquirerErrorRes xmlns="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"




<Error>

<errorCode>AP3000</errorCode>

<errorMessage>Product specific error</errorMessage>

<errorDetail>Mandate Identification is missing</errorDetail>

<consumerMessage>

Het verstrekken van een online machtiging is momenteel niet mogelijk. Probeer het

later nogmaals of betaal op een andere manier.

</consumerMessage>

<container>



<MndtAccptncRpt>

<GrpHdr>

<MsgId> Message1234567222</MsgId>

<CreDtTm>2014-08-12T10:41:57Z</CreDtTm>

</GrpHdr>

<UndrlygAccptncDtls>

<OrgnlMsgInf>


<MsgNmId>Issuing</MsgNmId>



</OrgnlMsgInf>

<AccptncRslt>

<Accptd>false</Accptd>

<RjctRsn>

<Cd>MD02</Cd>

</RjctRsn>

<AddtlRjctRsnInf>Missing mandatory value</AddtlRjctRsnInf>

</AccptncRslt>

<OrgnlMndt>

<OrgnlMndtId>unknown</OrgnlMndtId>

</OrgnlMndt>

</UndrlygAccptncDtls>

</MndtAccptncRpt>

</Document>

</container>

</Error>







<DigestValue>3EGuIuPGkoltpWxUQ5rwv3Fwmo+XzLh0N1PCgpG7R1w=</DigestValue>


<SignatureValue>W90tGz40Z0/p3f7jN2p7hSnBUMKqNZGmQfXTyfCLie4TIsMsO40PBqd2o8mWKymGpXHlqasNindvRvx

zAxb+ZUNXC6p49bGo0ACRvmNt4f0KxDeBodlR/BEOQfDspewLEkRahehNIzXf77FvDX9LInPuA4CHl3KnNa1s8rW0pnFyUk

YaerSA1z05CXKg1BL5HN6E9oUBsqUO8kgkmXUWNaPv3dZCLXsfLXrxciVnjKaDdR8HnKRYm9+Q3g9pgHJh61ipI0DI1lBdP

bMWQhet99jRwDithFXpKjkfwP9b9U289i+K96P1t0zxIAYvgwVoobZZCRrLi4h7B6iChg8Ueg==</SignatureValue>

<KeyInfo>



</AcquirerErrorRes>

X’. AcquirerErrorRes (with namespace prefixes, but without container element) <?xml version="1.0" encoding="UTF-8"?>

<idx:AcquirerErrorRes version="1.0.0" productID="NL:BVN:eMandatesCore:1.0"

xmlns:idx="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"


instance">

<idx:createDateTimestamp>2001-12-17T09:30:47Z</idx:createDateTimestamp>

<idx:Error>

<idx:errorCode>SO1000</idx:errorCode>

<idx:errorMessage>Failure in system</idx:errorMessage>

<idx:errorDetail>System generating error: issuer</idx:errorDetail>

<idx:DebtorMessage>

... some Debtor message ...

</idx:DebtorMessage>



</idx:Error>

<ds:Signature>

<ds:SignedInfo>

<ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>

<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>

<ds:Reference URI="">

<ds:Transforms>

<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-

signature"/>

<ds:Transform Algorithm=" http://www.w3.org/2001/10/xml-exc-c14n#" />

</ds:Transforms>

<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>

<ds:DigestValue>VW+VjenRyZVFCNfBTeoxDflQ4yfR8KYFvwPVinVPqBs=</ds:DigestValue>

</ds:Reference>

</ds:SignedInfo>

<ds:SignatureValue>

IELLwKSGFMk64US23YrpZ8//hJ8DeJEtYht5knlxJvBOr8dcI+aJTBq+YtyzP9ClcK62Obs5aynHBE/GPHZShuMw+8WHq4f

CMInOwKURgwjDOz8UYaIMqG0Ojiz8dFYGn+dH2lL0QVss4jmIIAD8MCijb27oqij6PclXw9Y9veI=

</ds:SignatureValue>

<ds:KeyInfo>

<ds:KeyName>7D665C81ABBE1A7D0E525BFC171F04D276F07BF2</ds:KeyName>

</ds:KeyInfo>

</ds:Signature>

</idx:AcquirerErrorRes>

APPENDIX D: iDx XML Schema <?xml version="1.0" encoding="UTF-8"?>





<xs:schema xmlns="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"

xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#"

targetNamespace="http://www.betaalvereniging.nl/iDx/messages/Merchant-Acquirer/1.0.0"

elementFormDefault="qualified" attributeFormDefault="unqualified" version="1.0.0">

<xs:import namespace="http://www.w3.org/2000/09/xmldsig#" schemaLocation="xmldsig-core-

schema.xsd"/>

<xs:annotation>

<xs:documentation>elements defined</xs:documentation>

</xs:annotation>

<xs:element name="DirectoryReq">

<xs:annotation>

<xs:documentation>Directory Request (A)</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>

<xs:element name="createDateTimestamp" type="dateTime"/>

<xs:element name="Merchant">

<xs:complexType>

<xs:sequence>

<xs:element name="merchantID" type="Merchant.merchantID"/>

<xs:element name="subID" type="Merchant.subID"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element ref="ds:Signature"/>

</xs:sequence>

<xs:attributeGroup ref="MessageAttributes"/>

</xs:complexType>

</xs:element>

<xs:element name="DirectoryRes">

<xs:annotation>

<xs:documentation>Directory Response (A')</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>


<xs:element name="Acquirer">

<xs:complexType>

<xs:sequence>

<xs:element name="acquirerID" type="Acquirer.acquirerID"/>

</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Directory">



<xs:complexType>

<xs:sequence>

<xs:element name="directoryDateTimestamp" type="dateTime"/>

<xs:element name="Country" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="countryNames" type="Country.countryNames"/>

<xs:element name="Issuer" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>

<xs:element name="issuerID" type="Issuer.issuerID"/>

<xs:element name="issuerName" type="Issuer.issuerName"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>


</xs:sequence>


</xs:complexType>

</xs:element>

<xs:element name="AcquirerTrxReq">

<xs:annotation>

<xs:documentation>Acquirer Transaction Request (B)</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>


<xs:element name="Issuer">

<xs:complexType>

<xs:sequence>

<xs:element name="issuerID" type="Issuer.issuerID"/>

</xs:sequence>

</xs:complexType>

</xs:element>


<xs:complexType>

<xs:sequence>



<xs:element name="merchantReturnURL" type="url"/>

</xs:sequence>

</xs:complexType>

</xs:element>



<xs:element name="Transaction">

<xs:complexType>

<xs:sequence>

<xs:element name="expirationPeriod" type="Transaction.expirationPeriod"

minOccurs="0"/>

<xs:element name="language" type="Transaction.language"/>

<xs:element name="entranceCode" type="Transaction.entranceCode"/>

<xs:element name="container" type="Transaction.container"/>

</xs:sequence>

</xs:complexType>

</xs:element>


</xs:sequence>


</xs:complexType>

</xs:element>

<xs:element name="AcquirerTrxRes">

<xs:annotation>

<xs:documentation>Acquirer Transaction Response (B')</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>



<xs:complexType>

<xs:sequence>


</xs:sequence>

</xs:complexType>

</xs:element>

<xs:element name="Issuer">

<xs:complexType>

<xs:sequence>

<xs:element name="issuerAuthenticationURL"

type="Issuer.issuerAuthenticationURL"/>

</xs:sequence>

</xs:complexType>

</xs:element>


<xs:complexType>

<xs:sequence>

<xs:element name="transactionID" type="Transaction.transactionID"/>

<xs:element name="transactionCreateDateTimestamp" type="dateTime"/>

</xs:sequence>

</xs:complexType>

</xs:element>


</xs:sequence>




</xs:complexType>

</xs:element>

<xs:element name="AcquirerStatusReq">

<xs:annotation>

<xs:documentation>Acquirer Status Request (F)</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>



<xs:complexType>

<xs:sequence>



</xs:sequence>

</xs:complexType>

</xs:element>


<xs:complexType>

<xs:sequence>


</xs:sequence>

</xs:complexType>

</xs:element>


</xs:sequence>


</xs:complexType>

</xs:element>

<xs:element name="AcquirerStatusRes">

<xs:annotation>

<xs:documentation>Acquirer Status Response (F')</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>



<xs:complexType>

<xs:sequence>


</xs:sequence>

</xs:complexType>

</xs:element>


<xs:complexType>

<xs:sequence>


<xs:element name="status" type="Transaction.status"/>

<xs:element name="statusDateTimestamp" type="dateTime" minOccurs="0"/>



<xs:element name="container" type="Transaction.container" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>


</xs:sequence>


</xs:complexType>

</xs:element>

<xs:element name="AcquirerErrorRes">

<xs:annotation>

<xs:documentation>Acquirer Error Response (X')</xs:documentation>

</xs:annotation>

<xs:complexType>

<xs:sequence>


<xs:element name="Error">

<xs:complexType>

<xs:sequence>

<xs:element name="errorCode" type="Error.errorCode"/>

<xs:element name="errorMessage" type="Error.errorMessage"/>

<xs:element name="errorDetail" type="Error.errorDetail" minOccurs="0"/>

<xs:element name="suggestedAction" type="Error.suggestedAction"

minOccurs="0"/>

<xs:element name="DebtorMessage" type="Error.DebtorMessage" minOccurs="0"/>

<xs:element name="container" type="Transaction.container" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>


</xs:sequence>


</xs:complexType>

</xs:element>

<xs:annotation>

<xs:documentation>simpleTypes defined</xs:documentation>

</xs:annotation>

<xs:simpleType name="Acquirer.acquirerID">

<xs:restriction base="xs:token">

<xs:length value="4" fixed="true"/>

<xs:pattern value="[0-9]+"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="Country.countryNames">


<xs:minLength value="1"/>

<xs:maxLength value="128"/>

</xs:restriction>

</xs:simpleType>



<xs:simpleType name="Error.DebtorMessage">

<xs:restriction base="xs:string">

<xs:maxLength value="512" fixed="true"/>

<xs:minLength value="1" fixed="true"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="Error.errorCode">



<xs:pattern value="[A-Z]{2}[0-9]{4}"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="Error.errorDetail">




</xs:restriction>

</xs:simpleType>

<xs:simpleType name="Error.errorMessage">


<xs:minLength value="1"/>


</xs:restriction>

</xs:simpleType>

<xs:simpleType name="Error.suggestedAction">




</xs:restriction>

</xs:simpleType>

<xs:simpleType name="Issuer.issuerAuthenticationURL">

<xs:restriction base="url"/>

</xs:simpleType>

<xs:simpleType name="Issuer.issuerID">

<xs:restriction base="BIC"/>

</xs:simpleType>

<xs:simpleType name="Issuer.issuerName">




</xs:restriction>

</xs:simpleType>

<xs:simpleType name="Merchant.merchantID">




</xs:restriction>

</xs:simpleType>

<xs:simpleType name="Merchant.merchantReturnURL">



<xs:restriction base="url"/>

</xs:simpleType>

<xs:simpleType name="Merchant.subID">

<xs:restriction base="xs:nonNegativeInteger">

<xs:maxInclusive value="999999" fixed="true"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="Transaction.entranceCode">




<xs:pattern value="[a-zA-Z0-9]+"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="Transaction.expirationPeriod">

<xs:restriction base="xs:duration">

<xs:minInclusive value="PT1M" fixed="true"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="Transaction.language">

<xs:restriction base="language"/>

</xs:simpleType>

<xs:simpleType name="Transaction.status">


<xs:pattern value="Open|Success|Failure|Expired|Cancelled|Pending"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="Transaction.transactionID">




</xs:restriction>

</xs:simpleType>

<xs:annotation>

<xs:documentation>basic simpleTypes defined</xs:documentation>

</xs:annotation>

<xs:simpleType name="BIC">


<xs:pattern value="[A-Z]{6,6}[A-Z2-9][A-NP-Z0-9]([A-Z0-9]{3,3}){0,1}"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="dateTime">

<xs:restriction base="xs:dateTime">

<xs:pattern value=".+Z"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="language">




Copyright © Currence Services BV of 100 All rights reserved.

<xs:pattern value="[a-z]+"/>

</xs:restriction>

</xs:simpleType>

<xs:simpleType name="productID">

<xs:restriction base="xs:string"/>

</xs:simpleType>

<xs:simpleType name="url">

<xs:restriction base="xs:anyURI">


</xs:restriction>

</xs:simpleType>

<xs:simpleType name="version">


<xs:pattern value="1\.0\.0"/>

</xs:restriction>

</xs:simpleType>

<xs:annotation>

<xs:documentation>complexTypes defined</xs:documentation>

</xs:annotation>

<xs:complexType name="Transaction.container">

<xs:sequence>

<xs:any namespace="##any" maxOccurs="unbounded"/>

</xs:sequence>

</xs:complexType>

<xs:annotation>

<xs:documentation>attributeGroups defined</xs:documentation>

</xs:annotation>

<xs:attributeGroup name="MessageAttributes">

<xs:annotation>

<xs:documentation>attributes of each message</xs:documentation>

</xs:annotation>

<xs:attribute name="version" type="version" use="required"/>

<xs:attribute name="productID" type="productID" use="required"/>

</xs:attributeGroup>

</xs:schema> Elektronisch

creditor implementation guidelines emandates - core · • chapter 12: presentation of emandates on...

Documents