Jump to content

Harald Ponce de Leon

Admin
  • Content count

    5,378
  • Joined

  • Last visited

  • Days Won

    125

Posts posted by Harald Ponce de Leon


  1. @@saikamini I don't know why you are experiencing problems only in live mode and not sandbox mode. I suggest trying v1.0 of the module - it does not verify the order when the customer returns back to the store but it should work for you.

     

    The PayPal payment modules will be updated again soon which you can try again once they are available.

     

    Could you tell me which country your PayPal account is setup with? (Both live and sandbox accounts)


  2. Your PayPal account does not need to be changed to support IPN - this is taken care of automatically by the payment module.

     

    Can you confirm that the following file exists:

     

    ext/modules/payment/paypal/standard_ipn.php

     

    What happens when you call that file with your browser?


  3. Nothing new yet.

     

    Although the older version module works, it is not recommended as it does not validate the order when the customer returns back to the store.

     

    To help, enable the send debug email feature and post the email that you receive to this topic. It would also be great to post the requests PayPal makes from your webserver access log. The pages to look out for in the access log file are:

     

    ext/modules/payment/paypal/standard_ipn.php

    checkout_process.php


  4. This problem could be browser related. It seems customers on IE are being redirected back to the store two times during the 10 second countdown. The first request processes the order properly and the second request is when no preparing order exists and a "can not verify transaction" error message is shown.

     

    I can reproduce this double redirection problem with IE only - it works fine with Chrome and Firefox.

     

    It would be great if those experiencing this problem could try with a different browser to confirm this.


  5. Hi Herald

     

    I am very happy as you have replied to my issues.Yes I have put my email id in place of debug email address..But as my transaction is not getting failure so I am not getting any debug mails in both cases..

     

    Can You please reply me wht the area that I have made mistakes??One thing I can figure out that api test connection failed...

     

    Can you check your web server error log to see if any errors are being reported?


  6. Hi Kamini..

     

    Can you enter your email address in the Debug E-Mail Address field and perform an order in both sandbox and live modes and post the results of the email here?

     

    There may be some sensitive info the parameter values which you can mark out, I am mainly interested in the parameter keys.

     

    Kind regards,


  7. I don't know how useful this will be, however I just hacked in a second connection test to test the instant update url. The problem is, this tests the connection from your webserver to your webserver and does not reveal how long it takes for PayPal to make the same request.

     

    paypal_express.php

     

    Copy the attached file to includes/modules/payment/ and overwrite the v3.1 file.

     

    This update is a hardcore hack not ready for the public. The following lines need to be edited:

     

    Line 806: Enter a valid product ID for a shippable product without attributes

    Lines 808-812: Enter a valid address to ship to

     

    A second Test API Server Connection link is added to the module configuration page. Use this to see how long it takes your server to calculate the Instant Update result. Ignore whatever text is displayed on error as it's not relevant to Instant Update. It should show "Success!" and the time the request took.

     

    Again, its a hardcore hack just to quickly test Instant Update. This definitely needs to be worked on if it is to be added to a module update.


  8. That's strange that I can't reproduce it locally. The "rm" parameter is being set in the transaction to have PayPal post the parameters back to the store when the customer returns back to the store, however the debug email shows that $HTTP_POST_VARS is empty.

     

    Even if we remove the checking of the POST parameters, they are required so the transaction can be verified otherwise it leaves orders open to fraud.


  9. It's possible as you can pay with a credit card on our demo site:

     

    http://demo.oscommerce.com

     

    (choose paypal_standard on the checkout payment page)

     

    It might have to do with your PayPal (sandbox) account. Our sandbox seller account is a Business account set up in the US.

     

    I don't know why you have the option in your PayPal account to enable/disable Account Optional and still does not work on the PayPal payment page.


  10. You'd have to debug why jQuery isn't hiding the button.

     

    To confirm that jQuery is executing that part of the code, in includes/modules/payment/paypal_pro_hs.php, around line 388 change from:

    <script>
    $(function() {
      $('form[name="checkout_confirmation"] input[type="submit"], form[name="checkout_confirmation"] input[type="image"], form[name="checkout_confirmation"] button[type="submit"]').hide();
      $('form[name="checkout_confirmation"]').attr('action', '{$form_url}');
    });
    </script>

    to:

    <script>
    $(function() {
      alert('1');
      $('form[name="checkout_confirmation"] input[type="submit"], form[name="checkout_confirmation"] input[type="image"], form[name="checkout_confirmation"] button[type="submit"]').hide();
      alert('2');
      $('form[name="checkout_confirmation"]').attr('action', '{$form_url}');
      alert('3');
    });
    </script>

    You should then get three javascript alert prompts when loading the checkout confirmation page.


  11. If the customer is paying by card in the iframe on checkout_confirmation.php, but clicks the standard "Confirm Order" button, rather than the one within the iframe, they get thrown back to checkout_payment.php with a query string of ?payment_error=paypal_pro_hs

     

    Did you perhaps change the name of the form on the checkout confirmation page? The original form name is checkout_confirmation.

     

    Before the module loads the iframe on the checkout confirmation page, it executes javascript (jQuery) to hide all submit buttons and images in the checkout_confirmation form.

     

    If you didn't change the form name, which browser and version are you using? Do you also see the same behaviour on our demo site at:

     

    http://demo.oscommerce.com

     

    (the module code name to choose on the checkout payment page is paypal_pro_hs)

×