How to handle overlapping subscriptions

[PseudoNyhm]

I wanted to share my results from running a test failure scenario. Overall, can you review this and advise me of:

• How to best prepare for and deal with this scenario in practice?
• How does s2Member's logic handle this case? (Some experimental results below)

Scenario: User creates a PayPal subscription for Level 1 access, which works just fine. Somehow, the user becomes confused and thinks they must sign up again. Even though my site's logic is supposed to keep them away from the subscription button, they manage to sign up with another subscription (there are a few ways this could happen). Now they have 2 active subscriptions.

Here's what I've found from Sandbox testing: Upon initial subscription, s2Member receives an IPN and assigns subscr_id (say, I-ABCDE) to user's account and sets them at Level 1, as expected. Upon future redundant subscription (which PayPal is happy to take), s2Member receives an IPN identifying the customer by the original subscr_id (I-ABCDE), but including a new subscr_id (say, I-VWXYZ). s2Member's log (see below) shows that it updates payment times for the associated member. In the WordPress User panel I see that s2Member has replaced the user's subscr_id with the new one (I-VWXYZ).

• What is the result of 'Updated Payment Times'?
• What will happen when recurring payments are made on each of these subscriptions?

Second IPN (redundant subscription) from s2member-logs/paypal-ipn.log:

Code: Select all

'option_name1' => 'Referencing Customer ID',
'option_selection1' => 'I-ABCDE',
...
'subscr_id' => 'I-VWXYZ',
...
's2member_log' =>
  array (
    0 => 'IPN received on: Sun Jul 3, 2011 4:16:31 pm UTC',
    1 => 's2Member POST vars verified through a POST back to PayPal®.',
    2 => 's2Member originating domain ( _SERVER[HTTP_HOST] ) validated.',
    3 => 's2Member txn_type identified as subscr_payment|recurring_payment.',
    4 => 'Sleeping for 5 seconds. Waiting for a possible subscr_signup|subscr_modify|recurring_payment_profile_created.',
    5 => 'Awake. It\'s Sun Jul 3, 2011 4:16:36 pm UTC. s2Member txn_type identified as subscr_payment|recurring_payment.',
    6 => 'Updated Payment Times for this Member.',
  ),


Cancellation testing: The customer decides to cancel the second subscription. The IPN cancel signal includes the Customer ID as the original subscr_id (not the WordPress user ID). s2Member sorts this out and sets the user's EOT. This is not entirely correct, because there is still another active subscription.

• What will happen when the other subscription makes a payment? Will the subscription be reinstated? Will the EOT be extended?

Code: Select all

'subscr_id' => 'I-VWXYZ',
'option_name1' => 'Referencing Customer ID',
'option_selection1' => 'I-ABCDE',
's2member_log' =>
  array (
    0 => 'IPN received on: Sun Jul 3, 2011 4:47:46 pm UTC',
    1 => 's2Member POST vars verified through a POST back to PayPal®.',
    2 => 's2Member originating domain ( _SERVER[HTTP_HOST] ) validated.',
    3 => 's2Member txn_type identified as subscr_cancel|recurring_payment_profile_cancel.',
    4 => 'Auto-EOT Time for this account: Tue Jul 5, 2011 4:16 pm UTC',
  ),


The customer decides to cancel the original subscription, as well. PayPal sends an IPN referencing the subscr_id of the original subscription (I-ABCDE). This time, the Customer ID = WordPress User ID (instead of a subscr_id). Unfortunately, s2Member cannot find a user with said Customer ID and given subscr_id, so the action fails.

Code: Select all

'subscr_id' => 'I-ABCDE',
'option_name1' => 'Referencing Customer ID',
'option_selection1' => '5',
's2member_log' =>
  array (
    0 => 'IPN received on: Sun Jul 3, 2011 4:49:01 pm UTC',
    1 => 's2Member POST vars verified through a POST back to PayPal®.',
    2 => 's2Member originating domain ( _SERVER[HTTP_HOST] ) validated.',
    3 => 's2Member txn_type identified as subscr_cancel|recurring_payment_profile_cancel.',
    4 => 'Unable to handle Cancellation. Could not get the existing User ID from the DB.',
  ),


In the end, the user is degraded (to Level 0) after the EOT. However, there are many ways in which this would cause a lot of customer support overhead. Any advice is appreciated.

Request: One thing I'd like to request is an activity page within s2Member that digests and interprets these log events for me, and puts flags on unexpected/failure cases. I'd never have any clue what was going on behind the scenes in a live situation, without wading through reams of logs.

[Jason Caldwell]

Thanks for your excellent questions.

s2Member associates each User account in WordPress with ONE paid "Subscription", and/or "Recurring Profile" on the PayPal side of things. As you've seen, if a Customer somehow pays twice for two separate "Subscriptions", the last paid Subscription is the one associated with their account. Once this occurs, the first paid Subscription will go completely unrecognized by s2Member, because it's no longer associated with the account. This is the intended behavior, and it's the reason why errors result in your IPN log in this circumstance. These errors indicate that s2Member has no association with the Subscription ID being referenced in the IPN, because the User's account is no longer associated with the original Subscription. In this case, you would need manual intervention to rectify duplicate billing routines.

In practice, it is best to use PayPal Modification Buttons generated by s2Member to avoid this, so the Subscr. ID does not change. In the case of s2Member Pro, this is not an issue, because s2Member Pro will void the original "Subscription" (aka: Recurring Profile), and replace it with a new one during the billing modification.

Request: One thing I'd like to request is an activity page within s2Member that digests and interprets these log events for me, and puts flags on unexpected/failure cases. I'd never have any clue what was going on behind the scenes in a live situation, without wading through reams of logs.

Thanks. I completely agree. Work is underway on this. We are planning to release this functionality in stages though. The first stage will include a built-in log-viewer inside the Dashboard, and later we'll add more sophisticated log parsing and other administrative tools.

[PseudoNyhm]

Thank you for your quick response. I see that this is just an administrative task that must be handled manually (if a customer manages to double-subscribe).

Notice that using PayPal Modification Buttons does not solve this issue for redundant initial subscriptions (because that's exactly what I tested, since I have open registration). That is, the user can still double-subscribe, which replaces the old subscription with the new. (Then again, who knows if the user might actually intend to do this.)

I have also found that PayPal Sandbox (sometimes?) puts up a warning when attempting to subscribe to the same terms twice... but will just go ahead and do it anyway if the user clicks "Accept." This should also help mitigate/reduce the likelihood of this happening.

I'm very glad to hear that activity reports will be included in s2Member in the future.

[Cristián Lávaque]

If you have registrations open, then you could only sell subscriptions to logged in users, which would allow you to then use conditionals to know whether to show a subscription or modification button to avoid the situation you tested.

[Jason Caldwell]

For PayPal Standard integration, the modify="" Attribute in your Shortcode will control this behavior. You will find further details on this inside your Dashboard, under:
s2Member -> PayPal Buttons -> Shortcode Attributes.

modify="0" Modification directive. Only valid w/ Membership Level Access. Possible values: 0 = allows Customers to only create a new Subscription, 1 = allows Customers to modify their current Subscription or sign up for a new one, 2 = allows Customers to only modify their current Subscription.

I recommend setting the value to modify="2" in your test case.

PayPal Pro Forms with s2Member Pro, will ALWAYS require a Customer to be logged-in before making modifications to their account. s2Member Pro is capable of handling this in a more graceful way, because the checkout/modification Forms are hosted on-site.

[PseudoNyhm]

If you have registrations open, then you could only sell subscriptions to logged in users, which would allow you to then use conditionals to know whether to show a subscription or modification button to avoid the situation you tested.

Indeed, when everything goes smoothly, this all works like a charm. However, if IPN is delayed/lost, the user may come back to my site and still be Level 0 (and try to subscribe again). That is what has happened in my testing. Even though it's probably a fringe case, I'm trying to consider all possible failure cases.

modify= "2" (allows Customers to only modify their current Subscription)

This sounds promising, but what if they don't have a subscription at all yet (they're just registered at Level 0)? Wouldn't modify = "1" be needed to allow a new PayPal subscription?

[Jason Caldwell]

This sounds promising, but what if they don't have a subscription at all yet (they're just registered at Level 0)? Wouldn't modify = "1" be needed to allow a new PayPal subscription?

Yes, that's correct. PayPal Standard integration accepts this parameter to dictate this behavior. The default value for Payment Buttons created by s2Member is modify="0", and for Modification Buttons created by s2Member, the default value is modify="1". If you're concerned about duplicate Subscription signups during account modifications, you could set modify="2" to prevent that from happening.

All of that being said, if an existing Customer comes to your site and pays you again through a normal PayPal Button, without going through a Modification Button, a second Subscription could be created. Some site owners place a message on the site asking existing Customers to log in before upgrading to a higher Level, this way a Modification Button could be used instead. Either that, or upgrade to s2Member Pro Forms with a PayPal Pro account to prevent any possibility of this occurring.

Ideally, s2Member would support multiple "Standard Subscriptions" for each Customer, but doing that, can also get hairy in ways unique to that approach. We have plans to extend s2Member in ways to improve this though. While we're working on this ( FYI: we're also working toward extending Capabilities too ), PayPal Pro integration might serve you better in this regard, with s2Member Pro.

[PseudoNyhm]

Jason, thank you so much for your advice. I will experiment with the best scenario for my particular needs.

At this time, I do not want to use PayPal Pro because I do not want to touch customer billing information. I'm building a picture of how Pro would be beneficial in the future. I'm glad to hear s2Member has plans to handle more PayPal Standard use cases.

By the way, I plan to upgrade to s2Member Pro, even if I'm only using PayPal Standard, because this product and the support (both Jason and Cristián, not to mention other users) is just so awesome.

[Jason Caldwell]

That's awesome. We appreciate the KUDOS!
~ thanks for your patience too.