Gateway implementation issues

Posts: 2
Joined: 02/22/2008

I'm developing a payment gateway for a Danish provider. There seems to be some interest in the Danish Drupal community for an official gateway (as there is none), so this provider has generously sponsored development of both ECommerce and Übercart modules. But I have some issues with UC:

Firstly, I thought it would just be a matter of implementing a gateway for uc_credit, and let that deal with all the card stuff, and just handle the processing. However looking at the uc_credit code, I see that it stores the card information in the database, and according to PBS (the entity all Danish gateways talk to), that's a big nono.. They're scared enough letting people handle the card data for an instant, if you're actually storing it anywhere, you have to pay big bucks and spend a lot of man hours convincing them that you have a secure setup.

So my only option is to create a fullblown payment gateway from scratch and not get any of the niceness of uc_credit, if I'm gonna make sure that the card data only ever go from $_POST to the gateway HTTPS call?

Secondly, the way uc_payment works, it calls a processing function in the gateway module, and if it returns 'OK', it does an uc_payment_enter to enter the payment on the balance. As far as I can see, the way it deals with the minor difference between an authorization and an captured payment is that it doesn't? I've figured out (with some help) that people handle the capture part by using Workflows, but I don't get how they manage to make their order balance not even out at checkout?

Well, actually, I just thought of a possible way: defining my *_charge function to take $amount as a reference, and then set it to 0 if I'm just authorizing, but that feels rather hacky..

So what am I missing?

Oh, and if someone could give a pointer to where too hook in the capture buttons (form_altering uc_payment_by_order_form?), I'd be very grateful.

Posts: 5367
Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

I agree, there ought to be a way for CC data to never touch the database and this is definitely part of the roadmap for the future. If you even had an acceptable patch for core I'd review it in a heartbeat. I'm guessing it doesn't matter if the data is encrypted and only around while the order is in process and then dumped? Sticking out tongue

The biggest problem is that the way forms are submitted in Drupal, you're going to lose $_POST somewhere during the form processing. The best you can really do is either bypass the review page and process the CC then or else store it encrypted in a session variable or in a hidden field on the form on the review page and then process it in the review forms submit handler. Of course, either of those methods are going to be just as vulnerable as storing it encrypted in the database.

Regarding authorizations... you know, we just haven't run into a use case where someone could test and offer feedback on that functionality. The payment isn't captured yet, but it's as good as a payment received when authorized. If the store owner decides not to capture those funds for one reason or another, the payment could always be deleted from the order. Perhaps just put in the order comments and the payment comment that it was just an authorization and leave another comment when it's captured. The main reason I'm not looking for a capture notification is I don't have any clue how a third party service would want to notify the store that a pre-authorized payment has now been captured. This would really depend on the gateway module. In this case, I don't think your idea of receiving the amount by reference is a hack at all.