Excerpt
Version: 1.04 Date: 01-11-2017

Div

style	no-print
class	no-print

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:

...

Vragen over dit document, of verzoeken om meer informatie, kunnen worden gericht aan uw Creditor bank of Payment Service Provider.

...

Inhoud

Expand

title	...

Table of Contents

maxLevel	2
style	none

...

1. Inleiding

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 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

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

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.
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.
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.
De XML-tags zijn toegevoegd in de tabellen met XML elementen in hoofdstuk 8 en 9.
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
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.
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

2.1 Wat is Incassomachtigen?

Incassomachtigen is door de Nederlandse banken ontwikkeld om het online proces voor machtigen te faciliteren. Incassomachtigen biedt de mogelijkheid tot het direct en veilig real-time afgeven en wijzigen van Incassomachtigingen (online machtigingen) door Debtors naar Creditors. Er is niet altijd sprake van real-time tekenen en afgeven in geval van meervoudig ondertekenen bij een specifieke Debtor.

...

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.

...

Expand

title	Incassomachtigen Mobiel

Deelnemende banken zullen ook een mobiele versie van Incassomachtigen implementeren. Dit zal gebaseerd zijn op mobiele bankdiensten zoals mobiele websites en mobiele apps. Dit product zal Incassomachtigen Mobiel gaan heten.

De belangrijkste kenmerken van Incassomachtigen Mobiel zijn:

Er zijn geen veranderingen in de berichten die worden uitgewisseld tussen de Debtor bank en de Creditor bank, en geen veranderingen in de berichten die worden uitgewisseld door de Creditor en zijn bank ten opzichte van reguliere Incassomachtigen;
Creditor en Debtor hoeven geen extra handelingen te verrichten voor het uitvoeren van een mobiele Incassomachtigen-transactie. Het redirecten van de Debtor naar een mobiel bankierkanaal wordt geautomatiseerd gedaan door de Debtor bank. Bij banken die Incassomachtigen in hun bankierapp ondersteunen kan de Debtor kiezen of hij de Incassomachtiging wil goedkeuren via de mobiele web browser of via de bankierapp;
De basis van Incassomachtigen Mobiel is betrouwbaarheid, veiligheid en gebruiksvriendelijkheid, net als op een PC of laptop. In die gevallen waar mobiele technologie niet dezelfde technische veiligheidsmaatregelen ondersteunt als een desktop computer zal de bank alternatieve veiligheidsmaatregelen treffen ter compensatie.

Iedere Debtor die een internetbankierproduct afneemt bij één van de Debtor banken die Incassomachtigen ondersteunen kan gebruik maken van Incassomachtigen via een mobiel apparaat (al zal het in sommige gevallen nodig zijn dat de Debtor hiervoor een mobiele app downloadt). De Debtor banken die (nog) geen Incassomachtigen Mobiel implementatie hebben, of die Incassomachtigen in zoverre hebben geïmplementeerd dat zij nog niet de meerderheid van alle Debtors kunnen bereiken, zullen nog steeds in staat zijn om transacties te verwerken via de reguliere (op desktop-gerichte) Incassomachtigen pagina's op de browser van het mobiele apparaat.

2.2 Ontwerpprincipes

2.2.1 Technische principes

Incassomachtigen is gebaseerd op de volgende technische principes:

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

2.3 Het vier partijenmodel

Het Incassomachtigen systeem is gebaseerd op het vier partijen model. Bijgaande figuur laat de rollen in dit model zien, vergezeld door hun wederzijdse primaire relaties in de context van Incassomachtigen. De rollen zijn die van de Debtor, Creditor, Creditor Bank, Debtor Bank, Routing Service en Validation Service:

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 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’.

2.3.1 De relaties tussen deze rollen

Zowel contractuele als technische relaties bestaan tussen de genoemde rollen. Deze relaties zullen hieronder in meer detail worden toegelicht.

...

Section

Column

width	50%

Contractuele relaties:

Creditor – Creditor bank: De Creditor heeft een Incassomachtigen contract met een Creditor bank. De Creditor moet ook in het bezit zijn van een incassocontract bij dezelfde of een andere Creditor bank.
Debtor – Debtor bank: De Debtor heeft een bankrekening bij de Debtor bank. De identiteit die verbonden is aan deze rekening wordt gebruikt voor het goedkeuren van Incassomachtigingen en vervolgens, weliswaar buiten de scope van de Incassomachtigen oplossing, voor het afhandelen van automatische incasso’s.
Debtor - Creditor: De Debtor mandateert de Creditor door middel van een Incassomachtiging. Dit geeft de Creditor bij machte van de SDD regelgeving permissie om gelden van de rekening van de Debtor’s rekening te innen in een later stadium door middel van een automatische incasso (het uitvoeren van deze incasso valt buiten de scope van de Incassomachtigen oplossing).

Technische relaties:

Creditor – Routing Service: De Creditor heeft een technische relatie met de Routing Service. De Routing Service biedt de Creditor de mogelijkheid om verzoeken voor Incassomachtigingen naar de Validation Service te sturen. In relatie tot dit doel wisselen zij berichten uit.
Routing Service – Validation Service: De Routing Service en de Validation Service hebben een relatie in het kader van de Incassomachtigen oplossing. In relatie tot dit doel wisselen zij berichten uit.
Debtor – Validation Service: De Validation Service biedt de Debtor de mogelijkheid tot het afgeven van Incassomachtigingen aan Creditors, door het goedkeuren van Incassomachtiging verzoeken door middel van een online bankierproduct

Column

width	50%

^{Vier partijen model}

2.4 Terminologie

Incassomachtigen is deels gebaseerd op generieke XML berichten (van de zogeheten iDx standaard), die zijn afgeleid van het iDEAL XML berichtenverkeer. Om informatie over te dragen die Incassomachtigen-specifiek is, worden ISO berichten in een container element geplaatst in deze iDx XML berichten. Omdat de XML berichten enkele afwijkende terminologie en elementnamen hebben, is er een vertaalslag nodig van de XML elementnamen en de functionele namen zoals die binnen Incassomachtigen worden gebruikt.

...

Functionele Incassomachtigen element namen	XML element namen
`Creditor.CreditorBankID`	`Acquirer.acquirerID`
`Debtor.DebtorBankID`	`Issuer.issuerID`
`eMandate.ContractID`	`Merchant.merchantID`
`eMandate.ContractSubID`	`Merchant.subID`
`eMandate.DateTimestamp`	`Transaction.statusDateTimestamp`
`eMandate.TransactionID`	`Transaction.transactionID`

^{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.

Naast de vier genoemde partijen die altijd betrokken zijn bij het uitvoeren van een transactie, kunnen additionele partijen betrokken zijn. De Creditor kan, bijvoorbeeld, gebruik maken van een Service Provider om een technische verbinding te leggen met zijn routing service. Indien een Service Provider de gelden van de Debtor int en deze nadien aan de uiteindelijke Creditor doorstort, spreken we van een ‘Collecting Payment Service Provider’ (CPSP).

3. Incassomachtigen protocol

Section

Column

width	50%

3.1 Algemeen

Een typische Incassomachtigen transactie omvat een (request/response) XML berichtenuitwisseling en twee browser-redirects die zorgen voor het initiëren en het verwerken van een transactie, waarbij alle betrokken partijen geïnformeerd raken over de status van de transactie. De verschillende stappen zijn schematisch weergegeven in de figuur hiernaast.

Er zijn drie request/response paren (ook wel protocollen genoemd) die deel uitmaken van een Incassomachtigen transactie:

Het Directoryprotocol: dit protocol wordt gebruikt om de meest recente lijst van Debtor banken op te vragen van de Routing Service.
Het Transactieprotocol: dit protocol omvat het volledige Incassomachtigen proces van initiatie tot voltooiing.
Het Statusprotocol: dit protocol wordt gebruikt om de status van een transactie op te vragen bij de Validation Service (via de Routing Service). Een StatusResponse met status Sucess bevat de daadwerkelijke Incassomachtiging (pain.012)

Column

width	50%

^{Schematische representatie van de stappen in een Incassomachtigen transactie}

...

Expand

title	Specifieke eisen aan Incassomachtigen Mobiel: Redirect to Debtor bank pagina’s kunnen leiden naar de mobiele app of mobiele website van de Debtor bank

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 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).

4.1 Het afgeven van een nieuwe Incassomachtiging

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.

4.2 Het wijzigen van een bestaande Incassomachtiging

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 staat de Creditor vrij wijzigingen te accepteren op bestaande (papieren) mandaten via de Incassomachtigen oplossing.

4.3 Het intrekken van een bestaande Incassomachtiging

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.

...

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

Voor Incassomachtigen kan het zijn dat meervoudig ondertekenen noodzakelijk is in het Debtor bankdomein. Dit is het geval indien de Debtor gebruik maakt van een zakelijke rekening om de Incassomachtiging goed te keuren. Dit kan niet altijd worden bewerkstelligd in een enkele sessie, wat betekent dat de Debtor bank het Incassomachtigen-verzoek moet bewaren en toegankelijk moet kunnen maken voor goedkeuring in de nabije toekomst. Daarnaast impliceert meervoudig ondertekenen het volgende:

...

De standaardinstelling is dat de Creditor geen waarde invult in het expiratie periode-veld van de transactie. De standaard expiratieperiode is in dat geval 30 minuten.
Wanneer de eerste Debtor inlogt op het Debtor bankdomein binnen 30 minuten, kan de Debtor bank bepalen of meervoudig ondertekenen nodig is. Indien meervoudig ondertekenen inderdaad vereist is, zet de Debtor bank de expiratieperiode automatisch op 7 dagen; in alle andere gevallen blijft de expiratieperiode 30 minuten.
De Creditor mag te allen tijde aannemen dat de expiratieperiode 30 minuten is en kan een Statusverzoek doen nadat deze 30 minuten zijn verstreken (onder de aanname dat het redirecten van de Debtor naar de Creditor website nog niet is gebeurd en dat er nog geen automatische trigger is geweest om de status van de transactie op te vragen).
Indien meervoudig ondertekenen vereist is, verkrijgt de transactie de status ‘Pending’. De Creditor mag in dat geval de status van de transactie iedere dag eenmaal opvragen. Na 7 dagen wordt de status van de transactie definitief ‘Expired’, indien niet alle vereiste ondertekenaars de Incassomachtigen transactie hebben goedgekeurd.
Indien de Creditor de urgente behoefte heeft aan een striktere expiratieperiode, mag hij ervoor kiezen de expiratieperiode aan te passen naar zijn gewenste tijdsframe, met een maximum van 7 dagen en een minimum van 1 minuut. De Debtor bank houdt zich aan deze ingevulde periode (zelfs wanneer meervoudig ondertekenen genoodzaakt is). Een mogelijke consequentie van het opgeven van een expiratieperiode voor Debtors is dat als meervoudig ondertekenen vereist is, zij wellicht niet genoeg tijd hebben om alle ondertekenaars de transactie goed te laten keuren. We raden de Creditors daarom sterk aan om geen specifieke expiratieperiode op te geven.

4.6 Creditor Registratie voor Incassomachtigen

4.6.1 Randvoorwaarden aan de Creditor

Iedere Creditor die gebruik wilt maken van de Incassomachtigen oplossing moet een Incassomachtigen-contract hebben. Als randvoorwaarde voor het krijgen van dit contract moet een Creditor in het bezit zijn van een Incassocontract bij dezelfde of een andere Creditor bank. Slechts nadat is vastgesteld dat de Creditor een incassocontract heeft, kan de Creditor bank een Incassomachtigen-contract aangaan met de Creditor.

...

Het Creditor registratieproces bij de Creditor bank faciliteert de selectie van de juiste Creditor informatie door de Routing Service voor op de Incassomachtiging.

4.6.2 Creditor registratie

Wanneer de Creditor zich registreert bij de Creditor bank voor Incassomachtigen, kent de Creditor bank de Creditor een eMandate.ContractID toe. De Creditor ontvangt ook een eMandate.ContractSubID in geval dit nodig is om onderscheid te kunnen maken tussen de Creditor handelsnamen en/of adressen. 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. De exacte details van het registratieproces worden bepaald door uw Creditor bank en/of de Routing Service die handelt in naam van de Creditor bank.

In het Incassomachigen proces worden het eMandate.ContractID en het eMandate.ContractSubID verzonden naar de Routing Service door de Creditor in het Incassomachtigen-verzoek. De Routing Service voegt vervolgens specifieke Creditor informatie toe aan dit verzoek op basis van het ContractID (en wanneer relevant, ook het SubID). De Routing Service selecteert de juiste Creditor.Name, Creditor.CreditorID, Creditor.TradeName, Creditor.AddressLine1 en Creditor.AddressLine2 om toe te voegen aan het Incassomachtigen-verzoek. Het is de Creditor niet toegestaan om deze elementen van informatie te voorzien.

4.7 Validatie Referentie

Wanneer de Debtor de Incassomachtiging heeft goedgekeurd in het Debtor bankdomein, genereert de Validation Service een referentienummer (ValidationService.ValidationReference). Deze referentie wordt aan de Creditor verstuurd als onderdeel van de Incassomachtiging. Deze referentie moet worden toegevoegd aan de automatische incasso informatie van de Creditor aan zijn Creditor bank. Deze referentie wordt gebruikt door de Debtor bank om de Incassomachtigen validatie informatie op te halen in geval van een dispuut met de Debtor.

4.8 Dispuutmanagement

In geval van een dispuut heeft de Debtor bank de rol om de integriteit en authenticiteit van de Incassomachtiging te verifiëren. In geval van een dispuut (MOI) geldt daarom:

De Creditor moet óf het ISO pain.012 bericht, dat de eigenlijke Incassomachtiging vormt, aanleveren in exclusively canonicalized vorm, óf het hele XML bericht aanleveren dat in de StatusResponse is ontvangen. Daarnaast moet ook andere additionele wijzigingsinformatie aangeleverd worden, in het geval er een wijziging is geweest op het mandaat buiten het Incassomachtigen protocol om. Een voorbeeld van dergelijke informatie is het bericht dat u ontvangt van uw bank wanneer één van uw klanten door middel van de overstapservice is gewisseld van bank.
De Creditor stuurt deze informatie per mail naar de Creditor bank. De Creditor bank stuurt deze informatie door naar de Debtor bank.
De Debtor bank gebruikt de certificaatinformatie om de elektronische handtekening te verifiëren, zodat de integriteit en authenticiteit van de Incassomachtiging kunnen worden vastgesteld.

...

5. Incassomachtigen Bericht Formaat

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.

Conventies voor lege velden

In het Incassomachtigen scheme zijn de XML tags voor een optioneel of conditioneel veld:

...

Note
Een uitzondering op deze regel is dat er verscheidene verplichte tags in de ISO pain berichten zijn, die aanwezig moeten zijn zelfs als ze leeg zijn.

Berichtvalidatie

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.

XML Namespace declaratie

De namespace voor alle berichten is als volgt:

...

Alle instanties van berichten moeten deze namespace declareren. Namespace declaratie kan worden gedaan in elke manier die wordt toegestaan door de XML standaard (standaard namespace declaratie of namespace kwalificatie/prefixes). Alle partijen moeten in staat zijn om berichten te ontvangen en verwerken met beide namespace declaratiemethodes.

Berichtattributen

Alle XML berichten bevatten de volgende attributen in het root element, zoals gespecificeerd in de volgende tabel:

...

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

...

6. Incassomachtigen Data Catalogus

Dit hoofdstuk beschrijft de data elementen en de ID’s van de Incassomachtigen oplossing.

6.1 Incassomachtigen ID’s

De Incassomachtigen oplossing maakt gebruik van identifiers zoals beschreven in tabel hieronder.

Nr.	Element	Omschrijving	Berichten	Formaateisen
1	`Creditor.CreditorBankID`	Creditor bank identificatie nummer	Alle Response berichten	4 cijfers
2	`Debtor.DebtorBankID`	Het ID (BIC) van de Debtor bank geselecteerd door de Debtor, zoals getoond in de Debtor bank lijst in de DirectoryResponse	TransactionRequest	BIC (ISO 9362)
3	`eMandate.ContractID`	Het Incassomachtigen Contract registratie nummer van de Creditor. Dit unieke ID identificeert de Creditor naar de Creditor bank in de context van het contract dat zij hebben voor de Incassomachtigen service.	Alle Request berichten	10 cijfers: Uniek 4-cijferig `Creditor.CreditorBankID`, gecombineerd met een unieke combinatie van zes nummers (afgegeven door de Creditor bank).
4	`eMandate.ContractSubID`	Incassomachtigen contract registratie nummer Sub van de Creditor. Het unieke SubID stelt de naam en het adres vast van de Creditor voor gebruik in de Incassomachtiging.	Alle Request berichten	Een nummer van 0 tot en met 999999 waarbij elke waarde is gerelateerd tot een aparte instantie welke geregistreerd staat bij de Creditor bank. De standaard waarde is ‘0’.

^{Incassomachtigen ID’s}

6.2 Generieke data elementen

Tabel hieronder bevat alle XML data elementen die voorkomen in de berichten die relevant zijn voor de Creditor, samen met de informatie die betrekking heeft op het formaat en de toegestane waardes.

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	DirectoryResponseDirectoryRes
`Directory`	`countryNames`		AN..128		DirectoryResponseDirectoryRes
`Directory`	`Issuer`	`issuerID`	ANS..max 11	BIC, ISO9362	DirectoryResponseDirectoryRes
`Directory`	`Issuer`	`issuerName`	AN..max 35		DirectoryResponseDirectoryRes
`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		TransactionResponseTransactionRes
`Merchant`	`merchantReturnURL`		AN..max 512	Bepaald door de Creditor	TransactionRequestTransactionReq
`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`		Must be empty	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	TransactionRequestTransactionReq StatusResponseStatusRes
`Transaction`	`entranceCode`		ANS..max 40	Bepaald door de Creditor	TransactionRequestTransactionReq
`Transaction`	`expirationPeriod`		RDT	ISO 8601 - Bepaald door de Creditor	TransactionRequestTransactionReq
`Transaction`	`language`		CL AN..2	ISO 639-1 - Bepaald door de Creditor	TransactionRequestTransactionReq
`Transaction`	`status`		CL AN..max 9	Open, Success, Failure, Cancelled, Expired, Pending	StatusResponseStatusRes
`Transaction`	`statusDateTimestamp`		DT	ISO 8601	StatusResponseStatusRes
`Transaction`	`transactionID`		PN..16	Bepaald door de Creditor	TransactionResponseTransactionRes StatusRequestStatusReq StatusResponseStatusRes
`Transaction`	`transactionCreate DateTime stamp`		DT	ISO 8601 Bepaald door de Routing Service Provider	TransactionResponseTransactionRes

Expand

title	Gebruikte data formaten in de data catalogus

Notatie	Betekenis
AN	Alfanumeriek, vrije tekst
ANS	Alfanumeriek, strikt (slechts letters en nummers)
N	Numeriek
PN	Numeriek (padded), de waardes worden aangevuld tot de maximale lengte met nullen
..max #	Maximaal aantal posities voor alfanumerieke/numerieke waardes
..#	Vast aantal posities voor alfanumerieke/numerieke waardes
CL	Codelijst, opgesomd
DT	Datum/tijd veld in UTC (geen zomertijd): YYYY-MM-DDThh:mm:ss.sssZ In berichten afkomstig van de Routing Service Provider zal de waarde altijd tot op de milliseconde nauwkeurig gevuld zijn. Creditors hoeven zelf niet aan deze eis te voldoen, zij mogen na de secondes nul tot drie decimalen meegeven. YYYY verwijst naar het kalenderjaar hh is in 24 uurs notatie, 12 uurs notatie is niet toegestaan
RDT	Relatief datum/tijd veld: PnYnMnDTnHnMnS
DEC(#1,#2)	Decimaal, #1 totale cijfers, #2 decimalen: DEC(6,2) kan 1234.56 zijn bijvoorbeeld

^{Gebruikte data formaten in de data catalogus}

...

Expand

title	Frequency (niet mogelijk in de huidige implementatie)

Frequency wordt gedefinieerd als het aantal incasso’s per periode voor een specifiek eMandateID. In het Incassomachtigen bericht wordt dit aangegeven middels een specifiek nummer (eMandate.FrequencyCount) en een periode (eMandate.FrequencyPeriod).

De volgende tabel toont de codes die gebruikt kunnen worden om de periode van incasso’s aan te geven. Let op: Aangezien Frequency niet gebruikt mag worden in deze implementatie van Incassomachtigen, kan de codelijst met toegestane periodes en definities in Tabel 9 aangepast worden nadat besloten is dat Frequency gebruikt zal worden.

eMandate.FrequencyPeriod Code	Definitie
ADHO	Evenement vindt plaats op verzoek of indien nodig
DAIL	Evenement vindt iedere dag plaats
FRTN	Evenement vindt iedere twee weken plaats
INDA	Evenement vindt meerdere keren per dag plaats
MIAN	Evenement vindt elke zes maanden plaats of twee keer per jaar
MNTH	Evenement vindt plaats iedere maand of een keer per maand
QURT	Evenement vindt iedere drie maanden plaats of vier keer per jaar
WEEK	Evenement vindt eenmaal per week plaats
YEAR	Evenement vindt eenmaal per jaar plaats of ieder jaar

^{eMandate.FrequencyPeriod codes}

...

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 directoryDateTimestamp te 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.

...

Section

Column

width	675px

Velden van het DirectoryRequest

Naam	Omschrijving	Formaat
`createDateTimestamp`	Datum en tijd waarop het DirectoryRequest is gecreëerd.	DT
`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..max6
`SignedInfo`	Bevat informatie over de digitale handtekening conform de W3C XMLdsig specificaties. Zie Hoofdstuk 11 voor meer informatie	*
`SignatureValue`	Bevat de digitale handtekening conform de W3C XMLdsig specificaties. Zie hoofdstuk 11 voor meer informatie	*
`KeyInfo`	Bevat informatie (fingerprint) over het certificaat dat gebruikt is voor het genereren van de meegestuurde digitale handtekening, zodat de ontvanger de juiste public key kan gebruiken voor validatie van de handtekening conform de W3C XMLdsig specificaties. Zie hoofdstuk 11 voor meer informatie	*

_{*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

style	padding-left: 1cm
class	no-print

Column

width	100%

Insert excerpt

	iDx DirectoryReq (A)
	iDx DirectoryReq (A)
nopanel	true

7.3 DirectoryResponse

De Creditor ontvangt de DirectoryResponse als antwoord op de DirectoryRequest. Dit XML bericht bevat een lijst met namen van Debtor banken met hun bijbehorende Debtor bank ID (BIC). Debtor banken zijn gegroepeerd per land. De banken in het voorkeursland van de Creditor mogen bovenaan in de Debtor bank selectielijst worden getoond, de overige banken worden getoond op alfabetische volgorde van landsnaam en vervolgens van bank naam. De tabel hieronder toont alle velden en hun formaat voor het DirectoryResponse:

Section

Column

width	675px

Velden van het DirectoryResponse

Naam	Omschrijving	Formaat
`createDateTimestamp`	Datum en tijd waarop het response bericht gecreëerd is.	DT
`acquirerID`	Uniek kenmerk van 4 cijfers van de Creditor Bank (`Creditor.CreditorBankID`) binnen Incassomachtigen.	PN..4
`directoryDateTimestamp`	Tijd die aangeeft wanneer de Directory voor het laatst gewijzigd is door de Routing Service	DT
`countryNames`	Bevat de landnamen in de officiële talen van de betreffende landen, gescheiden door een “/” symbool (bijv. ‘België/Belgique’). Landnamen hoeven alleen getoond te worden in de lijst met Debtor banken als er banken van meer dan één land in de lijst staan. Als alle banken in de lijst uit hetzelfde land komen, hoeft de landsnaam niet te worden getoond.
`issuerID`	Bank Identificatie Code (BIC) van de Incassomachtigen Debtor bank. `Debtor.DebtorbankID`	ANS..max 11
`issuerName`	De naam van de Debtor bank (zoals deze getoond moet worden aan de Debtor in de Debtor bank lijst van de Creditor).	AN..max 35
`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

style	padding-left: 1cm
id	no-print
class	no-print

Column

width	100%

Insert excerpt

	iDx DirectoryRes (A')
	iDx DirectoryRes (A')
nopanel	true

7.4 Presentatie van de Debtor bank selectie lijst

Section

Column

width	50%

Om ervoor te zorgen dat een Incassomachtigen transactie voor de Debtor altijd op dezelfde wijze verloopt, dienen alle Creditors de volgende presentatie aan te houden:

Alle Debtor banken uit de DirectoryResponse moeten worden getoond in een “dropdown listbox”. Het eerste element van deze lijst is “Kies uw bank...”; dit is ook het element dat voorgeselecteerd is. Vervolgens wordt de landsnaam van het voorkeursland van de Creditor getoond (ofwel het land waar de Creditor is gevestigd ofwel het land waar de Debtor (vermoedelijk) vandaan komt). De namen van alle Debtor banken uit het voorkeursland worden vervolgens getoond in afzonderlijke elementen, in dezelfde (alfabetische) volgorde als gehanteerd in de DirectoryResponse. Daarna worden de namen van andere landen en de bijbehorende Debtor banken getoond, ook weer in dezelfde (alfabetische) volgorde als in de DirectoryResponse. De Creditor moet een foutmelding genereren indien de Debtor een van de elementen “Kies uw bank...” of een landnaam kiest.

Het is aan te bevelen het HTML “value” veld van de items in de listbox in te stellen op de Debtor bankID (BIC) van de betreffende Debtor bank, omdat deze nodig is in vervolgberichten. Een voorbeeld van een Debtor bankselectielijst is te vinden in het figuur hieronder.

Column

width	50%

^{Voorbeeld van een (open) dropdown list box welke de Debtor bank lijst laat zien}

...

Indien de Creditor middels het eMandate Notification System (Centraal Meldpunt voor Incassomachtigen banken om onbeschikbaarheid te melden) of via vanuit de Creditor bank ontvangen foutmeldingen heeft vastgesteld dat een bepaalde Validation Service niet beschikbaar is, kan de Creditor een melding tonen aan de Debtor op zijn website dat de betreffende bank op dat moment niet beschikbaar is. Een dergelijke melding tonen is dus toegestaan; het uitgrijzen of tijdelijk verwijderen van de Debtor bank uit de Debtor bankselectielijst is dat niet.

...

8. Incassomachtigen Transactieprotocol

8.1 Algemeen

Het Transactieprotocol initieert het berichtenverkeer van het daadwerkelijke Incassomachtigen proces. Nadat de Debtor voor Incassomachtigen als betaalmethode heeft gekozen en zijn Debtor bank heeft geselecteerd, stuurt de Creditor een TransactionRequest naar zijn Routing Service. Binnen de Standaard wordt dit bericht aangeduid als het AcquirerTransactionRequest. De Routing Service beantwoordt het TransactionRequest met een TransactionResponse. Deze bevat onder andere de IssuerAuthenticationURL waarheen de browser van de Debtor moet worden geredirect om de Debtor de Incassomachtiging te laten autoriseren.

8.2 TransactionRequest

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

width	675px

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

style	padding-left: 1cm
class	no-print

Column

width	100%

Insert excerpt

	iDx AcquirerTrxReq (B)
	iDx AcquirerTrxReq (B)
nopanel	true

8.2.1 Container inhoud

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 minteken (-) per level.
Kolom 3 geeft uitleg over de inhoud van een element (wanneer het element gevuld is)

8.2.2 Inhoud van het container element voor nieuwe Incassomachtiging

Include Page

	Incassomachtigen Initiatie request van Creditor aan Routing Service
	Incassomachtigen Initiatie request van Creditor aan Routing Service

8.2.3 Inhoud van het container element voor wijzigen bestaande Incassomachtiging

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).

...

Include Page

	Incassomachtigen 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).

Section

Column

width	675px

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
`transactionCreateDate Timestamp`	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

style	padding-left: 1cm
class	no-print

Column

Insert excerpt

	iDx AcquirerTrxRes (B')
	iDx AcquirerTrxRes (B')
nopanel	true

8.4 Fouten bij het uitvoeren van het Transactieprotocol

Bij de uitvoering van het Incassomachtigen Transactieprotocol kan een aantal foutsituaties optreden. Deze kunnen te maken hebben met onbeschikbaarheid binnen uw webwinkel omgeving (Creditor), de Routing Service omgeving of de Validation Service omgeving.

...

In alle bovenstaande gevallen, kan het Transactieprotocol niet succesvol worden uitgevoerd. Dit betekent dat het niet mogelijk is voor de Incassomachtigen transactie om plaats te vinden op dat moment. Foutafhandeling wordt in meer detail besproken in Hoofdstuk 10.

8.5 Redirect naar de online bankieromgeving (issuerAuthenticationURL)

Na het ontvangen van de TransactionResponse dient de Creditor de Debtor door te sturen (Engels: “redirect”) naar de issuerAuthenticationURL van de gekozen bank, zoals die in de TransactionResponse is ontvangen. Als de pagina is opgebouwd met behulp van HTML-frames dan zullen deze door de Debtor bank verwijderd worden (“frame-busting”). Na terugkomst op de website van de Creditor (middels de merchantReturnURL) zal de Creditor ervoor moeten zorgen dat de frames weer opgebouwd worden voor het tonen van de orderbevestiging.

...

Expand

title	8.5.1 Specifieke eisen aan Incassomachtigen Mobile: Redirect naar de Issuer (geen in-app browser)

De Creditor is verantwoordelijk voor het redirecten van de Debtor, vanaf de (mobiele) web pagina of app van de Creditor, naar de Debtor bank, waar de Debtor zijn/haar Debtor bank selecteert. Als het bij het doorsturen niet mogelijk is de Debtor in dezelfde web pagina te houden moet dit worden gecommuniceerd met de Debtor (bijvoorbeeld: "U zal nu worden doorgestuurd naar de app of (mobiele) website van uw bank").

In het geval dat een Incassomachtigen transactie wordt geïnitieerd vanuit de mobiele Creditor app is het niet toegestaan de Debtor bank schermen te tonen in de app omgeving van de Creditor middels 'in-app-browsing' (web-view). Alle stappen van de transactieflow, tot aan de redirect terug naar de Creditor, moeten doorlopen worden in een omgeving die door de Debtor vertrouwd wordt. Dit kan de voorkeurs-web-browser zijn, die door de consument gekozen is, of de mobiele app van de Debtor banken. De issuerAuthenticationURL moet daarom altijd voor uitvoering aan het mobiele OS worden aangeboden. Gedurende de opgestarte transactieflow mag het voor de Debtor niet mogelijk zijn een andere transactie te initiëren in de app van de Creditor.

Relevante details over deze redirect van de Creditor naar het mobiele kanaal van de Debtor bank:

De Debtor bank bepaalt welke Debtors worden omgeleid naar welk kanaal. Sommige Debtor banken kunnen bijvoorbeeld gebruikers van een tablet op dezelfde manier behandelen als gebruikers van een smartphone, terwijl andere banken tablet gebruikers zullen behandelen zoals reguliere PC gebruikers;
De Creditor heeft geen invloed op de redirect, er is maar één issuerAuthenticationURL voor gebruik in alle transacties, dus geen aparte URL voor mobiele Incassomachtigen transacties;
Als de Debtor bank Incassomachtigen mobiel heeft geïntegreerd in haar mobiel bankieren app zal de Debtor, op de 'landing page' van de Debtor bank, de mogelijkheid geboden worden de mobiel bankieren app te openen of verder te gaan via de (mobiele) web pagina. Op de 'landing page' kan de Debtor ook de mogelijkheid geboden worden de nieuwste versie van de mobiel bankieren app te downloaden voor het geval deze nog niet geïnstalleerd is op het mobiele apparaat van de Debtor.

8.6 Redirect naar de Creditor omgeving (merchantReturnURL)

Nadat de Debtor de interactie met de Debtor bank heeft doorlopen, biedt de Debtor bank hem een ‘Doorgaan’ knop aan die hem moet terugleiden naar de website van de webwinkelier, middels de merchantReturnURL die de Creditor heeft opgegeven in de TransactionRequest.

...

Note

Let op dat een Debtor niet altijd gebruik zal maken van de knop die door de Debtor bank wordt aangeboden om terug te keren naar de omgeving van de Creditor bank. Let ook op dat in uitzonderlijke gevallen de Creditor bank mogelijk niet in staat is de transactionID te vinden in zijn systemen of er andere storingen optreden, die het onmogelijk maken om de Debtor terug te leiden naar de Creditor. In alle andere gevallen wordt de Debtor terug geleid met de complete URL inclusief parameters zoals hierboven beschreven, ongeacht de eindstatus van de transactie (succes, afgebroken, verlopen). De Creditor moet vervolgens het Statusprotocol gebruiken (zie het volgende hoofdstuk) om de status van de transactie vast te stellen.

8.6.1 Eisen voor Incassomachtigen Mobiel: redirect naar de Creditor omgeving.

Nadat de Debtor geauthentiseerd is door de Debtor bank in ofwel de mobiele ofwel het reguliere kanaal, en de Incassomachtiging door de Debtor is goedgekeurd, zal hij worden terug geleid naar de Creditor door middel van de merchantReturnURL. De merchantReturnURL begint normaalgesproken met 'https' en dit zorgt ervoor dat de Debtor wordt terug geleid naar een web pagina van de browser op het mobiele apparaat. Als de Debtor de transactie geïnitieerd heeft vanaf de Mobiele Creditor App kan de merchantReturnURL beginnen met de app handler van de Merchant, die de Debtor doorstuurt naar de app van de Creditor. Een app handler is een mechanisme dat ervoor zorgt dat vanuit de ene app (van de Debtor bank) een andere app gestart wordt en er een bepaalde actie uitgevoerd wordt. Een Creditor app handler kan bijvoorbeeld starten met 'nl.companyname://' en hiermee wordt de Creditor app geopend.

...

Per e-mail.
Op uw website, bijvoorbeeld in het account van de Debtor of via de browsersessie van de Debtor.

8.8 Vier scenario’s voor het afronden van een mobiele Incassomachtigen transactie

Om een overzicht te geven van alle mogelijke processtappen en belangrijke opmerkingen met betrekking tot mobiele Incassomachtigen transacties, hebben we vier verschillende scenario’s gespecificeerd. Er zijn vier verschillende scenario’s omdat de Debtor bank, de Creditor of beiden gebruik kunnen maken van een (mobiele) web pagina of een mobiele app.

...

Expand

title	In dit overzicht worden specifieke aandachtspunten voor de Creditor gegeven per scenario aan de hand van de stappen in het Incassomachtigen mobiel proces

Stap	Beschrijving	Scenario 1 - Creditor (mobiele) web page naar Debtor bank *(mobiele) web page*	Scenario 2 - Creditor (mobiele) web page *naar Debtor bank Mobiel Bankieren App*	Scenario 3 - Creditor mobiele app naar Debtor bank *Mobiel Bankieren App*
1	De Debtor selecteert het item wat hij wil kopen, selecteert Incassomachtigen als betaalmiddel en selecteert zijn/haar Debtor bank.
2	De Debtor wordt doorgestuurd naar de Debtor bank van zijn/haar keuze.			Het is verplicht voor de Creditor om het Operating System (OS) van het mobiele apparaat de issuerAuthenticationURL te laten afhandelen of gebruik te maken van de veilige in app browsingtechnieken SafariViewController en Chrome Custom Tabs. Zie paragraaf 5.5 voor meer informatie.
3	De Debtor bank leidt de consument automatisch door naar de mobiel bankieren app (stap 4 vervalt dan) of presenteert de 'landing page' met daarin de optie de Incassomachtiging af te ronden in de Debtor bank's Mobiel Bankieren App of (mobiele) web pagina.
4	De Debtor selecteert de Mobiel Bankieren App of de (mobiele) web pagina van de Debtor bank
5	De Debtor wordt doorgestuurd naar de Mobiel Bankieren App of (mobiele) web pagina van de Debtor bank waar hij kan inloggen en de Incassomachtiging kan autoriseren. Nadat de machtiging is afgerond wordt het resultaat van de betaling door de Debtor bank getoond aan de Debtor.
6	De Debtor wordt door de Debtor bank terug geleid naar de app of web pagina van de Creditor. Hiervoor wordt gebruik gemaakt van de MerchantReturnURL die meegegeven is door de Creditor.		Aangezien de betaling plaatsvindt in de Mobiel Bankieren App van de Debtor bank, buiten de web browser setting, kan het zijn dat de browser sessie verloren gaat. Dit betekent dat de Credtior niet in staat is de Consument te herkennen aan de hand van de browser sessie. Daarnaast wordt de merchantReturnURL, bij het terugleiden van deDebtor bank Mobiel Bankieren App naar de Creditor, afgehandeld door het Operating System (OS) van het mobiele apparaat. Het OS kiest de als standaard ingestelde web browser voor de afhandeling van deze URL. Als de Incassomachtigen transactie was gestart in een andere, niet standaard ingestelde web browser, gaat deze originele browser sessie verloren.
7	De Creditor laat het resultaat van de Incassomachtiging zien aan de Debtor.	De `merchantReturnURL` begint normaal gesproken met https:// en bevat twee parameters (`entranceCode` en `transactionID`) die gebruikt kunnen worden voor de correcte identificatie van de Debtor als deze terug geleid is naar de Creditor.		De `merchantReturnURL` bevat een app handler en twee parameters (`entranceCode` en `transactionID`) die gebruikt kunnen worden voor de correcte identificatie van de Debtor als deze terug geleid is naar de Creditor. Daarnaast is het ook mogelijk gebruik te maken van Universal Links (iOS) of Android App Links technieken om de Debtor direct terug naar de Creditor app terug te leiden.

8.9 Verwerkingssnelheid en time-out van transactieberichten

De verwerkingssnelheid van de systemen van de Debtor bank en de Routing Service heeft een directe invloed op de gebruikerservaring van de Debtor. Daarom schrijft Incassomachtigen een streeftijd en een time-out periode voor de transactie responseberichten voor. De voor een Creditor relevante streeftijd en time-out periode hebben betrekking op de communicatie met zijn Incassomachtigen Routing Service:

...

* 95^ste percentiel is een term uit de statistiek die aangeeft dat 95% van de transacties in een steekproef binnen de gestelde streeftijd moeten vallen.

8.10 Specifieke eis voor Incassomachtigen Mobiel: Print of e-mail een bevestigingsbericht

Na een succesvolle Incassomachtigen transactie moet de Debtor bank de Debtor altijd de optie geven om de bevestiging van de Incassomachtiging te printen. In een mobiele omgeving zal afdrukken echter vaak niet mogelijk zijn, daarom wordt deze eis uitgebreid met alternatieven zoals het via e-mail ontvangen van een bevestiging of het ontvangen van een bevestiging in de internetbankieromgeving.

...

9. Incassomachtigen Statusprotocol

9.1 Algemeen

Om na te gaan of een transactie is geslaagd, start de Creditor het Statusprotocol door het versturen van een StatusRequest naar de Routing Service. In de Incassomachtigen Standaard wordt dit bericht aangeduid als het AcquirerStatusRequest.

Om onnodige belasting van systemen te voorkomen, mogen statusverzoeken niet ongelimiteerd worden gedaan; zie paragraaf 9.5 voor meer details over wat is toegestaan. Het statusprotocol kan gestart worden bij terugkeer van de Debtor op de website van de Creditor (na de redirect door de Debtor bank) of bijvoorbeeld 5 of 10 minuten na het verlopen van de standaard expiratieperiode van 30 minuten van de transactie (expiration period). Zoals uitgelegd in paragraaf 4.2 over meervoudig ondertekenen, moet de Incassomachtiging nog door andere Debtors worden ondertekend in geval de status van de transactie op ‘Pending’ staat. De Creditor mag in dat geval het Statusprotocol dagelijks uitvoeren. Als de Incassomachtiging niet compleet is goedgekeurd binnen 7 dagen, dan wordt de status gewijzigd naar ‘Expired’ door de Validation Service.

9.2 StatusRequest

Tabel hieronder bevat alle velden die onderdeel zijn van het StatusRequest XML bericht. De Creditor stuurt dit bericht naar de Routing Service. Zie paragraaf 7.2 voor meer informatie over de afkortingen in de kolom ‘Formaat’.

Section

Column

width	675px

_{Velden van het StatusRequest}

Naam	Omschrijving	Formaat
`createDateTimestamp`	Datum en tijd waarop de StatusRequest gecreëerd is.	DT
`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. Op de Incassomachtiging wordt dit weergegeven als: 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
`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).	PN..16
`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

style	padding-left: 1cm
class	no-print

Column

width	100%

Insert excerpt

	iDx AcquirerStatusReq (F)
	iDx AcquirerStatusReq (F)
nopanel	true

9.3 StatusResponse

Het antwoord op het StatusRequest is de StatusResponse. Dit bericht is gemaakt door de Validation Service en wordt door de Routing Service naar de Creditor gestuurd. De StatusResponse bevat de velden die worden getoond in Tabel 23. Dit bericht communiceert de status van de transactie (gerelateerd aan het TransactionID welke was verzonden in het StatusRequest) aan de Creditor. Indien de status “Success” is, wordt het containerelement bijgesloten in de response. In het containerelement bevinden zich de goedgekeurde Incassomachtiging (het ISO pain.012 bericht) en de elektronische handtekening op de Incassomachtiging.

...

Section

Column

width	675px

_{Velden van de StatusResponse}

Naam	Omschrijving	Formaat
`createDateTimestamp`	Datum en tijd waarop de StatusResponse gecreëerd is.	DT
`acquirerID`	Uniek kenmerk van 4 cijfers van de Routing Service binnen Incassomachtigen.	PN..4
`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.	PN..16
`status`	Geeft aan of de Incassomachtigen transactie geslaagd is of dat het resultaat één van de volgende onderstaande andere statussen is. Success: Positief resultaat, de Incassomachtiging is goedgekeurd door de Debtor. Cancelled: Negatief resultaat door annulering door Debtor, de transactie is niet uitgevoerd. Expired: Negatief resultaat door verlopen van geldigheid van de transactie (expiratieperiode is verlopen). De transactie is niet uitgevoerd Failure: Negatief resultaat door andere reden; de transactie is niet uitgevoerd. Open: Resultaat nog niet bekend. Er is een nieuwe StatusRequest nodig om de definitieve status te achterhalen. Pending: De transactie is nog niet afgerond en is in afwachting van meervoudige ondertekening. De status kan dagelijks worden opgevraagd.	CL AN..max9
`statusDateTimestamp`	Aanwezig indien Status = Success, Cancelled, Expired or Failure (niet aanwezig als de status ‘Open’ of ‘Pending’ is) Datum en tijd waarop de Debtor bank de Transaction.status voor deze transactie heeft vastgesteld en geregistreerd als onderdeel van de transactiedetails.	DT
`container`	Indien Transaction.status ‘Success’ is, wordt dit veld toegevoegd in de StatusResponse. Voor alle andere waardes van Transaction.status, wordt dit veld niet toegevoegd. Indien dit veld wordt toegevoegd, bevat deze de daadwerkelijke Incassomachtiging, bestaande uit het Incassomachtigen ISO bericht en de elektronische handtekening van de Validation Service. Beiden moeten worden gearchiveerd door de Creditor.
`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

style	padding-left: 1cm
class	no-print

Column

width	100%

Insert excerpt

	iDx AcquirerStatusRes (F')
	iDx AcquirerStatusRes (F')
nopanel	true

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

9.4 Foutsituaties tijdens het uitvoeren van het Statusprotocol

Bij het navragen van de Incassomachtiging status door middel van het Statusprotocol kunnen foutsituaties optreden waardoor de status van de Incassomachtigen transactie op dat moment niet door u kan worden opgehaald. De eindstatus van de transactie kan op dat moment dus niet aan de Debtor worden getoond.

...

Per e-mail.
Op uw website, bijvoorbeeld in het account van de Debtor of via de browsersessie van de Debtor.

9.5 Haalplicht

De Creditor dient een StatusRequest uit te voeren wanneer de Debtor terecht komt op de pagina waarnaar hij is geredirect door de Debtor bank (de merchantReturnURL uit het TransactionRequest). Het kan echter zo zijn dat de Debtor zijn browser-window sluit voordat hij terugkeert op de merchantReturnURL-pagina. De Creditor moet ook in dat geval een StatusRequest voor de transactie uitvoeren. Er geldt een zogenaamde “haalplicht” t.a.v. het resultaat van de transactie. Aan deze haalplicht kan voldaan worden door voor elke transactie het StatusRequest uit te voeren als de expiratieperiode (opgegeven in de TransactionRequest of 30 minuten indien geen waarde voor dit veld is ingevuld) is verstreken en er nog geen definitieve status verkregen is.

...

Indien de eindstatus "Success" is, kan de Creditor m.b.v. de bewaarde ordergegevens overgaan tot levering van het bestelde product. Als de klant op een niet reguliere wijze (bijvoorbeeld met de ‘Terug’ knop van de browser), terug komt op de website van de Creditor en opnieuw ervoor kiest om met Incassomachtigen te betalen, dient de Creditor hiervoor een nieuw Incassomachtigen transactieverzoek in te sturen, nadat hij eerst geprobeerd heeft om een eindstatus van de eerder ingestuurde Incassomachtigen transactie op te vragen.

9.6 Verwerkingssnelheid en time-out van statusberichten

De verwerkingssnelheid van de systemen van de Debtor bank en de Routing service heeft een directe invloed op de gebruikerservaring van de Debtor. Daarom schrijft Incassomachtigen een streeftijd en een time-out periode voor de status responseberichten voor. De voor een Creditor relevante streeftijd en time-out periode hebben betrekking op de communicatie met zijn Incassomachtigen Routing Service:

...

* 95^ste percentiel is een term uit de statistiek die aangeeft dat 95% van de transacties in een steekproef binnen de gestelde streeftijd moeten vallen.

...

10. Foutafhandeling

10.1 Algemeen

Als er iets fout gaat bij de verwerking van een DirectoryRequest, TransactionRequest of StatusRequest, bijvoorbeeld omdat het request een foutieve waarde bevat, wordt er geen normale response teruggegeven. In plaats daarvan komt er een ErrorResponse bericht terug. Deze ziet er voor alle drie de request typen hetzelfde uit.

10.2 ErrorResponse

In plaats van een normale response (DirectoryResponse, TransactionResponse of StatusResponse) zal de Routing Service een ErrorResponse terugsturen als het door de Creditor verstuurde request bij ontvangst of bij de verwerking ervan een fout optreedt. In Tabel 26 staan de velden opgesomd die voorkomen in een ErrorResponse. De foutcodelijst, errorDetails en consumerMessages kunnen worden gevonden in APPENDIX B.

...

Expand

title	Pain.012 error response acceptance report tabel......

Include Page

	Incassomachtigen Error response Acceptance report
	Incassomachtigen Error response Acceptance report

10.3 Onbeschikbaarheid

Het kan zijn dat één van de Debtor banken tijdelijk niet beschikbaar is. Transacties voor die Debtor bank zullen dan een ErrorResponse opleveren (paragraaf 10.2). Nadat een Routing Service heeft vastgesteld dat er sprake is van een onbeschikbaarheid zal hij dit doorgeven aan de betreffende Debtor bank. Een Creditor heeft dus nooit rechtstreeks contact met een Debtor bank.

...

Per e-mail.
Op uw website, in het account van de Debtor.
Op uw website, als onderdeel van de sessie-informatie van de bestelling.

...

11. Beveiliging en certificaten

11.1 Algemene principes van certificaten

Bij asymmetrische encryptie wordt gebruik gemaakt van twee sleutels: een publieke en een private sleutel. De publieke sleutel is gekoppeld aan een certificaat en mag aan iedereen bekend worden gemaakt, de private sleutel moet door de eigenaar strikt geheim worden gehouden. Door bijzondere wiskundige eigenschappen van het private deel en het publieke deel van een certificaat, kan een stuk tekst dat versleuteld is met de publieke sleutel ontsleuteld worden met de private sleutel en andersom. Het is niet mogelijk een tekst te ontsleutelen met dezelfde sleutel als waarmee deze versleuteld is.

...

Incassomachtigen legt geen eisen op aan de communicatie tussen Debtor en Creditor. Dus deze kan al dan niet via TLS verlopen. Creditors worden echter aangeraden om altijd TLS te gebruiken voor de betaalpagina’s van hun website. Binnen Incassomachtigen wordt ook gebruik gemaakt van de tweede toepassing, het elektronisch tekenen van een bericht om de authenticiteit, integriteit en onweerlegbaarheid te waarborgen van alle berichten behalve de redirects. Doordat bijvoorbeeld de StatusResponse getekend wordt door de Routing Service kan de Creditor de transactiebevestiging op echtheid controleren.

11.2 Het elektronisch tekenen van Incassomachtigen berichten

De Creditor tekent alle berichten die hij naar de Routing Service stuurt (DirectoryRequest,TransactionRequest en StatusRequest). Het ondertekenen van berichten gebeurt volgens de "XML Signature Syntax and Processing (2nd Edition) W3C Aanbeveling” van 10 juni 2008 (http://www.w3.org/TR/xmldsig-core/), met de volgende instellingen en restricties:

...

Voor het aanmaken van een publieke en private sleutel zie paragraaf 11.4.

11.2.1 Het tekenen van het ISO pain.012 acceptance report

Naast het gewone tekenen van het hele XML bericht, moet het ISO bericht (die in het container element geplaatst wordt) separaat worden ondertekend door de Debtor bank (alleen voor de status “Success”). Deze elektronische handtekening van de Debtor Bank moet bewaard blijven gedurende de hele levensduur van de Incassomachtiging, omdat het de handtekening is die gebruikt kan worden om de integriteit en authenticiteit te verifiëren van een Incassomachtiging door de Debtor bank in een later stadium in geval van een Melding Onterechte Incasso (MOI). Het is essentieel dat dit de handtekening van de Debtor Bank blijft, omdat de Debtor bank de Incassomachtiging ondertekent ‘namens de Debtor’.

Deze vorm van tekenen volgt dezelfde eisen die van toepassing zijn op het tekenen van het gehele XML bericht, met uitzondering van het volgende: In plaats van te refereren naar het certificaat dat gebruikt dient te worden om per ‘fingerprint’ de elektronische handtekening te verifiëren, wordt het hele certificaat in de elektronische handtekening meegegeven via het X509Certificate element welke binnen het X509Data element binnen het KeyInfo element. Dit wordt gedaan om de beschikbaarheid van het certificaat te garanderen om na vele jaren ook nog de handtekening in geval van een dispuut te kunnen controleren.
De elektronische handtekening kan alleen worden gevalideerd indien het ISO bericht uit het XML container element wordt gehaald, met behulp van exclusive canonicalization. Validatie mislukt wanneer het ISO bericht nog ingebed is. De reden hiervoor is de impliciete referentie van de handtekening naar het <Document> element.

11.3 Authenticatie van Incassomachtigen berichten

Om zeker te zijn van de status van een transactie, moet een Creditor de elektronische handtekening van de Routing Service in de Response berichten controleren. Indien de status “success” is dient ook de handtekening in het aanwezige pain.012 bericht gecontroleerd te worden, zodat zeker is dat het bericht juist is.

Om de handtekening in het SignatureValue veld te controleren, wordt aangeraden gebruik te maken van de standaard XML Digital Signature libraries die hiervoor beschikbaar zijn in de meeste (web)programmeertalen.

11.4 Maken van een sleutelpaar

Als u gebruik wilt maken van een zogenaamd “self signed certificate” leest u in deze paragraaf hoe u dit certificaat kunt maken. U kunt ook een certificaat inkopen bij een daarin gespecialiseerde partij (Certificate Authority), zie daarover paragraaf 11.4.1.

...

Download de ‘OpenSSL Library’ van openssl.org. Meer informatie over de te gebruiken ‘certificate generating utility’ vindt u hier: www.openssl.org/docs/apps/req.html. Het is ook mogelijk om met behulp van andere software een sleutelpaar te creëren, raadpleeg in dat geval de handleiding van de gebruikte software.
Genereer een ‘RSA private key’ met het volgende commando (gebruik een zelfgekozen wachtwoord voor het veld [privateKeyPass]):

openssl genrsa –aes128 –out priv.pem –passout pass:[privateKeyPass] 2048
Genereer een certificaat op basis van de ‘RSA private key’ (gebruik hetzelfde wachtwoord voor het veld [privateKeyPass]):

openssl req –x509 –sha256 –new –key priv.pem –passin pass:[privateKeyPass]
-days 1825 –out cert.cer
Deze openssl instructie genereert een certificaat in X509 formaat, met een geldigheid van 5 jaar (1825 dagen), de maximumduur voor Incassomachtigen signing certificaten.
Het bestand priv.pem bevat de private key, het bestand cert.cer bevat het certificaat met de publieke sleutel. Het bestand priv.pem moet de Creditor dus zelf houden en wordt gebruikt in de RSA versleuteling. Het cert.cer bestand moet beschikbaar worden gesteld aan de Routing Service. Hoe dit beschikbaar moet worden gesteld, verschilt per Routing Service.

11.4.1 Een certificaat aanschaffen bij een Certificate Authority

Als een certificaat gekocht wordt van een Certificate Authority (CA), in plaats van een self-signed certificaat te gebruiken, is het volgende van belang: Het certificaat dat de CA gebruikt (en de rest van de certificate chain) moet ten minste even veilig zijn als het certificaat van de Creditor.

...

Certificaten voor ondertekening mogen bovendien maximaal 5 jaar geldig zijn.

...

12. Presentatie

12.1 Algemeen

Ten aanzien van de presentatie van Incassomachtigen op de site van de Creditor geldt een aantal eisen. Het voornaamste doel van deze eisen is het creëren van een uniforme gebruikerservaring voor Debtor, ongeacht op welke website ze een Incassomachtiging afgeven. De verschillende eisen worden in de volgende paragrafen genoemd en toegelicht.

...

De Incassomachtigen betaalmethode moet worden gepresenteerd in de lijst van betaalmethodes op een dergelijke manier dat het minstens dezelfde hoeveelheid aandacht krijgt als andere betaalmethodes.

12.2 Incassomachtigen via uw bank-knop

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 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’.

12.3 Transactieflow

Wanneer de ‘Incassomachtigen via uw bank’-knop wordt geklikt, krijgt de Debtor onmiddellijk een Debtor bank selectielijst gepresenteerd zonder dat er intermediërende schermen worden getoond door de Creditor (bv. Debtor login en/of registratieschermen). Nadat de relevante Debtor bank is geselecteerd door de Debtor, wordt hij/zij meteen doorgestuurd naar de Debtor bankomgeving van de geselecteerde bank (op basis van de issuerAuthenticationURL die de Creditor ontvangt in de TransactionResponse).

12.4 Redirect naar de Debtor bank

Een Creditor dient de redirect naar de Debtor bank binnen het browservenster te laten plaatsvinden waar de Debtor de bank heeft geselecteerd, waarna de volledige pagina van de Creditor vervangen wordt door de volledige pagina van de gekozen Debtor bank. Het is dus niet toegestaan de redirect naar de Debtor bank in een nieuw browservenster te laten plaatsvinden. Het is wel toegestaan een nieuw venster, met zichtbare adresbalk, te openen vóór de Debtor zijn bank selecteert.

12.5 Frames

Frames in de site van de Creditor worden toegestaan. Het scherm van de Debtor bank zal deze frames wegdrukken met een framebusting techniek zodat de Debtor beter kan controleren dat er werkelijk bij zijn eigen bank betaald wordt met Incassomachtigen. Na de redirect moet de Creditor het eigen scherm weer volledig laten opbouwen, voor het tonen van de bevestiging van de bestelling door de Creditor.

12.6 Nieuw venster

Het afhandelen van een Incassomachtigen transactie in een nieuw browservenster is toegestaan, als de Creditor dit window laat verschijnen bij (of voorafgaand aan) de betaalmethodekeuze door de Debtor. Het openen van een nieuw venster mag alleen op initiatief van de Debtor gebeuren (geen pop-up). De gehele transactieflow dient in dit venster plaats te vinden tot en met de bevestiging van de bestelling door de Creditor. Dit nieuw geopende venster dient ook voorzien te zijn van een zichtbare adresbalk, zodat dit adres gebruikt kan worden om te controleren of er bij de Debtor bank met Incassomachtigen wordt betaald door verificatie van het adres (URL) en het SSL-certificaat. Gedurende de transactieflow moet het voor de Debtor niet mogelijk zijn via het oorspronkelijke browserwindow van de Creditor nogmaals een Incassomachtigen transactie voor dezelfde order te starten.

...

Expand

title	12.6.1 Specifieke eisen aan Incassomachtigen Mobiel: Nieuw venster of app

Het mobiele Incassomachtigen proces kan een Debtor omleiden naar een andere mobiele webpagina of app als onderdeel van de transactie. De Creditor moet ernaar streven om de Debtor zoveel mogelijk binnen één browserpagina te houden maar de Creditor mag geen gebruik maken van een in-app browser (web view) in zijn app (zie Hoofdstuk 6 voor meer details). In die gevallen waar het switchen naar een andere app of venster noodzakelijk is (zoals de redirect naar de Debtor bank) moet de Debtor hierover worden geïnformeerd om verwarring te voorkomen. (Bijvoorbeeld: “U zal nu worden doorgestuurd naar de app of (mobiele) website van uw bank").

12.7 Debtor Bank list

De Debtor Bank lijst moet worden gepresenteerd zoals beschreven in paragraaf 7.4

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

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

12.9 Incassomachtigen uitleggen aan Debtors

Creditors die specifieke hulp en instructies aan Debtors willen aanbieden, worden geadviseerd om de volgende tekst te gebruiken:

...

Place your order
Select ‘Incassomachtigen via uw bank’ as your payment method
Select your bank
This opens the familiar (mobile) banking environment or mobile app of your own bank
The relevant details of your eMandate will already be shown
You approve the eMandate in the way you are accustomed to at your bank
Your bank confirms your eMandate and you can email it or download it
You return to this website – eMandate accepted and you can continue shopping

12.10 Creditor front-end

De Creditor draagt de hoofdverantwoordelijkheid voor het initiëren van het Incassomachtigen proces en voor de communicatie naar de Debtor met betrekking tot de status van de Incassomachtiging.

...

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.

12.11 Debtor Bank front-end

Alle Incassomachtigen-gerelateerde informatie (zoals Incassomachtiging informatie, Debtor informatie, Creditor informatie en Ondertekenaar informatie), met de uitzondering van het Debtor Referentie nummer (klantnummer), worden gepresenteerd aan de Debtor voor goedkeuring door de Validation Service.

...

^{Voorbeeld van een Incassomachtiging (one-off incasso) bevestigingswebsite of mobiel app-scherm}

...

13. Incassomachtigen en incasso

In dit hoofdstuk wordt de relatie tussen Incassomachtigen en het uitvoeren van incasso’s uitgelegd, alsmede de relatie met de overstapservice.

13.1 Uitvoeren incasso

Het is belangrijk om te weten dat Incassomachtigen geen middel tot pre-notificatie is. Dit dient nog steeds plaats te vinden.

...

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.

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

De informatie over de Incassomachtiging zit in de ISO pain berichten die in het container element zijn geplaatst. De volgende tabel toont een overzicht van de ISO pain berichten in de container van de Incassomachtigen berichten.

...

^{Containerinhoud voor Incassomachtigen}

...

APPENDIX B: Error codes

Categorieën

De Error.errorCode bestaat uit:

...

Categorie	Toelichting
IX	Ongeldige XML en alle gelieerde problematiek. Zoals verkeerde encoding, ongeldige versie, anderszins onleesbaar.
SO	Systeemonderhoud. De fouten die gecommuniceerd worden ten behoeve van systeemonderhoud of -storing. Omvat ook de situatie waarin nieuwe Requests niet meer geaccepteerd worden, maar Requests die al zijn ontvangen nog wel worden afgehandeld (tot een bepaald tijdstip).
SE	Security en authenticatie fouten. Verkeerde authenticatie methoden en verlopen certificaten.
BR	Veldfouten. Extra informatie over foutieve velden.
AP	Applicatie fouten. Fouten met betrekking tot ID's, rekeningnummers, tijdzones, transacties, valuta.

^{Foutcode categorieën}

Foutcodes

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 Details van de fout kunnen worden gevonden in het ISO pain.012 error acceptance bericht.

...

Source: ISO External Code Sets spreadsheet (subset of ISO reason codes)

consumerMessage

Het consumerMessage kan een van de vier gestandaardiseerde teksten bevatten die naar de Creditor worden gestuurd door de Routing Service. De Creditor moet de consumerMessage aan de Debtor laten zien op zijn website.

...

Situatie	Message to be shown to Debtor (English)	Message to be shown to Debtor (Dutch)
Fout opgetreden bij zenden of ontvangen van berichten DirectoryRequest/Response en TransactionRequest/Response	Signing an eMandate is currently not possible. Please try again later or pay using another payment method.	Het verstrekken van een online machtiging is momenteel niet mogelijk. Probeer het later nogmaals of betaal op een andere manier.
Fout opgetreden bij verzenden of ontvangen van bericht StatusRequest/Response	The result of the online mandate process can not yet be determined	Het resultaat van de online machtiging kan nog niet worden bepaald.
Fout opgetreden door onbeschikbaarheid van Validation Service (SO1000, SO1100, SO1200, SO1400)	The selected bank is currently unavailable. Please try again later or pay using another payment method	De geselecteerde bank is momenteel niet beschikbaar. Probeer het later nogmaals of betaal op een andere manier.
Fout opgetreden door onbeschikbaarheid van Issuer (zie boven) EN additionele informatie beschikbaar uit het eMandates Notificatiesysteem	The selected bank is currently unavailable due to maintenance until the expected time or date time from the NotificationSystem. Please try again later or pay using another payment method.	De geselecteerde bank is momenteel niet beschikbaar i.v.m. onderhoud tot naar verwachting date time from Notification System. Probeer het later nogmaals of betaal op een andere manier.

^{consumerMessage}

...

APPENDIX C: Berichtvoorbeelden (volg link voor syntax highlighting)

De meeste voorbeeldberichten die hier getoond worden maken alleen gebruik van de standaard methode van namespace declaration. Aan het einde van de appendix wordt een voorbeeld gegeven van een bericht met namespace prefixes (dit bericht bevat geen informatie container; het is slechts bedoeld om het gebruik van namespace prefixes te duiden).

...

Include Page

	Example Messages Incassomachtigen (without syntax highlighting)
	Example Messages Incassomachtigen (without syntax highlighting)

...

APPENDIX D: iDx XML Schema (volg link voor syntax highlighting)

Include Page

	XSD Schema iDx Merchant Acquirer (without syntax highlighting)
	XSD Schema iDx Merchant Acquirer (without syntax highlighting)

...

Version	Old Version 9	New Version 10
Changes made by	Currence	Currence
Saved on	Jun 26, 2018	Jun 26, 2018

Content Comparison

Versions Compared

Key

Voorwaarden

Inhoud

1. Inleiding

1.1 Doelgroep

1.2 Andere referenties

1.3 Conventies met betrekking tot de notaties

1.4 Definities van online bankieren

1.5 Revisies

1.6 Wijzigingen in vergelijking met eerdere versies

2. Incassomachtigen Overzicht

2.1 Wat is Incassomachtigen?

2.2 Ontwerpprincipes

2.2.1 Technische principes

2.2.2 Functionele principes

2.3 Het vier partijenmodel

2.3.1 De relaties tussen deze rollen

2.4 Terminologie

3. Incassomachtigen protocol

3.1 Algemeen

4. Functies van de oplossing

4.1 Het afgeven van een nieuwe Incassomachtiging

4.2 Het wijzigen van een bestaande Incassomachtiging

4.3 Het intrekken van een bestaande Incassomachtiging

4.4 Consumentenbeschermingsinstellingen

4.5 Meervoudig ondertekenen

4.6 Creditor Registratie voor Incassomachtigen

4.6.1 Randvoorwaarden aan de Creditor

4.6.2 Creditor registratie

4.7 Validatie Referentie

4.8 Dispuutmanagement

5. Incassomachtigen Bericht Formaat

5.1 General

HTTP

XML Header

Karakterset

Conventies voor lege velden

Berichtvalidatie

XML Namespace declaratie

Berichtattributen

6. Incassomachtigen Data Catalogus

6.1 Incassomachtigen ID’s

6.2 Generieke data elementen

7. Incassomachtigen Directoryprotocol

7.1 Algemeen

7.2 DirectoryRequest

7.3 DirectoryResponse

7.4 Presentatie van de Debtor bank selectie lijst

8. Incassomachtigen Transactieprotocol

8.1 Algemeen

8.2 TransactionRequest

8.2.1 Container inhoud

8.2.2 Inhoud van het container element voor nieuwe Incassomachtiging

8.2.3 Inhoud van het container element voor wijzigen bestaande Incassomachtiging

8.2.4 Inhoud van het container element voor Incassomachtigen intrekking

8.3 TransactionResponse

8.4 Fouten bij het uitvoeren van het Transactieprotocol

8.5 Redirect naar de online bankieromgeving (issuerAuthenticationURL)

8.6 Redirect naar de Creditor omgeving (merchantReturnURL)

8.6.1 Eisen voor Incassomachtigen Mobiel: redirect naar de Creditor omgeving.

8.8 Vier scenario’s voor het afronden van een mobiele Incassomachtigen transactie

8.9 Verwerkingssnelheid en time-out van transactieberichten

8.10 Specifieke eis voor Incassomachtigen Mobiel: Print of e-mail een bevestigingsbericht

9. Incassomachtigen Statusprotocol

9.1 Algemeen

9.2 StatusRequest

9.3 StatusResponse

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

9.4 Foutsituaties tijdens het uitvoeren van het Statusprotocol

9.5 Haalplicht

9.6 Verwerkingssnelheid en time-out van statusberichten

10. Foutafhandeling

10.1 Algemeen

10.2 ErrorResponse

10.3 Onbeschikbaarheid

11. Beveiliging en certificaten

11.1 Algemene principes van certificaten

11.2 Het elektronisch tekenen van Incassomachtigen berichten