[Ideal] Rabo Professional
Hallo beste mensen,
Voor een organisatie heb ik een kleine betaalmodule gemaakt die het online bestellen van artikelen mogelijk maakt door middel van Rabobank Ideal Professional.
Momenteel wordt er via mij site de gegevens gegenereert en doorgestuurd naar de rabobank betaalomgeving, zo ook wordt de client naar die betaalomgeving doorgestuurd. Er wordt een cookie geset met het betaalkenmerk en een timecode waar ik later nog op terugkom
Als de client de betaling heeft afgerond, wordt deze doorgestuurd naar de success pagina waarna alleen cookie van het betaalkenmerk en de timecode gevalideerd wordt. Als deze overeenkomt dan krijgt de administrator een bevestiging en wordt het geupdate in de mysql database.
Maarnu, afgezien van het feit dat het waarschijnlijk niet echt veilig is, en vanwege het feit dat sommige users geen cookie kunnen zetten ivm browser settings, vroeg ik me af hoe ik dit beter kan oplossen. Vandaar dat ik even hier aan wilde kloppen of iemand hier meer ervaring mee heeft hoe ik de betaling beter kan valideren en dat gebruikers geen problemen kunnen ondervinden.
Overigens, het betaalkenmerk is iets als dit: FBXCLWJ-51526-MF, dus het is vrij lastig om het te omzeilen. Het gaat dus vooral om de cookies weg te werken.
Ik hoor graag van jullie. Alvast bedankt!!
Met vriendelijke groet,
Reno
PS. Is het optioneel of essentieel om een SSL certificaat aan te schaffen voor op de website??
Voor een organisatie heb ik een kleine betaalmodule gemaakt die het online bestellen van artikelen mogelijk maakt door middel van Rabobank Ideal Professional.
Momenteel wordt er via mij site de gegevens gegenereert en doorgestuurd naar de rabobank betaalomgeving, zo ook wordt de client naar die betaalomgeving doorgestuurd. Er wordt een cookie geset met het betaalkenmerk en een timecode waar ik later nog op terugkom
Als de client de betaling heeft afgerond, wordt deze doorgestuurd naar de success pagina waarna alleen cookie van het betaalkenmerk en de timecode gevalideerd wordt. Als deze overeenkomt dan krijgt de administrator een bevestiging en wordt het geupdate in de mysql database.
Maarnu, afgezien van het feit dat het waarschijnlijk niet echt veilig is, en vanwege het feit dat sommige users geen cookie kunnen zetten ivm browser settings, vroeg ik me af hoe ik dit beter kan oplossen. Vandaar dat ik even hier aan wilde kloppen of iemand hier meer ervaring mee heeft hoe ik de betaling beter kan valideren en dat gebruikers geen problemen kunnen ondervinden.
Overigens, het betaalkenmerk is iets als dit: FBXCLWJ-51526-MF, dus het is vrij lastig om het te omzeilen. Het gaat dus vooral om de cookies weg te werken.
Ik hoor graag van jullie. Alvast bedankt!!
Met vriendelijke groet,
Reno
PS. Is het optioneel of essentieel om een SSL certificaat aan te schaffen voor op de website??
Lees de documentatie van Rabobank er eens op na of kijk naar de code van anderen:
http://www.rabobank.nl/images/pdf_20130703_ideal_merchant_integratie_gids_v3_3_1_nl_juli_2013_29542840.pdf
https://www.ideal-checkout.nl/idealprofessional
http://www.rabobank.nl/images/pdf_20130703_ideal_merchant_integratie_gids_v3_3_1_nl_juli_2013_29542840.pdf
https://www.ideal-checkout.nl/idealprofessional
Gewijzigd op 29/09/2013 16:39:45 door Ward van der Put
Op het moment dat je een transactie start bij ideal krijg je een transactionId terug. deze moet je opslaan in je database. Minimaal zet je er ook de status bij en een timestamp, maar je kunt gelijk ook extra info opslaan zoals je eigen ordernummer.
als een klant terugkomt op je site dan krijg je een trxid en een ec mee. de eerste staat weer voor hetzelfde als transactionId en hieraan kun je dus al herkennen om welke betaling het gaat. de ec is hetzelfde als de EntranceCode die je ook meegegeven hebt bij het starten van de transactie. (het verschil met de transactionId is dat je zelf mag weten wat je EntranceCode is. het transactionId wordt door ideal bepaalt). Met deze gegevens moet je alle bijbehorende informatie weer uit je database kunnen halen en de status moet je dan weer bijwerken in je database.
Waar je verder nu niet over praat maar wat wel een veel voorkomende fout is, is het feit dat je er van uit gaat dat ook elke klant terugkeert naar je webshop nadat ie betaald heeft of de betaling geannuleerd heeft. In de praktijk is dit echter absoluut niet altijd het geval. Je moet dus ook nog periodiek de status ophalen van de transactionId's die nog de status 'Open' hebben zodat de statussen van de mensen die niet terugkeren alsnog bijgewerkt worden. Een reden te meer om met een database te werken. Hierdoor worden de cookies dan inderdaad ook overbodig.
als een klant terugkomt op je site dan krijg je een trxid en een ec mee. de eerste staat weer voor hetzelfde als transactionId en hieraan kun je dus al herkennen om welke betaling het gaat. de ec is hetzelfde als de EntranceCode die je ook meegegeven hebt bij het starten van de transactie. (het verschil met de transactionId is dat je zelf mag weten wat je EntranceCode is. het transactionId wordt door ideal bepaalt). Met deze gegevens moet je alle bijbehorende informatie weer uit je database kunnen halen en de status moet je dan weer bijwerken in je database.
Waar je verder nu niet over praat maar wat wel een veel voorkomende fout is, is het feit dat je er van uit gaat dat ook elke klant terugkeert naar je webshop nadat ie betaald heeft of de betaling geannuleerd heeft. In de praktijk is dit echter absoluut niet altijd het geval. Je moet dus ook nog periodiek de status ophalen van de transactionId's die nog de status 'Open' hebben zodat de statussen van de mensen die niet terugkeren alsnog bijgewerkt worden. Een reden te meer om met een database te werken. Hierdoor worden de cookies dan inderdaad ook overbodig.
Dag heren,
bedankt voor jullie hulp! Ik zal het eens goed door gaan kijken en aanpassen. Ik vond cookies zoiezo al een slecht idee.
@Frank: Dank voor de tip, had ik inderdaad nog niet echt bij stilgestaan.
Die Entrance-Code, weetje toevallig welke dat precies is?
Danku
bedankt voor jullie hulp! Ik zal het eens goed door gaan kijken en aanpassen. Ik vond cookies zoiezo al een slecht idee.
@Frank: Dank voor de tip, had ik inderdaad nog niet echt bij stilgestaan.
Die Entrance-Code, weetje toevallig welke dat precies is?
Danku
De EntranceCode die maak je zelf aan. De PDF van ward zijn eerste link op bladzijde 21.
Frank, ik ben niet zo thuis in de iDEAL-variant van Rabobank, maar mijn PSP heeft nog een alternatief: de server van de PSP kan een wijziging van de transactiestatus terugposten naar een verborgen URL op je eigen server. Zo hoef je zelf de status niet meer te controleren en heb je een tweede controleproces, dat helemaal los staat van wat de koper doet.
Kan dit niet ook bij Rabobank?
Kan dit niet ook bij Rabobank?
Ward, zo ver ik weet heeft ideal geen PUSH notifications. (dat is toch wat je bedoelt?) bijvoorbeeld paypal heeft dat wel en je mag dan als merchant zelf weten of je daar gebruik van maakt of niet. Zij noemen dat IPN of "Instant Payment Notifications". Overigens is dat een zeer uitgebreide service. Ideal heeft dat niet.
Dank je Frank!
Ik ga eens wat PHP-bestanden afstoffen om te kijken hoe ze het precies doen. Uit het hoofd: er staat sowieso een IP whitelist via SSL op de URL, zodat een vervalsing van de PSP-respons vrijwel uitgesloten is.
Ik ga eens wat PHP-bestanden afstoffen om te kijken hoe ze het precies doen. Uit het hoofd: er staat sowieso een IP whitelist via SSL op de URL, zodat een vervalsing van de PSP-respons vrijwel uitgesloten is.
Zoals beloofd, heb ik nog even gekeken hoe mijn PSP de iDEAL-terugkoppeling aanpakt. Dat gaat grofweg zo:
1. Je roept met cURL de server van de PSP aan. Daarbij geef je een openbare return-URL en een geheime report-URL door. De report-URL is optioneel.
2. De PSP zet een iDEAL-transactie klaar en antwoordt met onder andere de URL van de iDEAL-bank van de klant.
3. Je redirect de client naar de URL van de gekozen bank.
4. Is de iDEAL-transactie betaald (of mislukt), dan rapporteert de PSP dat via de geheime report-URL.
5. De klant kan daarna terugkeren naar de openbare return-URL, maar dat hoeft niet, zoals Frank inderdaad aangaf.
Dit systeem is waterdicht. Je vangt het slagen/mislukken van de iDEAL-transactie namelijk niet af via de openbare return-URL, maar achter de schermen met de geheime report-URL.
Bovendien is de report-URL te beveiligen met een IP-whitelist (met uitsluitend IP-nummers van de PSP) en kun je daaraan zelf nog versleutelde data toevoegen (bijvoorbeeld een order- of factuurnummer).
1. Je roept met cURL de server van de PSP aan. Daarbij geef je een openbare return-URL en een geheime report-URL door. De report-URL is optioneel.
2. De PSP zet een iDEAL-transactie klaar en antwoordt met onder andere de URL van de iDEAL-bank van de klant.
3. Je redirect de client naar de URL van de gekozen bank.
4. Is de iDEAL-transactie betaald (of mislukt), dan rapporteert de PSP dat via de geheime report-URL.
5. De klant kan daarna terugkeren naar de openbare return-URL, maar dat hoeft niet, zoals Frank inderdaad aangaf.
Dit systeem is waterdicht. Je vangt het slagen/mislukken van de iDEAL-transactie namelijk niet af via de openbare return-URL, maar achter de schermen met de geheime report-URL.
Bovendien is de report-URL te beveiligen met een IP-whitelist (met uitsluitend IP-nummers van de PSP) en kun je daaraan zelf nog versleutelde data toevoegen (bijvoorbeeld een order- of factuurnummer).
Dank voor de info, maar als ik het goed begrijp is dat push/PSP notification niet mogelijk bij de rabobank?
Hartelijk dank !
Hartelijk dank !
Gewijzigd op 03/10/2013 11:12:13 door Reno L
Reno L op 03/10/2013 11:11:34:
Dank voor de info, maar als ik het goed begrijp is dat push/PSP notification niet mogelijk bij de rabobank?
Rabobank heeft het in paragraaf 6.4 in haar iDEAL Merchant Integratie Gids [PDF] over een “haalplicht”:
Rabobank:
De Merchant dient een StatusRequest uit te voeren wanneer de Consument terecht komt op de pagina waarnaar hij is teruggeleid door de Issuer (de merchantReturnURL uit het TransactionRequest). Het kan echter zo zijn dat de Consument zijn browserwindow sluit voordat hij terugkeert op de merchantReturnURL. Merchants moeten ook in dat geval een StatusRequest voor de transactie uitvoeren. Er geldt een zogenaamde “haalplicht” t.a.v. het resultaat van de transactie. Aan deze haalplicht kan voldaan worden door voor elke transactie het StatusRequest uit te voeren als de expiration period (opgegeven in de TransactionRequest) is verlopen en er nog geen definitieve status verkregen is.
Ik lees dat als: je moet altijd zelf de status controleren. Zowel wanneer de consument terugkeert als wanneer de consument het browservenster sluit.
Ahh okee, wel dat is geen probleem. Ik was zoiezo van plan elk kwartier een cronjob te laten lopen die openstaande betalingen valideert.
Bedankt voor de hulp!
Bedankt voor de hulp!




