ideal Advanced ING Wholesale Banking Integratiehandleiding PHP voor ideal Advanced Versie 2.3, april 2010 Inhoud

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


Pag 3 van 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 (±).


Pag 4 van 26


1.3

1.4

-

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.

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 [email protected] 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.

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


Pag 5 van 26


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


Pag 6 van 26


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.


Pag 7 van 26


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 van het iDEAL Advanced Integration PHP package, te vinden onder de menu-optie Documentatie.


Pag 8 van 26


In een Linux testen productie-omgeving:

3.2

-

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 van het iDEAL Advanced Integration PHP package, te vinden onder de menu-optie Documentatie.

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


Pag 9 van 26


3.3

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

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:

•

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

https://idealtest.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


Pag 10 van 26


MerchantReturnURL=http://[yourwebpage]/StatReq.php ExpirationPeriod=PT10M LogFile=<path-to>/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.


Pag 11 van 26


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=<eigenWachtwoord> Privatecert=cert.cer

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


Pag 12 van 26


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.


Pag 13 van 26


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.


Pag 14 van 26


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 ) { $errorCode = $response->getErrorCode(); $errorMsg = $response->getErrorMessage(); $consumerMessage = $response->getConsumerMessage(); } else { $IssuerList =& $response->getIssuerFullList(); }

Periodiek aanroepen 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 }


Pag 15 van 26


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.


Pag 16 van 26


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.

•


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.


Pag 17 van 26


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.


Pag 18 van 26


•

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.


De voorbeeldcode voor de aanroep van RequestTransactionStatus kan bijvoorbeeld als volgt zijn: $response = $connector->RequestTransactionStatus( $transactionId ); if ( ! $response ) { $errorCode = $response->getErrorCode(); $errorMsg = $response->getErrorMessage(); $consumerMessage = $response->getConsumerMessage(); // Voeg toe: tonen van de consumerMessage } else { $status =& $response->getStatus(); if ( $status === IDEAL_TX_STATUS_SUCCESS ) { $consumerName = $response->getConsumerName(); $consumerAccNumber = $response->getConsumerAccountNumber(); $consumerCity = $response->getConsumerCity(); } }

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


Pag 19 van 26


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.


Pag 20 van 26


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:


Pag 21 van 26


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()) { $errorCode = $response->getErrorCode(); $errorMsg = $response->getErrorMessage(); $consumerMessage = $response->getConsumerMessage(); }

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()) { $errorCode = $response->getErrorCode(); $errorMsg = $response->getErrorMessage(); $consumerMessage = $response->getConsumerMessage(); // voeg toe:

Tonen van $consumerMessage op scherm

} waarbij “xxxx” een willekeurige functie voorstelt.


Pag 22 van 26


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


Pag 23 van 26


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


Cancelled


Expired


Open


Failure


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.


Pag 24 van 26


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.


Pag 25 van 26


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.


Pag 26 van 26

ideal Advanced ING Wholesale Banking Integratiehandleiding PHP voor ideal Advanced Versie 2.3, april 2010 Inhoud

Recommend Documents