| Excerpt |
|---|
Version: 1.04 |
Rood: geldt specifiek voor Incassomachtigen Core
Blauw: geldt specifiek voor Incassomachtigen B2B
Voorwaarden
De voorwaarden voor het beschikbaar stellen van de Incassomachtigen Creditor Implementatie Gids zijn:
...
| Expand | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
1.1 DoelgroepDit 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:
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
Referenties 1.3 Conventies met betrekking tot de notatiesBerichten en redirects worden geschreven als dit, en data elementen worden geschreven als 1.4 Definities van online bankierenIn 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
1.6 Wijzigingen in vergelijking met eerdere versiesWijzigingen die zijn doorgevoerd sinds versie 1.02
Wijzigingen die zijn doorgevoerd sinds versie 1.03
|
...
- 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.
...
- Gebruik van bestaande online bankier- en mobiele bankierproducten.
- Communicatie over het Internet.
- Gebruik van open standaarden in de markt, daar waar mogelijk.
- Implementatie van de Creditor met zo min mogelijk complexiteit.
- Maatregelen nemen om betrouwbaarheid te verbeteren, daar waar mogelijk.
- Gebruik van de Multilingual European Subset 2 (MES-2) standaard karakter set.
- Selectie van de Debtor bank (Issuer) door de Debtor op basis van de naam van de Debtor bank.
- Veiligheid en betrouwbaarheid (stabiliteit).
2.2.2 Functionele principes
- 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.FrequencyFrequencyCount en eMandate.MaxAmountFrequencyPeriod 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 deDebtor 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 het bedrijf dat de incasso int. Dit kan de daadwerkelijk Creditor zijn, of een Collecting Payment Service Provider die in naam van de uiteindelijke Creditor de incasso int.
- De Debtor is een consument of een bedrijf met een rekening bij de Debtor bank, van welke de Core/Zakelijke incasso’s worden geïnd.
- De Creditor bank is de bank bij welke de Creditor zijn contract heeft voor het Incassomachtigen product.
- De Debtor bank is de bank waar de Debtor de rekening heeft waarop hij de Incassomachtiging wil afgeven. Deze rekening MOET door de Creditor worden gebruikt voor de automatische incasso.
- Routing Service: Dit is een technische rol (routering van berichten) die wordt vervuld door de Creditor bank zelf, of door een derde partij namens de Creditor bank. Waar in dit document de term ‘Routing Service’ wordt gebruikt, dient dit geïnterpreteerd te worden als ‘Routing Service van de Creditor bank’.
- Validation Service: Dit is een technische rol die vervuld wordt door de Debtor bank zelf of door een derde partij namens de Debtor bank. Waar in dit document de term ‘Validation Service’ wordt gebruikt, dient dit geïnterpreteerd te worden als ‘Validation Service van de Debtor bank’.
...
Functionele Incassomachtigen element namen | XML element namen |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Mapping van Incassomachtigen elementen naar xml elementen
Zoals aangekondigd in de introductie zal dit document slechts ingaan op de berichten die worden uitgewisseld tussen de Creditor en de Routing Service. Echter, de berichten die worden uitgewisseld tussen de Routing Service (van de Creditor bank) en de Validation Service (van de Debtor bank) zullen kort worden toegelicht om een goed inzicht in de algehele transactie te verschaffen.
...
| Section | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
- Door middel van het Directoryprotocol stuurt de Creditor een DirectoryRequest naar de Routing Service. Het DirectoryRequest is een verzoek, in XML formaat, van de Creditor aan de Routing Service om de lijst met aangesloten Debtor banken voor Incassomachtigen op te leveren. De Routing Service levert deze lijst door middel van het DirectoryResponse. De banken die de Creditor in het DirectoryResponse ontvangt toont hij aan de Debtor. De Debtor kiest uit de aangeleverde lijst de Debtor bank waar hij bankiert aan het begin van het Incassomachtigen proces. Het Directoryprotocol wordt in meer detail beschreven in Hoofdstuk 7.
- Door middel van het Transactieprotocol stuurt de Creditor een TransactionRequest naar de Routing Service, waarin onder andere het ID van de gekozen Debtor bank, de mandaatinformatie en andere transactiedetails worden doorgegeven. Dit bericht bevat ook de merchantReturnURL waar de Debtor, na het afronden van de Incassomachtigen-transactie in het Debtor bankdomein, heen wordt geleid om terug te keren naar de website van de Creditor (redirect).
- Nadat de Routing Service het bericht van de Creditor ontvangen heeft, voegt hij enkele van tevoren opgegeven Creditor-details toe aan het bericht en stuurt het bericht door naar de Validation Service van de Debtor bank die door de Debtor geselecteerd is. De Validation Service antwoordt met een bericht dat onder andere de Debtor issuerAuthenticationURL bevat. De Routing Service geeft deze issuerAuthenticationURL samen met een uniek TransactieID via de TransactionResponse terug aan de Creditor, welke een antwoord is op de TransactionRequest.
- De Creditor dient de Debtor nu te redirecten naar de issuerAuthenticationURL, een pagina van het internetbankiersysteem van de Debtor bank. De Debtor komt dan in zijn internetbankieromgeving terecht waar hij verder kan gaan met de Incassomachtigen transactie. De Debtor keurt de Incassomachtiging goed en ontvangt een bevestiging van de Debtor bank. Daarna redirect de Debtor bank de Debtor terug naar de website van de Creditor via de merchantReturnURL. Het Transactieprotocol en de twee redirects worden uitgebreider behandeld in Hoofdstuk 8.
- De Creditor initieert tot slot het Statusprotocol door een StatusRequest te sturen naar de Routing Service. De Routing Service vraagt de status van de transactie, indien nodig, op bij de betreffende Debtor bank en retourneert deze status aan de Creditor. Als de gehele transactie foutloos is verlopen, ontvangt de Creditor in de StatusResponse de Incassomachtiging en de elektronische handtekening. In Hoofdstuk 9 is meer informatie te vinden aangaande het Statusprotocol.
- In plaats van het reguliere response op een van de bovengenoemde requests te leveren, kan er ook een ErrorResponse teruggestuurd worden als een request een fout bevat of als er tijdens de afhandeling van het request een fout optreedt. De ErrorResponse wordt behandeld in Hoofdstuk 10.
Hoofdstuk 5 beschrijft het algemene formaat van Incassomachtigen berichten. In de Hoofdstukken 7, 8 en 9 worden de berichten voor het Directoryprotocol, het Transactieprotocol en het Statusprotocol in detail beschreven.
| Expand | ||
|---|---|---|
| ||
Het stroomdiagram van een Incassomachtigen Mobiel transactie is vrijwel identiek aan de transactieflow van een reguliere Incassomachtigen transactie. Het enige verschil is de automatische redirect naar een landingspagina (op basis van de issuerAuthenticationURL). Op deze pagina kan de Debtor de keuze maken of hij de Incassomachtiging via de (mobiele) website van de Debtor bank of eventueel via de mobiele app van de Debtor bank wil afhandelen.
Schematische representatie van de stappen in een Incassomachtigen Mobiel transactie |
...
4. Functies van de oplossing
Dit hoofdstuk beschrijft de verschillende specifieke functies van de Incassomachtigen oplossing.Alle 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).
...
Het afgeven van een nieuwe Incassomachtiging wordt ondersteund door het gebruik van het ISO pain.009 bericht type. De Creditor vult de mandaatinformatie in het bericht in. Deze informatie wordt vervolgens aangevuld door de Routing Service met de Creditor informatie en door de Validation Service met de Debtor informatie, waarna het complete mandaatverzoek goedgekeurd dient te worden door de Debtor. Na akkoord van de Debtor voegt de Debtor bank een elektronische handtekening toe aan de Incassomachtiging namens de Debtor. De getekende Incassomachtiging wordt vervolgens opgehaald door de Creditor in het Statusprotocol en moet worden gearchiveerd.
...
De Creditor is vrij om intrekkingen van bestaande (papieren) mandaten te accepteren via de Incassomachtigen oplossing.
4.4 Consumentenbeschermingsinstellingen
eMandate.FrequencyFrequencyCount en eMandate.MaximumAmount zijn 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.
...
Alle berichten moeten worden gevalideerd tegen het Incassomachtigen XML Schema (zie Appendix D). Het schema refereert ook naar het XML Digital Signature Schema, welke gebruikt moet worden om het element met de elektronische handtekening te valideren. Het XML Digital Signature Schema is te verkrijgen van W3C via de volgende URL: http://www.w3.org/2000/09/xmldsig#.
...
| Note |
|---|
LET OP: In de pain berichten zijn er elementen waarvoor striktere eisen gelden met betrekking tot het verplicht zijn en het formaat dan gespecificeerd is in de ISO XSD’s. Deze eisen kunnen worden gevonden in de Data Catalogus en in de tabellen die specificeren hoe de ISO berichten gebruikt worden (bijv. in Tabel 13). |
XML Namespace declaratie
...
Attribuut | Verplicht | Toelichting |
|---|---|---|
| Ja | De waarde moet zijn: 1.0.0 |
| 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 | Alle | |
Data element | Sub-element | Formaat | Toelichting waardes | Berichten | |
| DT | ISO-8601 | Alle | ||
|
| DT | ISO-8601 | DirectoryResponse | |
|
| AN..128 | DirectoryResponse | ||
|
|
| ANS..max 11 | BIC, ISO9362 | DirectoryResponse |
|
|
| AN..max 35 | DirectoryResponse | |
|
| AN..max 512 | ErrorResponse | ||
|
| Any | ErrorResponse | ||
|
| CL AN..6 | Zie Appendix B | ErrorResponse | |
|
| AN..max 128 | ErrorResponse | ||
|
| AN..max 256 | ErrorResponse | ||
|
| AN..max 512 | ErrorResponse | ||
|
| AN..max 512 | TransactionResponse | ||
|
| AN..max 512 | Bepaald door de Creditor | TransactionRequest | |
|
| Alle | |||
|
| http://www.w3.org/2001/04/xmldsi g-more#rsa-sha256 | Alle | ||
|
|
| Must be empty | Alle | |
|
|
| http://www.w3.org/2000/09/xmldsi g#enveloped-signature | Alle | |
|
|
| Alle | ||
|
|
| http://www.w3.org/2001/04/xmlen c#sha256 | Alle | |
|
|
| Base64 | Alle | |
| Base64 | Alle | |||
|
| Fingerprint van certificate | Alle | ||
|
| Any | Te vullen met eMandate ISO pain bericht |
| |
|
| ANS..max 40 | Bepaald door de Creditor | TransactionRequest | |
|
| RDT | ISO 8601 - Bepaald door de Creditor | TransactionRequest | |
|
| CL AN..2 | ISO 639-1 - Bepaald door de Creditor | TransactionRequest | |
|
| CL AN..max 9 | Open, Success, Failure, Cancelled, Expired, Pending | StatusResponse | |
|
| DT | ISO 8601 | StatusResponse | |
|
| PN..16 | Bepaald door de Creditor |
| |
|
| DT | ISO 8601 | TransactionResponse | |
...
Nr. | Incassomachtigen naam | Omschrijving | Formaat eisen |
|---|---|---|---|
| 1 |
| Het Creditor adres – regel 1 | Max70Text |
| 2 |
| Het Creditor adres – regel 2 | Max70Text |
| 3 |
| Land van het post adres van de Creditor | [A-Z]{2,2} |
| 4 |
| Direct Debit ID van de Creditor (NL: IncasantID) | Zoals beschreven in AT-02 (Identifier of the Creditor) in de EPC SDD Implementation Guidelines. |
| 5 |
| Naam van de Creditor | Max70Text |
| 6 |
| 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 | Max70Text |
| 7 |
| Datum en tijd | UTC time format (YYYY-MM- DDThh:mm:ss.sssZ), ISO 8601. |
| 8 |
| Naam van de rekeninghouder, wiens rekening wordt gebruikt voor de Incassomachtiging | Max70Text |
| 9 | Debtor.DebtorBankID | BIC van de Debtor Bank, geselecteerd door de Debtor, zoals getoond in de Debtor bank lijst in de DirectoryResponse | BIC (ISO 9362) |
| 10 |
| Debtor’s rekeningnummer | IBAN (ISO 13616) |
| 11 |
| 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 |
| 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 |
| 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 |
| Referentie ID dat de Debtor aan de Creditor identificeert. Wordt afgegeven door de Creditor | Max35Text |
| 15 | eMandate.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 |
| Het maximale bedrag per incasso. Alleen in B2B niet in coreCore | Een bedrag tussen 0.01 en 999999999.99 met nul of twee decimalen. Decimalen worden gescheiden door een punt. |
| 17 |
| 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 | Max35Text |
| 18 |
| Geeft de reden voor de Incassomachtiging aan | Max70Text |
| 19 |
| Indiceert het type Incassomachtiging: eenmalige incasso of terugkerend | 'OOFF' of 'RCUR' |
| 20 | eMandate.TransactionID | De waarde van dit ID wordt overgenomen van Transaction.transactionID transactionID | 16 cijfers |
| 21 |
| Refereert naar het type van het validatieverzoek |
|
| 22 |
| 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 |
| Het nummer van incasso inningen tijdens een specifieke Is niet toegestaan in de huidige implementatie. | Maximum 18 cijfers. Geen decimalen toegestaan |
| 24 | eMandate.FrequencyPeriodCURRENTLY NOT USED | Periode voor het aantal ( Is niet toegestaan in de huidige implementatie | Zie de eMandate.FrequencyPeriod codelijst |
eMandates data elements
...
7. Incassomachtigen Directoryprotocol
7.1 Algemeen
- Het Directoryprotocol heeft als doel de Creditor de actuele lijst met aangesloten Debtor banken te laten ophalen bij zijn Routing Service, zodat deze lijst getoond kan worden aan de Debtor. Het Directoryprotocol zorgt ervoor dat wijzigingen op de Debtor banklijst automatisch in de keuzelijsten van alle Creditors te zien kunnen zijn.
- Het is niet toegestaan het Directoryprotocol voor elke transactie met een Debtor uit te voeren. Aangezien de lijst met Debtor banken slechts sporadisch wijzigt is het voldoende eenmaal per dag de lijst op te halen en op basis van de
directoryDateTimestampte bepalen of de lijst gewijzigd is. De lijst dient, indien deze anders is dan de huidige lijst, opgeslagen te worden en voor alle volgende transacties gebruikt te worden. Routing Services informeren normaliter alle Creditors (bijv. via e-mail) over wijzigingen in de Debtor banklijst. Het Directoryprotocol moet minstens eenmaal per week uitgevoerd worden. - Het Directoryprotocol bestaat (zoals ook het Transactieprotocol en Statusprotocol) uit een HTTP POST request van de Creditor naar de Routing Service waarop hij een HTTP response ontvangt. Het DirectoryRequest wordt verstuurd naar de URL die door de Routing Service voor dit doel aan de Creditor is verstrekt. Dit kan een andere URL zijn dan voor het TransactionRequest en StatusRequest geldt, maar de Routing Service kan hier ook dezelfde URL voor gebruiken.
- De Routing Service controleert de authenticiteit van het bericht van de Creditor door de meegestuurde handtekening te controleren. De Routing Service moet hiervoor beschikken over het gebruikte certificaat van de Creditor met daarin de publieke sleutel. De manier waarop de Creditor het publieke deel van het certificaat met de Routing Service deelt verschilt per bank. Zie Hoofdstuk 11 voor meer informatie omtrent de authenticatie en beveiliging.
7.2 DirectoryRequest
Het DirectoryRequest bestaat uit een XML bericht dat naar de Routing Service verzonden wordt via HTTP POST.
Tabel 10 De tabel hieronder toont alle velden en hun formaat voor het DirectoryRequest:
| Section | ||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Zoals uitgelegd, worden de mandaat-gerelateerde ISO pain berichten in het container element geplaatst. Het ISO bericht is een gestandaardiseerd bericht, en om die reden bevat het ook elementen die niet worden gebruikt in de Incassomachtigen oplossing. In de hierop volgende tabellen worden slechts de verplichte en aan te raden optionele elementen voor de Incassomachtigen oplossing benoemd. De kolommen van de tabellen bevatten de volgende informatie:
- Kolom 1 is de index. Deze index is specifiek voor dit document.
- Kolom 2 geeft de naam van het berichtelement weer zoals gespecificeerd in de ISO 20022 XML standaard, Wanneer een element sub-elementen bevat, zijn deze geïndenteerd en genoteerd met een plusteken minteken (+-) per level.
- Kolom 3 geeft aan of uitleg over de inhoud van een element (wanneer het element Verplicht of Optioneel gevuld is.)
8.2.2 Inhoud van het container element voor nieuwe Incassomachtiging
| Include Page | ||||
|---|---|---|---|---|
|
8.2.3 Inhoud van het container element voor wijzigen bestaande Incassomachtiging
...
De volgende tabel beschrijft welke elementen de Creditor naar de Routing Service stuurt in het TransactionRequest, voor een Incassomachtiging wijziging
| Include Page | ||||
|---|---|---|---|---|
|
8.2.4 Inhoud van het container element voor Incassomachtigen intrekking
...
De volgende tabel beschrijft welke elementen de Creditor naar de Routing Service stuurt in het TransactionRequest, voor een Incassomachtigen intrekking.
Include Page eMandate Cancellations eMandate CancellationsIncassomachtigen Intrekking Incassomachtigen Intrekking
8.3 TransactionResponse
Als de Incassomachtigen transactie goed verloopt reageert de Routing Service op het TransactionRequest met een Transactionresponse. De tabel hieronder toont alle velden die voorkomen in het TransactionResponse bericht. De TransactionResponse heeft geen container, dus bevat dit antwoord geen ISO bericht (dit is anders in geval van een foutbericht, zie Hoofdstuk 10 over foutafhandeling).
...
| Include Page | ||||
|---|---|---|---|---|
|
9.4 Foutsituaties tijdens het uitvoeren van het Statusprotocol
...
errorCode | errorMessage | errorDetail | Komt als Error alleen voor in |
|---|---|---|---|
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 | TransactionResponse | |
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 | ||
| BR1200 | Version number invalid | ||
| BR1205 | ProductID invalid | ||
| BR1210 | Value contains non-permitted character | ||
| BR1220 | Value too long | ||
| BR1230 | Value too short | ||
| BR1270 | Invalid date/time | ||
| BR1280 | Invalid URL | TransactionResponse | |
| AP1100 | MerchantID unknown | ||
| AP1200 | IssuerID unknown | TransactionResponse | |
| AP1300 | SubID unknown | DirectoryResponse TransactionResponse | |
| AP1500 | MerchantID not active | ||
| AP2600 | Transaction does not exist | StatusResponse | |
| AP2920 | Expiration period is not valid | TransactionResponse | |
| AP3000 | eMandates specific error |
...