Forum Moderators: buckworks
I run an online shopping cart system call BlinkCart and was wondering what is the best way to process recurring payments. I have currently setup Paypal to handle my fees but Paypal seems very limited when it comes to functionalities such as cancelling and modifying payments.
Can anyone recommend a good online payment processer for recurring payments that isn't too costly and allows programmatically cancelling and modifying payments
Any advice would be much appreciated. Thank You.
It offers functionality to modify payment profiles, retry declined cards, cancel & resume payments, set subscription terms, and send decline emails to customers.
jwolthuis, to your knowledge does PayFlow Pro send a notification of the recurring billing back to the website to automate updates?
Scenario:
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.
Correct?
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
-Corey
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.
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]
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.
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?
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.
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'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.
ginger
A note about PayPal...
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.
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.
[edited by: minnapple at 3:59 am (utc) on July 30, 2007]
[edit reason] No urls please [/edit]
[edited by: minnapple at 2:29 am (utc) on Aug. 1, 2007]
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?
yes
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
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
