iDEAL Advanced - Pronamic

iDEAL Advanced 

ING Wholesale Banking 

Integratiehandleiding PHP voor iDEAL 

Advanced 

Versie 2.3, april 2010 

Inhoud

iDEAL Advanced – Integratiehandleiding PHP 

Inhoud ........................................................................................................................................................ 1 

1 Introductie ........................................................................................................................................... 4 

1.1 Overzicht ................................................................................................................................. 4 

1.2 Verplichtingen.......................................................................................................................... 4 

1.3 Aanvullende vragen?............................................................................................................... 5 

1.4 Begrippen ................................................................................................................................ 5 

2 Veiligheid ............................................................................................................................................. 6 

3 Vereisten.............................................................................................................................................. 8 

3.1 Vereiste software..................................................................................................................... 8 

3.2 Vereiste instellingen ................................................................................................................ 9 

3.3 Algemene configuratie........................................................................................................... 10 

3.4 Certificaat van de acquirer .................................................................................................... 11 

3.5 Certificaat en sleutelpaar van de acceptant .......................................................................... 12 

4 Develo pment ..................................................................................................................................... 14 

4.1 Directory-verzoek (GetIssuerList) ......................................................................................... 14 

4.2 Transactieverzoek (RequestTransaction) ............................................................................. 16 

4.3 Statusverzoek (RequestTransactionStatus).......................................................................... 18 

4.4 Foutafhandeling..................................................................................................................... 21 

4.5 Proxy-servers ........................................................................................................................ 23 

5 Testen ................................................................................................................................................ 24 

5.1 Verplichte testen.................................................................................................................... 24 

6 Deployment ....................................................................................................................................... 25 

6.1 Hosting in eigen beheer ........................................................................................................ 25 

Copyright © ING. Versie 2.3, april 2010 Pag 2 van 26


6.2 Hosting bij een externe provider............................................................................................ 25 

APPENDIX A: Data catalogus ................................................................................................................ 26 



1 Introductie 

Dit document is bestemd voor ontwikkelaars die verantwoordelijk zijn voor het integreren van 

iDEAL Advanced in een webwinkel via het ontwikkelplatform PHP. 

1.1 Overzicht 

Dit document beschrijft de volgende noodzakelijke stappen van het integratieproces: 

• Hoofdstuk 2, Veiligheid, gaat nader in op de veiligheidsaspecten van uw webshop. 

• Hoofdstuk 3, Vereisten, beschrijft de randvoorwaarden en noodzakelijke stappen vooraf 

(zoals het genereren van een eigen sleutelpaar voor de eigenaar van de webshop). 

• Hoofdstuk 4, Development, beschrijft de functionaliteit van iDEAL Advanced PHP, en hoe 

deze te integreren in de webshop. 

• Hoofdstuk 5, Testen, beschrijft de verplichte testen die moeten worden uitgevoerd 

voorafgaand aan in-productie-name van de webshop. 

• Hoofdstuk 6, Deployment, beschrijft enkele facetten rondom het in productie nemen van de 

webshop. 

Nota bene: Voor algemene informatie over iDEAL Advanced wordt verwezen naar het 

document ‘iDEAL Algemeen’. Voor integratie via een ander ontwikkelplatform voor iDEAL 

Advanced wordt verwezen naar de integratiehandleiding voor .NET of de integratiehandleiding 

voor Java. 

1.2 Verplichtingen 

Het wordt ten zeerste aangeraden dit gehele document, alsmede het inleidende document ‘iDEAL 

Algemeen’, te lezen voorafgaand aan de integratie van iDEAL Advanced in een webwinkel. 

Daarbij vragen wij speciale aandacht voor de volgende verantwoordelijkheden van de 

acceptant: 

- Beveiliging: Iedere iDEAL Acceptant is zelf verantwoordelijk voor de veilige opbouw van de 

eigen webshop. De door ING geleverde software, inclusief de iDEAL Advanced PHP 

Connector, is gebouwd op basis van alle gangbare security best practices. Onjuiste integratie 

kan echter desondanks leiden tot een onveilige webwinkel. Deze integratiehandleiding bevat 

een apart hoofdstuk (hoofdstuk 2) over veiligheidsaspecten. In de andere hoofdstukken zijn 

aanvullend praktische aanwijzingen opgenomen ten aanzien van de veiligheidsaspecten van 

uw webshop. Deze passages zijn in de regel herkenbaar aan het hangslotsymbool (). 



- Haalplicht: Iedere iDEAL Acceptant dient te voldoen aan de zogenaamde ‘haalplicht’. Deze 

haalplicht houdt in dat u zelf verantwoordelijk bent voor het ophalen van de status van een 

transactie, voordat u overgaat tot leveren. Meer over de ‘haalplicht’ leest u in sectie 4.3.1. 

- Presentatie: Hulpmiddelen bij de presentatie van iDEAL op uw website kunt u vinden op het 

acceptantendeel van http://www.ideal.nl, zoals iDEAL logo’s en banners. 

- Testen: Na het voltooien van de integratie van iDEAL in uw webwinkel, bent u verplicht om 

een aantal testen uit te voeren. Deze worden beschreven in hoofdstuk 5 van dit document. 

- Voorbeeldcodes: In een aantal hoofdstukken van dit document worden ten behoeve van de 

integratie van iDEAL Advanced in uw systeem voorbeeldcodes gegeven. Deze codes dienen 

enkel en alleen ter illustratie. De inhoud van de daadwerkelijk door de iDEAL Acceptant te 

gebruiken codes dient door de iDEAL Acceptant zelf te worden vastgesteld. ING Bank N.V. is 

niet aansprakelijk voor schade, van welke aard dan ook, die de iDEAL Acceptant mocht lijden 

in verband met of ten gevolge van het gebruik van de voorbeeldcodes. De iDEAL Acceptant 

dient ING Bank N.V. te vrijwaren tegen mogelijke vorderingen van derden tot vergoeding van 

schade in verband met of als gevolg van het gebruik van de voorbeeldcodes door de iDEAL 

Acceptant. 

1.3 Aanvullende vragen? 

- Vragen: Voor vragen of opmerkingen kunt u contact opnemen met de iDEAL service desk. 

Onze service desk is te bereiken tussen 09:00 en 17:00u via ideal@ing.nl of 09006522500 (€ 

0,10 p.m.). U kunt ook een service ticket indienen via het iDEAL Dashboard. Het iDEAL 

Dashboard bevat tevens een FAQ. 

- Illustratiecode: De download voor iDEAL Advanced PHP (beschikbaar via het iDEAL 

Dashboard: https://ideal.secure-ing.com) bevat ook illustratiecode. Daarmee kunnen alle 

functies van de iDEAL Advanced PHP Connector in kale vorm worden gesimuleerd. Deze 

illustratiecode is uitdrukkelijk niet bedoeld als basis voor een complete webshop, maar dient 

louter als illustratie. 

1.4 Begrippen 

Het iDEAL-systeem is gebaseerd op bilaterale relaties binnen het zogenaamde ‘4-partijen’ model. 

De 4 betrokken partijen in dit model zijn: 

- De acceptant: de eigenaar van de webwinkel 

- De acquirer: de bankrelatie van de acceptant (ING) 

- De consument: de klant die een product wil kopen in de webwinkel van de acceptant 

- De issuer: de bankrelatie van de consument 



2 Veiligheid 

Dit hoofdstuk gaat nader in op de veiligheidsaspecten van uw webshop. In de overige 

hoofdstukken van deze integratiehandleiding zijn verscheidene praktische veiligheidsaanwijzingen 

opgenomen, herkenbaar aan het symbool van een hangslotje (). 

Dit document pretendeert overigens geenszins volledig te zijn ten aanzien van de veiligheid van 

uw webwinkel. Dat is, gezien de omvang en complexiteit van het onderwerp, onmogelijk. Het doel 

van dit hoofdstuk en van de elders opgenomen aanwijzingen is met name om u bewust te maken 

van het onderwerp. 

In boekvorm en op het internet is in ruime mate documentatie voorhanden over de bedreigingen 

waaraan web applicaties bloot (kunnen) staan, en de te nemen preventieve en detectieve 

maatregelen om de eigen webshop daarvan te vrijwaren. Wij raden u met klem aan kennis te 

nemen van deze documentatie. Het succes van uw webshop is daarvan in hoge mate afhankelijk. 

De door ING geleverde software voor iDEAL Advanced PHP is gebouwd op basis van alle 

gangbare security best practices. Onjuiste integratie van deze software in uw webshop, en/of een 

onveilige opbouw van overige onderdelen van uw webshop, kunnen desondanks leiden tot een 

onveilige webwinkel. 

Veiligheid als procesonderdeel 

De eerste stap om dit te voorkomen, is het besef dat veiligheid alle stadia van het ontwikkelproces 

van uw webshop raakt: 

• Analyse & ontwerp: Reeds tijdens het ontwerpen van uw webshop dient u inzicht te verwerven 

in de voor uw webshop relevante bedreigingen, en daarop maatregelen te formuleren. 

• Development: Sommige code is per definitie onveilig. Veel van de beschikbare security 

documentatie bevat expliciete voorbeelden van onveilige code, alsmede de aangeraden 

vervanging ervan. Houd hier bij het bouwen van uw webshop rekening mee. 

• Testen: Onderkende bedreigingen, en de bijbehorende tegenmaatregelen, dienen uiteraard 

ook getest te worden. Hiervoor bestaande vele verschillende technieken en tools, variërend 

per ontwikkelplatform. 

• Deployment: Zorg er bij het deployen van uw webshop voor dat cruciale bestanden niet voor 

onbevoegden toegankelijk zijn. Denk hierbij bijvoorbeeld aan de configuratie van uw 

webshop, uw prive-sleutel, en uw database. Besteed hier extra aandacht aan als uw webshop 

niet door uzelf wordt gehost. 

OWASP 

De tweede stap op weg naar een veilige(re) webshop, is kennis te nemen van de eerder 

genoemde documentatie over de veiligheidsaspecten van web applicaties. Een goed startpunt 

hierbij is de website van het Open Web Application Security Project (OWASP), te vinden op 

www.owasp.org. De OWASP-site biedt uitgebreid inzicht in de kwetsbaarheden (vulnerabilities) 

van software, en de te nemen maatregelen (countermeasures). 



Volgens OWASP zijn er meer dan 300 security issues die de veiligheid van web applicaties 

(kunnen) raken. Periodiek stelt OWASP hieruit een top 10 samen met de meest voorkomende 

kwetsbaarheden van web-applicaties. De nieuwste versie hiervan is de top 10 van 2007 1 . 

Ook stelt OWASP regelmatig nieuwe versies beschikbaar van een aantal belangwekkende 

documenten. De belangrijkste hiervan zijn: 

• De OWASP Guide: Beschrijft gedetailleerd hoe web applicaties en web services veiliger 

gemaakt kunnen worden. Dit wordt geïllustreerd met voorbeelden in J2EE, ASP.NET en PHP. 

2 

• De OWASP Testing Guide: Geeft een gedetailleerde beschrijving van een op security gericht 

testprogramma. 3 

• De OWASP AppSec FAQ: Een lijst met veelgestelde vragen over kwetsbaarheden en 

maatregelen. 4 

De OWASP-site kent verder specifieke pagina’s voor verscheidene ontwikkelplatforms, waaronder 

PHP 5 . Deze pagina’s gaan nader in op platform-specifieke security issues, inclusief onveilige 

code en beveiligingsmaatregelen. 

Nota bene: Denk in het kader van OWASP onder andere aan het volgende: 

• Controleer ALLE input, ongeacht de bron (acquirer, consument). 

• Controleer bij voorkeur op toegestane waarden (white listing) en niet op verboden waarden 

(black listing). 

• Bescherm uw database, onder andere door de database connection niet onnodig open te laten 

staan. 

• Bescherm uw privé-gegevens (zoals sleutels) door deze niet te bewaren op voor onbevoegden 

toegankelijke plaatsen 

• Verstuur nooit onversleutelde usernamen en passwords. 

1 Te vinden op http://www.owasp.org/index.php/Top_10_2007. 

2 Zie http://www.owasp.org/index.php/Category:OWASP_Guide_Project. 

3 Zie http://www.owasp.org/index.php/Category:OWASP_Testing_Project. 

4 Zie http://www.owasp.org/index.php/OWASP_AppSec_FAQ. 

5 Zie http://www.owasp.org/index.php/Category: PHP. 



3 Vereisten 

Dit hoofdstuk beschrijft welke software, instellingen en configuratie vereist zijn voor een 

succesvolle integratie van iDEAL Advanced in het systeem van de acceptant, bij gebruikmaking 

van PHP als ontwikkelplatform. 

3.1 Vereiste software 

Een succesvolle integratie van iDEAL Advanced PHP in een webshop volgens de in dit document 

beschreven werkwijze vereist de volgende software: 

Voor ontwikkel- en configuratiedoeleinden: 

- Een ontwikkelomgeving voor PHP, bijvoorbeeld Eclipse voor PHP. Andere mogelijkheden zijn 

Adobe Dreamweaver of Zend Studio. De keuze hang af van de voorkeuren van de 

gebruiker/ontwikkelaar. 

- PHP vanaf versie 5. 

- Voor het genereren van het eigen certificaat/sleutelpaar: 

o OpenSSL implementatie voor Windows, te vinden op 

http://www.slproweb.com/products/Win32OpenSSL.html. Voor OpenSSL in het 

algemeen zie ook www.openssl.org. Paragraaf 3.5 van dit document beschrijft de 

stappen voor het maken van een eigen certificaat/sleutelpaar. 

o OpenSSL implementatie voor Linux, te vinden op 

http://www.devside.net/guides/linux/openssl met informatie over het installeren 

van OpenSSL onder Linux. Paragraaf 3.5 van dit document beschrijft de stappen 

voor het maken van een eigen certificaat/sleutelpaar. 

- De iDEAL Advanced PHP Connector, te verkrijgen via het iDEAL Dashboard, als onderdeel 

van het iDEAL Advanced Integration PHP package, te vinden onder de menu-optie 

Documentatie. 

In een Microsoft Windows testen productie-omgeving: 

- Apache met SSL, zie voor meer informatie over Apache en PHP onder windows bijvoorbeeld 

http://www.html-site.nl/apache_php_mysql.php 

- of IIS met PHP ondersteuning, zie bijvoorbeeld http://nl3.php.net/install.windows 

- Het eigen PKCS#12-certificaat (inclusief het eigen private/public key pair) van de acceptant. 

Paragraaf 3.5 van dit document beschrijft de noodzakelijke stappen voor het genereren 

hiervan. 

- Het certificaat van het iDEAL Acquiring platform (iDEAL.cer). Te verkrijgen via het iDEAL 

Dashboard. Zie paragraaf 0 voor details. 

- De iDEAL Advanced PHP Connector. Te verkrijgen via het iDEAL Dashboard, als onderdeel 


Documentatie. 



In een Linux testen productie-omgeving: 

- Apache met SSL, zie voor meer informatie over Apache en PHP onder linux bijvoorbeeld 

http://dan.drydog.com/apache2php.html 

- Het eigen PKCS#12-certificaat (inclusief het eigen private/public key pair) van de acceptant. 

Paragraaf 3.5 van dit document beschrijft de noodzakelijke stappen voor het genereren 

hiervan. 

- Het certificaat van het iDEAL Acquiring platform (iDEAL.cer). Te verkrijgen via het iDEAL 

Dashboard. Zie paragraaf 0 voor details. 

- De iDEAL Advanced PHP Connector. Te verkrijgen via het iDEAL Dashboard, als onderdeel 


Documentatie. 

3.2 Vereiste instellingen 

- Internet-verkeer over poort 443 (SSL): Het moet mogelijk zijn om vanaf de webserver (waar 

de webshop op staat) een SSL-verbinding te maken naar de iDEAL-server van de acquirer. 

Deze verbindingen verlopen over poort 443. 

- Toegang tot een directory met specifieke lees- en schrijfrechten tijdens het installeren van de 

certificaten op de webserver. 

- Beveiligingsmaatregelen: PHP dient als volgt op de juiste wijze geconfigureerd te worden: 

o REGISTER_GLOBALS: Het wordt met klem aangeraden deze optie UIT te zetten. 

Indien deze optie aan staat, is het mogelijk dat gebruikers de applicatie beïnvloeden. 

Als REGISTER_GLOBALS aan staat kunnen variabelen direct vanuit de adresbalk 

van de browser gevuld worden. Hierdoor wordt het voor kwaadwillenden makkelijker 

om misbruik van het systeem te maken. Zie ook 

http://www.php.net/manual/nl/security.globals.php. 

o OPEN_BASEDIR: Hiermee kun je op folder-niveau aangeven waar PHP toegang tot 

heeft. Gebruik deze instelling om minimaal de folders met uw configuratie en uw 

sleutels af te schermen. Zie ook http://nl2.php.net/manual/en/features.safemode.php#ini.open-basedir 

o SAFE_MODE: Als deze optie aan staat wordt er gekeken of de permissies voor het 

bestandssysteem overeenkomen met de gebruiker die het bestandssysteem probeert 

te wijzigen/openen. Als SAFE_MODE aan staat dan houdt dat dus in dat PHP alleen 

bestanden kan bewerken/openen waar het ook daadwerkelijk toestemming voor heeft 

gekregen. Het wordt sterk aangeraden om deze optie AAN te zetten, ook als dat 

betekent dat u bepaalde functionaliteit van uw webshop anders dient te 

implementeren. Zie ook http://nl2.php.net/manual/en/features.safe-mode.php 

o DISPLAY_ERRORS: Deze optie bepaald of er foutmeldingen weergegeven mogen 

worden. Als de optie UIT staat wordt er bij het optreden van een fout alleen een witte 

pagina weergegeven. Het wordt sterk aangeraden om deze optie UIT te zetten, ook 

als dat betekent dat u bepaalde functionaliteit van uw webshop anders dient te 

implementeren, zodat er geen waardevolle informatie prijs gegeven wordt. Zie ook 

http://nl2.php.net/errorfunc 



o ERROR_REPORTING: Deze optie bepaalt of en hoeveel waarschuwingen worden 

weergegeven op het moment dat er een fout optreed. Het wordt sterk aangeraden om 

deze optie UIT te zetten, ook als dat betekent dat u bepaalde functionaliteit van uw 

webshop anders dient te implementeren, zodat er geen waardevolle informatie prijs 

gegeven wordt. Zie ook http://nl2.php.net/errorfunc 

o EXPOSE_PHP: Deze optie bepaald of PHP mag aangeven dat het geïnstalleerd is op 

een webserver. Op het moment dat deze aan staat wordt bijvoorbeeld de signature 

van PHP toegevoegd aan de http-header van de webserver. Het wordt met klem 

aangeraden om deze optie in die de productie-omgeving UIT te zetten. Zie ook 

http://nl3.php.net/ini.core 

3.3 Algemene configuratie 

De volgende parameters dienen geconfigureerd te worden in het bestand config.conf: 

- MerchantID: het ID van de webshop, door de acceptant ontvangen tijdens het 

aanmeldproces 

- SubID: subID van de webshop, defaultwaarde = 0 (nul); alleen te wijzigen na overleg met de 

acquirer 

- MerchantReturnURL: URL van de pagina in de webshop waarnaar de consument wordt 

teruggeleid (‘redirect’) na een iDEAL-transactie. Deze waarde kan in de webshopimplementatie 

waar nodig worden overruled (zie paragraaf 4.2.2). 

- AcquirerURL: URL van de acquirer van de acceptant; voor ING gelden de volgende 

voorgeschreven waarden: 

• Testomgeving: https://idealtest.secure-ing.com/ideal/iDeal 

• Productie-omgeving: https://ideal.secure-ing.com/ideal/iDeal 

- AcquirerTimeout: aantal seconden (default = 10) dat er gewacht wordt op respons van de 

iDEAL services. Indien binnen die tijd geen respons komt, wordt een exception gegeven. 

- Privatecert: Organisatienaam van de acceptant zoals opgegeven tijdens de creatie van 

het eigen certificaat. Zie paragraaf 3.5 voor meer informatie over het certificaat van de 

acceptant. 

De instellingen in het config.conf bestand kunnen er bijvoorbeeld als volgt uitzien: 

Privatekey=priv.pem 

PrivatekeyPass=passwd 

Privatecert=cert.cer 

Certificate0=webserver.crt 

AcquirerURL=ssl://ideal.secure-ing.com:443/ideal/iDeal 

AcquirerTimeout=10 

MerchantID=005012345 

SubID=0 



MerchantReturnURL=http://[yourwebpage]/StatReq.php 

ExpirationPeriod=PT10M 

LogFile=/Connector.log 

TraceLevel = DEBUG,ERROR 

In het bestand iDEALConnector_config.inc.php dient het volgende aangepast te worden: 

- define( "SECURE_PATH", "%PATH%" ); 

Hier dient op de plek van %PATH% het volledige pad naar de map te staan waarin het 

config.conf bestand en de private keys en certificates gevonden kunnen worden. 

Nota bene: Zet het configuratiebestand, encryptiesleutels en andere gevoelige informatie nooit 

in de document root van de webserver (www of www-root). Op die locatie zijn uw gegevens 

namelijk zeer makkelijk toegankelijk voor ongewenste bezoekers. 

Nota bene: Zet in de productie-omgeving NOOIT tracing aan. Dit kan zowel performance- als 

security-problemen opleveren! 

3.4 Certificaat van de acquirer 

iDEAL Advanced wordt geleverd met een certificaat van het iDEAL Acquiring systeem: 

ideal.cer. Dit certificaat bevat de public key van het iDEAL Acquiring platform, waarmee het 

mogelijk wordt om te controleren dat alle berichten daadwerkelijk door het iDEAL Acquiring 

platform van ING worden verstuurd. 

De volgende stappen dienen te worden doorlopen om het certificaat van het iDEAL Acquiring 

platform te installeren op het systeem van de acceptant: 

1. Kopieer het certificaat-bestand naar een afgebakende folder buiten de webroot. 

2. Geef uitsluitend het gebruikersaccount van de webserver rechten op dit certificaat; dit 

account heeft uitsluitend leesrechten nodig 

Nota bene: Plaats uw certificaat NIET in de webroot. De webroot is namelijk ook voor 

onbevoegden makkelijk te benaderen 

Nota bene: Dit certificaat dient uitsluitend als medium voor de publieke sleutel. Het maakt 

derhalve niet uit als de status volgens de certificaat-details Ongeldig is. 



3.5 Certificaat en sleutelpaar van de acceptant 

De volgende stappen dienen te worden doorlopen om een eigen certificaat en sleutelpaar te 

genereren en activeren: 

1. Genereer een ‘RSA private key’ met het volgende commando (gebruik een zelfgekozen 

wachtwoord voor het veld eigenWachtwoord ): 

openssl genrsa –des3 –out priv.pem –passout pass:eigenWachtwoord 1024 

Het resultaat hiervan is de file priv.pem. PEM-files zijn bedoeld voor het opslaan van de 

private key en de public key. Het bestand wordt default opgeslagen in de bin directory onder 

de OpenSSL directory. 

Nota bene: Houd er rekening mee, dat het hier opgegeven wachtwoord ook benodigd is bij 

het installeren van het certificaat in de uiteindelijke hosting omgeving. Dit is mogelijk niet de 

eigen omgeving van de acceptant, maar die van een externe hosting provider. Maak daarom 

geen gebruik van een wachtwoord dat de acceptant gebruikt voor andere zakelijke of privédoeleinden. 

Nota bene: Gebruik in alle gevallen een sterk wachtwoord, want met dit certificaat kan een 

kwaadwillende zich voordoen als u ten opzichte van het acquiring-platform. 

2. Genereer een certificaat op basis van de ‘RSA private key’ (gebruik hetzelfde wachtwoord 

voor het veld eigenWachtwoord als in stap 2): 

openssl req –x509 –new –key priv.pem –passin pass:eigenWachtwoord 

–days 3650 –out cert.cer 

Dit commando leidt tot een reeks vragen over de aanvrager. Voer de juiste waarden in. Dit 

betreft onder andere de organisatienaam (“Organization Name”). Deze organisatienaam heeft 

u in enkele vervolgstappen nodig. 

Het resultaat is de file cert.cer. CER-files bevatten het certificaat en de public key. Het 

bestand wordt default opgeslagen in de bin directory onder de OpenSSL directory. 

3. Kopieer de private key en het certificaat naar dezelfde afgebakende folder als het configuratie 

bestand (zie paragraaf 3.3). 

4. Configureer de volgende parameters in het bestand config.conf; vervang daarbij de 

waarde voor PrivatekeyPass in het eigenWachtwoord dat u ook in stap 2 heeft gebruikt: 

Privatekey=priv.pem 

PrivatekeyPass= 

Privatecert=cert.cer 

5. Upload cert.cer op de testomgeving van het iDEAL Acquiring platform (via het iDEAL 

Dashboard). 



6. Na positieve verificatie door de iDEAL Service Desk (zie het hoofdstuk ‘Aanmeldproces’ van 

het document ‘iDEAL Algemeen’): Upload cert.cer op de productie-omgeving van het 

iDEAL Acquiring platform (via het iDEAL Dashboard). 

Nota bene: De aangemaakte bestanden priv.pem, cert.cer en config.conf bevatten geheime 

informatie (de private key en configuratiegegevens). Zorg ervoor dat deze bestanden niet voor 

anderen toegankelijk zijn en dus ook niet in de webroot van de webserver staan ( de www-root of 

www folder ). 

Aanbeveling: Om voor uzelf duidelijk onderscheid te kunnen maken tussen de productie- en de 

testomgeving van iDEAL is het aan te raden voor beide omgevingen een apart *.cer en *.p12 

bestand aan te maken. 



4 Development 

Dit hoofdstuk beschrijft in detail hoe de iDEAL-protocollen geïntegreerd kunnen worden in een 

webshop. Binnen iDEAL wordt gebruik gemaakt van de volgende protocollen: 

- Directory-protocol: ophalen van de lijst van bij iDEAL aangesloten issuers. Hieruit kiest de 

consument (klant van de webshop) diens eigen bank. De iDEAL Advanced PHP Connector 

ondersteunt dit protocol via de functie GetIssuerList. 

- Betaalprotocol: starten en uitvoeren van een transactie, waarbij geld wordt overgemaakt van 

de door de consument gekozen issuer naar de acquirer van de acceptant. De iDEAL 

Advanced PHP Connector ondersteunt dit protocol via de functie RequestTransaction. 

- Navraagprotocol: opvragen van de status van een transactie. Zie hiervoor o.a. de paragraaf 

over de Haalplicht (4.3.1). De iDEAL Advanced PHP Connector ondersteunt dit protocol via 

de functie RequestTransactionStatus. 

- Foutenprotocol: richtlijnen voor het verwerken van foutsituaties (zie hiervoor ook paragraaf 

2.5 van de iDEAL Referentiegids). De iDEAL Advanced PHP Connector ondersteunt dit 

protocol impliciet: elke foutsituatie wordt afgehandeld via een exception; in het geval van 

iDEAL-fouten is dat een IDealException. Elke IDealException omvat o.a. alle iDEAL 

ErrorRes informatie, inclusief de consumerMessage. 

Nota bene: Indien tussen de webshop en de acquirer een proxy server aanwezig is, dienen 

speciale maatregelen genomen te worden. Zie hiervoor paragraaf 4.5. 

4.1 Directory-verzoek (GetIssuerList) 

Het Directory-verzoek, in de iDEAL Advanced Connector geïmplementeerd via GetIssuerList, 

zorgt ervoor dat de meest recente lijst van aangesloten Issuers (banken van consumenten) wordt 

opgehaald. Op basis van deze lijst dient in de webshop de keuzelijst met banken gevuld te 

worden. Hieruit kiest de consument vervolgens diens bank. 

Input 

Een aanroep van GetIssuerList vereist geen parameters. 

Resultaat 

Een aanroep van GetIssuerList kan twee resultaten opleveren: 

• Indien er geen fout optreedt, wordt een DirectoryResponse object teruggegeven dat de 

volgende elementen bevat: 

o IssuerShortList: De short list met de issuers met het grootste marktaandeel. 

o IssuerLongList: De long list met de overige issuers. 



Paragraaf 4.3.1 van de Referentiegids beschrijft in detail hoe de issuers aan de consument 

gepresenteerd dienen te worden. 

• Indien er wel een fout optreedt wordt er een ander bericht teruggegeven. Zie meer hierover in 

paragraaf 4.4 

De voorbeeldcode voor de aanroep van GetIssuerList kan bijvoorbeeld als volgt zijn: 

$response = $iDEALConnector>GetIssuerList(); 

if ( ! $response ) { 

} else { 

} 

Periodiek aanroepen 

$errorCode = $response->getErrorCode(); 

$errorMsg = $response->getErrorMessage(); 

$consumerMessage = $response->getConsumerMessage(); 

$IssuerList =& $response->getIssuerFullList(); 

In de praktijk wijzigt de lijst van issuers slechts zelden. Het is daarom niet noodzakelijk bij elke 

transactie de functie GetIssuerList opnieuw aan te roepen. In plaats daarvan kan het resultaat 

periodiek worden opgehaald, en tussentijds gecached of opgeslagen. Aangeraden wordt de lijst in 

elk geval dagelijks op geldigheid te controleren en indien nodig te verversen. Daarbij kan het 

attribuut DateTimeStamp gebruikt worden om te controleren of de lijst is aangepast. 

De voorbeeldcode hiervoor kan er bijvoorbeeld als volgt uitzien, indien de issuerlijst tussentijds in 

de eigen webshop-database wordt vastgehouden: 

DateTime dirDateTime; // datetime stempel van GetIssuerList 

DateTime dbDateTime; // datetime stempel in eigen database 

// Voeg toe: aanroep GetIssuerList(), zie vorige voorbeeld 

$dirDateTime = $IssuerList->getDirectoryDateTimeStamp(); 

$dbDateTime = // aanroep eigen functie voor opvragen dbDateTime 

if ( $dirDateTime > $dbDateTime ) 

{ 

} 

// Voeg toe: functionaliteit om de nieuwe lijst 

// op te slaan in de eigen database 



Indien de issuer-lijst bij de acquirer wijzigt, is het raadzaam de lijst in de webshop daarop zo snel 

mogelijk aan te passen. Daarom is het aan te raden in de webshop functionaliteit in te bouwen 

waarmee de acceptant dit op elk gewenst moment kan doen. 

M.b.t. het aantal Directory-verzoeken geldt: 

• Maximaal 1 maal per 24 uur; 

• Geen Directory-verzoek voorafgaand aan iedere transactie. 

Nota bene: Paragraaf 2.2.1 van de Referentiegids geeft een overzicht van mogelijke fouten die 

kunnen optreden als de issuer-list binnen de webshop niet meer overeenstemt met de 

daadwerkelijke lijst. 

4.2 Transactieverzoek (RequestTransaction) 

Met het Transactieverzoek, geïmplementeerd via RequestTransaction, initieert u een iDEALtransactie. 

Alle hiervoor benodigde gegevens worden enerzijds afgeleid uit de door u aangeboden 

parameters, anderzijds impliciet door de connector uit de configuratiegegevens gehaald. 

Input 

Een aanroep van RequestTransaction vereist minstens 5 parameters: 

• IssuerId: het id van de issuer die de consument heeft gekozen uit de selectielijst 

• PurchaseId: het aankoopnummer volgens het systeem van de webwinkel 

• Amount: het bedrag in hele centen (geen decimalen; 1 euro = 100) 

• Description: de omschrijving van het produkt 

• EntranceCode: een door de webwinkel bepaalde code waarmee bij terugkeer in de 

webwinkel de aankoop geauthenticeerd kan worden (zie paragraaf 4.2.2 voor details). 

• (optioneel) ExpirationPeriod: indien anders dan de geconfigureerde waarde. 

• (optioneel) MerchantReturnURL: indien anders dan de geconfigureerde waarde. 

Nota bene: In de iDEAL-testomgeving wordt het resultaat van transacties bepaald door de 

waarde van het aangeboden amount. Gebruik bijvoorbeeld amount=100 om een succesvolle 

transactie te simuleren. Zie paragraaf 5.1 voor details. 

Nota bene: De appendix "Tekenset bij Interbancaire Uitwisseling" van de Referentiegids bevat 

een tabel met toegestane tekens. Overige tekens, zoals diakritische tekens, worden niet 

toegestaan. Bij gebruik van een teken buiten de afgesproken tekenset in properties van het 

Transaction-object (zoals Description, EntranceCode en PurchaseId) worden de tekens 

geconverteerd naar een equivalent dat wel in de tekenset voorkomt. 



Resultaat 

Een aanroep van RequestTransaction kan in essentie twee resultaten opleveren: 

• Indien er geen fout optreedt, wordt een AcquirerTransactionResponse object 

teruggegeven dat de volgende elementen bevat: 

o AcquirerId: het ID van de acquirer. 

o TransactionId: unieke identificatie van de transactie zoals uitgegeven door de 

acquirer. Aangeraden wordt dit nummer ter ondersteuning voor de eigen administratie 

te koppelen aan het eigen aankoopnummer (PurchaseId). 

o IssuerAuthenticationURL: de volledige URL van de issuer (de bank van de 

consument). De webshop dient de consument automatisch naar deze URL te 

redirecten. 


paragraaf 4.4 

4.2.1 Redirect naar de issuer 

Nadat het Transactieverzoek succesvol is geïnitieerd, wordt de consument via een redirect 

doorgestuurd naar zijn eigen internetbankier-omgeving. De URL waarop de issuer de consument 

verwacht wordt meegestuurd in het antwoord op het Transactieverzoek. Met behulp van de 

volgende voorbeeldcode wordt de consument doorgestuurd naar de issuer: 

Nota bene: De Referentiegids bepaalt dat de acceptant voorafgaand aan de redirect de URL 

dient te valideren, waarbij o.a. gecontroleerd moet worden dat deze geen scripting bevat. De 

iDEAL Advanced Connector voert deze URL-controle automatisch uit. 

$connector = new iDEALConnector(); 

// voeg parameters toe 

$response = $connector->RequestTransaction( . . . ); 

// voeg fout controle toe 

$url = $response->getIssuerAuthenticationURL(); 

header("Location: " . $url ); 

Nota bene: De iDEAL Referentiegids stelt als regel, dat de redirect naar de issuer binnen het 

browserwindow moet plaatsvinden waarin de consument op de Betaalknop heeft gedrukt. Daarbij 

moet de volledige pagina van de acceptant vervangen worden door de volledige pagina van de 

gekozen issuer. Het gebruik van een tweede browserwindow (pop-ups) of frames is dus niet 

toegestaan. 



4.2.2 Redirect naar de webshop 

Na de betaling (succesvol of niet) via internetbankieren wordt de consument automatisch terug 

geleid naar de webshop van de acceptant, via de URL die als waarde van merchantReturnURL 

is geconfigureerd. 6 

Validatie 

De return-URL bevat automatisch de entranceCode en het transactionId van de transactie. 

De entranceCode is initieel door de acceptant meegegeven als parameter van het 

Betaalprotocol, en kan nu (in combinatie met het transactie id) gebruikt worden om de consument 

te ‘authenticeren’ als degene voor wie de transactie ook is gestart. 

Nota bene: Het wordt aangeraden om deze validatie altijd uit te voeren. Houd daarbij rekening 

met de vereiste minimale variatie van de entranceCode, zoals bepaald in 3.3.1 van de 

Referentiegids. 

Vervolgens zal de webshop de status van de transactie opvragen. Gebruik hiervoor de functie 

RequestTransactionStatus (zie volgende paragraaf). 

4.3 Statusverzoek (RequestTransactionStatus) 

Na het uitvoeren van een betaalopdracht, dient de webshop in alle gevallen zelf de status van de 

transactie op te vragen via het zogenaamde Navraagprotocol van iDEAL. Dit protocol is in de 

iDEAL Advanced connector geïmplementeerd via de functie RequestTransactionStatus. 

Input 

Een aanroep van RequestTransactionStatus vereist als parameter uitsluitend het 

TransactionId van de te controleren transactie. 

Resultaat 

Een aanroep van RequestTransactionStatus kan in essentie twee resultaten opleveren: 

• Indien er geen fout optreedt, wordt een AcquirerStatusResponse object teruggegeven 

dat de volgende elementen bevat: 

o AcquirerId: het ID van de acquirer. 

o TransactionId: het ID van de transactie. 

6 Indien voor speciale gevallen een andere URL gewenst is, kan de in configuratie opgegeven URL worden overruled door 

de merchantReturnURL property van de Connector (tijdelijk) aan te passen. 



o Status: de status van de transactie. 

o Indien de transactie is geslaagd (status=Success), worden ook de gegevens van de 

consument verstrekt, te weten diens ConsumerAccountNumber, ConsumerName, 

en ConsumerCity. 


paragraaf 4.4 

De voorbeeldcode voor de aanroep van RequestTransactionStatus kan bijvoorbeeld als 

volgt zijn: 

$response = $connector->RequestTransactionStatus( $transactionId ); 

if ( ! $response ) { 




// Voeg toe: tonen van de consumerMessage 

} else { 

$status =& $response->getStatus(); 

if ( $status === IDEAL_TX_STATUS_SUCCESS ) { 

$consumerName = $response->getConsumerName(); 

$consumerAccNumber = $response->getConsumerAccountNumber(); 

} 

} 

Transactie gelukt 

$consumerCity = $response->getConsumerCity(); 

Paragraaf 2.3.1 van de Referentiegids beschrijft de mogelijke statussen die kunnen worden 

geretourneerd door RequestTransactionStatus. Uitsluitend de status Success betekent dat 

de transactie is geslaagd, en dat tot levering moet worden overgegaan. 

Nota bene: Indien de acceptant gebruik maakt van iDEAL-reconciliatie, dan toont het iDEAL 

Dashboard naast de status 003 (Succes) ook de vervolgstatussen 007 (gereconcilieerd) en 009 

(uitbetaald). Ook die statussen duiden op een succesvolle transactie. Via 

RequestTransactionStatus zult u in alle gevallen de status Success terugkrijgen; 003, 007 

en 009 kunt u niet langs programmatische weg van elkaar onderscheiden. Meer informatie over 

reconciliatie is te vinden op het iDEAL Dashboard. 

Status niet bekend 

Houd er bij de implementatie rekening mee dat een consument ervoor kan kiezen de browser 

tijdens, of direct na het uitvoeren van de betaling te sluiten. 



In zo’n geval wordt niet automatisch teruggekeerd naar de webshop, en wordt dus ook niet 

automatisch de status van de transactie opgevraagd. Indien de webshop niet op deze situatie is 

ingericht, kan het voorkomen dat een consument een betaling verricht maar geen produkt 

ontvangt omdat de transactiestatus voor de acceptant op ‘open’ blijft staan. 

Dit is niet alleen onwenselijk, maar staat ook haaks op de ‘haalplicht’ van de acceptant. De 

volgende paragraaf gaat nader in op deze ‘haalplicht’ en mogelijke oplossingen van de geschetste 

problematiek. 

M.b.t. het aantal Statusverzoeken per transactie geldt: 

• Maximaal vijf maal per transactie; 

• Maximaal twee maal binnen de expirationPeriod; 

• Buiten de expirationPeriod niet vaker dan eens per 60 minuten; 

• Geen Statusverzoek nadat een eindstatus is ontvangen voor een transactie; 

• Geen Statusverzoek voor transacties ouder dan 7 dagen. 

Voorbeelden van mogelijke momenten waarop een Statusverzoek kan worden uitgevoerd: 

• 30 seconden na het verzenden van een Transactieverzoek; 

• Halverwege een expirationPeriod; 

• Net na een expirationPeriod; 

• Na een bepaalde tijd (max. 1 uur) na afloop van de expirationPeriod. 

Normaal gesproken zou vrij kort na het verstrijken van de expiration period één van de 

eindstatussen teruggegeven moeten worden. Als het teruggegeven resultaat “Open” enige tijd na 

de expiration period nog steeds wordt teruggegeven is er sprake van een storing. Als deze storing 

niet binnen 1 dag is opgelost raadpleeg dan de iDEAL Dashboard en neem eventueel contact op 

met de iDEAL service desk in plaats van StatusRequests te blijven versturen. 

4.3.1 Haalplicht 

De acceptant heeft een zogenaamde haalplicht ten aanzien van het status van een transactie. Dit 

betekent dat een acceptant zelf verantwoordelijk is voor het ophalen van een definitieve status 

van een transactie, ook als de consument niet wordt teruggeleid naar de webwinkel na het (al dan 

niet) betalen van de transactie. Dit laatste kan gebeuren doordat de klant voortijdig het browser 

venster afsluit. 



Als de status van een transactie niet bekend is, of gelijk is aan Open, staan de volgende 

mogelijkheden tot uw beschikking om de status alsnog op te halen: 

- ‘Handmatig’ een statusverzoek uitvoeren voor een bepaald transactionID. Dit vereist het 

implementeren van functionaliteit in de webshop waarmee de acceptant in staat is als een 

losstaande handeling een statusverzoek te starten voor een op te geven transactionId. 

Nota bene: Functionaliteit die uitsluitend bedoeld is voor de eigenaar van de webshop, 

en niet voor consumenten, dient zodanig te worden geïmplementeerd dat onbevoegden 

deze functionaliteit noch rechtstreeks, noch indirect kunnen starten. Hiertoe dient een 

adequaat autorisatiemechanisme te worden geïmplementeerd. 

- Geautomatiseerd periodiek statusverzoeken uitvoeren voor alle nog niet afgehandelde 

transacties. Hierbij gelden dezelfde richtlijnen als voor het ‘handmatig’ ophalen van één 

transactiestatus. 

- Automatisch een statusverzoek uitvoeren nadat de expirationPeriod is verlopen. Zie 

hiervoor ook de laatste pagina van paragraaf 3.3.1 van de Referentiegids. 

- Inloggen in het iDEAL Dashboard, de betaling opzoeken en de status opvragen middels de 

‘Status request-knop’. 

Voorbeeld 

Een webwinkel die vliegtickets verkoopt, reserveert een ticket bij iedere potentiële aankoop voor 

een periode van 15 minuten. Binnen deze periode dient een consument een vliegticket aan te 

schaffen. Zo niet, dan wordt het ticket weer vrijgegeven voor verkoop aan andere consumenten. 

Indien de consument binnen 5 minuten via IDEAL een vliegticket koopt, maar het browser-venster 

na de betaling bij zijn internetbankier afsluit, dan wordt hij niet teruggeleid naar de webwinkel. De 

webwinkel krijgt nu geen signaal dat de betaling voldaan is en zal na 15 minuten het vliegticket 

vrijgeven, terwijl de consument wel degelijk heeft betaald! 

Om dit te voorkomen, dienen in de webwinkel maatregelen te worden genomen, bijvoorbeeld door 

het implementeren van een aan een timer gekoppelde navraagfunctie. De webwinkel zou dan (in 

dit specifieke voorbeeld) gebruik kunnen maken van een expirationPeriod van bijvoorbeeld 

10 minuten (hetgeen betekent dat een consument maximaal 10 minuten over een iDEALtransactie 

mag doen; daarna krijgt de transactie automatisch de status expired; verlopen). Als 

een consument dan na de gedefinieerde vervalperiode van 10 minuten nog niet is teruggekeerd 

naar de webshop, dan zal de zelfgebouwde navraagfunctie automatisch een statusverzoek doen, 

om zodoende ruim voor de reserveringsperiode van 15 minuten te kunnen beschikken over een 

definitieve status. 

4.4 Foutafhandeling 

Indien een fout optreedt in het berichtenverkeer tussen acceptant, acquirer en/of issuer wordt door 

de iDEAL Advanced Connector een ander bericht teruggegeven. Om te kijken of er een fout is 

opgetreden dient u na het ophalen van een response te controleren of er een fout is opgetreden 

door het aanroepen van de volgende functie: 



if (response->IsErrorMessage()) 

{ 

} 

... 

Als er een fout is opgetreden zal ‘true’ teruggegeven worden door de functie IsErrorMessage() en 

in het navolgende codeblok kan de fout afgehandeld worden met de volgende constructie: 

if ($response->IsErrorMessage()) 

{ 

} 




In deze variabelen zullen dan achtereenvolgens de foutcode, het foutbericht van iDEAL en het 

foutbericht voor de gebruiker getoond worden. 

Paragraaf 2.5.2 van de Referentiegids verplicht de acceptant ertoe aan de consument uitsluitend 

de consumerMessage uit dit object te tonen. Ter ondersteuning hiervan zorgt de iDEAL 

Advanced Connector ervoor dat het veld consumerMessage altijd is gevuld (hetzij met de door 

de acquirer doorgegeven waarde, hetzij met de verplichte teksten uit tabel 16 van de 

Referentiegids). 

De voorbeeldcode voor het tonen van de juiste foutboodschap aan de consument kan er daardoor 

bijvoorbeeld als volgt uitzien: 

} 

$response = $connector->xxxx(); 

if ($response->IsErrorMessage()) 

{ 




// voeg toe: Tonen van $consumerMessage op scherm 

waarbij “xxxx” een willekeurige functie voorstelt. 



4.5 Proxy-servers 

Indien tussen de webshop en de site van de acquirer een proxy server aanwezig is, dan kan dat 

betekenen dat als onderdeel van de communicatie moet worden ingelogd op de proxy server. 

Daartoe dient in de webshop functionaliteit te worden geïmplementeerd die een gebruikersnaam 

en wachtwoord meegeeft. 

Nota bene: Opslaan van de gebruikersnaam en het wachtwoord voor de proxy server dient op 

een veilige manier te gebeuren. Indien deze gegevens in een configuratiebestand worden 

opgeslagen moet dit bestand opgeslagen worden in een beveiligde folder, die alleen toegankelijk 

is voor PHP 



5 Testen 

Dit hoofdstuk beschrijft alle verplichte testen die moeten worden uitgevoerd voordat een webshop 

met iDEAL Advanced integratie in productie genomen kan worden. Aanvullend dient uiteraard ook 

de overige functionaliteit van uw webshop getest te worden. Dat valt echter buiten de scope van 

dit document. 

5.1 Verplichte testen 

De verplichte testen zijn functioneel beschreven in het hoofdstuk Aanmeldproces van de 

algemene documentatie van iDEAL Advanced. Het betreft zeven testen, allen uit te voeren op de 

testomgeving van iDEAL (https://idealtest.secure-ing.com). 

Voorafgaand aan het testen dient het volgende gecontroleerd te worden: 

• In het config.conf bestand dient privateCert gedefinieerd te zijn, met als waarde de 

organisatienaam die is opgegeven bij het creëren van het eigen certificaat van de acceptant 

(via de stappen in paragraaf 3.5 van dit document). 

• Het eigen certificaat (cert.cer) dient geupload te zijn naar de iDEAL testomgeving. 

Het uitvoeren van de testen gaat daarna als volgt: 

1. De acceptant logt in op de testomgeving van iDEAL, onder gebruikmaking van de tijdens het 

aanmeldproces verkregen gebruikersnaam en wachtwoord. 

2. De acceptant verzendt 7 testopdrachten naar de URL van de iDEAL testomgeving 

(https://idealtest.secure-ing.com/ideal/iDeal). De testomgeving geeft daarbij de volgende 

voorgeprogrammeerde resultaten terug: 

Opdracht Verwacht resultaat in geval van juiste integratie 

Transactie met amount = 100: Success 

Transactie met amount = 200: Cancelled 

Transactie met amount = 300: Expired 

Transactie met amount = 400: Open 

Transactie met amount = 500: Failure 

Transactie met amount = 700: SO1000 Failure in system 

Directory Request (GetIssuerList) Issuer Simulator 

3. De acceptant controleert de verkregen resultaten. 

Nota bene: Testresultaten worden ter verificatie enkele malen per dag automatisch verstuurd 

naar iDEAL. Positieve verificatie van de testresultaten is noodzakelijk voor het activeren van 

iDEAL in de productie-omgeving. Activatie dient te worden uitgevoerd door de acceptant, via het 

iDEAL Dashboard. Dat is mogelijk vanaf de eerstvolgende dag. 



6 Deployment 

Dit hoofdstuk beschrijft enkele aspecten van het deployen van een webshop met iDEAL Advanced 

integratie. Een volledige beschrijving van alle mogelijke deployment-scenario’s valt buiten de 

scope van dit document. 

6.1 Hosting in eigen beheer 

Controleer vooraf dat uw eigen omgeving voldoet aan alle voor iDEAL Advanced gestelde 

voorwaarden (zoals beschreven in hoofdstuk 3). 

Controleer na deployment nadrukkelijk dat alle onderdelen van uw site afdoende zijn afgeschermd 

voor onbevoegden. Denk bijvoorbeeld aan de configuratie, uw database, en eventuele pagina’s 

die uitsluitend voor u bestemd zijn. 

6.2 Hosting bij een externe provider 

Indien hosting geschiedt bij een externe provider dient nadrukkelijk rekening gehouden te worden 

met de privacy-aspecten van uw webshop. Denk daarbij met name aan uw private key (zie 

paragraaf 3.5). 

Controleer vooraf ook dat de hosting provider voldoet aan alle voor iDEAL Advanced gestelde 

voorwaarden (zoals beschreven in hoofdstuk 3). 

Controleer na deployment nadrukkelijk dat alle onderdelen van uw site afdoende zijn afgeschermd 

voor onbevoegden. Denk bijvoorbeeld aan de configuratie, uw database, en eventuele pagina’s 

die uitsluitend voor u bestemd zijn. 



APPENDIX A: Data catalogus 

Parameter Formaat Omschrijving 

issuerID PN..4 ID van de bank van de consument 

merchantID PN..9 Uw merchantID wordt verstrekt tijdens het aanmeldproces. 

subID N..max6 Default waarde = 0 (nul) 

authenticationType AN..max40 Vaste waarde = SHA1_RSA 

merchantReturnURL AN..max512 URL op het systeem van de acceptant waar de klant naar toe geleid wordt 

(‘redirect’) na de betaling in de internetbankier-omgeving. 

N.B. Deze pagina dient het Statusverzoek uit te voeren. 

purchaseID AN..max16 Uniek ordernummer van de webwinkel (bepaald door acceptant) 

amount N..max12 Totaal transactiebedrag in hele eurocenten 

N.B. Merk op dat op de testomgeving het resultaat van een transactie wordt 

beïnvloed door het transactiebedrag. Zie sectie 5.1 voor details. 

currency AN3 Vaste waarde = EUR (op dit moment wordt alleen de Euro ondersteund) 

expirationPeriod RDT Periode waarbinnen de iDEAL-transactie plaats mag vinden. Notatie PT1H 

voor 1 uur, PT10M voor 10 minuten. Maximale waarde: 1 uur. Minimale 

waarde: 1 minuut. Voorgestelde waarde: 10 minuten. 

language CL..2 Vaste waarde = nl (op dit moment wordt alleen Nederlands ondersteund) 

description AN..max32 Omschrijving van de order (bepaald door acceptant) 

entranceCode ANS..max40 Code bepaald door acceptant. Deze code maakt het mogelijk de consument 

te relateren aan een bepaalde transactie bij het terugkeren van de 

consument naar de webwinkel na de betaling. De entranceCode wordt 

middels HTTP(S) GET verstuurd naar de merchantReturnURL. 

acquirerURL n/a URL waar de iDEAL-verzoeken naar verzonden dienen te worden. 

Test omgeving: https://idealtest.secure-ing.com/ideal/iDeal 

Productie omgeving: https://ideal.secure-ing.com/ideal/iDeal 

Formaat Omschrijving 

AN Alfanumeriek, vrije tekst 

ANS Alfanumeriek strikt (alleen letters en cijfers) 

N Numeriek 

PN Numeriek (padded), inhoud wordt aangevuld tot maximale lengte met voorloopnullen 

..23 Maximum aantal posities voor alfanumerieke en numerieke waarden 

CL Code lijst 

RDT Relatieve datum-tijd veld: PnYnMnDTnHnMnS 

Parameters gerelateerd aan het certificaat: 

Parameter Omschrijving 

privateCert Organisatienaam die is opgegeven bij het genereren van het eigen 

certificaat. Zie sectie 3.5 voor details.

iDEAL Advanced - Pronamic

Create successful ePaper yourself

Delete template?

Save as template?