Jonathan brought up a key point: charge backs. I've heard that card processors handle charge backs differently, and I know of companies with lots of charge backs that selected/switched processors in large part due to related fees. I'm not sure what 'lots' of charge backs is, but if it's a big enough problem, perhaps it could be used to justify an investment to enhance the billing system.

Another topic that shouldn't be underestimated is revenue recognition. Your company wide billing system probably manages earned and deferred revenue. An account on monthly billing isn't that complex, but your first 90 days, gracing, and any other exceptions may be tricky, especially in considering third party solutions.

Geoff

Sent from my iPad

On Jun 9, 2013, at 11:45 PM, Anthony Zeoli <[address removed]> wrote:

On Sun, Jun 9, 2013 at 2:08 PM, Jonathan Vanasco <[address removed]> wrote:

1. First off, the internal auto-pay solution is egregiously stupid.

It's stupid that we have to use the companies auto-pay system that bills for its other services, which is not stupid for those services, but stupid for our service specifically. The architects missed this in the business requirements 5-weeks ago, so now we don't have time to update auto-pay to take into consideration our specific rules.

 

You should talk to that division about additional billing options.

It's not the "division." It's the entire company. Like I said, they have other services where weekly billing on Tuesdays is appropriate. This is their first attempt at a subscription based social music platform and would only know to update their billing practices when me, the product manager, tells them they need to.

 

As a customer, I would honestly fire you and look elsewhere if your autopay starts to hit on random days.

It's not random. It's weekly on Tuesdays.

 

 I want my billing to happen on specific days – bill me on the same date every month.

Agreed. I'm going to look into the SAS subscription service to handle our subscriptions, if changing out auto pay system is problematic.

 

AT THE VERY LEAST, you should be running the cards to AUTHORIZE payment on a consistent date.  That freezes the funds on the card.  You have several days to CAPTURE the funds afterwards -- that could happen on a tuesday.   What happens when a card is maxxed out ?  I'd assume that can happen frequently.

I never thought of pre-auth - maybe we can do that and then run it on the following Tuesday to deduct the funds. I have to look into whether we can do that or not with our current auto-pay system.

Considering your customer base ( musicians , who are terrible with money ), using a system where billing happens on random dates is just plain dumb.

You're preaching to the choir.

 

2. I'd personally prefer to see monthly based cycles. So if I buy on the 14th, you charge me a pro-rated cost.  Most of my vendors do this.

Yes, we do monthly cycles. We can set auto pay to charge by the month, but that is still a problem if the customer signed up on the Wednesday after a cycle ran on Tuesday. That would then give them 30+6 days, because the cycle of four weeks starts the following Tuesday after initial sign-up. 

 

3.  If I had to deal with your insanity, I'd change the TOS and have the system rebill 2 weeks in advance.  i.e., on day 75 if runs the card for days[masked]; on day 165 it runs the card for days ...   The problem you run into though, is that this becomes a random charge -- so I think it's likely to fail on your clientele.  You also have the issue with chargebacks – if someone didn't want to renew, and you renew before they cancel, you get a chargeback ( which costs you a penalty , depending on your credit card processor.  i'd talk to your billing team about that.  ).

Correct. This seems a little ugly and I'd prefer to get it right. 

 

4. Your entire approach considers to this considered the customer to be a thief. "Free access" is only free if they have no intent on renewing.  If there's a credit card problem on day 90, and you charge again on day 96, you only "gave away a free product" if the charge fails on 96 and they don't renew.  If the charge goes through, there's no sane reason to consider this a new billing period.    You're also talking about giving someone 6 days of free access AFTER they paid for 90 – so you shouldn't have a real tangible loss.    You should treat new cards , card updates and rebills as a "new sale" ( hitting the card instantly ) but keep the effective date of the billing cycle the same.

That's what we need to do. I just want the system to:

1. take the upfront payment on X day

2. take the first subscription payment 90 days from X

3. rebill every month 30 days from X above.

4. if customers card fails, give 7 days grace period

5. when customer updates card, hit card on day of and reset X to that day and star the new monthly billing cycle from the new X day.

As I said, our auto-pay does not take into consideration some of these requirements. We either have to program the solution and change our auto-pay system to take into consideration these requirements for our site type within the network or look for a third party solution to handle subscription offer. Given what I know today, the third party option that was proposed earlier may be the better option, because they've already factored all of this and we can just connect up to it and simply trigger the user profile to be unavailable when the API sends the notification to do so.

I thought I'd post this issue here as well, so anyone who is thinking about subscription payment systems can learn from my conundrum.

Tony

On Jun 9, 2013, at 12:16 AM, Anthony Zeoli wrote:

Hi NYTechsters,

So, I have a little dilemma. I'm trying to figure out how I should craft this subscription process for one of the projects I'm working on, specifically the music project I'm working on down here in Greensboro.

Here's the backstory:

Because I work for a multi-national corporation, there are times when we pull from the same code base and use programs that run other processes for other divisions of the company. One such process is our "auto-pay" that hits subscriber credit cards once a week on Tuesdays.

In our subscription model, it means the account holder purchases a 3-month advance subscription and their card is hit the day of the purchase. We then set an auto-pay to hit 90-days after sign-up. This means if the account holder purchases on a Wednesday, 90-days passes by and if the 90th day falls on a Thursday, then the account holder's card will not be hit again until the following Tuesday, giving them a few days free.

No matter how you slice it - whether the account holder subs on a Wednesday or on a Sunday, there are bound to be free days distributed, because of the Tuesday run.

Now for something even a bit more complex. If we give the 90 days and the renewal date falls on a Wednesday, the card does not get hit until the following Tuesday. And, if the card declines for any reason, then we give seven days grace period and we'll run the card again on the following Tuesday. This ends up giving the account holder possibly 6+7days free until we can hit their card again.

Also, say they are in the 7-day grace period and they add their new card. Any service would hit the card at the moment it was updated. In our auto-pay model, the card would not get hit until the next run. But, when the account holder fails to pay and their account expires, they have 90-days to come back. If they come back on a Wednesday and put their card in again, we're not going to hit the card until the next Tuesday, giving that person 6-days more of free access.

Hmmm...quite a conundrum working on a start-up inside a multinational corporation that already has an established subscription payment process.

While I'd love to re-write auto-pay, you can imagine it touches the entire company and it's a huge endeavor, because you have to regression test 30+ sites in the network.

Thoughts or solutions?

Tony Zeoli, Founder
 
WordPress | Digital Strategy | IA & UxD
310 W. 4th St, Winston-Salem NC 27101
✉ [address removed] | Visit Our Site
☎ [masked] 

My profiles:
Contact me: djtonyz tonyzeoli

More words: Digital Strategy Works On The Move

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])

This message was sent by Anthony Zeoli ([address removed]) from NY Tech Meetup.
To learn more about Anthony Zeoli, visit his/her member profile

Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

// Jonathan Vanasco

c. [masked]  |  [masked]

e. [address removed]

w. http://findmeon.com/user/jvanasco 

linkedin. http://linkedin.com/in/jonathanvanasco

blog. http://destructuring.net

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])

This message was sent by Jonathan Vanasco ([address removed]) from NY Tech Meetup.
To learn more about Jonathan Vanasco, visit his/her member profile

Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])

This message was sent by Anthony Zeoli ([address removed]) from NY Tech Meetup.
To learn more about Anthony Zeoli, visit his/her member profile

Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]

--
Please Note: If you hit "REPLY", your message will be sent to everyone on this mailing list ([address removed])

This message was sent by Geoff Scott ([address removed]) from NY Tech Meetup.
To learn more about Geoff Scott, visit his/her member profile

Set my mailing list to email me As they are sent | In one daily email | Don't send me mailing list messages

Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]