Ubercart

3rd Party Hosted Payment Solutions

Paypal and Google checkout, while these are very popular options for most people.... are abnormalities in the "Online Processor World" and we can not use these in the debate. I believe since these are soo different than how the majority of processors work on the internet, they will need to be dealt with as special cases. I believe since any hosted payment solution is so unique, they will need to get dealt with on a case by case basis.

Payment Solutions where you send the card info, instead of forwarding the user to 3rd party website.

This is the majority of other online processors and where you're going to be able to abstract a lot of code. Most of these are small mickey mouse operations with minimal feature sets. They simply provide you with an API which you integrate and toss the credit card numbers too and they process them. Having a processor which you can store credit card numbers on, in my experience, is the exception to the norm. Very few even provide you with a method to rebill your customers. If you expect to have these features for "future supported processors" you will quickly figure out, you will not be able to support most processors, since they do not have these features. In my opinion, you should be going for the lower common denominator feature set for all processors, and then allow ubercart to build up functionality around this common feature set. Any additional features which specific processor can support (storing rebilling information, storing credit cards) should be an extension for that processor...but Ubercart should be able to provide rebilling for processors which do not support it internally, this will require ubercart to store credit cards internally for a processor which does not support storing on the processors servers.

Think of all the functionality Ubercart could provide on top of a processors feature set, by dealing with the majority of processing itself. Also keep in mind that any extension of these features, would then be shared by all processors which Ubercart supports. Believe me, this is a powerful and useful bonus of dealing with things yourself. You'll actually find when implemented it like this, that it simplifies things, rather than makes the problem harder, because you can ignore the differences between processors and instead simply use your time to focus on what they have in common.

Also if you rely on a processors feature set, for say, rebilling. Then you also need to rely on their feature set for cancelling. Say one of your admins deletes a user which has a rebilling subscription on your site. You will need to contact the processor to cancel his recurring subscriptions (which is difficult and messy) instead of simply changing a field or two in your rebilling database. This gets messy really quickly and in my opinion again, is best internally dealt with.

I also if we're dealing with most things ourselves, we will need to down chargeback, refund and cancel information and cancel subscriptions, otherwise you have accounts which will continue to get billed, which shouldn't. This is important and should not be neglected as it will bring chargebacks to your account. I of course believe this can be optional, but should warn the admin if this "hook" is not implemented for his processor. Dealing with his yourself, is a lot simpler than having to deal with all the other issues which arise from having a processor deal with your subscriptions. Also 90% of processor support batch downloading of this information and if they don't processors I've worked with are able to created and provide you with a web service to pull the info down in a couple of days, as it's simple and they understand why it's important to you.

Another good reason to deal with the majority of the functionality yourself is that many processors charge you different amounts of "Levels of Integration", which essentially boils down to, you get charged a different amount for the feature set they provide for you. The lower you can get, the cheaper these solutions become. Some processors will charge you more, say if you want to use their recurring billing and cancel features.

If you rely on your processor to deal with all your credit card information and you run a subscription site...what do you do, once that processor no longer exists. Or what do you do, when say your merchant account gets too many chargebacks (with mastercard, that's 2%) and you are kicked off. Or what do you do, when you find a cheaper processor which will save you thousands of dollars a month in fees. The answer is nothing, if you've relied to heavily on the processor you're currently dealing with. Believe me, try going to a processor and asking for the stored credit card numbers, so that you can move off of them and onto a cheaper processor. Not going to happen.

What's the best way to make everyone happy?
Some processors support some features and some processors don't. In my opinion, you should chose the lowest common denominator of options most processors will support and create all the other functionality you need yourself. This functionality will be the default fall back for processor which do not support internal processor replacements for that functionality.

Ideally, we'd create a "shell module", which you copy and paste and fill in the functionality. Hooks will be used this.

• Auth
• Capture
• Refund
• Void
• Store Credit Card as Key (optional, store internally in PCI complaint method)
• Some kind of hook for rebilling (optional, use your own schedules)
• Batch Download Cancels, Chargebacks, Refunds (optional, warn admin if not implemented)
• Real Time Sample Menu Hook for Postback cancels, refunds, chargebacks (optional, warn admin if not implemented)

This is essentially the base feature set. Recurring functionality can get created from this. Extensions can get created from this. A bunch of other features can get created from this and once they are, they are shared between all processors supported by ubercart.

Another bonus is, that while some processors will support a bunch of other features in their API, they can essentially be ignored and only the lowest common denominator base functionality will be all that's required to get a processor working with Ubercart. This will allow to get a processor up and running in ubercart as quickly as possible. It can of course be extended after that to provide all the bells and whistles that processor supports internally (store credit cards on their server, use their rebilling methods).

When a admin installs a processor on their ubercart, they should be provided with a checklist of features that processor supports. Not all processors will support captures, so the admins should be warned about this. Not all processors will allow you do store credit cards on their servers. Not all processors will allow you to store rebill information on their servers. For Processors which do support "Extended Optional Features" we should allow the admin to choose if they want to use them or not. If they chose to opt out of storing their credit card information on Authorize.net's servers, and they can instead store them internally in Ubercart using a PCI complaint method. Perhaps we should default to allowing the processor to deal with as much as possible, or as little as possible. I don't care which one as long as I can choose.

Schedule Linked Lists
Essentially this is the most complicated schedule queue i've seen, but creating the architecture in the way I've discussed allows it to be extended very easily and hooked well into things like extension and discounts.

Scenario #1

1. 3 Day - Free Trial ($30 Auth) | Next Schedule #2
2. First Month ($30 Capture) | Next Schedule #3
3. Second Month ($30 Auth + Capture) | Next Schedule #3

Then you create a product and associate it with Rebilling Schedule #1.

Scenario #2
Say you have a physical product, which gets purchased once then ships a new suply every 30 days. Schedule would look like this.

1. 30 Day Supply ($30 Capture) | Next schedule #1

Failed Rebill Extensions

A client has a 30 day subscription which failed to bill. You extended him 3 days and tried again, failed. You extended him another 3 days at which point it was successful. Do you give him 30 days from the current date you've been able to bill him? Or do you give him 30 days from the time his subscription expired?

Expired is the most accurate answer, but this also increased chargebacks for our clients. Customers would see perhaps 2 charges in the same month maybe 2 weeks apart. We had to make this feature of the extensions customizable, with most clients choosing the later less correct option to avoid chargebacks.