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.
De callback loopt bij Mollie sowieso van server naar server. Maar het staat 'een ander' natuurlijk vrij om de server ook via diezelfde achterdeur aan te pesten. Dat wil je voorkomen. Dat gebeurt dus 1) al omdat je zelf de payment gegevens bij Mollie ophaalt (dus iemand kan op de achterdeur kloppen met wat ie wilt, je haalt zelf de gegevens op, dus dat valt niet te faken), en 2) voor de zekerheid geef je nog een hash mee die ze niet weten + niet kunnen gokken.
Bij Sisow staat wel alle info in redir / client URL, en die wordt daar beveiligd door een hash mee te geven. Die hash gaat over alle data in de URL (id, status, enz) *en* nog een secret dat niet in de URL staat (maar wel aan beide zijde bekend is). Door deze hash dus na te rekenen kun je achterhalen of er met de URL geklooid is (= dus ook veilig).
Je wilt sowieso niet de client een rol van betekenis geven. De callback met statusupdate moet daarom van server naar server lopen, niet via de client. Zolang je dat niet goed doet en de client-URL's gaat "beveiligen", tussen aanhalingstekens, heb je een tweederangs oplossing.
Je kan prima de client een GET laten doen en daar de check op uitvoeren hoor, je bent dan nog steeds zelf in control in je code, niets vreemds aan.
Ik wil het nog wel een keer uitleggen, deze keer wat langzamer, zodat je 'm misschien vat:
- Je hebt een stel params: $status, $id, $whatever; deze komen allemaal in de URL (GET) vanuit Sisow.
- Je hebt een $secret; die komt niet in de URL (maar beide zijden weten 'm).
- Sisow berekent een hash($status . $id . $whatever . $secret); die geven ze ook mee in de URL (GET).
- Aan de ontvangende kant maak je nu dezelfde som: hash($status . $id . $whatever . $secret) (eerste 3 uit de GET, secret weet je).
- Die controleer je met de hash uit de GET. Als die niet gelijk zijn weet je dus dat er geknoeid is met de $status, $id, of $whatever (en dat gebeurt regelmatig).
Mocht je hier toch mogelijkheden zien om daar omheen te komen, dan kun je vanaf nu gratis bestellen bij webshops die hun betalingen via Sisow laten lopen (gewoon Annuleren bij je bank, in de return URL status=Success zetten, en even zelf de hash uitrekenen). Succes(s) ...
Daar ging het niet om, het ging erom dat een client die een hash aanroept helemaal niet zo'n probleem is, hoe denk je anders dat een wachtwoord reset werkt ?
het vervelende van de route via de client is, dat je nooit 100% zekerheid hebt dat de klant ook werkelijk terugkomt.
Ik heb het zelf ooit gehad dat de redirect vanuit ideal naar de webshop misliep: url was niet bereikbaar. Misschien een overbelasting bij de (best grote) webshop, of een hik van de server. In elk geval had ik wel betaald, maar dat was niet bekend bij de shop.
Klantenservice kon vervolgens na contact niet leveren. Wel uiteindelijk geld retour gekregen maar producten waren al uitverkocht. Kennelijk triggerde die shop ook alleen maar op "klant komt terug". Of dat dan inclusief de hash was, of dat er ook een server-to-server contact was geweest, weet ik niet. Wel dat de webshop er ten onrechte vanuit ging dat de klant per se terug komt na de de betaling.
Ja klopt je moet het wel iets beter doen, het ging me meer om het verhaal een gehashte url wat prima kan.
Weet iemand waar Mllie de BetalingsId op baseert ? Het lijkt me dat er zeker wel duplicates in hun DB zitten namelijk en iedereen met die ID aan de haal kan gaan.
Het gaat me niet om de veiligheid van de hash, maar om het blindelings vertrouwen op een client request.
Zo'n 5 procent van de bezoekers die afrekenen met iDEAL, klikt in het laatste scherm niet op "terug naar de webwinkel". Nee, die sluiten gewoon het browservenster: betaald, klaar. Die GET met of zonder hash komt er dan dus nooit.
Precies wat Ward zegt gebeurde mij laatst bij een gerenommeerde webshop. Terwijl ik de tab in de browser sloot dacht ik: Oops ik had eerst terug moeten keren naar de webshop. Was ik even blij dat het om een grote bekende speler ging! Na een kwartiertje kwam netjes de bevestigingsmail binnen. Zonder server-to-server verbinding had die er nooit gekomen.
