Custom variables and automated renewals

Hi all,

I’ve been attempting to hook s2member up to our company CRM system so it updates lead information, purchase history, etc. I’ve hit a couple of issues and wondered if you guys could assist;

I need to be able to add/update a ‘subscription expiry’ field on the CRM whenever anybody purchases, upgrades, renews (via PayPal’s automated renewal) or cancels. We’ll use this to email them on/before these events.

Since the EOT isn’t calculated for a user record until they cancel, I’ve been doing this by taking the transaction date, adding a year on (our subscription runs for a year) and then updating the EOT on the CRM accordingly. Problem is, we now have products coming online that are one-off purchases, and this means that my previous logic doesn’t work anymore as the update EOT on CRM logic gets fired with the incorrect value.

Is there a recommended way of getting an accurate EOT for any user record that is on a subscription, including when the automated renewal will take place?

Secondly, in relation to products – I need to send a purchase record through to the CRM when someone purchases any product, and this must include renewals. I’ve been doing this for initial purchases by putting a unique product SKU in the CV1 value of the form shortcode (as our item_names are too long to use, really). This works great for initial purchases – using the notification API I’m picking the SKU and the value and sending a purchase to the CRM.

What I don’t know is if this works for automated renewals – ours occur every year. Will the CV1 value (our product SKU) from the original product purchase form be present when the automated renewal occurs and my notification script gets fired? What shortcode values are present when this happens via PayPal ‘behind the scenes’? It seems to be difficult to test this to see.

Thanks very much in advance for your help – you’ve got a great product here!

Stu

Hi Stu,

Please see my replies below.

Is there a recommended way of getting an accurate EOT for any user record that is on a subscription, including when the automated renewal will take place?

For recurring subscriptions, there is technically no EOT, since the subscription recurs indefinitely. If you sell access on a Buy Now basis (e.g., one-time charge for 1 year of membership), then s2Member calculates the EOT and sets it accordingly on the user’s profile.

However, if you sell a membership that is $X per year, as far as s2Member is concerned the subscription has no EOT (because the subscription automatically renews at whatever interval… the renewal isn’t an EOT, since if the renewal goes through the user continues to have access). If there’s a problem with renewal, e.g. the payment fails, then s2Member get’s notified that an EOT should occur and sets the EOT date on the user’s profile.

So to answer your question: No, there’s no way to get an accurate EOT for a user with a recurring subscription. If you need to calculate an EOT, you’ll have to use your business rules (e.g, “all subscriptions are 1 year, so renewal will be 1 year from now”) and apply your own logic, as you’re already doing.

What I don’t know is if this works for automated renewals – ours occur every year. Will the CV1 value (our product SKU) from the original product purchase form be present when the automated renewal occurs and my notification script gets fired? What shortcode values are present when this happens via PayPal ‘behind the scenes’? It seems to be difficult to test this to see.

Yes, if you’re using the Payment Notification API (Dashboard -› s2Member® -› API / Notifications -› Payment Notifications), the original value of your custom=”” attribute will be present in all payments. If you offer any upgrades (Dashboard -› s2Member® -› PayPal® Pro Forms -› Billing Modification Forms), you’ll need to make sure that you add that SKU to the custom=”” attribute there too, since Billing Modifications work by canceling the previous recurring profile and creating a new one (so if an upgrade form doesn’t contain that SKU, then future payment notifications for that person won’t contain the SKU either).