PayPal & pre-existing members

I am migrating subscription members from a previous generation custom-coded site into s2member. The new site is a membership site with one level of paid access.

Existing members have monthly subscriptions that were obviously initiated outside of s2member. My question is how do I keep the subscription renewals rolling once I migrate to s2member? I originally wanted to establish a second PayPal account so that I would not screw up anything with the existing PayPal account while I was figuring out how to do the migration. Upon further reflection it seems that this two-account strategy may be faulty thinking.

I have the new site in beta mode, and have tested PayPal interactions in the sandbox environment. I’m quite pleased here. I have also performed a test import of all paid members. I can see their memberships expiring, and s2member is demoting them appropriately.

Could my quandry be solved by replacing the sandbox credentials (API password, API signature, and PDT token) with the corresponding credentials of the PayPal account used to process subscriptions and renewals on the original site?

Hi there. Thanks for your inquiry.
~ I sincerely apologize for the delayed response.

Importing existing Members with s2Member allows you to include the Subscription IDs associated with any existing Members, so that s2Member can receive future communication about these Members from PayPal’s IPN service.

So, if you include the Paid Subscr. ID value when you do the import, and your PayPal IPN URL is reporting properly to your installation of s2Member (i.e. yoursite.com/?s2member_paypal_notify=1), s2Member can automate the management of these paying customers.

This includes any associated payments, cancellations, refunds, chargebacks, etc. If s2Member has the Paid Subscr. ID value, and PayPal is sending s2Member IPNs, these events can be handled by s2Member, including any EOTs (End Of Term) events.

Now, in practice. This is not always easy to accomplish. For instance, if your previous membership software used PayPal Button integration, and an IPN URL was established on a per-transaction basis, it might not be possible to update the IPN URL for each of your existing Members before importing them into s2Member (e.g. PayPal has some limitations in this regard).

Another issue is that s2Member expects to receive IPN data with the PayPal “custom” value set to your installation domain name, and with a proper item_number value, matching s2Member’s standardization. Further details on this in your Dashboard under:
s2Member -> PayPal Options -> IPN Integration.

In cases where these technical challenges get in the way of a smooth migration, we recommend that you import your existing userbase with a pre-configured EOT Time. Setting the EOT Time during your import will ensure that s2Member terminates each Member’s access at the correct point in time, based on the data in your import, and without any reliance on existing IPN communication, which might have previously been configured to work with an entirely different software application.

Using a manual EOT Time when importing Users/Members from software applications you used prior to running s2Member, is a very reliable way to deal with things. It leaves little doubt about how s2Member and any existing IPN data might be handled in the future. A pre-configured EOT Time establishes the exact date on which a Member’s account will lose paid access. After import, this value can also be changed by editing the Member’s account from within your WP Dashboard.

Jason,
Thanks for the reply. Let me see if I understand what you are saying.
1) It is possible to import users with their associated Subscription IDs (in my case I found transaction IDs, and I believe these are compatible).
2) I need to go to the Profile on the appropriate PayPal account, turn on the IPN, and set the URL to the appropriate value (i.e. mysite.com/?s2member_paypal_notify=1).

In theory, if PayPal were sending IPNs then S2Member should be able to handle the transactions from here. The communication link would be established. There are two problems, though.
3) PayPal may not send communication to my new default IPN URL because the original transaction may have been “hard coded” with a transaction-based notify_url which would override my default IPN that I just turned on (i.e. mysite.com/?s2member_paypal_notify=1).
4) Even if #3 is not a problem, s2Member is still looking for specific values to be transmitted (“custom” value and item_number). These values, like the notify_url string, would have been established in the original subscription transaction.

Given these limitations it appears you advocate just managing existing members by adjusting the EOT by hand in the users profile in s2Member. New members after the transition should be golden as all communication between s2Member and PayPal will be handled well. Members from the previous system are simply treated as legacy issues.

So that is my recap of what I heard you say. If I missed anything, please clarify.

Now I’ll turn the focus to what I have learned in the interim.

You mentioned earlier about the possibility of my old site using PayPal button integration. I’m not certain that it did in the sense that button code is used today, but I found the code used to pass information to PayPal for the original transactions. It does appear that the notify_url was hardcoded (input type=”hidden” name=”notify_url” value=”http://oldurl.com/paypal_process.html” /).

I am still running my old site in parallel to my new site. Last night I found several members who were due for renewal in the early hours of this AM. I have them all imported into the new site using s2Member. I already had their EOT in the appropriate location in their respective user profiles. I added their subscriber ID (it was called the transaction id in my old system). Given that I had changed the default IPN URL I had hoped that PayPal would communicate to my new site and adjust the members’ EOT. That was not the case, though. Not one of my members renewed in my new system. They did renew on the old system. My head is going down the path that the hard coded notify_url is my problem. Given this, I can’t be the first person to experience this issue. There has to be some solution. Any thoughts?

Jason,
I have done a little more research this morning. Matt at PayPal technical support mentioned that the only solution they recommend for people in my situation is to redirect PayPal’s subscription renewal post to my new system. While this was his solid recommendation, he had no offer of example code.

The architecture is as follows:
Use my old system to accept and verify the renewal post from PayPal (The verification from my site should satisfy PayPal as it is looking for this verification).
Once satisfying PalPal, echo/redirect the post data to my new site.

In forming the echo/redirect of the post data, couldn’t we straighten out the Custom and item_number issues which you referenced earlier?

I don’t need to be a code hero here. If you have something quicker and easier to offer, I’m all ears.

Hi Jason. Thank you very much for the follow-up.
Yes, that’s all correct.

Yes, that’s a solid recommendation from PayPal. I’ve seen many site owners do that with positive results. I’ve done that myself in the past when migrating from one site to another. If you have the technical know-how to make that happen, it’s a good way of going about it.

In terms of code, I can provide you with a copy of our central IPN processing script, which is what we recommend in cases where multiple sites are operating on a single PayPal Pro account. This file is distributed in the s2m-pro-extras.zip that’s available in your s2Member.com account. Please see: My Account -> s2m-pro-extras.zip -> paypal-central-ipn-sample.php.

That should give you some ideas about how to write your own proxy IPN handler. You’ll want to make sure that your script sets the “custom” value in the IPN response to the host domain name of your new site, and just set the “item_number” value to 1 (i.e. the Membership Level# associated with their account within s2Member on the new site).

In order for this to work, s2Member will need to have the Paid Subscr. ID value listed for each account in your new site. If it’s a Recurring Profile or Subscription, then s2Member will need the “Subscription ID”, or a “Recurring Profile ID” in the User’s Paid Subscr. ID field, in your new site.

You can import this value for the Paid Subscr. ID with s2Member, or change it manually in the Dashboard in the Users menu. A Transaction ID works also, but only in cases where the original transaction was a “Buy Now” purchase. If the original transaction was a Subscription or a Recurring Profile, s2Member needs to reference the original ID associated with the Subscription or Recurring Profile, because that’s what PayPal is going to send in any future IPNs. The Transaction ID is mostly irrelevant in the case of a Subscription or Recurring Profile.

Note. I got your email regarding access to s2m-pro-extras.zip. I’m taking a look at that now.

I think that link you mentioned, which was failing, is within the software application itself, is that correct? I’ll have that updated asap. In the mean time, you can access the Pro Extras ZIP file from within your account at s2Member.com at all times. There you’ll find the latest release of that ZIP.

This is all good, and leading to a conclusion. This last bit of clarification will be extremely helpful as your preceding posts have been quite helpful. I really appreciate your help with this.

If it’s a Recurring Profile or Subscription, then s2Member will need the “Subscription ID”, or a “Recurring Profile ID” in the User’s Paid Subscr. ID field, in your new site. 

The site’s subscription database has absolutely no field titled Subscription ID. The only thing that I have is the Transaction ID. In the code that handles the processing of the Post data, I can see the Subscription ID field being read and passed back to out to PayPal, but, of the two, only the Transaction ID is saved to the subscription database. I do not even see any mention of a field titled Recurring Profile ID, but more on this in a minute.

A Transaction ID works also, but only in cases where the original transaction was a “Buy Now” purchase. 

I don’t know how to determine if I have “Buy Now” functionality in my code (see code near bottom). I do know that users absolutely HAD to be logged into the system in order to make a purchase.

If the original transaction was a Subscription or a Recurring Profile, s2Member needs to reference the original ID associated with the Subscription or Recurring Profile, because that’s what PayPal is going to send in any future IPNs. 

The only ID that I can see consistently used between PayPal and the site’s subscription database is a field called User_ID. It happens to be passed to PayPal under the “invoice” label, but gets renamed as User_ID before being saved. I do not feel this is a viable replacement for our Recurring Profile ID because it is not generated by PayPal.

With that as background please help me with the following questions:
1) How can I determine if I had “Buy Now” functionality in the original purchase? If I can prove that the transaction was “Buy Now compatible”, then I should be good to go with a transaction ID, right? (see code below).
2) If the situation is not “Buy Now compatible”, then I clearly need a PayPal generated alpha-numeric in the form of a Subscription ID or a Recurring Profile ID. I have neither, so it appears that the “Buy Now” example is my only hope in the short term.
3) If we can not prove Buy Now compatibility then I suppose I could create a new column in the subscription database and attempt to capture the Subscription ID (if any exists) as the monthly renewals process.

Button Code

$pagecode .= '

<img src="https://www.paypal.com/en_US/i/scr/pixel.gif" width="1" height="1">
';
$pagecode .= '

';
$pagecode .= '
















';

Well, the button code obviously didn’t post the way it should. It looked fine in the preview, but didn’t post.

Ticket recovered. So sorry for the delayed response.
~ Reviewing this now. one moment please.

Well, the button code obviously didn’t post the way it should. It looked fine in the preview, but didn’t post.

Hi Jason. Thanks for your patience. We’ve been working through some issues with our installation of bbPress. I believe the problem you experienced has now been corrected. Very sorry for any confusion.

1) How can I determine if I had “Buy Now” functionality in the original purchase?

Hmm. Well if it’s a “Subscription” or “Recurring Profile” inside your PayPal account, it’s not a “Buy Now” transaction. So that’s the best way to tell. You’ll need access to the PayPal account where you can reference what your customers purchased. If it’s a “Buy Now” transaction, you really don’t need the Transaction ID even. All you really need to know is when access should stop for each account, so that you can import the EOT Times into s2Member. A “Buy Now” transaction is not going to be associated with any future IPN communication from PayPal, so there’s not any real *need* for s2Member to have that.

All s2Member needs to know is when access to the site should be stopped.