[Ideal] Rabo Professional
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??
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
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.
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.
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.
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.
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).
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.
Bedankt voor de hulp!