Versions Compared

Version Old Version 14 New Version 15
Changes made by

Currence

Currence

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Look & feel


Excerpt

Version: 1.04
Date: 01-11-2017

...

Expand
title...

1.1 Doelgroep

Dit document verstrekt een gedetailleerde beschrijving van de Incassomachtigen oplossing van de Nederlandse banken voor Core en B2B. Het document is bedoeld voor degenen die gedetailleerde informatie behoeven ten aanzien van deze oplossing. 

De specificaties in dit document gelden in beginsel voor zowel de Core als B2B oplossing. Echter, waar een specificatie specifiek geldt voor één van de twee producten is dit in twee kleuren aangegeven:

  • Rood waar dit een Core specificate betreft
  • Groen waar dit een B2B specificate betreft 

Incassomachtigen Creditors zijn bedrijven die Incassomachtigen willen gebruiken en daartoe een Incassomachtigen contract hebben afgesloten met een bank. Creditors worden geacht een incassocontract te hebben getekend alvorens ze een Incassomachtigen contract aanvragen. 

Dit document is bedoeld voor Creditors die aan willen sluiten op het Incassomachtigen platform van de door hen gekozen Creditor bank. Het behandelt het berichtenverkeer tussen Creditors en hun bank. Voor Creditors is het berichtenverkeer tussen de Routing Service van de Creditor Bank en de Validation Service van de Debtor Bank niet van belang. Dit deel van de Incassomachtigen Standaard wordt daarom in dit document niet behandeld, tenzij de berichten van enig belang geacht worden.

Dit document is niet bank-specifiek; dit wil zeggen dat alleen generieke Incassomachtigen zaken in dit document worden behandeld. Informatie over non-standaard aansluitvormen bij specifieke banken en de hulp-(middelen) die een bank verstrekt om aan te sluiten op Incassomachtigen zijn geen onderdeel van dit document. Voor informatie over deze onderwerpen verwijzen wij u naar de door uw bank verstrekte (aanvullende) documentatie.

Om Creditors verder te ondersteunen, zijn er Software Libraries ontwikkeld in .NET, PHP en Java. Neem contact op met uw bank voor meer informatie betreffende deze Software Libraries.

1.2 Andere referenties

Title

Versie

Verstrekt door

UNIFI (20022)


ISO

SDD Implementation Guidelines

7.0

EPC

SDD Rulebook

7.0

EPC

XML message for SEPA Direct Debit Initiation Implementation Guidelines for the Netherlands Verkrijgbaar op http://www.betaalvereniging.nl/wp-uploads/ 2013/01/XMLMessage-for-SDD-Version-7.0-February-2013.pdf

7.0

BVN

Payments Mandate Urgent Maintenance en de bericht XSD’s  Verkrijgbaar op http://www.iso20022.org/full_catalogue.page onder het kopje ‘Pain - Payments Initiation’

Oktober 2014

ISO

External Code Sets spreadsheet

13 juni 2014

ISO

De Base16, Base32, en Base64 Data Encodering http://www.ietf.org/rfc/rfc3548.txt 

Juli 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

Niet bekend

OWASP

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

Tweede editie, 10 June 2008

World Wide Web Consortium (W3C)

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

Versie 1.1 goedgekeurd 23 februari 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 januari 2011

NVB

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

1.0, januari 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, augustus 2008

IETF

Referenties

1.3 Conventies met betrekking tot de notaties

Berichten en redirects worden geschreven als dit, en data elementen worden geschreven als dit.

1.4 Definities van online bankieren

In dit document worden de termen 'internet bankieren' en 'online bankieren' gebruikt. Voor Debtor banken die Incassomachtigen mobiel implementeren, zouden deze termen geïnterpreteerd moeten worden als 'internet bankieren' en/of 'mobiel bankieren'. Waar internet of online gerelateerde terminologie gebruikt wordt, moet dit altijd gelezen worden als ook betrekking hebbende op het mobiele kanaal. In geval het mobiele gebruik van Incassomachtigen tot aanvullende vereisten (requirements) leidt, zullen deze specifiek benoemd worden in deze Implementatie Gids.

1.5 Revisies

Versie

Beschrijving

Release datum

1.02

Versie voor publicatie

10 april 2015

1.03

  • De canonicalization method voor het berekenen van de digest is aangepast naar exclusive canonicalization
  • De archiveringseisen zijn verduidelijkt
  • De eisen aan het formaat van eMandateID zijn toegelicht
  • Het gebruik van het Creditor Adres is toegelicht
  • Toegelicht dat de DateTime in het pain.012 bericht het moment van ondertekenen van de Incassomachtiging is

4 mei 2015

1.04

  • Hoofdstuk 13 is toegevoegd, met informatie over de relatie met de incasso
  • De archiveringseisen voor de machtiging zijn verduidelijkt
  • De eisen aan het plaatsen van timestamps door de Creditor zijn verduidelijkt
  • De XML-tags zijn toegevoegd in de tabellen met XML elementen, zodat de tabellen eenvoudiger te relateren zijn aan de xml berichten
  • Toegelicht dat de elektronische handtekening over de machtiging gecontroleerd moet worden door de Creditor
  • De formaateisen voor het veld maximum bedrag zijn verduidelijkt
  • Creditors mogen in B2B het veld ‘maximum amount’ bij amendments (pain.010) niet meer gebruiken (wijziging ten opzichte van vorige versie zakelijk Incassomachtigen CIG)

31 december

2015

1.6 Wijzigingen in vergelijking met eerdere versies

Wijzigingen die zijn doorgevoerd sinds versie 1.02

  1. De canonicalization method die gebruikt wordt voor het berekenen van de Digest is gewijzigd van inclusive canonicalization naar exclusive canonicalization. Dit heeft impact op zowel de berekening zelf, als het gedeelte van het XML bericht waar het berekeningsproces wordt omschreven.
  2. De eisen aan het archiveren van de originele Incassomachtiging (het ISO pain.012 bericht welke de elektronische handtekening en certificaat informatie bevat) zijn verduidelijkt. Het ISO pain.012 bericht can worden gearchiveerd nadat het is uitgepakt uit de XML envelop, met behulp van exclusive canonicalization. Alternatief is dat Creditors er voor kiezen om simpelweg het gehele StatusResponse bericht te archiveren.
  3. De eisen aan het formaat van eMandateID zijn verduidelijkt. Creditors worden er aan herinnerd dat de karakters van een eMandateID beperkt dienen te worden tot de SEPA Direct Debit karakter set, welke strikter is dan de MES-2 karakterset.
  4. Het gebruik van Creditor Adres is verduidelijkt. De Creditor dient zijn adres te registeren via twee adres regels, waarbij de eerste regel over het algemeen gebruikt wordt voor informatie over de straat, het huisnummer en toevoegingen, en de tweede regel voor postcode en stad.
  5. Toegelicht dat de dateTime in het ISO pain.012 bericht het moment van ondertekenen van de Incassomachtiging is. Het element eMandate.DateTimestamp is in de pain.012 tabel geplaatst om dit duidelijk te maken.

Wijzigingen die zijn doorgevoerd sinds versie 1.03

  1. Hoofdstuk 13 is toegevoegd, met informatie over de relatie tussen het product Incassomachtigen en het uitvoeren van de incasso, alsmede de relatie met de overstapservice.
  2. Toegelicht dat het opslaan van het bericht dat de machtiging bevat dient te gebeuren zonder enige wijzigingen aan dit bericht te doen, in verband met de controleerbaarheid van de elektronische handtekening.
  3. De eisen aan timestamps gezet door de Creditor zijn verduidelijkt. De Creditor mag in timestamps na de secondes nul tot drie decimalen meegeven en is dus niet verplicht om altijd drie decimalen te gebruiken.
  4. De XML-tags zijn toegevoegd in de tabellen met XML elementen in hoofdstuk 8 en 9.
  5. Indien het StatusResponse bericht de status “success” bevat is er een pain.012 bericht aanwezig met de elektronische handtekening over de machtiging. Deze handtekening dient gecontroleerd te worden door de Creditor bij ontvangst van de machtiging
  6. De eisen aan het veld maximum bedrag zijn verduidelijkt; het moet een bedrag tussen 0.01 en 999999999.99 zijn met nul of twee decimalen. Het decimale scheidingsteken is een punt.
  7. Voor B2B mogen Creditors geen waarde meegeven voor maximum bedrag bij het wijzigen van een Incassomachtiging. Het veld ‘maximum bedrag’ in het pain.010 bericht mag dus niet meer worden gebruikt. Als een Incassomachtiging wordt gewijzigd dan start dit process op de website van de Creditor. Na de redirect komt de Debiteur in de internetbankieromgeving van zijn bank terecht. De bank toont daar de huidige waarde van maximum bedrag, zoals die bij de bank is geregistreerd (de incasso’s worden tegen dit bedrag getoetst voordat ze mogen worden geïnd). Als de Debiteur dat wil kan hij deze waarde aanpassen. De (aangepaste) waarde van het maximum bedrag wordt vervolgens weer opgenomen in het pain.012 bericht. Dit bericht wordt opgehaald en opgeslagen door de Creditor.

...

  • Real-time online machtigen via een vertrouwd en bestaand internetbankier-product waar de Debtor al bekend mee is;
  • Real-time goedkeuren van de Incassomachtiging door de Debtor en real-time bevestiging van de Incassomachtiging aan de Creditor door de Creditor Bank. De Creditor ontvangt een Incassomachtiging dat getekend is door de Debtor Bank namens de Debtor;
  • Officieel erkend als geldige machtiging door de deelnemende Debtor banken. De termijn voor storneren en terugboeken van de SEPA Direct Debit incasso’s van de Creditor voor Core wordt hierdoor gereduceerd van 13 maanden tot 56 dagen;
  • De Debtor Bank verwerkt alleen zakelijke (Business to Business) SEPA Direct Debit incasso’s indien deze verwijzen naar een vooraf geregistreerde machtiging. Als onderdeel van het Incassomachtigen proces wordt de registratie van de Incassomachtigingen door de bank automatisch bijgewerkt op basis van de afgifte/wijziging/intrekking van een Incassomachtiging. Dit betekent dat de Creditor meteen kan overgaan tot incasseren. In vergelijking met het huidige mandaat-registratie proces zorgt deze methode voor een grote verlaging van de tijd tussen de afgifte van de machtiging en de incassering en het aantal mislukte incasso’s vanwege registratiefouten.
  • Incassomachtigen biedt de flexibiliteit om machtigingen te ontvangen voor verschillende doelen (bijvoorbeeld donaties, tijdschriftabonnementen, telefonische/e-mail bestellingen);
  • Ondersteunt meervoudig ondertekenen in de Debtor Bank omgeving in het geval dat dit nodig is voor specifieke Debtors.

...

  • De richtlijnen ter implementatie van Incassomachtigen zoals beschreven in dit document zijn bedoeld voor de Core/Zakelijke (Business to Business) SEPA Direct Debit.
  • De Incassomachtigen oplossing faciliteert het afgeven van nieuwe mandaten, het wijzigen van al bestaande mandaten en het intrekken van bestaande mandaten. De Creditor dient alle functionaliteiten aan te bieden.
    • De enige reden tot wijziging van het mandaat, is wanneer een Debtor van rekeningnummer wenst te wijzigen voor het innen van incasso’s, binnen dezelfde bank of naar een andere bank, of wanneer een Debtor het maximaal toegestane incassobedrag wil wijzigen. Na de redirect naar de internetbankieromgeving van zijn bank kan de Debiteur zijn rekening kiezen en/of het maximum bedrag voor de incasso (opnieuw) instellen.  
    • Het intrekken van Incassomachtigingen wordt voor Core niet ondersteund door de Incassomachtigen oplossing zelf. De reden hiervoor is dat intrekkingen vaak betrekking hebben op het beëindigen van een abonnement of contract, in plaats van op het mandaat zelf. Het intrekken van Incassomachtigingen is om die reden een zaak die elektronisch gefaciliteerd moet worden door de Creditor, zonder dat de Debtor bank daar een rol in heeft.
  • De Incassomachtigen oplossing maakt gebruik van ISO XML 20022 Standaard eMandates berichten om Incassomachtigen-specifieke data over te dragen. De volgende berichten zijn in gebruik: pain.009.01.04 (nieuw, hier wordt ook naar gerefereerd als ‘Issuing’), pain.010.01.04 (wijziging), pain.011.01.04 (intrekking) en pain.012.01.04 (acceptance report). De informatie in het ISO XML 20022 acceptance report (pain.012) fungeert als de daadwerkelijke machtiging. De ISO berichten zijn in een container element geplaatst in de berichten. De XSD’s voor deze ISO berichten kunnen worden gevonden op http://www.iso20022.org/full_catalogue.page, zie ‘pain – Payments initiation’.
  • De Incassomachtigen oplossing is bedoeld voor zowel terugkerende als eenmalige mandaten.
  • In het Incassomachtigen proces wordt de Incassomachtiging-informatie aan de Debtor getoond in het Debtor bank domein.
  • Iedere Incassomachtiging heeft een eMandateID (kenmerk machtiging) dat uniek is binnen het CreditorID. Elke Creditor is verantwoordelijk voor het gebruiken van unieke eMandateID’s. Creditors dienen ervoor te zorgen dat het eMandateID voldoet aan de SEPA karakterset, zodat het gebruikt kan worden in het incassoproces.
  • De Creditor is verantwoordelijk voor het archiverenvan het originele mandaat en de elektronische handtekening (het ISO pain.012 bericht), samen met eventuele wijzigings- of intrekkingsinformatie die op een later moment kan zijn ontstaan. Het is te verwachten dat in de toekomst striktere eisen zullen worden gesteld aan elektronisch archiveren, met name met betrekking tot het waarborgen van de integriteit van documenten over een langere periode van tijd. Op de korte termijn zal binnen de regelgeving omtrent elektronisch identificeren het onderwerp eArchiving geadresseerd worden en zal een wettelijk raamwerk worden opgesteld met betrekking tot tijdstempels. Dit raamwerk zal worden geëvalueerd en worden toegepast in deze implementatie gids. Het ISO pain.012 bericht kan worden gearchiveerd nadat het is uitgepakt uit de XML envelop, met behulp van exclusive canonicalization. Alternatief is dat Creditors er voor kiezen om simpelweg het gehele StatusResponse bericht te archiveren. Het opslaan van het bericht dient te gebeuren zonder het bericht op enige wijze aan te passen, omdat de elektronische handtekening door aanpassingen ongeldig wordt. Een voorbeeld van een wijziging waardoor de elektronische handtekening direct ongeldig wordt is het aanpassen van de opmaak van het bericht.
  • De elementen eMandate.FrequencyCount en eMandate.FrequencyPeriod zijn opgenomen in de Incassomachtigen oplossing om de Consumentenbeschermingsinstellingen van de Debtor Bank voor Incasso te faciliteren. Deze elementen zijn echter opgenomen voor mogelijk toekomstig gebruik en zullen niet worden gebruikt in deze versie van Incassomachtigen. De Creditor mag deze velden NIET OPNEMEN in welk Incassomachtigen bericht dan ook.
  • Een goedgekeurde Incassomachtiging wordt voor Core door de Debtor bank gebruikt om de Debtor’s whitelistte updaten, maar dit gebeurt slechts indien de whitelist al geactiveerd was door de Debtor. Een inactieve whitelist zal niet worden geactiveerd door een Incassomachtiging. Een whitelist is de goedkeuringslijst van de Debtor voor incasso in zijn bankdomein. Indien de whitelist door de Debtor is geactiveerd mogen alleen incasso’s van machtigingen die op de whitelist staan door de bank worden uitgevoerd.
  • Indien de Creditor of het MandateID op de blacklist van de Debtor staat, zijn er binnen Core verscheidene opties:
    • De blacklist wordt real-time aangepast door de Debtor, en de Incassomachtiging wordt goedgekeurd.
    • De blacklist moet eerst worden aangepast in een separaat proces, waarbij het Incassomachtigen proces onderbroken moet worden en opnieuw moet worden gestart op een later tijdstip.

  • Voor B2B worden Incassomachtigingen door de Debtor Bank gebruikt om de mandaatregistratie van de Debtor automatisch te updaten:

    • Een goedgekeurde nieuwe Incassomachtiging wordt toegevoegd aan de registratielijst
    • Wijzigingen van een Incassomachtiging (aanpassing van rekeningnummer of maximum incassobedrag) worden verwerkt in de registratielijst
    • Ingetrokken Incassomachtigingen worden verwijderd uit de registratielijst

...

De Creditor is vrij om intrekkingen van bestaande (papieren) mandaten te accepteren via de Incassomachtigen oplossing.

4.4 Consumentenbeschermingsinstellingen

eMandate.FrequencyCount en eMandate.FrequencyPeriod zijn opgenomen in dit document voor mogelijk toekomstig gebruik om de consumentenbeschermingsinstellingen van de Debtor banken te faciliteren. In de huidige implementatie van Incassomachtigen dienen deze elementen daarom niet te worden verwerkt door de Routing Service noch de Validation Service. Creditors mogen deze velden daarom niet opnemen in de huidige Incassomachtigen berichten, aangezien dit zal leiden tot een afwijzing van het gehele bericht.

4.5 Meervoudig ondertekenen

...

Dit hoofdstuk bevat een omschrijving van de algehele berichtstructuur voor het Directoryprotocol, het Transactieprotocol en het Statusprotocol. De volgende paragrafen beschrijven de specifieke velden in de XML berichten voor elk protocol in meer detail. 

Ieder bericht beschreven in deze paragrafen is een XML bericht dat conformeert aan het XML schema in APPENDIX D. 

5.1 General

HTTP

De volgende HTTP header wordt gebruikt voor alle berichten:

...

  • Alle berichten moeten voldoen aan de HTTP 1.1 standaard. Deze is gedefinieerd in RFC 2616 van W3C. Zie http://www.w3.org/Protocols/rfc2616/rfc2616.html voor meer informatie.
  • Een XML request bericht moet worden verstuurd via HTTP POST als body van het bericht.
  • Een XML response bericht moet worden verstuurd als body van een http 200 OK bericht.

XML Header

De volgende XML header wordt gebruikt voor alle berichten:

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

Karakterset

  • In alle Incassomachtigen berichten moet de Unicode karakterset worden gebruikt. Alleen de MES-2 subset wordt ondersteund.
  • De codering moet worden gebruikt zoals aangegeven in de HTTP en XML headers: UTF-8 (Unicode Transformation Format).
  • Het gebruik van karakters die geen onderdeel zijn van de Unicode karakterset zal niet leiden tot een weigering van een verzoek, maar het karakter kan gewijzigd worden naar een spatie, vraagteken of asterisk.
  • Het Byte Order Mark (BOM) mag niet worden gebruikt. De UTF-8 representatie van de BOM is de byte sequentie 0xEF,0xBB,0xBF.

...

Data element

Attribuut

Formaat

Toelichting waardes

Berichten 

Root element

version

AN..8

1.0.0

Alle

Root element

productID

AN..35

NL:BVN:eMandatesCore:1.0
NL:BVN:eMandatesB2B:1.0

Alle

Data element

Sub-element

Formaat

Toelichting waardes

Berichten

createDateTimestamp

DT

ISO-8601

Alle

Directory

directoryDateTimestamp

DT

ISO-8601

DirectoryRes

Directory

countryNames

AN..128


DirectoryRes

Directory

Issuer

 issuerID

ANS..max 11max11

BIC, ISO9362

DirectoryRes

Directory

Issuer

 issuerName

AN..max 35max35


DirectoryRes

Error

consumerMessage

AN..max 512max512


ErrorResponse

Error

container

Any


ErrorResponse

Error

errorCode 

CL AN..6

Zie Appendix B

ErrorResponse

Error

errorMessage

AN..max 128max128


ErrorResponse

Error

errorDetail

AN..max 256max256


ErrorResponse

Error

suggestedAction

AN..max 512max512


ErrorResponse

Issuer

issuerAuthenticationURL

AN..max 512max512


TransactionRes

Merchant

merchantReturnURL

AN..max 512max512

Bepaald door de Creditor

TransactionReq

SignedInfo

Exclusive
CanonicalizationMethod


http://www.w3.org/2001/10/xmlexc-c14n#

Alle

SignedInfo

Signaturemethod


http://www.w3.org/2001/04/xmldsi g-more#rsa-sha256

Alle

SignedInfo

Reference

URI


Moet leeg zijn

Alle

SignedInfo

Reference

Transforms


http://www.w3.org/2000/09/xmldsi g#enveloped-signature

Alle

SignedInfo

Reference

Transforms


http://www.w3.org/2001/10/xmlexc-c14n#

Alle

SignedInfo

Reference

DigestMethod


http://www.w3.org/2001/04/xmlen c#sha256

Alle

SignedInfo

Reference

DigestValue


Base64

Alle

SignatureValue


Base64

Alle

KeyInfo

KeyName 


Fingerprint van certificate

Alle

Transaction

container

Any

Te vullen met eMandate ISO pain bericht

  • TransactionReq
  • StatusRes

Transaction

entranceCode

ANS..max 40max40

Bepaald door de Creditor

TransactionReq

Transaction

expirationPeriod

RDT

ISO 8601 - Bepaald door de Creditor

TransactionReq

Transaction

language

CL AN..2

ISO 639-1 - Bepaald door de Creditor

TransactionReq

Transaction

status

CL AN..max 9max9

Open, Success, Failure, Cancelled, Expired, Pending

StatusRes

Transaction

statusDateTimestamp 

DT

ISO 8601

StatusRes

Transaction

transactionID 

PN..16

Bepaald door de Creditor

  • TransactionRes
  • StatusReq
  • StatusRes

Transaction

transactionCreate DateTime stamp

DT

ISO 8601
Bepaald door de Routing Service Provider

TransactionRes

...


Nr.

Incassomachtigen naam

Omschrijving

Formaat eisen

1

Creditor.AddressLine1

Het Creditor adres – regel 1
Postbus of straatnaam + gebouw + toevoeging (indien aanwezig)

Max70Text

2

Creditor.AddressLine2

Het Creditor adres – regel 2
Postcode, Stad

Max70Text

3

Creditor.Country

Land van het post adres van de Creditor

[A-Z]{2,2}

4

Creditor.CreditorID

Direct Debit ID van de Creditor (NL: IncasantID)

Zoals beschreven in AT-02 (Identifier of the Creditor) in de EPC SDD Implementation Guidelines.

5

Creditor.Name

Naam van de Creditor

Max70Text

6

Creditor.TradeName

Naam van het bedrijf (of dochterbedrijf, label etc.) op welke de Creditor de Incassomachtiging laat registreren. Mag alleen worden gebruikt wanneer het betekenisvol verschilt van de Creditor.Name

Max70Text

7

DateTime

Datum en tijd

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

8

Debtor.AccountName

Naam van de rekeninghouder, wiens rekening wordt gebruikt voor de Incassomachtiging

Max70Text

9Debtor.DebtorBankIDBIC van de Debtor Bank, geselecteerd door de Debtor, zoals getoond in de Debtor bank lijst in de DirectoryResponseBIC (ISO 9362)
10

Debtor.IBAN

Debtor’s rekeningnummer

IBAN (ISO 13616)

11

Debtor.SignerName

Naam van de persoon/personen die de Incassomachtiging ondertekent/ondertekenen. Mag eindigen op ‘e.a.’ in geval meer dan 70 karakters nodig zijn voor meerdere namen van ondertekenaars.

Max70Text

12

eMandate.AmendmentReason

De code van de reden voor het wijzigen van een Incassomachtiging

Moet ‘MD16’ zijn. Dit betekent dat de wijziging aangevraagd is door de Debtor.

13

eMandate.DateTimestamp

Datum en tijd op welke de Incassomachtiging goedgekeurd is door de Debtor in het Debtor bankdomein

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

14

eMandate.DebtorReference

Referentie ID dat de Debtor aan de Creditor identificeert. Wordt afgegeven door de Creditor

Max35Text

15eMandate.eMandateID

Uniek ID (kenmerk machtiging) dat het mandaat definieert en wordt afgegeven door de Creditor

Max35Text. Must be restricted to the SEPA character set

16

eMandate.MaxAmount
ALLEEN IN B2B

Het maximale bedrag per incasso. Alleen in B2B niet in Core

Een bedrag tussen 0.01 en 999999999.99 met nul of twee decimalen. Decimalen worden gescheiden door een punt. ActiveCurrencyCode: ’EUR’

17

eMandate.PurchaseID

Een aankoopnummer dat gebruikt kan worden om te refereren voor welke oorspronkelijke aankoop de Incassomachtiging is afgegeven. Creditors wordt aangeraden dit veld alleen te gebruiken als het een andere waarde heeft dan eMandate.Reason

Max35Text

18

eMandate.Reason

Geeft de reden voor de Incassomachtiging aan

Max70Text

19

eMandate.SequenceType

Indiceert het type Incassomachtiging: eenmalige incasso of terugkerend

'OOFF' of 'RCUR'

20eMandate.TransactionIDDe waarde van dit ID wordt overgenomen van Transaction.transactionID16 cijfers
21

Message.NameID

Refereert naar het type van het validatieverzoek

  • Issuing
  • Amendment
  • Cancellation (alleen B2B, niet Core)
22

ValidationService.
ValidationReference

De referentie naar het Incassomachtigen validation log van de Validation Service. Deze referentie wordt gecreëerd door de Validation Service. Deze referentie moet door de Creditor worden gebruikt in het veld ‘Electronic Signature’ van de incasso-opdrachten  (buiten de scope van dit document)

Max128Text

23

eMandate.FrequencyCount
CURRENTLY NOT USED

Het nummer van incasso inningen tijdens een specifieke eMandate.FrequencyPeriod

Is niet toegestaan in de huidige implementatie.

Maximum 18 cijfers. Geen decimalen toegestaan

24eMandate.FrequencyPeriod
CURRENTLY NOT USED

Periode voor het aantal (eMandate.FrequencyCount) incasso inningen

Is niet toegestaan in de huidige implementatie

Zie de eMandate.FrequencyPeriod codelijst

eMandates data elements

...

Het XML bericht dat wordt verzonden door de Creditor naar de Routing Service om de transactie te initiëren worden getoond in onderstaande tabellen: De Incassomachtiging informatie (ISO bericht) wordt in het container element geplaatst in het TransactionRequest. De definitie van het ISO bericht voor een nieuw Incassomachtigen-verzoek (ISO pain.009.001.004), een wijzigingsverzoek (ISO pain.010.001.004) en intrekkingsverzoek (ISO pain.011.001.004) worden getoond in onderstaande tabellen. 


Section


Column
width675px

Velden van het TransactionRequest

Naam

Omschrijving

Formaat

createDateTimestamp

Datum en tijdstip waarop het TransactionRequest bericht is gecreëerd.

DT

issuerID

Het ID (BIC) van de Debtor bank geselecteerd door de Debtor, zoals getoond in de Debtor bank lijst in de DirectoryResponse (Debtor.DebtorBankID).

ANS..max 11

merchantID

eMandate.ContractID zoals dit van de Creditor Bank ontvangen is. Indien het eMandate.ContractID uit minder dan 10 cijfers bestaat, worden voorloopnullen gebruikt.

PN..10

subID

eMandate.ContractSubID, door de Creditor Bank verstrekt aan Creditor, als Creditor aangeeft hier gebruik van te willen maken.

Een Creditor kan bij zijn Creditor Bank verzoeken om meerdere subID’s te mogen gebruiken. Hierdoor wordt op de Incassomachtiging niet alleen de  Creditor.Name (de incassant), maar ook de Creditor.TradeName en het relevante Creditor.Address  behorende bij het SubID weergegeven (Creditor.Name inzake Creditor.Tradename). 

Tenzij anders afgesproken met de Creditor Bank dient de Creditor hier 0 (nul) in te vullen als standaard subID (indien geen subIDs worden gebruikt).

N..max 6

merchantReturnURL

URL van de Creditor waarheen de Debtor na autoriseren van de transactie geredirect moet worden door de Debtor bank en die terugleidt naar de website van de Creditor. (Hoeft niet noodzakelijkerwijs te beginnen met http:// of https://). 

Bijvoorbeeld: https://www.webwinkel.nl/betaalafhandeling

AN..max 512

expirationPeriod

Optioneel: De geldigheidsduur van het transactieverzoek gemeten vanaf ontvangst door de Debtor bank. De Debtor dient de Incassomachtiging te accorderen binnen deze tijd. Als dit niet gebeurt dan wordt de status van de transactie door de Debtor bank op “Expired” gezet.

Waarde volgens ISO 8601: PnYnMnDTnHnMnS. Minimum waarde: PT1M or PT60S (1 minuut); maximum waarde: P7D, PT168H, PT10.080M (7 dagen). De Creditor wordt aangeraden dit veld leeg te laten. 

RDT

language

Door middel van dit veld kan de Debtor bediend worden op de site van de Debtor bank in de taal naar keuze (of zoals deze geselecteerd is op de site van de webwinkel), indien de site van de Debtor bank dit ondersteunt.

Codelijst conform ISO 639-1. (Engels = ‘en’, Nederlands = ‘nl’)

Indien een niet bestaande of niet ondersteunde taal wordt opgegeven wordt de standaardtaal van de Debtor bank gebruikt.

Geadviseerd wordt om alleen “nl” te gebruiken omdat andere talen niet door alle Debtor banken worden ondersteund.

CL AN..2

entranceCode

De Transaction.entranceCode is een ‘authenticatie sleutel’ ten behoeve van continuering van de sessie tussen Creditor en Debtor, zelfs als de bestaande sessie is beëindigd. De Creditor kan hiermee de Debtor herkennen die hoort bij een (inmiddels afgeronde) transactie. De entranceCode moet voor iedere transactie een unieke waarde hebben.

De Transaction.entranceCode wordt hiertoe meegestuurd in de HTTP(S) GET naar de Creditor als parameter achter de merchantReturnURL.  De Transaction.entranceCode dient een minimale variatie van 1 miljoen te hebben. Deze code moet bestaan uit letters en/of cijfers (maximaal 40 posities).

De Transaction.entranceCode wordt aangemaakt door de Creditor. 

ANS..max 40

Container

Deze container bevat de ISO pain berichten. Dit kan een 009 (nieuwe Incassomachtiging), 010 (wijziging) of 011 (intrekking) bericht zijn. Zie tabellen hieronder voor meer informatie.


SignedInfo


*

SignatureValue


*

KeyInfo


*

*SignedInfo, SignatureValue en KeyInfo zijn XML Signature data elementen die gedefinieerd zijn in de XML-Signature Syntax and Processing (Second Edition) W3C Aanbeveling 10 juni 2008. De digitale handtekening wordt in meer detail beschreven in Hoofdstuk 11. Het XML Digital Signature Schema is beschikbaar bij de W3C op het adres: http://www.w3.org/TR/2002/RECxmldsig-core-20020212/xmldsig-core-schema.xsd# 


Div
stylepadding-left: 1cm
classno-print


Column
width100%

Insert excerpt
iDx AcquirerTrxReq (B)
iDx AcquirerTrxReq (B)
nopaneltrue




...

Section


Column
width675px


Naam

Omschrijving

Formaat

createDateTimestamp

Datum en tijd waarop de TransactionResponse gecreëerd is.

DT

acquirerID

Uniek kenmerk van 4 cijfers van de Creditor bank. Creditor.CreditorBankID binnen Incassomachtigen

PN..4

issuerAuthenticationURL

De complete URL van de Debtor bank waar de Debtor naartoe dient te worden geredirect door de Creditor voor authenticatie en goedkeuren van de transactie.

AN..max 512

transactionID

Uniek 16 cijferig nummer binnen Incassomachtigen.
Het nummer bestaat uit het Creditor.CreditorBankID (eerste 4 posities) en een door de Routing Service gegenereerd uniek nummer (12 posities).

Dit unieke nummer identificeert iedere Incassomachtigen transactie. Het wordt gebruikt in de Statusrequest om te identificeren voor welke transactie de status wordt opgevraagd.   

PN..16

transactionCreate
transactionCreateDate TimestampDateTimestamp

Datum en tijd waarop de transactie voor het eerst is geregistreerd door de Routing Service. Deze tijd kan door Creditor, Creditor bank en Debtor bank gebruikt worden om over de transactie te rapporteren.

DT

SignedInfo


 *

SignatureValue


 *

KeyInfo


 *

Velden van de TransactionResponse.

*SignedInfo, SignatureValue en KeyInfo zijn XML Signature data elementen die gedefinieerd zijn in de XML-Signature Syntax and Processing (Second Edition) W3C Aanbeveling 10 juni 2008. De digitale handtekening wordt in meer detail beschreven in Hoofdstuk 11. Het XML Digital Signature Schema is beschikbaar bij de W3C op het adres: http://www.w3.org/TR/2002/RECxmldsig-core-20020212/xmldsig-core-schema.xsd# 


Div
stylepadding-left: 1cm
classno-print


Column

Insert excerpt
iDx AcquirerTrxRes (B')
iDx AcquirerTrxRes (B')
nopaneltrue



...

errorCode

errorMessage 

errorDetail

IX1100

Received XML not valid

Field generating error: location-reference in XML message

IX1200

Encoding type not UTF-8

IX1300

XML version number invalid

IX1600

Mandatory value missing

SO1000

Failure in system

System generating error: Issuer/Acquirer

SO1100

Issuer unavailable

SO1200

System busy. Try again later

SO1400

Unavailable due to maintenance

SE2000

Authentication error

Field generating error: location-reference in XML message

SE2100

Authentication method not supported

BR1200Version number invalid
BR1205ProductID invalid
BR1210Value contains non-permitted character
BR1220Value too long
BR1230Value too short
BR1270Invalid date/time
BR1280Invalid URL
AP1100MerchantID unknown
AP1200IssuerID unknown
AP1300SubID unknown
AP1500MerchantID not active
AP2600Transaction does not exist
AP2920Expiration period is not valid
AP3000

eMandates specific error
Details van de fout kunnen worden gevonden in het ISO pain.012 error acceptance bericht.

...