Mollie webhook call bij lokaal development
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.
op bijvoorbeeld whatismyip.com kun je jouw ip adres zien waarmee je vanaf het www te benaderen bent. Stel dat dat 111.222.333.444 is dan zou je pc te benaderen moeten zijn vanaf http://111.222.333.444. Voor Mollie wordt het dan iets als http://111.222.333.444/webhook.php of iets dergelijks. Ik hoop dat Mollie een ip adres accepteert in de test modus.
Zo niet dan zul je inderdaad een domeinnaam moeten registreren en bij de provider moeten doorlinken naar 111.222.333.444
En wees gewaarschuwd: Als jij je documentroot van buitenaf kunt benaderen dan kan de rest van de wereld dat ook.
Gewijzigd op 23/09/2017 10:21:07 door Frank Nietbelangrijk
Meestal zet je gewoon hard je test response ID omdat deze dan niet zou moeten veranderen, gaat hier dus iets wat anders helaas.
Ik kan hun IP's wel firewallen op poort X, dat is te doen.
Gewijzigd op 23/09/2017 10:33:36 door Wesley Rijnders
project1.mijndomein.nl
project2.mijndomein.nl
etc
Gewijzigd op 23/09/2017 10:34:42 door Frank Nietbelangrijk
Gewijzigd op 23/09/2017 10:41:31 door Wesley Rijnders
Het ligt er een beetje aan hoe je er tegenaan wilt kijken. En je kunt met de instellingen voor je webserver ( lees VirtualHost instellingen ) zorgen dat je vanaf localhost naar directory c:\xampp\htdocs gaat maar vanaf je domein naar c:\xampp\htdocs\wwww bijvoorbeeld. Dan goed weten dat alles wat in de www directory staat publiek is en je hebt niet al te veel problemen meer toch?
Dat heeft weinig met securtiy te maken, je wil development gewoon niet aan publieke dns records hangen.
Dat is jouw uitgesproken mening en dat mag en er is ook iets voor te zeggen maar anderzijds ben je bezig iets te bouwen dat ook op het www moet gaan komen en daar dan ook tegen bestand moet zijn. Anyway het alternatief is natuurlijk telkens je code uploaden... your choice
Maar verder wat Frank zegt. Zo lang jij je ontwikkel (sub-) domein niet aan Google doorgeeft is de kans vrij klein dat er iemand langs komt.
Of ik mis iets maar ik zie de POST request niet op mijn testmachine, ligt dit aan de request welke ik bij Mollie heb gedaan ?
Bedacht ik me later pas: Mollie doet volgens mij een bevestiging via een POST 'via de achterdeur'(direct naar je server), en de gebruiker (voorkant) wordt gewoon via een redirect (zonder verdere info) teruggestuurd naar 'de webshop'. Als je dus die POST van de bevestiging wilt zien moet je je testscript alle calls op laten slaan (want die zie je als gebruiker dus niet in je browser).
Ik moet even wachten op een DNS refresh, die staat laag dus dat ik zo gedaan. Ik hoop dat die post eerder gedaan wordt dan de redirect en ik het optijd af kan vangen.
Toevoeging op 23/09/2017 18:52:22:
Fixed, had de notifyURL nodig :)
Weet iemand of the notify wacht en dan past de return call aanroep @ mollie side ?
Gewijzigd op 23/09/2017 18:23:55 door Wesley Rijnders
De volgorde is wel zoals je omschrijft (eerst notify, dan redirect), maar ze wachten niet. Als je bij een notify 'iets' doet (ik noem maar wat: nog even wat dingen opzoeken - huh, welke order, en het resultaat in een database opslaan) kan het maar zo zijn dat de redirect d'r eerder is (en dus nog geen betalingsbevestiging ziet in de db). Ik heb het in ieder geval zo gemaakt dat als ik bij de redir nog geen betaling zie staan ik even een sleep(1) doe, en dan nog eens kijk (en dat nog een paar keer) (wij slaan alleen geslaagde betalingen op, dus ik kan niet controleren of de gebruiker geannuleerd heeft bij de bank). Dit heeft tot gevolg dat een annulerende gebruiker een paar tellen extra moet wachten, maar het voorkomt in ieder geval dat ik een betalende klant (toch wel het merendeel) een 'niet betaald' melding toon.
Je kan zelf weinig doen tussen de notify, the notify wordt door Mollie verzorgd.
Ik ga die sleep wel even toepassen, hoe pas jij hem toe als ik vragen max ? example (ofzo).
Gewijzigd op 23/09/2017 20:37:27 door Wesley Rijnders
Ik heb het zo even niet bij de hand, maar het was iets van:
Gebruik jij de metadata om je order te matchen als je via die post je id ontvangt en dan de status opvraagt ?
Ik zie in ieder voorbeeld order_id staan, het lijkt me dat je er gewoon in kan knallen tot 1Kb wat je wil ?
$order_id = $payment->metadata->order_id; is wat ik niet helemaal zie, trekt je zo de value van de order_id key welke je eerder in je metadata hebt gezet uit de metadata van die order ? in in je dashboard zie je de metadata namelijk niet.
Ik kan weinig over die functies verder vinden, weinig goede informatie op in de docs van mollie helaas.
https://github.com/mollie/mollie-api-php/blob/master/examples/02-webhook-verification.php ook ziet).
Voor de zekerheid doe ik er nog een hash bij op basis van de order details, en die controleer ik dan ook nog. Gewoon om zeker te weten dat niet iemand maar gewoon die webhook aan zit te pesten met z'n order_id (ik filter niet op die IP-adressen van Mollie, dan moet ik dat weer bij gaan lopen houden).
Sisow doet zoiets nl ook, maar dan vooral omdat die alle info in de returnUrl meegeven. Heeft zo z'n voordelen (niet dat timing probleem wat je dus bij Mollie kan krijgen), maar de gebruiker ziet dan ook de hele URL met alle info voorbij komen (en er zijn er dus zat die van 'Cancelled' toch even 'Success' maken om te kijken of het werkt). Daar krijg je dan een sha1 hash mee die over alle data is genomen + een secret.
Long story short: we ondersteunden al Sisow, die had een hash. Daarna gingen we Mollie doen, en die geef ik dus ook een hash mee. Gewoon omdat het kan, en omdat het betekende dat ik intern wat dingen gelijk kon houden.
De docs zijn inderdaad een beetje wazig. De voorbeelden op GitHub zijn echter vrij goed te volgen, en met een testaccount en de test "TBM bank" is het vrij goed te testen.
Ja, die metadata is gewoon een object met de properties die je d'r zelf in hebt gestopt (wat je hier Voor de zekerheid doe ik er nog een hash bij op basis van de order details, en die controleer ik dan ook nog. Gewoon om zeker te weten dat niet iemand maar gewoon die webhook aan zit te pesten met z'n order_id (ik filter niet op die IP-adressen van Mollie, dan moet ik dat weer bij gaan lopen houden).
Sisow doet zoiets nl ook, maar dan vooral omdat die alle info in de returnUrl meegeven. Heeft zo z'n voordelen (niet dat timing probleem wat je dus bij Mollie kan krijgen), maar de gebruiker ziet dan ook de hele URL met alle info voorbij komen (en er zijn er dus zat die van 'Cancelled' toch even 'Success' maken om te kijken of het werkt). Daar krijg je dan een sha1 hash mee die over alle data is genomen + een secret.
Long story short: we ondersteunden al Sisow, die had een hash. Daarna gingen we Mollie doen, en die geef ik dus ook een hash mee. Gewoon omdat het kan, en omdat het betekende dat ik intern wat dingen gelijk kon houden.
De docs zijn inderdaad een beetje wazig. De voorbeelden op GitHub zijn echter vrij goed te volgen, en met een testaccount en de test "TBM bank" is het vrij goed te testen.
Er zitten wat haken en ogen aan mollie inderdaad, ik kom vanaf omnikassa wat ook zo zijn voordelen had in implementatie, Sisow was prijstechnisch verre van interessant.
Maar zoals gezegd: ik was gewend aan een hash, dus heb ik er nog maar 1 toegevoegd als een eerste/extra check.
Sisow is inderdaad 'vrij duur', en keert ook minder uit als je reseller bent ;-)
Wat is jouw opinie over een hashed URL waar je je notify naartoe laat sturen ? Dat ding is dan wel status maar minder goed te raden zodat ze kunnen gaan posten op een single Id wat opzich wat vervelend kan worden.
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.