User's Paypal payment upgrading another account

#1

Hello,

We have seen over 25 instances of an error when individual users purchase a 12 month subscription via Paypal. Once the user purchases the subscription it has been upgrading another random user account instead of the user that has paid.

We know that this is the case as it drops the Paypal purchase number within random users account. There doesn’t seen to be link between both accounts either as it seems extremely random.

Is this something anyone has seen before, and or, what can we do in order to stop this happening?

Many Thanks,

#2

Hi Josh.

Do you have caching enabled for logged in users?

It seems that some other user is being referenced in the PayPal button, so the payment goes to that one instead of the actual one paying.

You do have the button in a page that requires users to be logged in, right?

Are you using the s2 shortcode for the PP button, or are you using the HTML? I ask because with the shortcode, s2 will try to prevent caching on that page, but the HTML won’t.

Do you have Object Caching? Just checking, I’ve seen it regularly cause weird behaviors.

Do you use CloudFlare? Not sure if it’d have this effect, but Rocket Loader has caused weird behaviors too.

I look forward to your update. :slight_smile:

#3

Hello Clavaque,

Do you have caching enabled for logged in users? We currently user WP Rocket

You do have the button in a page that requires users to be logged in, right? Here is our current sign up form: https://classroomsecrets.co.uk/nonrecurringpremium/

Are you using the s2 shortcode for the PP button, or are you using the HTML? I ask because with the shortcode, s2 will try to prevent caching on that page, but the HTML won’t. - We intergrate the form via the shortcode s2member provides

Do you have Object Caching? Just checking, I’ve seen it regularly cause weird behaviors. We are not sure about this - I have asked WP Rocket for some advice on this.

Do you use CloudFlare? Not sure if it’d have this effect, but Rocket Loader has caused weird behaviors too. No

Thank you for getting back to us some promptly

#4

Thanks for the additional info.

Okay… If you haven’t yet, please enable logging so we get more info from those transactions in the future. WP Admin > s2Member > Log Files

Do you know how to reproduce the behavior, or does it seem random at the moment? If the latter, then we’ll need to wait for it to happen again and see if the log file gives any clues.

#5

@clavaque will probably fix this someday since he inherited it, but I’ve found that s2 doesn’t work well with caching except for Comet Cache or, oddly enough, Kinsta.

As far as I know, s2 was written to follow caching standards and many others have gotten other cache plugins to work, but I wasn’t so lucky and you can probably find older posts about it.

#6

Hello Cristian,

We turned on the logging this morning and have 3 different users which we know this has happened too and can pull the Paypal log. Looking at the log, their doesn’t seen to be anything odd happening as the payment goes through as you would expect - compared to other users that haven’t had the issues.

The occurrences of this happening is extremely random which suggests caching may have something to do with it. I have sent a message to WP Rocket to see if there is anyway we can overwrite logged in user’s caching on the specific payment pages to see if this makes a difference.

Can I ask if implementing the Paypal button via the S2member short code is the right way of doing this?

Any other advice would be much grateful.

#7

Whether you’re using the PayPal button or pro-form, doesn’t make a difference in the logged in user caching.

When there’s an s2 shortcode in a page, s2 will attempt to disable caching for that page, so it should help, regardless of it being a pro-form or button.

That’s why I’m a bit stumped: it does look like a caching issue, but I know using the shortcode tries disabling caching.

Yeah, I’d ask the WP Rocket guys about disabling caching for that single page, and see if it helps.

When a payment form/button is loaded with a logged in user, his account will be referenced in the form so that the payment goes towards his account and not a new signup.

If the page with the reference for one user gets cached and served to another, then that other will pay but it’ll go towards the first account, the one whose reference got cached.

I look forward to your update. :slight_smile:

#8

Hi, Josh works for me and I wanted to provide an update as we now understand the cause of the issue. We offer a couple of sign up options, one via s2Members PayPal integration, but we also have some customers whom we invoice via our invoicing system. When we invoice we setup blocks of users via a CSV upload, but we set the wp_s2member_subscr_id to the invoice number - which seemed logical as it’s the equivalent to the PayPal transaction ID. The format of our invoice numbers is 123456.

We discovered that where the incorrect account was updated, the User ID matched the Invoice Number. So for example:

Day 1 - Mr Smith was invoiced and setup, his invoice number is 123456
Day 2 - Mr Jones pays via paypal, his User ID is 123456

Therefore, Mr Smith’s account us updated (EOT is added to), but Mr Jones’ account is not updated.

So we now understand the cause, just need to rectify this, for what is thousands of users.

My thoughts are using a mySQL query to move the invoice numbers to another field - but the question is which field?

I am wondering if the Custom Value field is an option?

I know I could add a new field of Invoice ID for example, but this will sit under the meta_key of s2member_custom_fields - so i’d have to append the invoice numbers some how - I have no idea how to do that in mySQL.

Other key point is that it must be a searchable field.

Any suggestions are appreciated!

Thanks

Ed

#9

Nice work tracking that down! Thanks for the update.

With the s2Member Pro user export/importer tool it’d be possible to update the users in bulk. https://s2member.com/kb-article/advanced-importexport-tools/

You can use an s2 custom field for the invoice, but where do you need it searchable? You can test with a user and see if it comes up in the search tool you use. WP Admin > s2Member > General > Registration/Profile Fields

:slight_smile:

#10

Ah of course! That would do the trick! The field needs to be searchable in users, not the front end. Which I think the custom fields are.

Thanks for your support.

1 Like