Latest News: (loading..)

Recidivist

Members
  • Content count

    69
  • Joined

  • Last visited

About Recidivist

  • Birthday 11/10/1970

Profile Information

  1. I had the same problem with both mods - the error as above. However, the problem was eventually tracked down to a combination of incorrect test url (should be https://certification.authorize.net/gateway/transact.dll if you don't have an A.net developer account), transaction ID and MD5 hash. The MD5 hash entry field in A.net account manager is shorter than most MD5 hash generators create, so I, at least, had a mismatch in the string i'd input into the contribution and the string A.net was looking for. It was off by about 8 chars. Double check your data and url in the first instance. The RC2a version now works fine with my MS2.2 store. KB
  2. I am looking into coding something for this, but outside of osCommerce. Remember that even with the AIM module you should be safe from PCI-related issues as it should not store credit card details. Just make sure the module you use (there are a few) is one that does not store them, or amend the one you use. You should also make it clear to your customers that you do not store their details. Unless you have a server security guru/genius on staff, you don't want to messing with PCI. The AIM module is the best of both worlds. KB
  3. Hi, did you remove the hack and get AIM working ok that way? Or, did you make AIM work with the hack? KB
  4. I also have the same problem with the AIM and am looking ito it. Does anyone know how to capture the outgoing or the incoming strings?
  5. If you don't already use them, these Protx links are a useful resource: Protx Support Forum and Protx Support Pages KB
  6. Me too. The following works for me right now on the LIVE server: tep_draw_hidden_field('Crypt', $crypt); and $crypt = $_REQUEST['crypt']; and on the TEST server: tep_draw_hidden_field('crypt', $crypt); and $crypt = $_REQUEST['crypt']; Is yours the same? KB
  7. Protx have just reverted to using a small c instead of the capital C when fetching $crypt. See https://support.protx.com/forum/Topic1186-23-1.aspx KB
  8. Having problems with the post-Maestro/switch changes. Does anyone know if there's an easy way to view the string which Protx sends back after a successful payment transaction? decrypt_protx.php does this perfectly for the string being sent TO protx, but I need to see what they send back. Many thanks KB
  9. I have just encountered this issue on the Protx test pages and not only do I see the same problem, but their test CC details don't work either. They've also yet to send me their new templates. Grrrr... Thanks for the fix.
  10. Thank you. This works beautifully. The javascript updates aren't correct, but like you say, that's not important. What is important is that the figure added to the database and subsequently displayed is correct. Thanks again. KB
  11. Yes, 17.5%. Our tax rules are all set up correctly. KB
  12. DJMonkey, your comment put me on the right track and I fixed the problem. Thank you. In edit_order.php you can set the sort order for the data (on mine it's line 401). I simply set this to match the tax sort order as set by my order creation script. Now that's fixed I've discovered another problem. When I add a discount amount in before shipping (directly after subtotal) the tax rate does not update accordingly - i.e. it still shows the tax rate from the non-discounted figure. Any ideas how to force the tax to be recalculated when a discount is applied? Cheers KB
  13. After further investigation the manual order entry tool is adding orders into the database with the correct order as follows: Subtotal: 1 Discount: 2 Delivery: 3 Tax/VAT: 4 Total: 5 After editing in edit_orders.php the ordering is changed as follows: Tax/VAT: 3 Subtotal: 4 Discount: 5 Delivery: 6 Total: 7 Any indication on where in edit_orders.php I can fix this would be massively helpful. Cheers KB
  14. Ah, you're right. We are using a manual order entry contribution to create a blank order, then Order Editor to amend it. The manual order entry script places all items in the correct order initially, but when the order is amended in edit_orders.php the VAT line is moved to the top of the list. I will now investigate this a little further, but I'm not convinced that the Order Editor isn't somehow involved. KB