D7 port

Yes and no. A D7 version is planned, but it has no timeframe.

The QuickPay module is only interesting to the majority of its users when there's modules to integrate it into other solutions. As for D7 that currently means Übercart and Commerce.

There is a working D7 port of the core module and a basic Commerce module that needs work and testing. The core module haven't been checked in yet, as the API might still change, and the Commerce module is the testing ground for the changes.

Übercart just recently got a beta release, and judging from the release notes, they're not done with fiddling with the interfaces. I don't want to surf the bleeding edge of Übercart releases.

Dear Xen

Do you have any time frame on when the Quickpay module for Übercart and Drupal 7 will be out, even in a beta?

We have portet our site to Drupal 7 and needs to have a webshop up and running in August, why we are hoping to be able to continue using Übercart with Quickpay.

/Henrik

No timeframe. Übercart is still in the same beta as the last time i checked.

The primary focus is Commerce, as it shows much more promise in being a stable fundament for E-Commerce solutions for Drupal. Übercart support will be more of an afterthought.

Maybe something will materialize before August, but I'm not making any promises yet.

Hi Xen

Would you mind to upload the D7 core port? It is for a very simple website that I would prefer to do in D7 rather than D6. I will not use Commerce or Übercart for it

/Bjørn

This is the working version, it passed its tests the last time i checked. It's the same API as the D6 version.

But be warned that the API will change when the proper version gets done. Updating should mostly be a matter of replacing function calls with a new object interface (the API will still map to the same QuickPay calls), but a bit of work will be needed.

I am working on this at the moment. I can create a git repo if anybody is interested.

Can one of the maintaniers create a 7.x branch in the repository and give me commit access? I need to port this for use with Drupal Commerce later on, but first steps are to ensure that everything works and make the settings form accessible.

I started off with the .tar.gz from above, but all the GUI elements are missing in this one.

Problems with the quickpay_commerce are currently creating a line item for $data['fee'] - it's a b**ch with the new currency field - but I will sort it out :-)

Regards,
Preben

Preben:
Is that an co-maintainer application?

I'd love to make you a co-maintainer, it would be nice to have someone that actually use Drupal Commerce helping out and with a 6 month old daughter and a new house, my time is pretty limited at the time being, but I want to make sure you're in the clear on what you're getting yourself into.

If I give you commit access, you're signing up to dealing with bugreports and feature requests on the 7.x-1.x branch (in cooperation with me) and in particular the commerce_quickpay submodule. I don't want to end up in a month maintaining a module I didn't write, on my own.

> I started off with the .tar.gz from above, but all the GUI elements are missing in this one.

No they're not, it's the job of the sub modules to make the settings form accessible somewhere logical. The different Commerce solutions all have their payment gateway settings pages in different places, and having the QuickPay settings page somewhere else is just confusing for the user.

> Problems with the quickpay_commerce are currently creating a line item for $data['fee'] - it's a b**ch with the new currency field - but I will sort it out :-)

Well, QuickPay has an API to calculate the fee beforehand, but that requires that we know what payment method the user selects in the payment window, which we can't. What's the problem with the currency field?

Argh, I did apparently not receive an e-mail when you answered this thread. It definitely is an application for being co-maintainer. This needs to be ported, and I want to help out until it works properly. I have used so many Drupal modules over time, and now is the time to give back :-)

I agree that it might be confusing for the user to change settings for commerce_quickpay somewhere else than in the payment gateway settings, but to make quickpay_settings_form() work in commerce_quickpay is a lot of work. I did make it work, but there are so many other elements in the base quickpay module that needs to be changed to make this work. For example we need to load the payment_method's instance every time we need configuration information. Read: Replace all variable_get()'s with payment_method_load(...), pull out the variable etc. etc.

This is really complicated in my opinion. But if that is the path, well - then that's what we do. But then the quickpay project is no longer a generic module that can be inherited into other payment modules over time.

I know that Quickpay returns the $data['fee'] field, but this needs to be added on top of the order's amount as a line_item(). This is what I am struggling with right now. When this is solved, next step is to implement the manual and auto capture functions.

You are more than welcome to contact me directly on preben@uhrskov.biz or prebenuhrskov on Skype.

Regards,
Preben

That's great, welcome on the boat.

> Argh, I did apparently not receive an e-mail when you answered this thread.

Apparently it happens. Rather annoying.

> Read: Replace all variable_get()'s with payment_method_load(...), pull out the variable etc. etc.

That's why I started work on a new (object oriented) API, that allows for different payment gateway instances, but that's still on the drawing board.

But for version 7.x-1.x, don't bother. Running with differently configured instances is an odd usecase that we can ignore for the moment being. Look into a way to ensure that there's always only one QuickPay payment gateway configured in Commerce, or, failing that, put a bigass warning on the configuration page telling the user that these are global settings.

The fee handling, cardlock=creditcard and autocapture is more important to get working, or else we'll very quickly get some feature requests.

Hi guys,
I was thinking about creating a module to integrate Drupal Commerce with Quickpays’ simple payment window, but found this thread during my research.
I’m very interested in hearing how the project is coming along? Would also love to help out if I can. Don’t have much experience with Git and pushing patches though..
// Stefan

Hi Preben and Xen

We are almost ready to go into production and would very much like to use this module to handle our payments. Therefore I was wondering if you would be able to post a status on the port to Drupal 7 and perhaps comment on the possibility of releasing an early alpha version of the port. I would be more than glad to help port this great module or simply assist with feedback and error-reports.

I look forward to response

Best regards

Henrik

Preben did something that apparently works for him. I pointed out some issues, but haven't heard anything since: https://github.com/xendk/qp-review/commit/255142650ba2009e25fc5d428af4bd...

I'll review any patches, answer questions and commit code when I'm happy about it, but unless someone steps up, nothing much is gonna happen in the foreseeable future.

So far, the user participation in this module has been limited to the occasional bug report. However, as I'm not actually using the module anymore, I'd rather that someone that uses the commerce solutions that QuickPay integrates with, write and test the code, as it's rather time consuming to learn and test against 2-3 different commerce implementations. Time that I don't have.

So, anyway. Anyone that takes the above mentioned patch, cleans up the issues raised in the comments and posts a new patch, will move 7.x-1.0 so much closer to reality.

Hi Xen

Thank you for your quick reply!

We got in contact with Preben, who mailed us the updated code. I will - together with a coworker - try to update the patch. Then we'll see where it takes on from there, but perhaps we could be interested in taking part of the project in the future, since we are depending on the module.

I use the D7 API (uploaded by Xen, see #5) for the site signup.salomontrailtour.dk. However, I've done a few changes to make it work. I've attached the current version that I use. It might help the D7 port moving on.

Beta 1 has been released.

Sorry to ask, but are there any timeframe on D7 port for ubercart?

Long, if ever. Couple of points:

The Commerce project was started to fix the fundamental architectural problems with Übercart, which wasn't fixable without rewriting the base. There was some ugliness and stuff about trademarks, and it ended up with a lot of Übercart developers leaving to work on Commerce. So Commerce is where the momentum is at.

Upgrading any non-trivial site requires work. A lot of things changed in core and the big contrib modules, so I can't imagine that upgrading an Übercart site is just a matter of upgrading the modules and running update.php.

Übercart has issues. Tax and discount modules breaks payment gateways because they don't even round the resulting total. How can you trust a system where there's no consistency between the amount on the order and the amount pulled from the payment gateway?

There's no migration path for Quickpay for the Übercart module, as I have no way to test if it works. While I could hack something together that would work for the few test orders I'd have in my development environment, I'd rather not pretend that there's a working migration path, when there's really no guarantee of it working on a given setup. Dataloss is worse than no migration path.

Considering these points, I'd suggest that anyone wanting to migrate to D7 look into migrating to Commerce. Alternatively, stick with Übercart on D6, as the advantages of D7 only really makes sense with Commerce which is build to take advantage of those features.

Hmm, not quite the answer I’d hoped for. I've looked into Commerce, but the concept and work paths are unusable, as many others have pointed out. Making a new product for each variant is not realistic at all.

Ubercart for D6 have a few problems, and I was hoping for them to be fixed in the D7 version. I fully understand that, if there still are problems, it is not a solid platform to build a store around. I’m just thinking, aren’t these problems able to be fixed? No one can use a system that can not be trusted. It really is a big minus, and sad, that we haven’t got a decent commerce module for Drupal.

Making a new product for each variant is not realistic at all.

For all intents and purposes, separate product entities is the way to go. One product with attributes seems like a good idea, but you're only making things more complex later on. Problem is that attributes are taking properties of the product (like price and stock availability), and fiddling with them, making things much more complex for everyone else. A stock tracking module have to split them out into separate entities for instance.

Another example: an attribute of a downloadable game might be which platform it runs on, which means that the module that handles access to downloadable files needs to understand attributes in order to serve the right file. While with distinct products, it just have to associate one file with each product, and let the product display handle the selection of platform.

Granted, Commerce could use some love in the bulk creation and management of ranges of products, and some work is being done. But attributes makes dealing with products much more complex, and requires all addon modules to understand attributes whether or not they actually use them or not.

And it seems that it's the accepted way to do things. Magneto works on the same principles (it also allows for simplistic attributes, if the need really be, just like http://drupal.org/project/commerce_option , with limitations).

I’m just thinking, aren’t these problems able to be fixed?

Yes they are. The fix is called Commerce.

It really is a big minus, and sad, that we haven’t got a decent commerce module for Drupal.

Excuse me? You find Übercart acceptable, apart from some issues, but Commerce isn't "decent"? I find that rather offensive against the Commerce developers that's worked hard to create a set of modules with solid architecture, documented APIs and test cases, in order to have a *solid* platform to build on.

So how many here are using some hacked up D7/UC3 version of Quickpay, and how many still want to use it?

And more importantly, anyone willing to step up and support it in the issue queue?