Ik ben bezig een Mollie te implementeren in mijn applicatie maar merk dat ik een probleem heb met de webhookcall en mijn lokale ontwikkeling in testmodus.
Klopt het dat ik de return URL met een DNS record moet directen naar mijn lokale IP-adres ? Dit lijkt me voor testmodus wat ongemakkelijk.
Op één of andere manier moet ik toch de id van de molliepayment terug kunnen krijgen tijdens het ontwikkelen.
Sisow doet beide:
- Initieel vertrouwen ze op de returnUrl, waarbij dus de hele rambam in 1x via de client wordt teruggeketst (met controle hash).
- Maar je kunt ook nog een callbackUrl meegeven waarmee ze een server-to-server terugkoppeling doen. Maar die komt dus vaak pas 'een tijdje later' (een kwartier klinkt wel herkenbaar).
Maar dat moet de webshop bouwert dan dus wel ingebouwd hebben. Je moet het nl apart aangeven op het moment dat je een payment link aanvraagt bij Sisow, en dat gebeurt idd niet altijd. Waardoor je dus bij sommige webshops niet moet vergeten om "terug naar de webwinkel" te klikken.
En zo zijn er natuurlijk ook nog legio webshops die die hele hash niet controleren en dus echt op de data in de GET vertrouwen. Dan kun je dus op "Annuleren" klikken bij je bank, en vervolgens zelf "Success" in de URL typen ...
Ik heb zelf nooit met Sisow te maken gehad maar ik vind dat maar vreemd dat je een server-to-server koppeling apart moet aanvragen. Ik zou mijn klanten als ik Sisow was duidelijk uitleggen dat ze die koppeling toch echt beter wel kunnen gebruiken. Het is voor een payprovider overigens ook mogelijk om te controleren of een klant de koppeling gebruikt ja dan de nee, iig tot aan de response die teruggegeven wordt door jouw applicatie op de koppeling.
Mijn gevoel zegt me dat Sisow meer uit de frôbel PHP hoek komt (of daar op mikt). Basis eerst, rest (beveiliging) "kan later altijd nog". Dus eerst alle params uit de GET halen, die hash "kan later altijd nog". Eerst via die returnUrl, als blijkt dat mensen niet altijd "terug naar de webshop" gaan, alsnog die callbackUrl inbouwen.
Mollie (meer ervaring heb ik ook niet met payment providers) voelt wat meer doordacht+degelijker. Maar komt dus ook wat meer bij kijken. Als je al via Composer werkt is het gewoon een regeltje d'r bij, maar voor Sisow hoef je maar één file te includen (meer is er ook niet).
Sisow zal dus voor een beginner heel snel op te pakken zijn, maar omdat het zo makkelijk is, en niets hoeft, laat je ook makkelijk gaten vallen (hash niet controleren, geen registratie als de klant niet "terug naar webshop" klikt = gezeik).
Een beetje zoals de gemiddelde vragensteller hier altijd roept dat ze "de beveiliging later wel op orde maken" als ze op SQLi e.d. gewezen worden (met een SSL certificaat) ;-)
Sisow doet beide:
- Initieel vertrouwen ze op de returnUrl, waarbij dus de hele rambam in 1x via de client wordt teruggeketst (met controle hash).
- Maar je kunt ook nog een callbackUrl meegeven waarmee ze een server-to-server terugkoppeling doen. Maar die komt dus vaak pas 'een tijdje later' (een kwartier klinkt wel herkenbaar).
Aha, nu begrijp ik het: je moet inderdaad haast wel de return-URL gebruiken als de callback zo idioot lang op zich laat wachten. Dat is gewoon niet werkbaar anders!
Ik heb ooit iDeal geïmpementeerd rechtstreeks bij "iDeal". Dat was dan een klein beetje, maar niet veel, verschillend voor bijvoorbeeld Rabobank en Abn-Amro.
Daarin was in de procdure vastgelegd, dat in principde de callback eerst kwam.
Maar ik ben niet 100% zeker of die callback daar ook bestond.
Maar komt je klant eerder terug dan de callback, dan moest je zelf de status opvragen.
Was die niet Success of Failure, en dus nog iets van "bezig", dan moest je gedurende 24 uur (of meer) op intervallen van een half uur of zo, steeds pollen of de status al definitief was.
En was het "success", dan alsnog de bestelling in werking stellen en klant mailen.
Dat kan de vertraging van een kwartier ook verklaren.
Nadeel was, dat je scripts voor een Rabobank klant net niet helemaal werkten als de volgende klant (als in klant voor de websitebouwer) bij de Abn zat.
En dan had Rabo vlak daarna ook een tussenvorm Internetkassa.
Maar uiteindelijk werkt het mi. via Mollie en dergelijke partijen het fijnst, omdat je dan naast iDeal ook nog zo vele andere methoden kunt aanvinken. Zonder al je scripts om te gooien
