Mollie webhook call bij lokaal development

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.

[size=xsmall]Toevoeging op 23/09/2017 18:52:22:[/size]

Fixed, had de notifyURL nodig :)

Weet iemand of the notify wacht en dan past de return call aanroep @ mollie side ?

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.

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).

Ik heb het zo even niet bij de hand, maar het was iets van:

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');

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.

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.

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.

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

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.

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.