reverse bounty for australian payment processor (eway.com.au)

[dan90]

Hi,

we had 3 NGO clients wanting to pool together resources to develop a payment processor for the eway.com.au ecommerce service, which supports Australian banks and recurring donations, for use in civicontribute and civicevent. However, two of those have had to defer participation in the project.

I thought I might propose a  drupal style reverse bounty to see if we can drum up enough funds to get the payment processor finished. The basic deal would be to get pledges to finish the project, and get paid when we complete it, provided we get enough pledges TO complete it. All donors are credited for their contributions. Would anyone be interested?

I'll post up more details if i get responses in this thread, but the long and short of it is, we are a small consultancy specialising in NGOs with a number of site developments under our belt (e.g. http://cpd.org.au) and various patches to drupal. we do development in python, php or whatever seems to fit the task at hand, etc, but we are on a tight budget and time-strapepd, so we NEED to pay coders to do the development. (Equally, we'd be delighted if someone else wanted to do the development of such a payment processor, but if anyone's doing it they are staying under the radar.)

At a rough estimate I'd say the job was worth about $10k, and we already have $2.5k pledged. If there are enough contributors i reckon this one could be polished off quick smart. Let us know. Alternatively if people have other ideas about how to approach this, I'd be keen to support them.

dan

[petednz]

Hey Dan - nice approach, and one that I was going to put up for discussion anyway. I think the issue for small players to contribute back is that to make the contribution seem meaningful pushes the development cost too high.
We also have a need to look at pulling data from NZ banks in order to be able to keep record of APs, when they cease, change etc. Would be interested to compare notes, and if what you are suggesting covers what we have on our list, then yes we could be in for a share.

Good move - what's your business name?

[Eileen]

How difficult is it for someone who has developed the payment processor for joomla to do it for civiCRM? I notice on this site there's a lot of people bidding a good deal less than $2500 to develop eway processor for joomla

http://www.joomlancers.com/Extensions_Programming/payment_mambot_for_j_subscribe__eway.com.au__1186512956.html

Although I don't think they do the open source ethos thing looking through the website 

[PBarwell]

G'Day - I've just written a CiviCRM eWAY Payment Processor - a week ago I looked for eWAY / CiviCRM and the only ref I could find was a Nabble conversation between Donald Lobo & Brant Winter (date Nov 22/24) - I contacted Brant last Thursday - he'd had no luck - so I wrote the module.
TWO CAUTIONs:
(1) I have only implemented a single payment process - ie I did not need nor have time to do the 'recur' process section.
(2) eWAY is multi-currency challenged - it will not integrate with CiviCRM for multi-currency as it uses different accounts ('user_name')for each currency and CiviCRM enables one per allocated payment processor, expecting (very reasonably) that the 'currencyID' parameter will be fed to the payment processor's gateway. This is not the case with eWAY - it does not have a field for 'currencyID' in its XML request. So you can have a different currency for a range of allocated (ie different named) payment processors for different (say) events - but you can't (without some interesting coding) have multiple currencies for the same event.

The package is fairly complete - has simple installation notes showing where all the files go, so as well as the main eWAY.php, there are the Contribute and Event class extenders files, and the eWAY (package) support files, and simple text for an SQL INSERT that will add the eWAY entry into 'civicrm_payment_processor_type ' table, plus entries for the 'Processor.Hlp' file for the eWAY config form's pop-up help 'boxes'.

Code was based initially on the recent PayJunction, borrowed heavily from AuthoriseNet, took a bit of input from Drupal 5.7's 'ecommerce' eWAY module (stable and dev versions), and of course referenced the 3 eWAY standard developer's sample files.

Code is pretty good on differentiating eWAY errors and system errors and formats error messages appropriately.
Stole some good duplicate checking from AuthoriseNet, so if the user submits twice if catches the second one before it can send a duplicate to eWAY.

There are two versions of the 'eWAY.php' - standard code and 'eWAY_Debug.php' full of debug 'alert' statements if you need to display request and response packages, etc. Might be useful for someone adding the 'recur' section'.

Was coded for CiviCRM V1.9 - but shouldn't be too much of an issue to use it for V2.0 - probably be doing that myself shortly.

All in all it's on a par with the coding standards of the existing payment processor modules - been reasonably well tested (haven't had a whole lot of time), and except for the missing 'recur' function, and eWAY's inherent multi-currency limitations its complete.

I've blitzed this since last Thursday (13 March 08) - it took me a very hard 5 days +, with many long hours straight through last weekend - if there is a possible form of compensation - I'd be v interested to hear about it - equally if there's a desperate impoverished NGO then what the hell.

Regards

Peter Barwell
PB at DolphinSoftware dot com dot au

[Donald Lobo]

this is awesome. thank you

lobo

[PBarwell]

Donald (lobo)

Looks like we are upgrading to CiviCRM 2.0 today (as support for Events looks a lot better) - I'll update the eWAY code for 2.0 if it needs any changes (clues ?) and post again accordingly.

You want this for your Melbourne gig ?

BTW eWAY says they are interested in listing it on their PlugIns page - if you add it into standard CiviCRM - then they'll link to you guys as a user of eWAY (every link helps).

Cheers

PB

[Donald Lobo]

Let me know when u've upgraded it to 2.0.

Is eway one of the main processors in AU? We need to figure out how we deal with the code / setup for various payment processors. Not sure if packaging it in the core code base is the way to go (its definitely not a scalable solution)

lobo

[PBarwell]

Donald,

OK - eWAY Payment Processor now operating in V2.0.1.

And to answer your question - Yes eWAY is one of the main processors in AU.

BTW - The single currency restriction may not be such a big deal for Aussie users of CiviCRM if the majority of the 'constituents' are Australian. Also it doesn't stop international users from paying - it only restricts them from paying in any currency other than the (eWAY account) designated currency (AUD by default).
So if for example you are being forced to pay in AUD for an Australian event - would you be that bent out of shape ? Happens all the time when you are actually (physically) travelling that you pay in the local currency with your credit card.

AND LASTLY - I wasn't suggesting that you add my stuff to core just yet - by having a package ready I meant that I've made a ZIP file with the modules, the help file update, the SQL syntax, and some reasonably clear install instructions. So I thought it might be useful for you to be able to indciate at your Melbourne gig that an eWAY solution (currently without recur) exists.

Cheers

pb

[woodsy3629]

What was the outcome of this, did you secure the funds you were after for the code you wrote? Or donated it the community?

I am very interested in it for the Non-profit org I work for, I looked at all the paypal pro, but they are too expensive for us to afford, but still wish to have it fully integrating into Civicrm without having to go to other pages.

Regards,

Woodsy

[PBarwell]

Woodsy,

Hi, I wrote to Dan90 directly to see what was happening - ie to see if there was some $$$ around but have had no reply.
I've been in contact with PeterD re possible use in NZ and Lobo re having it available for his Melbourne gig and that's about it.

I'm getting a lot of benefit from being able to use CiviCRM, so I'm happy to contribute - if you'd like to get hold of this package let me know - PB at DolphinSoftware dot com dot au

regards

PB

[Donald Lobo]

PB:

We'll definitely get this up at the melbourne training and see if folks would like this to be packaged with future versions.

If you are in the melbourne area, would be good to meet up

lobo

[woodsy3629]

Lobo,

I am in Melbourne, I would have loved to come to the training, but I heard it was full? I play football on saturday's so I didn't think I could have come anyway.

I am still interested in the eway payment processor, and woud love to have it in the 'core', or try and squeeze my group for some cash for it.

I have been ever increasing my interest in development with Joomla/Civicrm and a few other components.

I haven't done any coding since university (java), but have picked it up as I go, just like riding a bike (Just need to start riding some more)

Anyways, I'll keep reading and coding.

Cheers Woodsy

[VinceMD]

Hi,

sorry for replying to such a old post.
I was just wandering if further improvements were made to the eway payment processor ?
For instance, does it handle recurring payment ?

I found CiviCRM-eWay-recurring-payment-processor on github . is that something different from this payment processor, built by PBarwell?

[AndrewSmith]

Hey Vince,

Don't feel too bad about replying to an old thread.  If it wasn't for you I wouldn't have found it either.

I've found the eWay Payment Processor listed in the current CiviCRM ... so it's looking good.  Feeling even better about implementing CiviCRM than ever before!

Andrew