Community Support Forums

Re: Express Checkout Billing Modification Forms Cancelling U

2011-10-25T18:57:58-05:00

Investigation ongoing. Please review at your earliest convenience.

So far I've been unable to reproduce this on a default installation of s2Member+Pro v111017+. I suppose it's possible, given the customization and separate NVP API call that you're making, but please review and let me know. I don't see how this is possible in s2Member's default implementation though.

SNAG-0070.png
SNAG-0071.png

Please let me know if I've missed something. Thank you VERY much!

Also, you might check to see if you're running any sort of Object Caching plugin for WordPress. Is it possible that you have a plugin like W3 Total Cache that might be causing s2Member and/or your own custom code to deal with stale information? See: viewtopic.php?f=36&t=6309#p29559

Statistics: Posted by Jason Caldwell — October 25th, 2011, 6:57 pm

Re: Express Checkout Billing Modification Forms Cancelling U

2011-10-12T18:31:58-05:00

Thank you for reporting this important issue.
~ Investigating now.

Statistics: Posted by Jason Caldwell — October 12th, 2011, 6:31 pm

Re: Express Checkout Billing Modification Forms Cancelling U

2011-10-11T13:29:35-05:00

Yes, the end result is that a user who has upgraded has their new subscription profile associated with them, but they have an EOT date assigned to them based off the date of their old subscription profile.

Statistics: Posted by kynatro — October 11th, 2011, 1:29 pm

Re: Express Checkout Billing Modification Forms Cancelling U

2011-10-11T12:45:26-05:00

So the problem is that the user's old Automatic EOT Time is still active as well as the new one?

Statistics: Posted by Eduan — October 11th, 2011, 12:45 pm

Express Checkout Billing Modification Forms Cancelling Users

2011-10-11T12:41:40-05:00

We believe we have found a bug in s2member Pro's billing modification system that may be related to a race condition when doing a Billing Modification on a PayPal Express Checkout user's account. Occasionally these accounts are getting an Automatic EOT Time associated with them based off the previous recurring billing plan's date.

Here are the givens in our scenario:

s2member Pro manages all of our payment processing and user access level controls.
Users can register for a free account (s2member_level0) and for a paid recurring billing s2member_level1 account.
All paid users are given a custom capability based off the tier they have purchased (tier_1, tier_2, tier_3, etc.) This custom capability is how we manage what level of access our users have access to. We opted for this method because we could not guarantee that the business model would fit within the 5 user account levels that s2member provides and we may want to use those to further disseminate our users in the future for other reasons.
When users want to upgrade to a higher level tier, they stay s2member_level1 and are granted an additional custom capability to match the tier they are upgrading to.
We upgrade users who have paid with a standard credit card via our own PayPal NVP API implementation with the _UpdateRecurringPaymentsProfile_ API command.
When users pay with PayPal's Express Checkout method, they must manually upgrade themselves when they want to move to a higher level tier because of PayPal's built in 20% increase within a 6 month period restriction.

Here is a scenario describing the problem we are running into:

A Pro user that has paid for the lowest tier (user level s2member_level1 with tier_1 custom capability) with their PayPal Express Checkout account wants to upgrade their account.
User goes to a page with a Pro Billing Modification Form on it. This form is set to "Upgrade User to Level #1", Charge $##.## for a monthly fee at the upgraded tier's rate, and grant a custom capability of "tier_2" to the user.
The user upgrades successfully, the new custom capability "tier_2" is assigned to the user and their subscription ID is matched to their new PayPal subscription ID at the new monthly rate. Unfortunately, sometimes these users also get an Automatic EOT Time assigned to them based off of their previous lower tier's subscription termination.

It seems to me that this may be a result of a race condition where the user's subscription ID is not being updated before the IPN receives the cancellation ping, resulting in an Automatic EOT Time being incorrectly added to the user's profile. When the new subscription ID gets modified for the user, this Automatic EOT Time never gets cleared. As a simple solution on our end, we're going to add in a clear for this field's value whenever the recurring_payment_profile_created IPN event is fired to ensure that this doesn't happen for these legitimately upgrading users. You may want to consider adding this in to the s2member Pro plugin to accommodate for this paradigm as well.

Statistics: Posted by kynatro — October 11th, 2011, 12:41 pm