On August 26th, a participant attempted to pay for an event via PayPal. PayPal then redirected the user to a page on Doorkeeper that indicated the user had approved the payment. However, when Doorkeeper automatically attempted to confirm payment status with PayPal, PayPal had no record of the payment approval. Because of this discrepancy, Doorkeeper did not issue the ticket for the participant.
Because the participant's registration was in an ambiguous state, Doorkeeper staff were automatically notified of the issue, and began an investigation. Simultaneously, we were contacted by the organizer about the payment issue. We suggested the organizer contact PayPal's customer support regarding the status of the payment, and told them we would launch an independent investigation.
Since then, we've spent weeks with PayPal's customer support trying to track down what went wrong. Although it's clear to us that something strange happened on PayPal's side, most likely due to a bug on their side, PayPal's was unable to provide any explanation for it. Furthermore, in the time that it took for PayPal's customer support to escalate the issue to someone capable of fully investigating it, PayPal had already deleted their logs around the prepayment attempt. As such, they've told us there is nothing more they can do, and for us to wait until the bug occurs again and contact them then.
This bug does not appear to be a common one. Apart from the issue on August 26th, Doorkeeper appears to have had it on one other occasion, on July 31st. This was before we had introduced more extensive reporting about payment issues, and it went unnoticed by us at the time.
The wait and see strategy PayPal proposes doesn't sit well with us. Because participants will sometimes pay for an event just before it starts, we need to be able to confirm payment status immediately. Simply waiting for a bug to happen again isn't acceptable to us. However, because the issue appears to be on PayPal's side, and we don't have any way of working around it, we don't have a good conclusion to this issue at this time.
If you're currently an organizer using PayPal to collect prepayments for your event, we'd recommend switching to collecting money via Stripe instead. With Stripe, we've never received any ambiguous results like we have from PayPal, and are much more confident in Stripe's ability to process payments without errors.
When setting up a payment with PayPal, Doorkeeper provides them with a
returnUrl parameter. According to PayPal's documentation, this is a "URL to redirect the sender's browser to after the sender has logged into PayPal and approved a payment". Apart from this incident, our experience has shown that a participant is only redirected to that URL when they complete a payment.
After a participant is redirected to the
returnUrl, we check the status of their payment using PayPal's PaymentDetails API. This API call returns a result that includes a
paymentInfo section, which will include a
status field on the payment transaction only when a user has approved the payment (before they approve it, this
status field is missing).
In the case of this incident, the participant was redirected to the
returnUrl, which indicates they had completed the payment. However, when checking with the PaymentDetails API, the
paymentInfo section included no
status field, indicating that they hadn't completed payment.
This is clearly an ambiguous situation. Despite repeatedly contacting PayPal's customer support about it, they were able to provide no explanation for why it might occur. Because of this, we're lead to believe there is (or was) a bug on their side. As such, our strategy will be to follow PayPal's advice and contact them once more should the issue occur again.