Hoi. Ik ben enigsinds verward over de payment status in the Mollie webook! De open status wat houd die precies in? Iemand betaald en krijgt een succes status van IDEAL en keert terug naar de website. Alleen werk dit niet altijd zoals het hoort heb ik het vermoeden. In mijn ridirect url heb ik namelijk 3 acties staan die worden uitgevoerd op basis van wat de webhook terug stuurd

Voorbeeld In de database zie ik dat iemand gisteren om 16:15 een product in de winkelmand heeft geplaatst en meteen naar IDEAL is gegaan. In de return url heb ik staan dat als status is paid er een email naar mij verstuurd word met de bestelling. Deze email heb ik echter niet binnengekregen. Via de webhook update ik een andere tafel (order_status) voor de orderstatus (paid, cancelled, open). Nu zie ik echter in de tafel order_status dat de status paid pas om 16:24 heeft plaatsgevonden. Maar wel is de klant terug gestuurd naar de return url

Weet niet zo goed wat ik hier mee aanmoet?

Toevoeging op 31/10/2015 10:59:04:

Ik heb inmiddels het email gedeelte verplaatst van de return url naar de webhook

if($payment->status == "paid")
{
	$order_status  = 'paid';
				
	$update_status = $this->artikelen->set_order_status($klant_id,$order_status);
	
	include_once APP_PATH . '/helpers/mail_versturen.php';
}

En nu krijg ik het bericht duw wel binnen, alleen wel 5 tot 6 keer. Ik zie niet wat hiervan de oorzaak is
Maar in de webhook hoort toch ook helemaal geen menu te worden weergegeven (of wat voor html dan ook)?
Is dat een kloppende API key? lol.

Enne, mogelijk heeft TS er allemaal code tussen zitten fietsen?

Dan is het mogelijk een idee om na te gaan wat voor respons Mollie terugverwacht als deze je webhook aanroept? Mogelijk is deze niet goed en probeert ie het 5x opnieuw? Of ga na wat voor tactiek Mollie hierbij anders gebruikt.

Mogelijk kan er een kleine vertraging zitten in het aanroepen van de webhook (middels welke de status wordt geupdate) en het terugkeren naar de website. En als dit alles geen soelaas biedt zou je natuurlijk ook eerst de status lokaal opnieuw kunnen controleren voordat je een mail verstuurt, en vervolgens bijhoudt dat dit is gebeurd.

Dit soort "timing issues" en bijbehorende communicatie waar het een beetje op lijkt zouden in de API documentatie (uitvoerig) beschreven moeten staan?

Dan is e-mail mogelijk niet zo'n fantastisch middel voor logging (omdat hier ook van alles mee mis kan gaan - als je dit voor dit doel gebruikt), neemt dit soort dingen gewoon op in een soort van transactie-historie in je database wellicht?

En de webhook (call) en de return URL dienen inderdaad echt twee compleet verschillende doelen.
De status open is dat er een betaling is aangemaakt maar nog geen actie is geweest op de betaling vanuit de klant.
Er is dus geen geld betaald o.i.d

De webhook die word aangeroepen is om jou script te activeren om bij mollie weer de betaling op te halen zodat geen enkele hacker of iets met de payment status kan klooien.

En haal verdomme je live key weg
>> En haal verdomme je live key weg

Goedbedoelde tip, maar we kunnen ook gewoon beleefd tegen elkaar praten.
Inderdaad. Inmiddels heb ik de key zelf weggepoetst!
Hoi allen.

De problemen die ik in het begin had zijn inmiddels opgelost, door het een en ander inderdaad van elkaar los te koppelen. Ik blijf echter een problemen houden met de email meldingen naar website eigenaar. Al Mollie aan de webhook de status paid meld word er een email naar de eigenaar gestuurd met de klant info en bestelling. Dit gaat 9 van de 10 keer goed, maar die 10de keer krijgt de eigenaar wel de melding van molie maar niet de email met de juiste info
Dit gaat 9 van de 10 keer goed, maar die 10de keer krijgt de eigenaar wel de melding van molie maar niet de email met de juiste info

Wat bedoel je?
- de eigenaar krijgt (soms) geen mail
- de eigenaar krijgt altijd mail, maar soms met verkeerde info
?

Dit lijkt mij sterk? Indien Mollie de webhook aanroept dan wordt vervolgens aan "jouw kant" code uitgevoerd, waaronder het versturen van een e-mailbericht? Het kan niet zo zijn dat dit "soms" werkt. Ik zou dan haast denken dat er ergens iets met de mail misgaat; dat is ook de pest van mail: je kunt enkel "garanties" geven ten aanzien van het verzenden ervan, maar niet van ontvangst, net zoals bij de reguliere post.

Er kan van alles misgaan met het verzenden van mail. Daarom is dit, zoals eerder aangegeven, ook niet echt een fantastisch middel voor logging (als je dit hier voor gebruikt). Los hiervan, het kost tijd voordat mail aankomt, en de volgorde van evementen kan op die manier ook (heel) onduidelijk worden.

Het is sowieso handing en verstandig zelf een *grondige* administratie bij te houden van de status/het statusverloop van een betalingstransactie. Ook zodat je zelf direct gegevens paraat hebt als een klant vragen heeft over een betaling. Een e-mailbericht zou slechts een afspiegeling moeten zijn van deze administratie, maar deze zou niet moeten staan of vallen bij het al dan niet arriveren van dit bericht...

Als het vaak voorkomt dat mailtjes niet aankomen dan is dit een onderzoek waard en/of je bouwt een dashboard voor je eigenaren via welke ze direct een inzage hebben in de historie van het betalingsverkeer, die je sowieso om voorgenoemde redenen bij zou moeten houden.
Hi Thomas.

Het is inderdaad merkwaardig dat het versturen van de e-mails negen van de tien keer goed gaat. Dat doet inderdaad vermoeden dat op de momenten dat het fout gaat de email functie niet wordt uitgevoerd. Ik zit te denken en peinzen hoe ik het anders zou kunnen doen. De website eigenaar vindt het nou eenmaal prettig om de zaken op deze manier af te handelen, zonder steeds te hoeven inloggen om de gegevens van een bepaalde bestelling te kunnen zien. Klant is nou eenmaal koning, hoe graag ik het ook anders zou willen doen. Ik zit nu te denken aan cron-jobs. Als jij andere ideeen hebt hoor ik die graag

Reageren