71–80 of 125 posts
Caveat emptor, I am merely passing the link along, but I believe what they are trying to provide is making subscription membership easy.
Earlier quoted context omitted.
Authorize.net also offers a hosted option so that the merchant doesn't have to deal with the burden of PCI compliance. In other words, the merchant (you) never sees the credit card number. http://developer.authorize.net/api/sim/
They also have CIM, Customer Information Manager, where you send the credit card info (thus never storing it yourself) and you get back a token. Anytime you need to charge that card, you charge the token instead. PCI compliance is then on Authorize.net
My opinion on this: it is very difficult for me to add value via coding the world's best possible rebilling user experience and backend admin code. It is orders of magnitude easier for me to add value via either marketing (which I need to do more of) or adding features to the product that get it in the hands of more customers. This strongly suggests that I should not be writing billing code, ever. You need a bunch of…
You lose the ability to tweak and test one of the most important parts of the customer acquisition experience. There's a >10% conversion rate gap between different checkout flows I've tested on one of my ecommerce sites.
I've written my own subscription code for Authorize.net; it's around 200 lines, pretty straightforward (take the form data, POST to authnet to create a customer profile, POST to authnet to create a payment profile to store the card, POST to authnet to authorize the first payment, display any errors, otherwise save the reference token to the database and display a thank-you). It'd be smaller if you used a library like ActiveMerchant. Rebilling is a 15 line script as a nightly cron job.
I've also done integrations with Spreedly and Recurly. I didn't find they saved me any time; I had to write lots of code to send them information about the customers and process all their postbacks that you simply don't have to write if you do the charges yourself. Recurly was also changing its pricing and publicly arguing with its customers at the time, which killed my trust in the company.
Outsourcing your subscriptions to one of these startups is a business risk. They will forever be able to hold your cash flow hostage if they want to. If, however unlikely, your account is suddenly closed or they raise prices beyond what you can afford, you not only have to rip out all the integration you did and find another way to bill customers, but you will lose some of your customers while you're explaining why they can't manage their subscriptions at whatever.com anymore and begging them to fill out another payment form so you can continue billing them through someone else.
My opinion on this: it is very difficult for me to add value via coding the world's best possible rebilling user experience and backend admin code. It is orders of magnitude easier for me to add value via either marketing (which I need to do more of) or adding features to the product that get it in the hands of more customers. This strongly suggests that I should not be writing billing code, ever. You need a bunch of…
I do believe a blog post about how to practically implement such things into a framework (say Rails or Django) would do well.
Especially important for lean startups when considering payment providers for subscriptions is the ability to "take your customers with you" as you grow. When using Paypal, Clickbank, Fastspring/ Saasly, they are the merchant of record, so they "own" the customer data. If you ever want to move to a different provider, get your own or switch merchant accounts... the customers that signed up with these providers will n…
I use Stripe for Gumroad and it's amazing. Unfortunately, it's still private for now.
Earlier quoted context omitted.
I do believe a blog post about how to practically implement such things into a framework (say Rails or Django) would do well.
This is one of those instances where I wish everyone (specifically patio11) could see how much karma bryanh's comment has.
This may have been recommended in the other thread, but I don't recall it.
Earlier quoted context omitted.
I do believe a blog post about how to practically implement such things into a framework (say Rails or Django) would do well.
This is one of those instances where I wish everyone (specifically patio11) could see how much karma bryanh's comment has.
I disagree with most of what patio11 said, and have found (like bryanh) that using ActiveMerchant with Auth.net was no harder than when I tried Spreedly.
As such, I'd pass on patio11's advice and instead just get an authorize.net account, integrate that, and forget about it for the next five years.
SaaSy is all-inclusive, and once you see the list of features and comparison chart you realize that the basic services like Chargify, Recurly, Spreedly, etc. are actually missing 90% of the solution you'll need, leaving most of the software development and administrative work for you to do over the next couple of years. As opposed to leaving everything to SaaSy and being able to instead focus on growing your business.
For basic integrations, you can launch your subscription service in about 3 days and have the solution fully outsourced and handled by SaaSy, from your global taxes to chargebacks, payments, PCI, order and payment support, global currency payments, localized language-based order pages, fraud prevention, branded order and customer subscription page, cross-selling, subscription trial periods, etc. The list goes on and on, as SaaSy is truly an all-inclusive e-commerce and subscription management service that frees you up to focus on your business, and keeps you out of the complex e-commerce infrastructure business.
To see TechCrunch's take on SaaSy ("Online Subscription Billing Is Still A Hassle, SaaSy Aims To Change That"), see: http://techcrunch.com/2011/03/17/online-subscription-billing...