Latest News: (loading..)


  • Content count

  • Joined

  • Last visited


About SteveDallas

Profile Information

  • Real Name
  • Gender
  • Location
    Alabama, US
  • Website
  1. I have uploaded new versions for both osC v2.2 and v2.3. The osC 2.3 version is based mostly on the changes that amaische made a while back. It is now a full package with installation instructions specific to osC 2.3. Tested on osC Both versions have some minor changes to better deal with the RSS feed when it is broken. For osC 2.2: For osC 2.3:
  2. The RSS feed is broken and if you use the scheduled updates feature of this add-on, you will likely receive error messages. The osC team is working on fixing it. See:
  3. What version of whos_online are you using? The history for the contribution shows that this issue was fixed in v3.6.6.2 in 2010. --Glen
  4. The latest version was just a bug fix for some problems that could occur with catalog/contrib_tracker.php, which is the code that checks the RSS feed for updates and sends email messages that one of your contributions has been updated. The old version checked the name of the contribution, but it is possible for two contributions to have the same title, which led to a problem when both contributions are updated at the same time. It would also lead to "false positive" notifications. You'd get an update notice and the status would turn to red if the non-installed contribution (with the same name) was updated. The new test uses the link, which contains the contribution number. I saw this when the following contributions were updated at the same time: (Just a pointer to the other one so that people searching v2.3 contributions can find it) --Glen
  5. It hasn't been abandoned. I still update it from time to time. I just fixed a couple of bugs. --Glen
  6. Enable "Debug Mode" in the module control panel. You will receive the XML request and response (with password and card information redacted) in an email to the "Store Owner's Email" address for each failed transaction. --Glen
  7. At the top of my Profile page, I have a blue box labeled Services. In it, appear three entries related to my WPP subscription, "Website Payments Pro", "Virtual Terminal", and "PayPal Express Checkout". Below that, appears an entry labeled "Risk Controls". Inside "Risk Controls", I have "Risk Controls - All Payments", with "Country Monitor" and "Maximum Amount" (which you have), and a second area entitled "Risk Controls - Direct Payment or Virtual Terminal Payments". You don't have this. You must contact PayPal tech support to get them to enable it for you. Note that PayPal features vary from country to country and the best approach may be to tell them that you started receiving the 10505 errors on orders from US customers and complain that they changed something that is negatively impacting your business. Tell them that you believe that they changed the default risk control behaviour and that you need the tools to restore the previous settings. They should be able to enable the appropriate Risk Controls options to allow you to control AVS handling. --Glen
  8. Chris, This happened for US accounts (non-US transactions were being rejected) a few years ago when PayPal implemented Risk Controls, which changed the default behaviour of their risk management system. The Risk Controls feature, which usually carries a monthly fee, enables the account holder to manage certain aspects of the PayPal risk management filters. I was able to get them to enable Risk Controls on my account when I complained loudly enough. It may be a limited version, rather than the version that they charge for. Check your PayPal profile to see whether Risk Controls is available to you, then check the settings for AVS under "Risk Controls - Direct Payment and Virtual Terminal payments". There are three filters for AVS; "no match", "partial match", and "service unavailable/unsupported". I have them all set to "accept" and review each transaction before shipping. "Accept and report" is also available, which generates a flag and an email notification. My guess is that one of your filters is set to "decline". --Glen
  9. I received an Express Checkout transaction on Friday, 1st October. I'm fairly certain that I'm using the latest code, as I'm one of the maintainers. I do use WPP a little differently than most, as I use Authorization and Capture, rather than immediate sale, because some of my products sometimes take several days before they are ready to ship. I wouldn't think that this will cause a difference as to whether payments are accepted, though. --Glen
  10. It shouldn't be different, unless the template modifies the checkout flow. Compare checkout_shipping.php from the RC2a distribution and compare it to the one supplied with your template. --Glen
  11. This is true. I last mentioned it in post 4198 of 2 July. I still haven't had brain cycles to spend on it. It is still on my list of things to do, (It's also listed as an issue at Github.) I don't know what an "under review" payment looks like, possibly because I use "Authorization and Capture" in my shop. However, I also use the osC PayPal IPN payment module and uncleared checks go into my osC "Pending" order status, which is where all unreviewed orders go. I manually move those to a new status that I created called "Uncleared", and ship them once the customer's echeck clears. This also works for payments from countries, such as Germany, where the customer must send funds to PayPal from their bank after making a purchase. PayPal made a number of changes to Express Checkout after this module was developed. Some of them will allow us to streamline the Express Checkout process further, but will require additional development. Again, some of this is on my "to do" list, but I believe that PayPal only returns one address in Express Checkout. However, I'll have to look at the API and the code to verify that. --Glen
  12. While the problem may be "related" to this module, it isn't caused by this module. It appears that the problem would occur when an order contains a credit card number, which would be the case for many modules that process credit cards. What I can tell you is that this module redacts all but the last four digits of credit card numbers when storing the card number in the database, in accordance with current rules regarding card security. The number is stored in the form: XXXXXXXXXXXX1234 --Glen
  13. It has been a long time since I set up my test shop in the PayPal Sandbox, but it worked identically to the live version. I know that they have made some changes to make it easier to find credentials and such, but they may not support certificates in the new changes. Best to ask PayPal developer technical support about that. --Glen
  14. This is correct. It's covered in the installation instructions as item 2 in step #15. The WPP module needs some of the methods of the 'orders' class earlier than the stock admin/orders.php, so we insert the include near the top of the code and comment out the original. --Glen
  15. @galey: It sounds as though the token is not being sent to PayPal when you are re-directed. Have you contacted DynamoEffects about this issue? It could be a DynamoCheckout problem. --Glen