Integrate more tightly with the UC Payment module

I'd also like to request co-maintainership of the module to help develop and maintain it further.

Thanks for going over it jrust! I appreciate it.

For the fraud detection, I mentioned that I had removed it. Looking over the code, it seems that you're talking about the system automatically charging and then voiding a credit card based on what the user dictates are appropriate AVS and CVV responses, correct?

Could you elaborate on what you mean by marking an order as shipped in Linkpoint? To my knowledge, an order will be marked as shipped automatically by the system when an order is a SALE txn or a POSTAUTH txn. As I understand it, your shop owners just go through and move PREAUTH orders to a complete sale by doing a ticket transaction.

The functionality I've added allows you to do this in Ubercart itself now. Credit cards can now be charged through the API using Ubercart. This eliminates the need for your store keepers to go through the linkpoint virtual terminal for most occasions. I understand that you don't want bad/rejected cards to be marked as shipped, and you would simply not "charge" the cards in Ubercart now.

Does this make sense? Are we on the same page?

I apologize for the tab issue. I work in Coda, where I do indeed use two space tabs, but when I copied it into TextEdit, the tab lengths were not retained.

ryan,

Haven't done that because the changes are rather significant. The patch file would be a total mess... that's why I'd rather fork it to a 2.x branch.

jrust,

Linkpoint's take on the matter is that it doesn't really matter what you do when you want to void a preauth. You could either just leave the preauth there or move it to post and void like you did. My personal preference was to not move it to a postauth at all because it felt strange to charge a card at all if the AVS was not satisfactory. I also guess that's because we now process all post-auths through Ubercart and wouldn't accidentally do it through the virtual terminal.

I also suppose I overlooked SALE transactions, which would need to be voided right away anyway.

Regardless, I'll add back in that functionality and post a patch tonight or tomorrow night for review.

Took a bit longer than anticipated. I wanted to implement voiding the orders in as clean way as possible, so I spent some more time on it. I finished it tonight, I'll be doing some testing throughout the weekend and post when finished... Don't think anyone is holding their breath anyway!

Patch attached. Sorry for the delay, never patched a module before.

I went through all of the revisions since 1.2 (which is what I was working from originally I believe) and added in everything. I may have missed something, so this needs to be reviewed. I've tested it with a test LP account and will be trying it out with a real one in a few days.

I DO apologize if it seems that I rewrote a lot of what was done. I went through the code and did several changes of the structure. It became very tricky when trying to properly implement voiding without duplicating a lot of code. I tried to comment and keep everything organized. Hopefully not too confusing.

Don't think I mentioned this before, but I've also added order prefixes in the settings.

Looks like it replaced the whole module in the patch.... perhaps because of line breaks... i'm looking into it

Fixed, thanks to lotyrin. Thanks

jrust,

There is a problem with what you added in there for determining the order number.

    // If we are charging the account through the backend, we'll need a unique order number based on authorized order
    $orig_order_id = end(array_keys($order->data['cc_txns']['authorizations']));
    if ($_SESSION['uc_linkpoint_attempt'] == 0 && !empty($orig_order_id)) {
      if (preg_match('/-(\d+)$/', $orig_order_id, $matches)) {
        $_SESSION['uc_linkpoint_attempt'] = $matches[1];
      }
      else {
        $_SESSION['uc_linkpoint_attempt'] = 1;
      }
    }
    $_SESSION['uc_linkpoint_attempt']++;

Not sure I understand what you did here. You would never get to this code if the transaction is a POSTAUTH, but you are trying to get the order ID from a prior authorization... But that wouldn't exist. Not quite sure what the intention here was.

I did notice some other issues with backend processing though.

1. If someone were to create an order in the backend and charge the credit card, but there is an issue, the order number will indeed increment and another attempt can be made. However, if this person were to exit the browser and try again later (or if someone else tried), that session variable keeping track of the transaction attempt is lost.

2. If someone were to create an order in the backend and only charge partial amounts to the subtotal (or just add additional funds to the order through a CC purchase), it will work the first time. However, if they go back to charge the card or another card so the SAME order later, it will not work. This is for the same reason above: the order number is reset and you will get an error because that order number already exists in Linkpoints database.

I'm working out how to remedy this situation, but in the meantime the module currently throws out warnings when orders are created normally. I'll post a patch for all this sometime tonight hopefully.