Versions Compared

Version Old Version 13 New Version 14
Changes made by

Currence

Currence

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Look & Feel (groen ipb blauw voor B2B)


Excerpt

Version: 1.04
Date: 01-11-2017

...

Div
styleno-print
classno-print

Rood: geldt specifiek voor Incassomachtigen Core
BlauwGroen:  geldt geldt specifiek voor Incassomachtigen B2B 

...

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
  • Blauw 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.

...

2. Incassomachtigen Overzicht

...

  • 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

2.3 Het vier partijenmodel

...

Dit hoofdstuk beschrijft de verschillende specifieke functies van de Incassomachtigen oplossing. Alle Incassomachtigen processen worden geïnitieerd op de Creditor website door de Debtor. Incassomachtigen processen worden nooit geïnitieerd vanuit het Debtor bankdomein. Het Incassomachtigen (afgevings-, wijzigings- of intrekkings) verzoek wordt gecreëerd door de Creditor. De Incassomachtiging is nog niet compleet; het wordt aangevuld door respectievelijk de Routing Service (met Creditor informatie) en de Validation Service (met Debtor informatie). 

...

Vergelijkbaar met het afgeven van nieuwe Incassomachtigingen, wordt het proces op de Creditor website geïnitieerd door de Debtor. Het wijzigen van een Incassomachtiging is alleen toegestaan wanneer de Debtor van rekeningnummer wenst te wisselen (binnen dezelfde bank of naar een andere bank) of om het maximaal toegestane bedrag per incasso te wijzigen.Het proces is vrijwel identiek aan het proces voor het afgeven van een nieuwe Incassomachtiging, maar voor een wijziging (eng. Amendment) wordt het ISO pain.010 bericht gebruikt in plaats van het ISO pain.009 bericht.

...

Het intrekken van Incassomachtigingen wordt niet ondersteund door de Incassomachtigen Core oplossing; een intrekking (eng. Cancellation) wordt daarom niet in het Debtor bankdomein gedaan, maar de Incassomachtiging moet direct via de Creditor worden ingetrokken. De Creditor moet dit faciliteren door middel van elektronische (website, e-mail) en reguliere kanalen.

Vergelijkbaar met het afgeven en wijzigen van Incassomachtigingen worden voor B2B intrekkingen geïnitieerd door de Debtor op de website van de Creditor. Voor zakelijk Incassomachtigen bevat het intrekkingsproces een controle bij de Debtor Bank (waar het bij Core een zaak is tussen de Creditor en de Debtor). Voor het intrekken van bestaande machtigingen wordt het ISO pain.011 bericht gebruikt.

Het intrekkingsbericht bevat een verwijzing naar de originele Incassomachtiging: eMandateID, Debtor IBAN en Debtor Bank ID. Intrekkingen kunnen echter alleen worden gedaan bij dezelfde bank waar de machtiging is uitgegeven of goedgekeurd (dat wil zeggen, de bank waar de incasso’s plaatsvinden). De Creditor dient duidelijk te maken aan de Debtor dat deze moet kiezen voor dezelfde bank waar de machtiging is afgegeven. Indien de Debtor een andere bank kiest, zal de transactie door deze bank worden afgewezen.

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.

...

Attribuut

Verplicht

Toelichting

version

Ja

De waarde moet zijn: 1.0.0

productID

Ja

De waarde refereert naar het product voor welke het Incassomachtigen protocol gebruikt wordt. Moet zijn: NL:BVN:eMandatesCore:1.0 NL:BVN:eMandatesB2B:1.0 

Let op: Deze attributen worden niet voor elk bericht apart gespecificeerd in deze Gids.  

...

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 11

BIC, ISO9362

DirectoryRes

Directory

Issuer

 issuerName

AN..max 35


DirectoryRes

Error

consumerMessage

AN..max 512


ErrorResponse

Error

container

Any


ErrorResponse

Error

errorCode 

CL AN..6

Zie Appendix B

ErrorResponse

Error

errorMessage

AN..max 128


ErrorResponse

Error

errorDetail

AN..max 256


ErrorResponse

Error

suggestedAction

AN..max 512


ErrorResponse

Issuer

issuerAuthenticationURL

AN..max 512


TransactionRes

Merchant

merchantReturnURL

AN..max 512

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 40

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 9

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

...

De tabel hieronder beschrijft de data elementen die gebruikt worden in de Incassomachtigen ISO pain berichten (009, 010, 011 en 012), samen met hun formaateisen. Let op: een deel van deze elementen wordt door de Routing Service en door de Validation Service toegevoegd aan de Incassomachtiging en worden dus niet door de Creditor in de TransactionRequest aangeleverd. Zie paragraaf 8.2 voor een overzicht welke gegevens deel uit maken van de TransactionRequest


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




...

Een Debtor kan het Debtor rekeningnummer of maximaal toegestane incassobedrag van een bestaande Incassomachtiging wijzigen via de Incassomachtigen oplossing. Het website proces is vergelijkbaar met het afgeven van een nieuwe Incassomachtiging, maar in dit geval geeft de Debtor aan welk bestaande Incassomachtiging (MandateID) hij wenst aan te passen. Het originele Debtor bank ID en het originele Debtor IBAN worden ook meegestuurd in het wijzigingsverzoek. 

...

Include Page
Incassomachtigen Wijzigen request van Creditor naar Routing Service
Incassomachtigen Wijzigen request van Creditor naar Routing Service

8.2.4 Inhoud van het container element voor Incassomachtigen intrekking

Een Debtor kan een bestaande Incassomachtiging intrekken via de Incassomachtigen oplossing. Het website proces is vergelijkbaar met het afgeven van een nieuwe Incassomachtiging, maar in dit geval geeft de Debtor aan welke bestaande Incassomachtiging (MandateID) hij wenst in te trekken EN de Debtor kan zijn Incassomachtiging alleen intrekken bij de bank waar de Incassomachtiging geregistreerd staat. De Creditor moet dit duidelijk maken aan de Debtor (om te voorkomen dat de Debtor de verkeerde bank kiest). 

De volgende tabel beschrijft welke elementen de Creditor naar de Routing Service stuurt in het TransactionRequest, voor een Incassomachtigen intrekking. 

Include Page
Incassomachtigen Intrekking
Incassomachtigen Intrekking

...

9.3.1 Inhoud van het container element voor nieuwe Incassomachtigingen, wijzigingen of intrekkingen

De volgende tabel specificeert de Incassomachtigen elementen in het ISO pain.012 bericht die in de container geplaatst worden. De Validation Service handtekening wordt ook in de container geplaatst, in het supplementary data-veld van het ISO bericht. Zie paragraaf 11.2.1 voor meer informatie. Het is essentieel dat de Creditor zowel het ISO pain.012 bericht als de elektronische handtekening (inclusief de certificaat-informatie) bewaart tot minimaal 13 maanden nadat de laatste incasso heeft plaatsgevonden die gerelateerd was aan de Incassomachtiging. Het pain.012 bericht is vrijwel identiek voor nieuwe Incassomachtigingen en voor gewijzigde Incassomachtigingen en voor Incassomachtigen intrekkingen. Het enige verschil is het veld ‘Message Name Identification’; dit element krijgt de waarde ‘Issuing’ indien het oorspronkelijke TransactionRequest een pain.009 bericht bevatte. Het krijgt de waarde ‘Amendment’ indien het oorspronkelijke TransactionRequest een pain.010 bericht bevatte. Het krijgt de waarde ‘Cancellation’ indien het oorspronkelijke TransactionRequest een pain.011 bericht bevatte.

Include Page
eMandate Acceptance Report - NL
eMandate Acceptance Report - NL

...

Indien de Routing Service een fout in het pain bericht (009, 010 of 011) detecteert in de container van het TransactionRequest, zal de ErrorResponse een ISO Pain.012 Error Acceptance Report bevatten. Dit bericht wordt getoond in onderstaande tabel. In dit geval zal de errorCode, zoals gespecificeerd in Appendix B, de waarde AP3000 hebben. Het pain.012 Error Acceptance Report zal de status “Rejected” hebben en zal ook een Reject Reason code bevatten. Zie Appendix B voor de beschikbare Reject Reason codes.

...

Het moet duidelijk zijn voor de Debtor hoe en wanneer hij/zij Incassomachtigen als betaalmethode kiest. Dit wordt bewerkstelligd door een Incassomachtigen-knop te tonen, over het algemeen op het deel van de pagina waar men normaliter een betaalmethode selecteert. Het moet  Het moet voor de Debtor duidelijk zijn dat hij bezig is met zakelijk Incassomachtigen. De Incassomachtigen-knop moet de volgende tekst bevatten: ‘Zakelijke Incassomachtigen via uw bank’. 

...

Het logo van Incassomachtigen kunt u vinden in het huisstijlhandboek Incassomachtigen.

12.9 Incassomachtigen uitleggen aan Debtors

...

  • U bestelt een product of dienst
  • Selecteer ‘Zakelijke ‘Zakelijke 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 de Incassomachtiging en u kunt het emailen of downloaden
  • U keert terug naar de webwinkel. De machtiging is geaccepteerd en u kunt weer verder winkelen

...

  • Een Creditor moet zich ervan verzekeren dat in het ontwerp van zijn implementatie de Incassomachtigen oplossing en de start van het Incassomachtigen proces als zodanig te herkennen zijn. De Creditor moet ook duidelijk onderscheid maken tussen het proces om een nieuwe Incassomachtiging af te geven en het proces om een bestaande Incassomachtiging te wijzigen en het proces om een bestaande Incassomachtiging in te trekken
  • Creditors die Incassomachtigen accepteren moeten de Incassomachtigen oplossing in hun lijst van betaalmethodes opnemen (als zij die hebben).
  • De Incassomachtigen oplossing moet gepresenteerd worden in de lijst van betaalmethoden op een dergelijke manier dat de oplossing dezelfde hoeveelheid aandacht krijgt als de andere betaalmethodes.
  • Het moet duidelijk zijn voor de Debtor dat hij op het punt staat om een Incassomachtigen transactie aan te vangen.

...

  1. Het afgeven van een nieuwe Incassomachtiging
    Een nieuwe Incassomachtiging kan worden afgegeven wanneer bijvoorbeeld een Creditor een nieuwe klant krijgt (Debtor) of wanneer een bestaande klant (Debtor) een nieuwe Incassomachtiging dient af te geven in verband met additionele (nieuwe) producten of diensten. 
  2. Het wijzigen van een bestaande Incassomachtiging
    Een bestaande Incassomachtiging kan alleen worden gewijzigd in het geval de Debtor het rekeningnummer wenst te veranderen (binnen dezelfde bank of naar een andere bank) of om het maximaal toegestane bedrag per incasso te wijzigen. Andere wijzigingen aan de Debtor-zijde (zoals adresveranderingen) en Creditor wijzigingen zijn niet relevant voor de Incassomachtiging.

  3. Het intrekken van een bestaande Incassomachtiging
    De Debtor kan er voor kiezen om een bestaande Incassomachtiging in te trekken. De Creditor dient de Debtor er op te wijzen dat de Creditor moet kiezen voor de bank waar de Incassomachtiging geregistreerd staat. De Debtor wordt doorgestuurd naar de Debtor Bank om de intrekking te valideren.

De Creditor moet duidelijk aangeven aan de Debtor of hij een nieuwe Incassomachtiging afgeeft of een bestaande Incassomachtiging wijzigt of intrekt. Het intrekken van een Incassomachtiging wordt rechtstreeks gedaan tussen de Debtor en Creditor, zonder validatie in het Debtor Bank domein. 

...

  • eMandate.eMandateID
  • eMandate.Reason (optioneel)
  • eMandate.SequenceType
  • eMandate.MaxAmount (optioneel)
    • Indien de Creditor geen maximum bedrag heeft ingevuld in het pain.009 bericht (nieuwe machtiging), geeft de Debtor Bank de Debtor de mogelijkheid om deze zelf te bepalen. Dit maximum bedrag wordt toegevoegd aan het ISO pain.012 bericht. Voor wijzigingen van Incassomachtigingen mag de Creditor geen waarde voor het maximum bedrag invullen in het pain.010 bericht. De Bank van de Debiteur toont de huidige waarde van het maximum bedrag uit de registratielijst en de Debiteur heeft de mogelijkheid om deze waarde aan te passen. De (aangepaste) waarde wordt toegevoegd aan het pain.012 bericht. 
  • eMandate.PurchaseID (optioneel)
  • De term ‘SEPA’ moet worden genoemd op de Incassomachtiging

...

Indien een machtiging gewijzigd wordt via het Incassomachtigen proces wordt dit op dezelfde manier verwerkt in het incassobericht als wanneer een papieren machtiging gewijzigd zou worden.

Zakelijke incassos worden gechecked tegen de mandaat registratie van de Debtor. Als de Debtor een eMandate afgeeft, wijzigt/cancelt, gebruikt de Debtor Bank deze informatie meteen om de mandaat registratie aan te passen. Op deze manier kunnen Creditors meteen na het ontvangen van het pain.012 bericht incasso's inschieten.

13.2 Relatie met overstapservice

Wanneer de Debiteur gebruik maakt van de overstapservice wordt de Creditor geinformeerd over de wijziging van het rekeningnummer van de Debiteur. De Creditor bewaart de overstapinformatie samen met de originele Incassomachtiging. De Debiteur hoeft in dit geval geen nieuwe machtiging af te geven. De Debiteur moet er bij B2B wel zelf voor zorgen dat de machtigingen bij zijn nieuwe bank worden geregistreerd.  

Als alternatief voor de Overstapservice kan de Debiteur gebruik maken van het wijzigingsproces van Incassomachtigen. Daarmee kan elke machtiging afzonderlijk gewijzigd worden. Als hiervan gebruik wordt gemaakt in geval van B2B, dan wordt de machtiging ook direct toegevoegd aan de registratie van de nieuwe Bank van de Debiteur.

...

APPENDIX A: Overzicht van de container inhoud

...

 iDx Bericht

Containerinhoud Nieuwe Incassomachtiging

Containerinhoud Incassomachtiging WijzigingContainerinhoud Incassomachtiging Intrekking

AcquirerTrxReq

pain.009.001.04 

pain.010.001.04pain.011.001.04

AcquirerStatusRes

pain.012.001.04 

AcquirerErrorRes

pain.012.001.04 (Foutbericht versie)

...

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.

...