Error #E00013. Subscription ID is invalid.

I’m getting this error constantly in the “authnet-api.log” log. It seems like it’s running this for every user, every day, even though I don’t sell subscriptions. Any ideas?

Hi TJ.

Could you please send the logs so I can look at them, please? s2Member® » Private Contact Form

Thanks!

Hi Cristián,

Can I email you the logs directly instead of uploading it using the form? Can it be diagnosed with just the logs as a first step?

Thanks.

If you send the login info using the form, I can look at the logs directly via FTP.

I don’t know if they’ll be enough to solve the problem, but it’s the first thing I’d look at in case they have something that helps.

Hi Cristián,

Sorry to be a bother, but can I directly email you the logs as a .zip file?

Thanks.

Sure, the same contact form has a field for file attachments. Add the zip file there when you send the email.

Hi Cristián,

I meant can I send you the email directly at your yourname [at] s2member [dot] com address rather than filling out the form above?

Thanks.

I sent you an email to the address in your account, you can reply to it with the log files.

Thanks Cristián. I sent it.

Thanks, got all the logs now.

In the authnet-api.log I found at least three subscription IDs that are repeated over and over in lots of transactions. The first one for each seems to be a normal transaction, without an error, but then it starts repeating with the error. While other transactions don’t seem to have that error.

The entries with the error, all seem to have to do with a wp-cron job, I’m not sure why yet. You’re not getting this error when the users checkout, do you?

I’d like to take a look at your site, please. Include the address of the page where you have the pro-form. s2Member® » Private Contact Form

Hi Cristián,

Thanks for looking into this. Email set. This is odd because I don’t sell subscriptions. I don’t even have subscriptions activated in my authnet account.

I provided a link to the pro-form in the email comments. Just FYI: on the pro-form page (authnet) there is also a link to the paypal pro-form, although the problem seems to be isolated to authnet pro-form.

Thanks again.

Thanks, got the email.

Those aren’t recurring payments for a subscription, s2Member doesn’t handle those, they are handled by Authorize.Net. These entries are related to a wp-cron job caused by I don’t know what.

I emailed Jason asking him, will let you know when I hear back from him.

Thanks for the heads up on this thread.

I can see how this could be confusing for you. These log files are for mostly for debugging purposes, so they record every API call that is made to the Authorize.Net system. Some API calls will anticipate errors in the response from Authorize.Net, which is the case here.

In this case, the error log entries can simply be ignored. This is s2Member logging responses from Authorize.Net where there is no Recurring Billing Profile associated with existing paid customers. You’re not charging on a recurring basis, so these errors being returned from the API are to be expected.

I’m getting this error constantly in the “authnet-api.log” log. It seems like it’s running this for every user, every day, even though I don’t sell subscriptions. Any ideas?

Yes, that is correct. While these customers may not be associated with recurring fees, it’s s2Member’s job to determine this, and keep track of who is and who is not, by communicating with the Authorize.Net API. What you’re seeing in the logs is s2Member finding out that they do not have recurring fees.

If you would rather disable this functionality in s2Member, you can disable s2Member’s Automatic EOT System from your Dashboard. See: Dashboard -› s2Member® -› Authorize.Net® Options -› Automatic EOT Behavior

This being said, I recommend that you leave the EOT system enabled, and simply ignore those log entries, or simply turn off s2Member’s logging routine.

Thank you Cristián and Jason for looking into this.

No problem. Glad we could help! Sorry I didn’t explain that before, I wasn’t aware of that kind of logging with Authorize.Net until now, since you’re the first to ask and I hadn’t seen Jason describe it before. :)