views:

253

answers:

3

There are a whole raft of questions regarding payment processors for web applications but I haven't seen one yet for desktop applications. What are your experiences?

Perhaps to put this into a little context, the requirements:

  1. Should be customisable
  2. Should be available in Australia at least, if not world wide (less critical).
  3. No storage of credit card details
  4. Recurrent micro payments of varying amounts each time
  5. 1-click payment. It's ok for the user to be registered with the payment processor provider.
A: 

Times may be a changing, but I don't think that you can get all of the above.

I do have some experience a couple years back with credit cards in North America. At the time the company I worked for needed recurring billing for a different amount each month (much like your requirement). At the time, none of the providers I looked into allowed for recurring payments where the amount varied. This may have changed, but I do not know of one.

I suspect your options are either to store credit cards and process your own transactions (not too hard but a path you have to walk carefully) or use recurring billing with a constant amount.

vfilby
+3  A: 

Unless you're looking for a world of hurt, you should not have Credit Card processing code in your client software! You might want to have an online component that responds to your client-software events and processes payments, through HTTPS requests, preferably.

It is essential that you remember to never trust ANY business decision / input that comes from the client machine! Otherwise you may be putting yourself at the mercy of black-hats who would code-kong-fu you into bankruptcy.

Redbeard
+1 code-kong-fu
dotjoe
A: 

Micropayments sort of throws the whole thing out, I think, but why not use bpay? Everyone in Australia knows and trusts bpay, I think: http://www.bpay.com.au/

tunaranch