A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.
I run a small, friendly, all-ages dating/community site that offers paid subscriptions. In order to increase convenience for my members and hopefully boost sales, I'm looking into auto-recurring billing services.
Oddly enough, the fact that we're *not* an adult-oriented site has led me down some wrong paths. My first thought was to see what some well-known adult websites were using since adult websites often lead the way. Unfortunately for me, there seems to be a cottage industry of processors that specialize in processing payments *only* for adult sites and weren't interested in my business. :)
I've been relatively happy with PayPal so far because they have a simple API. Unfortunately, while normal PayPal purchases can be made with a credit card and no PayPal account, their recurring billing options are only available to customers with PayPal accounts.
What I'd like is something that works like the following:
1. Customer selects purchase option on my website
2. I pass the billing information (customer ID, product ID, price) to the payment processor's server
3. Payment processor takes credit/debit card details
4. Payment processor calls a page on my site when a successful transaction is accomplished. Note that I'm on a shared webhost and may not be able to install custom components. I'm also stuck on ASP "classic" so a simple form-based API is preferred/needed.
5. Payment processor calls a page on my site every month (or year) when the subscription is auto-renewed. With the original passthrough variables such as customer ID in addition to the instance-specific variables.
PayPal does exactly what I want, aside from forcing recurring customers to create PayPal accounts.
I've seen a few services like WorldPay.com's FuturePay service and 2Checkout.com that offer recurring billing services. However, they are under-documented compared to their other offerings and feel like a bit of an afterthought. Whether this is the actually the case or not, I don't know... so I turn to JoS for recommendations!
Here are some previous discussions on the topic here at JoS:DoS. Note that these threads are archived and cannot be replied to, or I'd have brought one of these back to life rather than creating a new one.
"How to handle online credit card transactions"
Some good starting points, although there's no mention of recurring billing.
"Credit Card Processors/Merchant Services"
Again, some good information; not recurring-oriented.
Sunday, October 15, 2006
We struggled with the same issues earlier this year when we were setting up our payment system for our site ( http://www.MyHomePoint.com ). This thread has some details: http://discuss.joelonsoftware.com/default.asp?biz.5.342999.16
In the end, we ended up ditching the automatic recurring billing option and went with the basic PayPal API. So now, instead of automatically renewing their subscription, they get notices on the site that tells them that they need to re-subscribe soon. Once the date passes, they can't access their account until they renew for another period. Less than ideal, we know, but we really didn't want to force anyone into having a PayPal account.
And while the Consumer Reports tactic of slipping in that $3.95 charge every month for an ongoing revenue stream is appealing, we wanted to take a slightly higher road.
While that doesn't directly help you with your goal of finding a recurring billing solution, we felt that it was just easier to move forward with the simplest thing to get incoming revenue and we could fix it later if necessary. So far there have been no complaints from a user perspective.
Hope that helps!
Tuesday, October 17, 2006
I do my own recurring billing through TrustCommerce (Trustcommerce.com)
They store the CC in their system and provide a billing ID.
We reference that billing ID when doing the charges through their API.
We keep a start date, next payment date, and recurring interval in a database.
Every night a cron script runs and does the payments.
Pretty easy really.
We use SkipJack as the gateway and 5/3rd bank as our Merchant processor. We can do all these things relatively easy and they have an API to tie into. We can do recurring billing via the API or set it up on-line at the gateway.
Monday, October 23, 2006
I use Skipjack ( www.skipjack.com ) and it does everything you want, except call a page on your site every month. It can be configured to send you and/or the customer email notifications whenever payments are processed or declined. I tried PlugNPay but they charge extra for the recurring payment processing and I thought their documentation wasn't as good as Skipjack's. Skipjack doesn't charge extra for recurring payments and the documentation and examples are pretty good.
My application is an online backup service, www.rhinoback.com . Rhinoback customers choose a subscription plan on the website and their credit card is automatcially billed monthly. In the case of the Rhinoback website, I built and process my own secure forms because Rhinoback dynamically calculates the cost as the customer selects subscription options and storaage amounts. Rhinoback also does some other things that are specific to the online backup service, such as allowing customers to upgrade or downgrade their subscription by selecting variable amounts of backup storage as needed. Rhinoback customers can also change their credit card and billing information online or cancel their online backup accounts at any time and stop the billing completely.
I am sure there are other good payment gateways, but I only have experience with these two.
Friday, November 10, 2006
This topic is archived. No further replies will be accepted.Other recent topics
Powered by FogBugz