Div | ||||
---|---|---|---|---|
| ||||
NL/EN |
...
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.
...
- 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 internetbankieren omgeving 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:
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.
...
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
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 | |
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 | |
AP1100 | MerchantID unknown | |
AP1200 | IssuerID unknown | |
AP1300 | SubID unknown | |
AP1500 | MerchantID not active | |
AP2600 | Transaction does not exist | |
AP2920 | Expiration period is not valid | |
AP3000 | eMandates specific error |
...