PayPal App Issues?

[trier]

Hi, There appears to be 2 faults in the new PayPal App (PayPal Standard) which seem to attract no interest -

 

1. If the customer does not return to site, any comments added to an order (delivery instructions?) will be lost, never to be seen.
2. I don’t know if this happens ‘live’ but in the sandbox (when ‘auto return to site’ is  set), just after payment, you are invited to click ‘Return to site’ if not returned within 10 seconds. If the ‘click’ is made after a couple of seconds there seems to be 3 possible outcomes depending on the timing – normal (everything as expected), almost normal (all OK but returned to empty shopping cart), not normal (return to checkout success but updating/emails actioned twice).

 

 

Either I have something badly wrong or there is another problem when using the app to make a PayPal Standard payment from a tablet/phone (doesn’t seem to happen with PC/laptop) – the customer is returned to a populated shopping cart with the message “Could not verify the PayPal transaction ......”.

 

As far as I can tell the problem seems to be in paypal_standard.php ‘function pre_before_check’ when called from checkout process. The function uses the POST/GET vars to verify the transaction. With tablet/phone transactions the POST/GET vars don’t appear to be populated?

 

Provided the PayPal IPN is successfully processed in standard_ipn.php the order will be correctly processed (the POST/GET vars are populated).

 

Can anyone shed any light on this?

[burt]

Have you set up the API? I presume so, can you check your balance from within your shop admin ?

If yes, API is working.

 

Have you set up PDT?

Have you set Return Page => the checkout_success.php page of your live site

[trier]

@@burt  Hi, Thank you for the reply.

 

The comments all relate to test site & sandbox. Everything works as expected apart from the issues noted.

 

I believe the API is correctly set – the PayPal balance can be seen in admin. The PayPal log in admin shows a failed entry (empty) for the user IPA, and a successful (populated) entry for the IPN.

 

I’m sure PDT is ‘off’.

 

Return page (in paypal_standard.php ‘return=>’) is checkout_process.

 

The issue appears to be only with tablet/phone transactions. There is no issue processing transactions by PC/laptop, both checkout_process.php and standard_ipn.php are OK regardless of which is called first.

 

Probably not too relevant to this, osc version is 234bs.

[burt]

I’m sure PDT is ‘off’.

...

Return page

In your Paypal (not the module at your shop but your paypal account at paypal.com), you need to set PDT = on and set return url to the checkout_success.php page of your site. The PDT token is then inserted into the Paypal App at your shop.

Edited May 29, 2015 by burt

[trier]

@@burt       Thank you, 

 

1)    PayPal account>Profile>Website Payment Preferences>Auto Return for Website Payments     - on/checkout_success.php  (live)

 

2)    PayPal account>Profile>Website Payment Preferences>Payment Data Transfer                       - on

 

3)    admin>PayPal>Configure>PDT Identity Token                                                                            - populated from PayPal account (above)

 

 

Presumably setting PDT ‘on’ will not have any impact on current live (non PayPal App) processing?

PayPal account settings seem to apply to both live & sandbox so presumably the auto-return (1 above) has to be the ‘live’ site? If the auto-return is checkout_success does this not bypass checkout-process?

 

With the above in place – tablet/phone still returns to shopping cart with “Could not verify” message ($_POST & $_GET still unpopulated).

 

[trier]

osc 2.3.4bs, PayPal App v4.039

 

When making a PayPal Standard payment from a PC/laptop, checkout_process and IPN both behave as expected (regardless of which happens first).

Returning from PayPal to checkout_process, $_POST is populated as expected. The logs show the return with a POST method -

 

PC/Laptop payment example

86.139.224.32 - - [31/May/2015:12:43:04 +0100] "POST /checkout_confirmation.php HTTP/1.1" 200 1114 …...........

86.139.224.32 - - [31/May/2015:12:43:33 +0100] "POST /checkout_process.php HTTP/1.1" 302 614 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) ….............

86.139.224.32 - - [31/May/2015:12:43:36 +0100] "GET /checkout_success.php HTTP/1.1" 200 4766 "-" "Mozilla/5.0 (Windows NT 6.3; WOW64) …..............

173.0.82.126 - - [31/May/2015:12:43:30 +0100] "POST /ext/modules/payment/paypal/standard_ipn.php HTTP/1.0" 200 513 "-" "PayPal IPN ( https: //www.paypal.com/ipn )"

 

 

When making a PayPal Standard payment from an iPad/phone, IPN behaves as expected, checkout_process always returns the “Could not verify...”message (regardless of which happens first).

Returning from PayPal to checkout_process, the neither $_POST nor $_GET is populated. The logs show the return with a GET method??? -

 

iPad/phone payment example

86.139.224.32 - - [31/May/2015:12:30:50 +0100] "POST /checkout_confirmation.php HTTP/1.1" 200 2320 ...............

86.139.224.32 - - [31/May/2015:12:31:16 +0100] "GET /checkout_process.php HTTP/1.1" 302 528 "-" "Mozilla/5.0 (iPad; CPU OS 8_3 like Mac OS X) …..............

86.139.224.32 - - [31/May/2015:12:31:16 +0100] "GET /shopping_cart.php HTTP/1.1" 200 21849 "-" "Mozilla/5.0 (iPad; CPU OS 8_3 like Mac OS X) …...............

173.0.82.126 - - [31/May/2015:12:31:25 +0100] "POST /ext/modules/payment/paypal/standard_ipn.php HTTP/1.0" 200 475 "-" "PayPal IPN ( https: //www.paypal.com/ipn )"

 

Any clues?

[tgely]

did you pay with smartphone app on Ipad?

[trier]

@@Gergely

 

Hi, Didn't use app. on iPad, through website via safari browser. Phone was through website via chrome browser. Safari, chrome, IE all work fine on laptop.

 

Probably not relevant, but the only other thing of note - on the admin>PayPal>Credentials page, I have never managed to display the button to extract the credentials from PayPal.

 

Thanks

[trier]

In case it is of interest – not surprisingly @@burt was quite right, PDT has be on, the PDT Identity Token and API credentials all have to reflect the appropriate sandbox/live seller account.

 

It took a little while to get these right (bufoon?), when I did get them right it was a bit confusing because within the same session (even after clearing cookie/cache) the fault was still present. It was only when the changes were still in place when ‘playing about’ started the following day that it worked.

 

Testing the new app in the sandbox, it seems -

With PDT (within PP account) off, making payments from a PC/laptop will always work, payments from an iPad/phone will probably fail.

With PDT on, payments from a PC/laptop will usually work (see PP fault below), payments from an iPad/phone will always work.

 

PP Fault: PayPal Standard PDT in the sandbox from a PC/Laptop (doesn't seem to happen to iPad/phone payment). I think this is nothing to do with the new app, it seems there is a known PayPal fault when making PDT payments (I don’t know if it happens to other than standard or in PP live) -

 

The bug only happens when the user clicks the "click here to return to..." link at the end of the transaction. (If they wait for the auto redirect back to your site, params are the correct case.)

It gives ($response) of "FAIL" with an error code of 4002.

PayPal returns the transaction code ($HTTP_GET_VARS['tx']) in lower case, apparently it should always be upper case.

 

The simple answer seems to be (this is the new PP app includes/modules/payment/paypal_standard.php)-

 

in function pre_before_check()

   add

      $HTTP_GET_VARS['tx']=strtoupper($HTTP_GET_VARS['tx']);

   before line 565 (ish)

     $parameters = 'cmd=_notify-synch&tx=' . urlencode($HTTP_GET_VARS['tx']) . '&at=' . urlencode(OSCOM_APP_PAYPAL_PS_PDT_IDENTITY_TOKEN);

 

or

   change line 565(ish) to

     $parameters = 'cmd=_notify-synch&tx=' . urlencode(strtoupper($HTTP_GET_VARS['tx'])) . '&at=' . urlencode(OSCOM_APP_PAYPAL_PS_PDT_IDENTITY_TOKEN);