Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

JoeMcManus

Archived
  • Posts

    165
  • Joined

  • Last visited

Everything posted by JoeMcManus

  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: http://www.oscommerce.com/community/contributions,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]
  16. Gary is trying the latest contrib now - when I get his feedback and incorporate it into the final release it will go up. Beware, this will require PHP skills and advanced osCommerce/ePDQ contrib experience. You can start getting your back-ups in shape in preparation.
  17. No, that's an odd one. The contrib doesn't use a config file so I bet it's a Barclays issue. Ring them.
  18. Didn't get round to my PMs yet, sorry. Thanks for the offer. I did test it with someone else and now on my own shops. What I have works fine though people who use attributes a lot (I completely got rid of it in my code) might have to add just a little bit of code themselves. More details at launch. After the weekend I should be able to wrap it all up in a working contrib.
  19. Don't do that. You need checkout_process. It's strange that the transaction is success but it sends you back to the basket. How it ends up at checkout payment is a mystery to me. I'm afraid you'll have to unleash your debugging skills on this. It must be to do with your particular setup. You can alsways comment out the redirects and echo the results that checks epdq_transactions etc. I can't help you too much since I now made most of that redundant in the new code. It's up to you whether to debug your current version or wait a week for the new version.
  20. Harshy, The actual redirect path is set in includes/modules/payment/ePDQ.php about 3 quarters down where the logo and font colours are set as well. See there, it should be set to epdq_success.php which on its turn decided to redirect to the basket or the checkout_process. Double check that's all as described. Jon, In the filenames.php it probably refers to needing the epdq_success.php defined. Check if that is in that filenames.php file, otherwise add it just like the other entries. The files belong in the folders how they come zipped. Some in /catalog some in /catalog/includes/modules/payment, some in the language folder etc. The way they are layed out in the zup file, that's how they should go to your site.
  21. First off, I'll attend to my PMs shortly. The updated ePDQ contrib is nearly done and will be shared soon. I just need a couple more real transactions to consider it stable. Harshy, epdq_success does nothing but checking the status and then decides to redirect back to the basket in case of a Declined, or forward to epdq_process in case of a Success. Read the code in that file and double check it should have indeed gone back to the basket (your table epdq_transactions for that order probably shows something else than Success).
  22. In terms of making sure you get the payment, the old version works fine. But the new version is a lot better. Those who PMed me, I'll get to those messages tonight.
  23. Yeah I have your e-mail, got some bike image and an interesting thought on life the other day from you I think :) I'm in no real rush since I already have the code obviously. When do you think you might be able to get the ePDQ going? If you already have one account, shouldn't be that hard to get a second, third etc. I'm going snowboarding for 10 days from the 17th so depending on how badly people want this code, I can do it before or after that fact. Because my shops are modded so heavily it could really do with some testing, else this thread could become a very very long one :) If you use admin access levels it shouldn't be much of an issue to get me in on your systems. Just wipe my details after the fact. On a bare shop there also isn't the issue of code you might not want to share etc.
  24. Finally, I've finished my version of this code. I can now just extract the files, delete the stuff that are specific to my setup and release the contrib. I got it to work so that complete.php sends the confirmation e-mails making ePDQ now... INDEPENDENT from the customer clikcing that last (hated) button. E-mails are sent, products_purchased updated, cart wiped, status updated and more all when Barclays send in the POST to cpi/complete.php. The e-mailing part was a biatch to get going because it relies on so many files but it looks like it's all good to go. I removed the need for the epdq_transactions table to clean things up. I also included functionality for fraud score calculation with the help of MaxMind's minFraud system. I will leave the code in there but commented out. Short intro: you can send a handful of data like IP address, e-mail address and billing address and then their service checks the data against known card fraudsters, spammers, checks that the IP address isn't in Nigeria whilst the billing is in Suffolk etc. Based on many variables it returns a fraud score so you know whether to ship that item or not. Really useful and only a measily $0.004 per query (yes, a fraction of a penny). I have one slight problem. I CAN NOT TEST THIS EASILY! - I NEED YOUR HELP (if you want this code) You know how you have to set up the allowed URL... Unless I shut down one of my shops I can't test this contribution. If one of you guys are developing a NEW SHOP with ePDQ, please let me know and I will install this LATEST version free of charge on your shop. Then we'll test it together so I can release this contribution out in the wild for the rest to enjoy. I will need FTP access, PHPMyAdmin access and access to your back-end. Ideally also login to your CPI Administration and ePDQ back-end. I'd like you to be there one night this week after hours, say 7 to 10pm so we can sus this out. I can not guarantee I will get this going and reserve the right to abandon installation at any time from where you can just paste your back-up and have it all as it was. You need to know your stuff with PHP etc. and ideally you already had the previous ePDQ contrib going. By sacrificing an evening of your time you can help me round up 13 months worth of slowly developing this contribution and help others enjoy the latest and greatest code which shouldn't need much else done to it to work for years to come and without the little bugs we all have now. If you think you qualify, please contact me by PM or in this thread. If you can't wait for me to package it all up, contact me and I will give you the necessary files so you can do your own magic without a nice readme. Advanced osC/ePDQ/PHP users only please.
  25. You should really check your database. To just "think it must have saved in a database" is not helping much. Find out what order status they have at each of the points I indicated above.
×
×
  • Create New...