https://bugzilla.wikimedia.org/show_bug.cgi?id=26340
Summary: Time-outs leading to double donations Product: MediaWiki extensions Version: any Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: Normal Component: DonationInterface AssignedTo: aricha...@wikimedia.org ReportedBy: aricha...@wikimedia.org CC: tf...@wikimedia.org Including original email thread here for tracking (yes, it is awkwardly in reverse order): Sorry not to have responded sooner, this thread got burried in my inbox. Like Tomasz said, PayPal will timeout during our communications, but that doesn't always mean that they did not receive the transaction. This is clearly problematic, but it's what we have to work with. Since I recently lost my dragon-slaying sword, I think there's not much chance of us fixing PayPal or preventing 'Anonymous' from DDoS'ing PayPal, so our solution should probably be a user-experience once. So, we could leave the timeout threshold as it is (we actually used to have it set higher, but typically if PayPal doesn't respond within a couple of seconds, the trxn is going to timeout anyway), but change the user experience so that the user is alerted their transaction is pending or processing (rather than telling them it failed). We could also send an email about the transaction to the fundraising team, alerting us to the fact that there's a transaction in question to follow up on. We wouldn't necessarily need to store any more transactional data about the user than we already do - perhaps name, email address, contribution amount and internal tracking id. And I do not think we'd need any sort of centralized storage for this, we could just pass this info off in an email. That should be enough info for our team to look up the transaction in the PayPal interface and match it up to a donor. While a little more difficult than just increasing the timeout threshold, I think this would go a long way to improving the user's experience. The downside to this approach is that it's possible that a user's transaction will fail (maybe they entered their address or credit card # incorrectly) but won't know about it until the transaction's been reviewed by someone on our team. But I imagine it would alleviate the double-charge problem. On 12/11/2010 11:33 AM, Tomasz Finc wrote: > Adding Arthur > > What happens here is that PayPay is not responding to us when we send over a > transaction. We need them to respond in order to know if a credit card was > valid or not. Typically this takes about 3-5 seconds. > > But, we've seen this creeping up as a result of the Wikileaks attacks against > PayPal which have drastically degraded their performance. > > A couple of options here > > 1) If we hit a timeout then surface a "Thanks, were processing your trxn > message" and hope for the best > pro: simple text change > con: we have to store user info while we are waiting and notify them by > email if the trxn fails > > medium difficulty > > 2) We increase the timeout past a minute > pro: simple change > con: most people wont wait that long > > easy difficulty > > 3) We get the 'Anonymous' group to stop attacking paypal > pro: no code changes > con: they might ddos us > > there by dragons difficulty > > Arthur might have even better ideas ... > > --tomasz > > On Dec 10, 2010, at 6:13 PM, Josh VanDavier wrote: > >> Hey Tomasz -- >> >> We're still seeing a lot of these time-outs. I spend most of my time in OTRS >> going through these issues. It looks like the donors submit their >> information, but the system displays a message that the site has timed out >> and that they need to re-submit their information. Then they are charged >> twice (or 3 times if it "times-out" on them again). >> >> Any idea what is causing this? >> >> Thanks! >> >> On Tue, Nov 23, 2010 at 4:17 PM, Josh VanDavier<jvandav...@wikimedia.org> >> wrote: >> Hi Tomasz -- >> >> We've been getting messages in OTRS regarding donations timing out and >> donors having to resubmit their information. This seems to happen more often >> between 5:30pm until we arrive the next day, both here and internationally. >> >> Here are a few ticket numbers of some of the donations we've been looking at: >> >> Zoom Ticket#: 2010112210025366 >> Zoom Ticket#: 2010112310033873 >> Zoom Ticket#: 2010112310027648 >> >> Thanks! >> -- >> Joshua VanDavier >> >> Community Officer >> Wikimedia Foundation >> >> >> >> -- >> Joshua VanDavier >> >> Development Associate >> Wikimedia Foundation -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l