Page MenuHomePhabricator

Donation form issues if back button utilized
Closed, ResolvedPublic

Description

We were contacted by the donor in ZenDesk ticket 1141758 (CID 56294529) who provided some great information regarding a possible bug on the donation form.

The donor reached out about an unintended monthly donation via PayPal that they initiated on July 26th, 2022.

The donor advised the following: "First I by mistake choose 2€ per month. Then I canceled the payment and choose 10€ + 40cent one time.
Looks like you have a bug in your system, because at once I was registered for 10,40 a month and not just one time"

I was able to recreate what I believe they are describing on desktop in Safari and also on an iPhone using Google Chrome.

I first recreated using this link: https://donate.wikimedia.org/w/index.php?title=Special:LandingPage&country=AT in Safari. I then followed the donors steps by choosing give monthly > €2 > selected no for email > then selecting PayPal. When I got to the paypal login page I hit "cancel and return to WMF" at the bottom of PayPal screen which redirects you to this other ways to give page: https://donate.wikimedia.org/w/index.php?title=Ways_to_Give&token=EC-6FR54275RK282420M.

I then hit the back button a few more times to return to the donation form itself. When back on the donation form I selected > just once > €10 > added the .40 fee > selected no for email > chose paypal again (See image 1 below which shows my selections). You can see before it gets to the Paypal login screen that it's going to process this as monthly (See image 2 below).

I recreated this a second time and fully submitted the donation on the US form as well using Google Chrome on an iPhone and you can see that it did create a recurring donation on my civi record which is CID 51202551 when I indicated a "one-time donation".

Seems like the donation form may not be performing well if users are hitting the back button. Possibly this has to do with the cookies? Not sure if this is something that can be easily fixed but wanted to put it on your radar.

Thank you!

Image 1:

image 1.png (1×898 px, 273 KB)

Image 2:

image 2.png (570×740 px, 47 KB)

Event Timeline

We should look at the recurring parameter being sent by donatewiki - maybe it's sending a blank / no value for recurring when the donor chooses one-time? Probably it should send recurring=0 to affirmatively overwrite any previous recurring=1.

Pcoombe added a subscriber: Pcoombe.

I think this may be an issue with the form chooser, as donatewiki does send recurring=false as a parameter. Pasting in my notes from the other task

Steps to reproduce:

In the same session

Expected result

  • Receive a one-time form

Actual result

I tested passing recurring=1 and recurring=0 to GatewayChooser instead, and got the same results as above

Thanks @Pcoombe, I'll try to replicate locally and get a patch out ASAP.

OK, seems to be the getLocalURL call in the GatewayChooser is discarding values of 'false' but keeping values of '0'. Looks like there was a recent patch to cast recurring to a bool before sending it to that function, but it really should be casting it to an int.

Change 820175 had a related patch set uploaded (by Ejegg; author: Ejegg):

[mediawiki/extensions/DonationInterface@master] Ensure recurring=false passes through chooser

https://gerrit.wikimedia.org/r/820175

Change 820175 merged by jenkins-bot:

[mediawiki/extensions/DonationInterface@master] Ensure recurring=false passes through chooser

https://gerrit.wikimedia.org/r/820175

Ejegg claimed this task.

@Pcoombe We deployed a fix for this and it seems to be working as expected. Thanks for your excellent testing and writeup of the replication steps!