Latest News: (loading..)


  • Content count

  • Joined

  • Last visited

1 Follower

About JoeMcManus

Profile Information

  • Real Name
    Joe McManus
  1. Depends on what your turnover is. And how good your negotiation skills are. Never deal with the first bunny answering the phone and never sound too excited. Everything is negotiable. They want your money. I'm not the one who did the rates deal with them but I think they were equally as good as we had with Barclays. Functionality was the main reason indeed. One benefit I forgot to mention will save us some dough as well. We currently have 7 ePDQ accounts on 7 shops because they only allow one URL for the referrer (paying 7 x monthly charge). WorldPay has a different authentication system and you can have many 'installations' within one 'account'. It's just way more flexible. And I hadn't mentioned full control of the lay-out. Compare that to Barclays 1 x image and font colour.
  2. Fuzioneer... I highly recommend installing FireFox with the Web Developer Toolbar. With it you can easily examine form elements and their values. Whenever something doesn't work, you can quickly inspect what the form is sending Barclays. That way you can easily establish the order value is incorrect, without having to wait for them. Tax is calculated in functions/general.php tep_get_Tax. I hacked that function to bits since I completely removed zones. Can;t help you much with that. And here's another announcement. I'm completely moving away from Barclays' epdq. 18 months of requests have resulted in nothing more but 'that little HTML tweak we agree with has to be proposed to the board and decided up by them old men in grey suits who don't have a clue about the interweb so don't count on it happening anywhere in the foreseeable future'. It's the classic scenario of a large multi-billion company and its inherent bureacracy. So it's World Pay for me. And here's what it offer off the shelve that Barclays is having troubles with even grasping: - AVS responses by default included in POST (fraud prevention anyone?!) - Verified by VISA response in POST (anyone interested in knowing they aren't liable for this transaction anymore?) - Remote post auth (no more logging in to an unintuative admin back-end where links should have been buttons and the other way around) - Remote refunds (no more having to enter all the details again just to give them 2 quid back, take their billing address from osCommerce database and just type the card number). - No more 'hey dumb customer, you know you just entered you shipping and billing address on our shop? Well guess what, enter them again on Barclays pages because it makes an aweful lot of sense adding 2 pages to the checkout flow just to annoy you and give you 2 extra chances to cock up and give up, abandon the sale etc.' - WorldPay allows you to hide them, reducing the endless stream of checkout pages significantly. - No more 'look on page 1634 of the third of the 7 manuals we gave you for the answer' - simple online tutorials and responsive support staff who aren't held back by the inertia of a multi billion pound organisation. - Get a free fully functional test account so you can mock about until you're convinced it all works. My code isn't to a stage yet where I feel comfortable sharing it but it only took me a day and a half to take the current old-ish WorldPay contrib, mix it with the principle of the ePDQ (mainly taking the order before checkout_process and then just updating the status based on the POST response like complete.php) and then coding the post auth into orders.php as well as a refund function. So if, like me, you've had enough of a quickly falling behind payment system (seriously, ClearCommerce and especially Barclays version of it is getting so outdated compared to WorldPay and others) I can highly recommend WorldPay. You can keep Barclays as your bank, just dump their poor payment system and opt for full osCommerce integration. WorldPay should pay me for this advert :) (and Barclays should still pay me for consultancy and this contrib :evil: ) So... I'm turning off the topic subscription in this thread and I hope to see you guys and girls soon in a new WorldPay thread. I hope the code I left behind is transaprent enough for you to further develop. And if you do stay with Barclays ePDQ, I hope they get their ass in to gear for you. Ciao for now! PS if anyone is truely ineterested in WorldPay and subsequently able and willing to help me develop the contrib further then please do PM me. But please, only if you can contribute with solid code.
  3. I couldn't quite follow the previous posts so if you post your troubles concisely again I may be able to help you out.
  4. Not just yer unclue, a god, almost. :) The SEO class isn't a necessity indeed, I came across similar issues because the class modified the tep_href_link() function and indeed broke this script. I do have that class inclusion uncommented and works fine in my setup. Forgot exactly why I kept it, probably because I wanted to use the tep_href_link. I'll try and catch up with the other posts.
  5. I'll see if I can rid of it without breaking things. If we don't understand it, get rid of it :D The logic is fairly simple and it seems like we don't need it. 1. They choose ePDQ 2. on checkout_confirmation it gets stored 3. If they change something and go back to checkout_confirmation 4. It needs to Update the order. So all that's required is remembering the order_id that was entered by ePDQ. Whether or not the basket has changed etc. is irrelevant in a way - if they hit checkout_confirmation we can UPDATE regardless - whether or not anything has changed. That way we always have it correct.
  6. Yes, that's what it says in the comments but since it's not compared to any other value that I can see, how does that hacking prevention work? But yeah, all that might not have to affect this contrib so I'll check it out. BTW just found another little bug... In complete.php the confirmation e-mail doesn't get the order comments since the order class is used and the part that gets it from the DB doesn't fetch the comment, the part that gets it from the session (can't use that in complete) does have the comments. I'll make a workaround.
  7. cartID is meant to be random on every page. I'm having a hard time understanding how it's referenced against the ID in the database/session though. On one of my shop (which takes loads of orders just fine) the damn $cartID is empty all the time! Will take some digging to 1. understand it and then 2. do something wise with the knowledge.
  8. There multiple way of doing this... Don't think there is a 'best' way. It changing on checkout_shipping is surprising to me. I'll check that out. The previous version would delete an order on confirmation and add a fresh one. I didn't like it since it runs up your order numbers pretty fast. That's why it now (was supposed to) update the order instead. Let me have a geeze.
  9. That makes more sense... This line if ( ($curr['currency'] != $order->info['currency']) || ($cartID != substr($cart_ePDQ_temp_id, 0, strlen($cartID))) ) { is probably causing that. However, I haven't ever checked whether changing the cart would give it a new cart id. Whilst I;m in there I'll examine the logic of it, that was largely untouched from even back in 2003 so it might well be due some thinking. Could you echo the $cartID in ePDQ.php please and see whether it changes every time you change the basket?
  10. Gary, Yes, that might well be the case. If I remember correctly, we looked at that bit of code before but we must have not quite gotten there then. If someone could verify Rob's solution works then I'll defo add it. Rob, It shouldn't do that. It checks to see whether the cart id and temp epdq order id are registered in the session. If it is (like it should when you get back to checkout_confirmation, then it won't insert a new one. See the code where it says if ($insert_order == true)... So maybe you didn't copy the necessary parts from checkout_payment etc.? I'm updating that part of the code as we speak - right now it won;t update when someone changed the address for instance - will be fixed shortly.
  11. Thanks, I'll add that to the update. In the selection function I have code that deals with fraud handling. I had to remove that from the contrib - it's too tailored. Looks like I forgot to put back what would have been there originally. Thanks for the digging.
  12. Rob, Check your configuration table to see it was added properly there. I coded most of it and never installed it from scratch again on a fresh store so other than the usual debugging I can't help much. Look for while loops in the payment functions and classes and echo all the ones they find to see whether it gets close at all. By the way, I spotted a silly mistake in the latest update which I'm finally fixing now so hopefully I'll be able to put a new contrib up today or tomorrow. Problem is that after the customer hits the checkout_confirmation page, and then goes back to change stuff, the order won't get updated. Johan
  13. I do have an update_status function in my ePDQ which I use to check that for that billing country I allow ePDQ. Maybe when I deleted that code I did it wrong. In the original stock code, that function doesn't exist. Where I return false in the contrib maybe we should get rid of it altogether or let it return true? Maybe you guys can try that. It obviously is somewhere in that region.
  14. That's strange because Gary had the same thing. Is ePDQ your only payment module or do you have more? Check checkout_payment.php and try anbd follow its logic. There if statements that handle when there's more than 1 $selection. You will find that if ePDQ is the only one, it should draw a hidden field with its ID set. That's $payment on checkout_confirmation.php and without it it won't load the form data indeed. With Gary's setup, that payment option didn't get forced into that hidden field. Only on a reload which is even more strange. His work around was to hard code it in. I never got this issue (have 3 payment options) so I don't know whether this is a bug with the contrib or in osCommerce altogether. If someone finds the origin then let me know so I can incorporate it. Hopefully that info gets you going. EDIT LOL beaten to it by the man himself...
  15. [drumrolls] Quick! Run to the contribution section for the latest and greatest ePDQ contribution:,430 Do post your feedback if you can - but I have to warn I won't be able to provide the level of support I used to with this. There's enough skills amongst you guys to sort this out between you if it doesn't go according to plan. Enjoy! [/drumrolls]