Mollie Api verward over payment status
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
Code (php)
1
2
3
4
5
6
7
8
2
3
4
5
6
7
8
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';
}
{
$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
Donald Boers op 02/11/2015 13:30:12:
Wat ik mij eigenlijk afvraag is waarom Mollie een aparte webhook heeft en een return url. Eigenlijk zouden die twee toch het zelfde kunnen zijn. Afhankelijk van de status kun de dan iemand toch naar een andere View sturen? Of zie ik dat verkeerd?
Dat doen ze waarschijnlijk, omdat niet iedereen op OK, klikt en terug navigeert via die weg naar de website.
Mocht de gebruiker de browser of het schermpje sluiten, is iig de betaling wel verwerkt door de webhook.
Zoals te lezen op die pagina:
"De betaling is aangemaakt, maar er is verder nog niets gebeurd. Voor deze status roept Mollie geen Webhook aan."
Gewijzigd op 02/11/2015 14:05:24 door Randy vsf
a) als iemand betaald heeft en om een of andere reden niet terugkomt op je site (vergeet link te klikken, stroom viel uit, wifi stoorde, moest nodig naar toilet etc) dan heeft hij betaald en jij weet van niets.
b) als iemand de return url weet te raden en zonder betaling door gaat naar de juiste url, dan lever jij een product en krijgt geen geld.
Daarom geeft de payment provider onder water een seintje aan jouw server dat de betaling status ok/nok heeft. Mocht dat mislukken, dan zal het mogelijk enkele minuten later nog een keer gebeuren .
In zo'n geval geef ik de terugkerende klant de melding dat de betaling nog niet verwerkt is maar dat we wachten op een melding van de bank.
@Ivo Ik begrijp wat je bedoeld. Maar er zijn ten aller tijden toch ook mensen die wel de terug gaan naar de website. Hoe zou jou webhook er uitzien. Temeer daar de return url gebasseerd is/moet zijn op wat er in de webhook gebeurt
Op je webhook komen geen bezoekers, nooit. Daarom krijg je de status van Mollie door en die verwerk je in je database. Dat is alles. Er hoeft niet eens iets op te zien te zijn, daar kijkt Mollie toch niet naar.
Op je return url komt de bezoeker. Je haalt uit de database de status (die de webhook heeft doorgegeven) en toont deze aan je bezoeker.
Dat is alles.
De bezoeker zou dus in theorie altijd pas terugkomen nadat de status is doorgegeven.
Maar hou rekening met de incidentele gevallen waarin de status nog niet is doorgegeven en de status dus nog "open" is.
https://github.com/mollie/mollie-api-php/blob/master/examples/2-webhook-verification.php
en in andere voorbeelden juist weer aangeeft dat de update moet plaatsvinden binnen de check
https://www.mollie.com/nl/docs/webhook
Wat is de juiste weg om te kiezen
Toevoeging op 02/11/2015 22:07:47:
Dit is wat ik nu heb:
Code (php)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
public function webhookAction()
{
try
{
require_once (APP_PATH.'/Mollie/API/Autoloader.php');
$mollie = new Mollie_API_Client;
$mollie->setApiKey('live_KNIP');
$payment = $mollie->payments->get($_POST["id"]);
$klant_id = $payment->metadata->klant_id;
$this->artikelen->set_order_status($klant_id, $payment->status);
if ($payment->isPaid() == TRUE)
{
$klant_info = $this->artikelen->get_klant_info($klant_id);
$order = $this->artikelen->get_order_nummer($klant_id);
$cart_items = $this->artikelen->get_email_items($klant_id);
$klant_naam = $klant_info['naam'];
$klant_email = $klant_info['email_adres'];
include_once APP_PATH . '/helpers/verstuur_mail.php';
if ($email)
{
$this->artikelen->delete_cart_items($klant_id);
$this->artikelen->delete_order_status($klant_id);
}
}
elseif ($payment->isOpen() == FALSE)
{
$this->artikelen->delete_cart_items($klant_id);
$this->artikelen->delete_order_status($klant_id);
}
}
catch (Mollie_API_Exception $e)
{
echo "API call failed: " . htmlspecialchars($e->getMessage());
}
}
{
try
{
require_once (APP_PATH.'/Mollie/API/Autoloader.php');
$mollie = new Mollie_API_Client;
$mollie->setApiKey('live_KNIP');
$payment = $mollie->payments->get($_POST["id"]);
$klant_id = $payment->metadata->klant_id;
$this->artikelen->set_order_status($klant_id, $payment->status);
if ($payment->isPaid() == TRUE)
{
$klant_info = $this->artikelen->get_klant_info($klant_id);
$order = $this->artikelen->get_order_nummer($klant_id);
$cart_items = $this->artikelen->get_email_items($klant_id);
$klant_naam = $klant_info['naam'];
$klant_email = $klant_info['email_adres'];
include_once APP_PATH . '/helpers/verstuur_mail.php';
if ($email)
{
$this->artikelen->delete_cart_items($klant_id);
$this->artikelen->delete_order_status($klant_id);
}
}
elseif ($payment->isOpen() == FALSE)
{
$this->artikelen->delete_cart_items($klant_id);
$this->artikelen->delete_order_status($klant_id);
}
}
catch (Mollie_API_Exception $e)
{
echo "API call failed: " . htmlspecialchars($e->getMessage());
}
}
Echter op deze manier wordt wel 6 tot 7 keer een email verzonden. De eerste keer met de juiste artikel gegevens, de andere keren echter zonder artikel gegevens aangezien ik die verwijder wanneer de email word verzonden.
Ik hoop dat het enigsinds begrijpelijk is wat ik bedoel?
Alvast bedankt
Gewijzigd op 11/04/2016 10:22:34 door - Ariën -
Ik had het zelfde probleem en dagen op internet gezocht naar een fix maar niet gevonden, maar het is me nu uiteindelijk zelf toch gelukt.
Ben helemaal overnieuw begonnen en ben 1 voor 1 dingen gaan toevoegen van alle files. Ik kwam erachter dat zodra ik mijn include ('menu.php') erbij zette dat het fout ging. Daarna menu.php uitgeplozen en alles 1 voor 1 uitgezet.
Toen kwam ik erachter dat als ik onderstaande regel verwijder, ik slechts 1 email ontvang ipv 6 stuks achter elkaar:
<link rel="shortcut icon" href="#">
Omdat de post al van vorig jaar is vermoed ik dat je probleem al opgelost is, mocht het niet zo zijn probeer dit dan even, en anders hebben misschien meerdere personen er iets aan :)
Succes!
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.
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
Goedbedoelde tip, maar we kunnen ook gewoon beleefd tegen elkaar praten.
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
Quote:
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.
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