Mollie webhook call bij lokaal development

Overzicht Reageren

Sponsored by: Vacatures door Monsterboard

Pagina: 1 2 volgende »

Wesley Rijnders

Wesley Rijnders

23/09/2017 10:06:53
Quote Anchor link
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.
 
PHP hulp

PHP hulp

28/01/2022 13:46:08
 
Frank Nietbelangrijk

Frank Nietbelangrijk

23/09/2017 10:18:02
Quote Anchor link
Je zult port 80 moeten forwarden naar je lokale ip adres in je router zodat je jouw lokale webserver van buiten af kunt benaderen. Tip: controleer met je mobiel met wifi uitgeschakeld of je je pc kunt benaderen.

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
 
Wesley Rijnders

Wesley Rijnders

23/09/2017 10:29:51
Quote Anchor link
Exact wat je zegt ben ik daar niet heel gelukkig mee in een ontwikkelomgeving....

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
 
Frank Nietbelangrijk

Frank Nietbelangrijk

23/09/2017 10:33:45
Quote Anchor link
Klopt. Maar wil je serieus aan de slag dan is een domeinnaam voor je ontwikkel server wel makkelijk. Kun je gelijk een subdomein maken voor ieder nieuw project.

project1.mijndomein.nl
project2.mijndomein.nl
etc
Gewijzigd op 23/09/2017 10:34:42 door Frank Nietbelangrijk
 
Wesley Rijnders

Wesley Rijnders

23/09/2017 10:40:56
Quote Anchor link
domeinen zijn niet het probleem, voor lokaal ontwikkeling wil je gewoon zo min mogelijk aan het publieke domein hangen.
Gewijzigd op 23/09/2017 10:41:31 door Wesley Rijnders
 
Frank Nietbelangrijk

Frank Nietbelangrijk

23/09/2017 10:46:07
Quote Anchor link
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?
 
Wesley Rijnders

Wesley Rijnders

23/09/2017 10:47:38
Quote Anchor link
Dat heeft weinig met securtiy te maken, je wil development gewoon niet aan publieke dns records hangen.
 
Frank Nietbelangrijk

Frank Nietbelangrijk

23/09/2017 10:52:15
Quote Anchor link
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
 
Rob Doemaarwat

Rob Doemaarwat

23/09/2017 11:10:09
Quote Anchor link
Je kunt ze ook gewoon naar 'een' publieke URL sturen (bijvoorbeeld een testbestandje, die meteen de hele $_REQUEST op het scherm plempt. Dat neem je dan weer over naar je lokale testomgeving, en dan kun je kijken of het werkt.

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.
 
Wesley Rijnders

Wesley Rijnders

23/09/2017 18:06:31
Quote Anchor link
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 ?
 
Rob Doemaarwat

Rob Doemaarwat

23/09/2017 18:10:30
Quote Anchor link
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).
 
Wesley Rijnders

Wesley Rijnders

23/09/2017 18:16:37
Quote Anchor link
Ja dat klopt, daar was ik al achter echter zie ik geen POST binnen komen in mijn access.log, opzich wel vreemd.

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
 
Rob Doemaarwat

Rob Doemaarwat

23/09/2017 20:14:58
Quote Anchor link
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.
 
Wesley Rijnders

Wesley Rijnders

23/09/2017 20:30:50
Quote Anchor link
OK, dank je voor je uitleg.

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
 
Rob Doemaarwat

Rob Doemaarwat

23/09/2017 21:46:16
Quote Anchor link
Ik heb het zo even niet bij de hand, maar het was iets van:
Code (php)
PHP script in nieuw venster Selecteer het PHP script
1
2
3
4
5
6
7
for($i = 3; $i >= 0; $i--){
  $betaald = check_betaling_ontvangen();
  if($betaald) break; //alles OK
  if($i) sleep(1); //alleen slapen als er nog een retry volgt
}
if($betaald) print('Betaald');
else print('Niet betaald');
 
Wesley Rijnders

Wesley Rijnders

23/09/2017 22:13:57
Quote Anchor link
OK, wel duidelijk.

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.
 
Rob Doemaarwat

Rob Doemaarwat

23/09/2017 23:13:19
Quote Anchor link
Ja, die metadata is gewoon een object met de properties die je d'r zelf in hebt gestopt (wat je hier 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.
 
Wesley Rijnders

Wesley Rijnders

24/09/2017 06:32:02
Quote Anchor link
Ik ben het helemaal met je eens, ik zat ook te denken aan een hash omdat die webhook best makkelijk is te pesten inderdaad. Wellicht is het al beter om je notifyUrl een hash te maken zodat niet iedereen die zomaar kan raden, ondemand zou het mooiste zijn maar dat is niet te doen, hoewel dat is het wel!

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.
 
Rob Doemaarwat

Rob Doemaarwat

24/09/2017 10:42:23
Quote Anchor link
Op zich kan er niks fout gaan, want ook als iemand de notifyUrl aan loopt te pesten haal je zelf altijd nog de payment gegevens op bij Mollie via payment->get(), en met die gegevens controleer je de betaling ( isPaid() ). Zolang de DNS van je server dus niet gespoofd wordt kunnen ze schieten wat ze willen.

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 ;-)
 
Wesley Rijnders

Wesley Rijnders

24/09/2017 11:46:44
Quote Anchor link
Ik heb ook liever een extra check ;)

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.
 
Ward van der Put
Moderator

Ward van der Put

24/09/2017 12:38:16
Quote Anchor link
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.
 

Pagina: 1 2 volgende »



Overzicht Reageren

 
 

Om de gebruiksvriendelijkheid van onze website en diensten te optimaliseren maken wij gebruik van cookies. Deze cookies gebruiken wij voor functionaliteiten, analytische gegevens en marketing doeleinden. U vindt meer informatie in onze privacy statement.