Decline Authorize.net not downgrading users

Existing members who’s credit cards have been declined are not getting downgraded per my EOT settings. This is a show stopper for me. I can’t watch every transaction come through and manually downgrade every account that gets declined. Surely S2Member can handle this???

Thanks for your inquiry.

Please post a screenshot of your current EOT settings/configuration so we have some idea about what’s going on with your installation. Also, these are declines you said; are they failed recurring payments, or initial Buy Now transaction declines?

What version of s2Member® Pro are you currently running?
Is your Authorize.Net account connected to a US or Canadian bank?
Do you have s2Member’s logging routines enabled?

Please see: Dashboard -› s2Member® -› Authorize.Net® Options -› Account Details -› Logging

Thanks!
Here’s the screenshot: http://miracleofyoga.com/eot.jpg
The failed transaction that I had was on a recurring member who made 3 payments and the 4th was declined.
S2Member Pro version: 130406
Authorize is connected to a US bank.
Logging is not enabled.

Could this have anything to do with it?
http://www.s2member.com/forums/topic/authnet-eot-demote-probs-for-manual-entries/
I did rebuild his site with a fresh WP install and imported the users over. If the above thread has the solution how do I implement it? I can put that code where it needs to be if I know where it goes. Thanks!

Anyone?

@christianleeby

Could this have anything to do with it?
http://www.s2member.com/forums/topic/authnet-eot-demote-probs-for-manual-entries/
I did rebuild his site with a fresh WP install and imported the users over. If the above thread has the solution how do I implement it? I can put that code where it needs to be if I know where it goes. Thanks!

Yes, this is most definitely the issue. s2Member® does not have all of the data for these customers. You have given s2Member® enough to move them over and deal with most things, but EOTs applied against these customers will fail because there were no ipn_signup_vars moved over during import/export. This is an issue that I will remind Jason about so that a future release can include these details in the export file.

For now, it can be resolved by adding an EOT manually for each user (in the Dashboard); or by giving s2Member what it needs to do the job for you automatically. For each of your users, you will need to give s2Member the original ipn_signup_vars. If you have the old WP database, you can probably just bring over the wp_usermeta table and that’s that.

If not, the details about the ipn_signup_vars field were posted here by Jason.
http://www.s2member.com/forums/topic/authnet-eot-demote-probs-for-manual-entries/#post-37503

Thanks so much! I’m going to try your suggestions.

The thing is when I imported the users from one install to another they didn’t all transfer. So some I had to set up manually. If I add an EOT manually in the dashboard what should I put in? Since it’s an ongoing membership should I just put a date way way off in the future like 10 years or something? What value would S2Member put in by default if I’m set up for recurring payments with no end date? They just cancel when they want so there’s no term they sign up for.

@christianleeby

The thing is when I imported the users from one install to another they didn’t all transfer. So some I had to set up manually. If I add an EOT manually in the dashboard what should I put in? Since it’s an ongoing membership should I just put a date way way off in the future like 10 years or something? What value would S2Member put in by default if I’m set up for recurring payments with no end date? They just cancel when they want so there’s no term they sign up for.

In this case you don’t need an EOT Time at all. What you do need is to have the ipn_signup_vars on this site for each Member so that s2Member and Authorize.Net can communicate with each other. This way when/if they do cancel or payments begin to fail, s2Member® can terminate their access automatically.

Short of that, you could do this manually as it occurs.

• This reply was modified 3 years, 4 months ago by  Mike (Volunteer Moderator).

Thanks so much for your help with this. I’ve been trying to wrap my head around how the ipn_signup_vars should be implemented and decided to look at the old database. I am not a developer, however it looks like all those variables are stored as one entry in the database (array?).

The meta_key field is titled this:
wp_s2member_ipn_signup_vars

and the meta_value is like this:
a:31:{s:8:”txn_type”;s:13:”subscr_signup”;s:9:”subscr_id”;s:8:”16796xxx”;s:6:”custom”;s:21:”www.miracleofyoga.com”;s:6:”txn_id”;s:8:”16796822″;s:7:”period1″;s:3:”1 M”;s:7:”period3″;s:3:”1 M”;s:10:”mc_amount1″;s:4:”0.00″;s:10:”mc_amount3″;s:4:”9.95″;s:8:”mc_gross”;s:4:”0.00″;s:11:”mc_currency”;s:3:”USD”;s:3:”tax”;s:4:”0.00″;s:9:”recurring”;s:4:”9.95″;s:11:”payer_email”;s:23:”***.***@gmail.com”;s:10:”first_name”;s:7:”FirstName”;s:9:”last_name”;s:5:”LastName”;s:12:”option_name1″;s:23:”Referencing Customer ID”;s:17:”option_selection1″;s:2:”59″;s:12:”option_name2″;s:19:”Customer IP Address”;s:17:”option_selection2″;s:13:”xx.xxx.xx.xxx”;s:9:”item_name”;s:78:”30 days free / then $9.95 USD / Monthly (recurring charge, for ongoing access)”;s:11:”item_number”;s:1:”1″;s:14:”proxy_verified”;s:7:”authnet”;s:14:”subscr_gateway”;s:7:”authnet”;s:6:”eotper”;N;s:5:”ccaps”;N;s:5:”level”;s:1:”1″;s:2:”ip”;s:13:”67.153.30.194″;s:12:”initial_term”;s:3:”1 M”;s:7:”initial”;s:4:”0.00″;s:7:”regular”;s:4:”9.95″;s:12:”regular_term”;s:3:”1 M”;}

I have no idea what some of that means (looks kinda complicated) and if transferring users has caused me to lose this data then my site is fairly well broken. I was not anticipating development costs associated with this. Do I need to actually pay a developer to fix it? I really really hope not since this site has already blown our budget out of the water.

If I’m assuming wrong here please let me know, but I was expecting that I could transfer all my users without an issue within S2Member’s admin. This isn’t the only issue I’ve had with transferring users. I had to manually enter some through S2Member because the import feature was looking to match them with an existing ID. Since I was moving users to a new install there weren’t any users to match up, so if I remember correctly, I removed the user ID and let it automatically assign them. A couple didn’t import so I had to manually create those accounts in S2Member. It’s been a real mess I’ll have to admit. Not sure what to do here since the user ID’s don’t match up, and I have no more money to spend on this site.

Any other advice that might help me get this resolved quickly and at low-to-no cost? Only thing I can think of is manually rummaging through the old database to find the users with ipn_signup_vars and pull them over to the new database. That doesn’t sound very fun at all.

• This reply was modified 3 years, 4 months ago by  Christian Leeby.
• This reply was modified 3 years, 4 months ago by  Christian Leeby.