About: Jason Owens

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 .= '
















';

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?