Recurring billing adding another ARB account

Auth.net problem that creeped up on me the third month of usage on the live site. We setup early EOT notifications to go out to users who are not recurring charged users, primarily users who are year to year instead of month to month.

Naturally we had a lot of hand entered people with EOT’s setup in the DB, so the same email went out to some of our monthly people so that they could go through the checkout process and get themselves entered into the Auth.net system. This is where the issue came up. We had one user who I guess got the email erroneously – my fault :/ – and he went and did his checkout on his account.

We ended up with two ARB subscriptions for him! He got charged twice and all that jazz. I thought if someone checkout a capability twice and they already had the existing capability it would merely add to the term lengths? Or am I mistaken? Is there anyways to modify the behavior of someone checking out twice?

It did have this note in his account: “Paid Subscr. ID @ time of demotion: authnet -› 16429099” and it assigned him his newest one with a sub date starting on 6/5/2013 which did extend his time. But no EOT was setup on his older account(old account inside Auth.net’s ARB system – he has two subs)?

Let me see if I understand:

This is where the issue came up. We had one user who I guess got the email erroneously – my fault :/ – and he went and did his checkout on his account.

So this user is one that had already paid through Auth.Net, not one that you created manually.

We ended up with two ARB subscriptions for him! He got charged twice and all that jazz.

Twice in the same attempt to pay, or because he had already subscribed months earlier and now again?

I thought if someone checkout a capability twice and they already had the existing capability it would merely add to the term lengths?

So you’re selling a subscription with a ccap included in the shortcode?

Ccaps don’t have EOTs, levels do. Subscriptions don’t add to remaining paid time, they start anew.

It did have this note in his account: “Paid Subscr. ID @ time of demotion: authnet -› 16429099″ and it assigned him his newest one with a sub date starting on 6/5/2013 which did extend his time. But no EOT was setup on his older account(old account inside Auth.net’s ARB system – he has two subs)?

Do you have log entries for this? [hilite path]Dashboard -› s2Member® -› Log Files (Debug) -› s2Member® Log Viewer[/hilite] s2Member® » Private Contact Form

*Logs files sent via the contact form.* (scrubbed down to this month user name in question is “Javier Jane” on May 5th and 6th.)

Yes the user had already paid through Auth.net and these transaction where separate. The ccap is sold with a subscription however I’m exchanging capability with subscription, sorry. The user ended up being assigned two ARB ID numbers with Auth instead of extending. Maybe my thinking is off?

If I understand correctly there is no way for them to pay and extend a currently running membership? If not that explains what’s happening I think.

Just an update. I had a second client do it this morning again! In auth.net’s arb status I have noticed on thing however.

Old subscription ID:
Start Date: 05/08/2013
Completed payments 1

New subscription ID:
Start Date: 06/07/2013
Completed payments 0

There are no EOT times for either since they are recurring, but will the old account turn off at the end of the month or will he start having two recurring payments coming through for his membership level? (This is not a capability purchase)

Have 5 people like this now. Not sure if it’s double billing them or not. Start dates seem right and S2 has a “at time of demotion id #xxxxx” setup in their notes on my site, however there are no end dates put into the ARB system! I really need to make sure this isn’t going to double bill, as in the example in june, because there is a good sum of money for some of these people in each transaction and we can potentially lose clients.

It’s been 4 days guys do we have any advice, any clues? I now have clients and a boss breathing down my neck for an answer. Logs were sent in on the 7th. I’m at a loss and would rather not have to manually manage my members and their payments.

Sorry about the delay.

Yes the user had already paid through Auth.net and these transaction where separate. The ccap is sold with a subscription however I’m exchanging capability with subscription, sorry. The user ended up being assigned two ARB ID numbers with Auth instead of extending. Maybe my thinking is off?

I didn’t see any ccaps in the log entries for this user.

I noticed that he paid for the subscription one day and the next he paid for the subscription again. The second sale would start a new subscription, not modify the first one. Only selling an ccap individually with [hilite mono]level="*"[/hilite] in the shortcode would leave the existing subscription alone. The way I understand it, what would normally happen when purchasing the new subscription, though, is that the previous one gets cancelled, which is not happening from what you say. I’ll ask Jason about this.

We have several different subscriptions. The break down is like this:

1. Monthly no ccap non-recurring
2. Monthly ccap recurring
3. Yearly

non-recurring

It’s fine it it adds a new subscription and will work out perfect for us because it does set the start date with auth.net out another full month which is what I would expect. However it doesn’t put a cancellation date etc in with auth which sort of leaves me out in the wet here.

I would appreciate some feedback from Jason, there may be something I’ve done wrong here and I just need this to be as hands off as possible as we are trying to move away from a hands on paypal setup now hah!

Thanks a lot for the help Cristian, just have the boss stressing if you know what I mean.

Thanks for the heads up on this thread :-)

Any new sale results in a new Paid Subscr. ID (and the old one is cancelled; e.g. the old ARB is terminated).

With TWO exceptions. If level="*" where the customer is making a Buy Now purchase for Independent Custom Capabilities; or if you are selling Specific Post/Page Access via Buy Now functionality.

See: Dashboard -› s2Member® -› Authorize.Net® Pro Forms -› Capability (Buy Now) Forms
See also: Dashboard -› s2Member® -› Authorize.Net® Pro Forms -› Specific Post/Page (Buy Now) Forms

---

If you are making a Buy Now purchase that does NOT have level="*" it will cancel the previous Subscription and start you on a new one that is costing you only ONE time (e.g. a Buy Now purchase).

---

If you want to sell something extra, WITHOUT modifying an existing Subscription (of any kind); you should do that with Independent Custom Capabilities (e.g. level="*"), or with Specific Post/Page Access.

All of this assumes the customer is logged in when they make a purchase from you. If an existing customer makes another purchase while they are NOT logged into the site; there is no way for s2Member to associate that customer with an existing account; and therefore any previous ARBs will NOT be cancelled.

We suggest that existing customers be instructed to log into the site before changing their billing plan with you. With s2Member’s Authorize.Net integration, you can force the customer to be logged into the site by adding this Shortcode Attribute to your Pro Form Shortcode.

modify="0" Modification directive. Only valid w/ Membership Level Access. Possible values: 0 = allows Customers to modify their current Subscription or sign up for a new one, 1 = allows Customers to only modify their current Subscription. When modify="1", s2Member will force a Customer to be logged-in before they can fill out the Form (very handy).

See also: Dashboard -› s2Member® -› Authorize.Net® Pro Forms -› Shortcode Attributes (Explained)

Please let us know if problems persist :-)

Thanks for the feedback Jason. The only question I really have remaining is the cancellation of the Auth.net ARB ID. Inside Auth.net the customers still don’t have end dates filled in with auth.net. So when does S2 cancel it at the end of their subscriptions? As I see it happening right now come next month they will have two arb recurring charges since neither of them have end dates on them with auth or my site? That’s what is throwing me for a loop.

The clients were logged into the site when they checked out the second membership hence the:

“Paid Subscr. ID @ time of demotion: authnet -› 16429099”

added to the notes section of their accounts. Meanwhile inside auth.net the old transaction is, in this example “16429099” does not have an end date specified. So I’m not sure where / how the cancellation happens and I don’t want to see some of these people get double billed considering the amount of money involved.

Thanks for any insight that may let my light switch click on here.

Luke

Thanks for the follow-up.

So when does S2 cancel it at the end of their subscriptions?

A new purchase (for a new Subscription) results in the old ARB being cancelled (in real-time; during checkout); and a new ARB is created to take it’s place — with the new terms of sale.

If you are seeing an active ARB in your Authorize.Net account which will result in double billing, I suggest terminating (or deactivating) that manually until you can find the underlying cause of this problem on your installation.

I just took a quick at your log files and I’m not seeing an s2Member® demotion referencing `16429099`. However, it’s possible I’m not seeing some of your latest log entries. If s2Member left a demotion note, that would indicate to me the ARB is no longer active?

Well I assumed it would cancel it upon checkout or possibly at the start of the new one but wasn’t sure. If it’s supposed to be doing it immediately on checkout it’s not for me. It is setting the new ARB ID a month ahead so that part is working correctly. However I have one client who’s ID is 16444286 with a date of 4/8/2013 originally. He checked out again and his new ID is 16754989 with a date of 5/8/2013 and the old ID has no expiration date setup and is still marked “Active” on Auth.net’s website. Both of which went through my system with him logged in.

I have went through and cancelled the others to insure nobody gets double charged. Do you have any idea where to start on troubleshooting this issue? Would my silent post url have anything to do with it?

Thanks for the help I really appreciate it – seems I get everything like I like it then I find something else. ;-/ Getting slightly frustrated on this issue however as it doesn’t seem to stem from any one thing.

Thanks again Jason and Cristian.

Luke

Do you have any idea where to start on troubleshooting this issue? Would my silent post url have anything to do with it?

Thanks for the follow-up.

No, the silent post integration should not have any impact this.

I would start looking at your authnet-api.log file for log entries that include x_method=cancel and an x_subscription_id matching the old ARB that should have been cancelled. If there is a communication issue between your site and the Authorize.Net API, the log entry should indicate that problem.

In my investigation, I did not find any references to x_method=cancel at all; indicating to me there could be a problem with the Pro Form Shortcode.

If you would like to submit a Dashboard login for me, I’ll run diagnostics for you. Also, please post the s2Member Pro Form Shortcode that’s being used. Please make sure that your Shortcode does not have level="*".

Here is the shortcode I’m using for the form.

[s2Member-Pro-AuthNet-Form level="2" ccaps="" desc="$99.00 USD / Monthly (recurring charge, for ongoing access)" cc="USD" custom="secure.profitinsites.com/" ta="0" tp="0" tt="D" ra="99.00" rp="1" rt="M" rr="1" rrt="" accept="visa,mastercard,amex,discover" coupon="" accept_coupons="1" default_country_code="US" captcha="0" template="authnet-checkout-mod.php" success="http://kerrylovvorn.com/?page_id=3548"/]

The only cancel I can find in the api log was this:

LOG ENTRY: Wed May 1st, 2013 @ precisely 10:21 pm UTC
PHP v5.2.17 :: WordPress® v3.5.1 :: s2Member® v130406 :: s2Member® Pro v130406
Memory 16.90 MB :: Real Memory 17.25 MB :: Peak Memory 16.95 MB :: Real Peak Memory 17.25 MB
secure.profitinsites.com/~kerry/?page_id=3023
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
-------- Input vars: ( Wed May 1, 2013 10:21:28 pm UTC ) --------
array (
  'x_method' => 'cancel',
  'x_subscription_id' => '5206942220',
  'x_login' => 'xxxxxxxx/key/tran',
  'x_tran_key' => 'xxxxxxxx/key/tran',
  'x_invoice_num' => '',
  'x_description' => '',
)
-------- Output string/vars: ( Wed May 1, 2013 10:21:28 pm UTC ) --------
<?xml version="1.0" encoding="utf-8"?><ARBCancelSubscriptionResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><messages><resultCode>Error</resultCode><message><code>E00013

Subscription ID is invalid.
array (
‘response_reason_code’ => ‘E00013’,
‘response_code’ => ‘E00013’,
‘response_reason_text’ => ‘Subscription ID is invalid.’,
‘response_text’ => ‘Subscription ID is invalid.’,
‘__error’ => ‘Error #E00013. Subscription ID is invalid.’,
)

Not even sure where it got that ID from. However I’ve had multiple people who have had this happen. I could probably provide you an account to the site – how would you want me to get that to you?

I could probably provide you an account to the site – how would you want me to get that to you?

You can use the private contact form here: s2Member® » Private Contact Form

Please leave a reply here after submitting it, so I look for it and forward it to Jason. Thanks!

Thanks for the follow-ups here.

A couple of observations.

custom="secure.profitinsites.com/" in your Shortcode should not have a trailing slash.
Please change that to: custom="secure.profitinsites.com"

'x_subscription_id' => '5206942220' being declared as invalid by Authorize.Net is normal. s2Member attempted to cancel a previous subscription ID which was actually referencing a non-recurring payment cycle. Thus, the error is normal and was handled gracefully by s2Member. This is to be expected whenever you have a customer that previously paid you on a Buy Now basis, but is now upgrading to a recurring payment cycle. The previous transaction ID was NOT an ARB; and thus it comes back with an error when s2Member tries to cancel a “possible” ARB associated with this (just in case it was an ARB). No worries.

---

I found two instances of this error in your s2-http-api-debug.log file. In both cases the error was handled gracefully; and since the ARB did not event exist to begin with, there was no issue.

<resultCode>Error</resultCode><message><code>E00013</code><text>Subscription ID is invalid.</text>

To clarify, Subscription ID is invalid
is interpreted by s2Member (in this scenario); as ARB does not exist with that ID.

If the previous transaction HAD been associated with an ARB (Automated Recurring Billing) profile, it would have been cancelled. Since I’m not seeing any other log entries referencing a cancellation, I’m not seeing a problem. Please let us know if problems continue. Also, please be sure to update the Shortcode attribute that I mentioned because that could result in unexpected issues.

Thanks for taking the time to look through everything Jason. Since this has been reported I haven’t seen it happen again. When we first put the site up we carried a few people over setting up an ARB subscription and then manually adding that information into the site. Those accounts seem to be the ones we had an issue with. Weird – guess Auth didn’t like me doing that?

Either way, I have been keeping a very keen eye on it the past couple of weeks and it hasn’t shown back up. I’ve also edit that shortcode in hopes that may eliminate future issues. As usual thanks for the help guys I really appreciate it!

Luke