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.
