search

pronamic / wp-pronamic-pay-mollie

Mollie driver for the WordPress payment processing library.
http://www.wp-pay.org/gateways/mollie/
6 stars 1 forks source link

Retry recurring payment on connection timeout #50

Closed rvdsteege closed 3 months ago

rvdsteege commented 3 months ago

We retry starting a recurring payment for some specific API error codes. However, it came to our attention in a support ticket that payments for which a connection timeout occurs, are not retried again. Can we retry these payments too?

https://github.com/pronamic/wp-pronamic-pay-mollie/blob/cb385db811df5f91fd18494139f07d295189788f/src/Gateway.php#L497-L547

Internal Help Scout ticket: https://secure.helpscout.net/conversation/2557833108/27086

remcotolsma commented 3 months ago

Mollie mentions the following for a number of statuses:

Retry the request at a later time.

Scherm­afbeelding 2024-04-02 om 13 30 39

All possible status codes

The Mollie API will only ever return a subset of all legal HTTP status codes. Here’s the full list:

Status Description
200 OK – Your request was successful.
201 Created – The entity was created successfully.
204 No Content – The requested entity was canceled / deleted successfully.
400 Bad Request – The Mollie API was unable to understand your request. There might be an error in your syntax.
401 Unauthorized – Your request was not executed due to failed authentication. Check your API key.
403 Forbidden – You do not have access to the requested resource.
404 Not Found – The object referenced by your URL does not exist.
405 Method Not Allowed – You are trying to use an HTTP method that is not applicable on this URL or resource. Refer to the Allow header to see which methods the endpoint supports.
409 Conflict – You are making a duplicate API call that was probably a mistake (only in v2).
410 Gone – You are trying to access an object, which has previously been deleted (only in v2).
415 Unsupported Media Type – Your request’s encoding is not supported or is incorrectly understood. We recommend to always use JSON.
422 Unprocessable Entity – We could not process your request due to another reason than the ones listed above. The response usually contains a field property to indicate which field is causing the issue. If your account is suspended, visit your dashboard for more information.
429 Too Many Requests – Your request has hit a rate limit. You can try again after a short period.
500 Internal Server Error – An internal server error occurred while processing your request. Our developers are notified automatically, but if you have any information on how you triggered the problem, contact us.
502 Bad Gateway – The service is temporarily unavailable, either due to calamity or (planned) maintenance. Retry the request at a later time.
503 Service Unavailable – The service is temporarily unavailable, either due to calamity or (planned) maintenance. Retry the request at a later time.
504 Gateway Timeout – Your request is causing an unusually long process time.

I suggest that we follow Mollie's advice as much as possible. Retrying is not mentioned in status 504 Gateway Timeout, so that may not be best practice. I also think that there is more likely to be a problem with the web hosting of the customer in question.

rvdsteege commented 3 months ago

The issue is unrelated to the Mollie API and not the same as a 504 Gateway Timeout response by Mollie. We can still continue to follow Mollie's advice regarding retrying for specific API status codes and also improve reliability of recurring payments when unexpected networking issues occur, in which case our requests have not even reached the Mollie API.

All kind of different (temporary) connection issues can occur, for example:

The payment may still be started with a new attempt in the 24 hours of the retry mechanism, instead of the subscription being placed 'On hold' immediately due to a failed payment and administrators needing to manually retry the failed payment(s).

remcotolsma commented 3 months ago

I get your point, but I also understand Mollie's view on how to deal with timeouts. We can try again a number of times, but there is no guarantee that it will go well the next time. If a website is always operating on the edge of network timeouts towards the Mollie API, then i think the focus should be on solving that problem. At the customer in question we regularly see that the REST API requests reach the 5 second timeout limit. I think a timeout of 5 seconds should generally be more than sufficient. According to Gemini, a REST API request between, for example, America and the Netherlands would take an average of 100 milliseconds. Apart from this, we have already made some adjustments for the background requests so that a higher timeout is allowed there (https://github.com/pronamic/wp-pay-core/issues/170). The customer in question is still running an outdated PHP version and could update it to 8 or higher. The Pronamic Pay plugin can then be updated and the problem may be solved. If we see this problem more often with other Pronamic Pay users, we can always reconsider, but for now I have the feeling that the problem is mainly limited to this customer.