These three threads, one on Recurly’s support forum and two on HackerNews, accurately portray what I’ve been working recently:

On refunds after upgrades:

Ive run into a bit of a snag while integrating Recurly into my app and I’m not sure if its a bug or whether I’m doing something wrong.

For purposes of this discussion, I have a user and two subscriptions: Basic and Pro.

If I try to issue the user a refund after they’ve created a subscription for the Basic plan, there’s no problem. However, if the user creates a subscription with the Basic plan, then upgrades to Pro, I’m unable to issue them a refund.

When I try to do it via the Test Site, I get the following error message:
“The refund could not be processed because the original transaction could not be found.”

When I do it via the Recurly gem, I get the following error:
ActiveResource::ResourceInvalid: Failed with 422 Unprocessable Entity
recurly (0.1.4) [v] lib/recurly/subscription.rb:20:in `refund’

In my test app, the Basic Plan is $15/mo and the Pro plan is $100/mo. It makes sense that if the user upgrades from Basic to Pro immediately and then wants a full refund, I should not issue them a $100 refund (because the $85 difference hasn’t been charged yet), but I’d still expect them to be issued a $15 refund, no?

If you need step by step instructions for how to reproduce this on my Test Site, I’d be happy to provide them.

On how and when to charge:

I’ve been building a web-based mockup tool called jMockups for the last several months and I’d like to get your thoughts on when and how to charge for it.

I’ve asked several experienced members of this community whether I should charge from the start or wait and charge down the road and I’ve had mixed feedback. Those that say charge now say that I should establish from the get go that this is a high quality product worth paying for and that transitioning from free to paid is a pain (which from my own experience with previous sites is true).

Those that say charge down the road say that I want to get as much feedback as possible right now to make it a better product, that I’ll get more inlinks and buzz because more people will try it, and that I’m in this for the long term so its not a big loss if I don’t charge for the first few weeks.

The second issue: how much? Balsamiq is the clear leader in this space and their main product sells for $79. We don’t have identical products — theirs focuses on low fidelity whereas mine currently focuses on high fidelity mockups — but there is a lot of overlap. I plan to charge per month and offer a free option for folks to try it. I find myself basing my pricing off of this $79 number ($7/mo = $84/year) and while I think thats something that a lot of folks would pay, some of the feedback I’ve gotten is that I’d be better off charging much higher… $20/mo on the low end.

I don’t have enough experience to decide with certainty on either issue which is why I’ve been asking for feedback and I’d like to get yours too: charge now or wait and how much?

On prorating refunds for canceled accounts:

I’m integrating a recurring billing service into my web app and am at a point where I have to make some decisions on how I want to handle some situations. I don’t have much experience with this and am hoping to get your feedback on these questions and monthly billing in general:

1) If a customer cancels their account should you offer a prorated refund for the unused time? Or do you establish a policy that your monthly payment will not be refunded at all when you cancel your subscription?

2) Should you let customers cancel their subscription to your service without deleting their account? In other words, should there be a “standby” state that locks down their account so they have the ability to resubscribe in the future and keep their data, or do you make canceling their subscription and deleting their account/data a single, inseparable action?

And for those of you who have been faced with similar decisions, can you remember other important decisions that you had to make? Appreciate it.

Integrating a service like Recurly into your web app is not that hard, but handling the edge cases and making policy decisions complicate things a lot. Plus, billing is something you want to do right the first time. There is no minimum viable product for your billing system. You get it wrong and it could take a long time before you dig yourself out of the hole you create, especially if your users are vocal.

What fun would it be if it was easy?