Payment via PayPal sometimes results in duplicate purchases #673
Comments
|
Looking in the access logs reveals that multiple calls are being made to the callback: This one resulted in multiple purchases being created. Of note are the the purchase IDs, which are 365 and 366, the latter being accessed via This one resulted in just a single purchase being created, despite the callback being called multiple times. Presumably the There are instances where only a single request to the callback route is made though: There's also this one, which calls the callback route twice but with different return codes. This one also resulted in just a single purchase being created... This seems to be the normal behavior for the site, a 301 redirect followed by the 302 to (presumably) the success page. I think this might actually be a misconfiguration of our web server, or rather the proxy in front of it, and the payment callback URLs are generated with the HTTP scheme instead of HTTPS. Could this also play a part in the duplicate entries being generated? |
Issue description
When a user purchases a ticket via PayPal, sometimes two
Purchases are created, resulting in the user gaining an extra ticket they did not pay for.Details/Observations
It is currently unknown when or why duplicate purchases are created. So far duplicate purchases have only been observed to be created when the user checks out via PayPal, suggesting the problem lies within the PayPal handler or with PayPal themselves. However, this could be a result of almost all of our users using PayPal instead of Stripe, thus biasing the problem towards PayPal.
The creation date of the duplicate purchases are also not identical, but rather a few seconds (usually between 2 and 3) apart, suggesting the callback gets called multiple times. Other than the creation date, the purchases are identical (transaction ID, token, etc.).
Ideas for mitigation
Without having a clear idea why some purchases are duplicated, there are some possible ways to mitigate the problem.
After the payment has been processed the params are not immediately forgotten, but rather during the success or failed view.
Forgetting the parameters right after the purchase has been created might work, but could also potentially break stuff somewhere else.
The risk here is potentially breaking the payment flow when a duplicate purchase is created.
"Proper" solution
The above described ideas are really only a temporary fix. To properly address the issue the payment flow needs to be investigated and pinned down, why some purchases are duplicated.
Furthermore, some additional measures could be put into place to prevent duplicate purchases from being created. A check if the same transaction ID is already present, similar to the suggestion above, would probably be a good idea. Or perhaps the use of a nonce, attached to the payment processing callback. If the nonce has already been used, meaning the callback was already executed, no further action is taken, instead the result of the previous callback is send again.
The text was updated successfully, but these errors were encountered: