I've had good luck with Payflow Pro, formerly owned by Verisign, now with PayPal.
It offers functionality to modify payment profiles, retry declined cards, cancel & resume payments, set subscription terms, and send decline emails to customers.
I've worked with both Authorize.net and NetBilling on recurring billing for customers but have encountered a serious shortcoming with both. I would like to expand this question into one that has been recurring lately:
jwolthuis, to your knowledge does PayFlow Pro send a notification of the recurring billing back to the website to automate updates?
1. Site owner offers automatic recurring billing for memberships (opted in by the customer of course.)
2. It would be easy to run a cron job from the website to check customer expirations and initiate a charge through the processor, but this would mean the cron job must get the CC info from "somewhere" - that somewhere being stored in a database on the web server. The customer wisely does not wish to store CC information on the website but rather allow the processor to manage it.
3. Therefore a "usable" recurrent billing system should be able to initiate the recurrent credit card charge and post a notification to a website url (not just send an email) to update the customer's membership.
All of the CC processors I have worked with are not able to do this, for whatever reason. I'm not sure if payPal can do this, but the model would be similar to payPal's IPN (Instant Payment Notification) methods. A secure string is posted to a recipient program or script on the website, which parses the input and updates the database.
When someone makes a purchase by eCheck through payPal, the IPN is not sent until several days later when the eCheck clears. It seems to me the same concepts should apply to recurrent billing.
This is relevant to the original question in that yes, Authorize.net, Netbilling, and PayFlow Pro manage recurrent billing, but if they doesn't post back to a website it means the site owner must manually update their database, which renders recurrent billing worthless for most automated maintenance.
It would be easier to maintain everything on your end, but if you are going to store credit card numbers, you need to be PCI compliant.
Some gateways will do the recurring billing for you on their end, thus bypassing the need for PCI compliancy (even though it is a good idea).
Most gateways don't charge you either for this service and it helps to reduce your transaction costs from the merchant account provider as well a few cents
Payflow Pro has a Reporting API that a website can call on a scheduled basis (daily perhaps) to download yesterday's results (successes and declines).
A website can either choose to allow Payflow Pro to email the declined customers, or process the declined transactions themselves.
In realtime, Payflow Pro has an Inquiry action to allow a website to determine "right now" if a specific recurring profile is "active", "retrying" (a decline), or "inactive" (due to a repeatedly-declined card).
Edit: I have to disagree with Corey, that it's easier to *not* store credit cards on your site. Modern gateways don't require them to process add-on transactions (refunds, voids), instead replying on a one-time Transaction ID. Recurring transactions are given Profile ID's, good for the life of a recurring payment.
The storing of credit card information provides limited benefit to order processing workflow, and can cost you your company if a former employee or web design firm accidentally lets that information loose.
worldpay have the futurepay system specially for recurring payments
We utilize PayPal Subscriptions for recurring payments. We're currently working on the API stuff to tie everything in with our applications.
Definitely an interesting topic. This is an area I've not explored in depth due to lack of demand. Now that I'm working on a Pay Per View project which includes a subscription based model, I'd be interested to see what others are doing.
|In realtime, Payflow Pro has an Inquiry action to allow a website to determine "right now" if a specific recurring profile is "active", "retrying" (a decline), or "inactive" (due to a repeatedly-declined card). |
This still puts the debit and site update "out of sync" and requires the website to regularly check with the API for recurring billing transactions. Authorize.net has this feature as well.
What should happen is the processor should debit the credit card and send an immediate notification to the web site. I have a customer that is searching for this ability and we're finding none.
The process is not that demanding. If a processor can send an auto-email, they can initiate a secure post. We've even considered parsing the notification emails which is a workaround at best - if the email changes, the system could break down.
He doesn't want to deal with customers who call and say "my credit card was debited and my account is still expired." "It will update tomorrow/in a few hours" is just not an acceptable answer for him.
[edited by: rocknbil at 6:09 pm (utc) on July 27, 2007]
We use plain old Paypal to process six-figures worth of recurring subscriptions a year. A bit of modification to readily available scripts makes it integrate into our user system flawlessly. We have VERY little overhead involved on our end, it's almost all automated.
The only issue we have is users (less than 1%) who don't read the four different warnings that the subscriptions automatically renew and get upset with us for 'stealing' from them.
Recurring income is one of the secrets to life.
rocknbil, Paypal does that. The IPNs are basically instantaneous.
Welcome to WebmasterWorld kungfufrog!
|Recurring income is one of the secrets to life. |
Ah, make money while you sleep. :)
|What should happen is the processor should debit the credit card and send an immediate notification to the web site. I have a customer that is searching for this ability and we're finding none. |
Depends on when they process the recurring payments, and how many "subscribers" you are dealing with.
If they process each recurring payment the second that it expires, then the IPN model is a great feature to have.
If they process several hundred at a time (as a batch), I'm thinking several hundred simultaneous IPN's might do bad things to my site.
When does PayPal send the IPN? At midnight, or at the precise time of the renewal?
I use Merchant Partners for my payment processing company for selling recurring advertising on my site. The current sale plus the recurring sale setup are all in one transaction.
Their control panel is very nice in that it allows you to modify virtually any part of the recurring transactions as well as create one from an existing sale - all without knowing the CC # once they have it on file.
I use 2checkout for recurring payments. It's just OK. From the description of some of these other services I would go with them over 2CO.
A note about PayPal... Their system is easy to use and IPN makes it easy to integrate into your own system.
However when it comes to subscriptions their system hasn't been updated, or apparently even looked at, for quite some time.
If a subscriber that has an actual PayPal account (pretty common, these) removes a credit card from their account (even if the subscription payments are setup to come out of their balance and/or bank account) the subscription is cancelled immediately. Subscriptions are also cancelled if a user changes their credit card information by adding a new card or switching their primary card.
Sometimes it seems like subscriptions are cancelled for even more esoteric reasons, possibly involving sunspots. When it happens the user is notified only via email.
So keep in mind that if you use PayPal to handle a large number of subscriptions you're going to be spending a lot of time manually dealing with subscription cancellations that the user may not even know about and/or writing the extra code to automate the process.
I had a miserable experience dealing with Paypal in general. Getting setup was a nightmare and none of their internal staff seems to understand the big picture enough to be able to help with anything.
I've heard horror stories of them locking up accounts on people over disputes and so I'm concerned about my ability to deal with them if anything like that ever occurs. This experience was worse than I even thought was possible and so I will *never* work with Paypal on such a level.
To me - this is simply a non-starter issue.
PS - Authorize.net was *much* more professional and behaved in a manner I expected of a services company that will handle my financial transactions.
Do you have the latest version of Authorize.net's Recurring Billing API? Supposedly they improved it recently.
Absolutely agree, the payPal hysteria alone is enough to make it a less than wise choice for a serious processor. For the purpose of this discussion, I only mention the IPN methods as a model for what a processor should do for recurring billing.
|When does PayPal send the IPN? At midnight, or at the precise time of the renewal? |
This is the "beauty" of it - in a credit card transaction, the IPN is sent almost immediately. In an eCheck transaction, it's sent several days later when the eCheck clears. Your script is always "listening" for a post from the processor to completely automate renewals. If this model were applied to recurrent billing, the attempted debits would only occur at a time you set for renewal - for example, renew at the hour of expiration, or hour before, or day before, etc.
|If they process several hundred at a time (as a batch), I'm thinking several hundred simultaneous IPN's might do bad things to my site. |
Nah the numbers would have to be in the thousands or hundreds of thousands to create serious issues with the functioning of a site. Unless your 100,000+ members all joined at the same time, the posts to the site should be comfortably spaced apart, depended on the date and time of the pending expiration.
|Do you have the latest version of Authorize.net's Recurring Billing API? |
Actually the email my customer received from A.N. about the improvements is what got him to thinking. :-) We fully investigated it and it all sounded great until we got to how we update the database, which is why it wound up in this thread.
I've been using PayPal subscriptions for quite some time and they work fine, with one glaring exception. PayPal sucks when it comes to moving a subscription from a lost or expired card to a new card. Very few of my customers ever get this transition right and the subscription ends up being cancelled inadvertantly. I give them a link to create a new subscription and life goes on. It's a pain...but it works.
Worlpay's 'futurepay' is good for recurring payments. We've implemented it on numerous sites over the years and it works just fine.
i'd go with paypal all the way but just note that the fees aren't competitive after six-figures. i've also found it's not viable for micro payments.
on the plus side, the integration costs are, without a doubt, very cheap. there are many good programmers who are familiar with the api, so hiring contractors is an option. they are also responsive to suggestions.
you might want to check out NOVA . they offer card processing and gateway in one product (viaklix) .. it handles recurring billing with ease. instead of paying two fees (one for merchant processing and one for gateway fees), you might want to consider NOVA which offers a one stop product. I dont work for them I am just a satisfied nova customer.
[edited by: minnapple at 3:59 am (utc) on July 30, 2007]
[edit reason] No urls please [/edit]
You could check with also google checkout, moneybookers, chronopay, protx, 2checkout, multicards etc.
We use 2checkout but the system sucks when it comes to setting up recurring payments. Highly confusing. I need a shift.
[edited by: minnapple at 2:29 am (utc) on Aug. 1, 2007]
We've recently implemented both with Paypals Website Pro Payflow Pro API and authorize.net for recurring billing. Supposedly the new API with Paypal was not up on their site up until this past week. This was required for us to complete the programmatic and seamless integration required by the client so you may want to contact paypal by phone if you don't see it on their site. It does require that you have your merchant account with paypal or your own merchant account.
Both are very solid systems for initiating recurring payments. With paypal you can start with their link only program until you have cash flow from your program and then do the programming work if you prefer.
Do any of these solutions work well when a subscription client's credit card needs to be replaced?
great question... also, how do we get notified when PayPal changes their API? I feel like it's constantly evolving but we never get the notices.
|Do any of these solutions work well when a subscription client's credit card needs to be replaced? |
we use worldpay's futurepay system
worldpay send us an email every month listing which customers cards are due to expire
when cards expire or fail, we have a standard email we send to the customer telling them to login to worldpay's system and update their card details
(bear in mind customers NEED the email - updating card details isn't something a customer will do regularly - they may have subscribed 2 or 3 years ago!)
about 70% of customers whose cards have failed manage to update their card details - payments are then taken automatically again
about 15% don't read the email and get confused with the logins and updating details (and they're almost certainly the type that wont RTFM for anything) but eventually get their card details updated
the other 15% don't update their details and we terminate their accounts, but at least we've had payments from them for a year or two or three!
put the time and effort and money into a good system and it pays you back many times over
I was going to start a new thread with the same question, but since this is already here....
Are there any solutions (besides going through all the hoopla of getting a merchant account and being PCI compliant, storing customer details, etc.) for billing subscriptions with variable charges each month? Let's say a fixed subscription fee plus a variable amount each month?
|Are there any solutions ... for billing subscriptions with variable charges each month? |
worldpay's futurepay *apparently* allows that or something like it (it's in the docs but i've never tried it as never had a need to use it)
with the normal (most common) use of futurepay, worldpay automatically charge the card for the same amount at regular intervals (ie weekly / monthly / etc) - you can adjust the amount for all future payments
AFAIK, with the other use of futurepay, worldpay stores the card details and allows you to charge whatever amount necessary whenever necessary - worldpay doesn't charge the card automatically
| This 40 message thread spans 2 pages: 40 (  2 ) > > |