I've a situation (4-5 out 400 orders) not completed and order status set to "pending". I've checked through watchdog log and can confirm that all these failed orders do not receive any IPN request from paypal compared to other successful order where I can trace IPN request in watchdog and also in apache log. Through apache log I can see that url "car/echeckout/submit" being called but that's all. Customers then being redirected to "car/checkout/complete". Fortunately there's no transaction happened at paypal end (no money being transferred from customers to us) but it still look bad to customers because it look to them the order is completed.
When we email paypal, this is the response we got:-
Upon doec, paypal returns the server a response with paymentstatus which is what should be captured instead of only depending on the callback. can you ask your developer to parse the response in addition to the callback method.
So I take a look at payment/uc_paypal/uc_paypal.module and can see the following code:-
841
842 $nvp_response = uc_paypal_api_request($nvp_request, variable_get('uc_paypal_wpp_server', 'https://api-3t.sandbox.paypal.com/nvp'));
843
844 unset($_SESSION['TOKEN'], $_SESSION['PAYERID']);
845 $_SESSION['do_complete'] = TRUE;
846
847 $form_state['redirect'] = 'cart/checkout/complete';
848 }
So the paypal response is never checkout and customers always being redirected to 'cart/checkout/complete' regardless of paypal payment status. So far, this is the workaround the I did:-
if ($nvp_response['ACK'] !== 'Success') {
drupal_set_message("There's an error with the payment processor and your order cannot be completed. You are advised to call CLIENT office immediately. Your order number is $order->order_id", 'error');
$error = implode(':', $nvp_response);
watchdog('uc_paypal', '!error', array('!error' => $error), WATCHDOG_ERROR);
$message = array(
'to' => 'me@client.site',
'subject' => 'Paypal Error',
'body' => $error ." order_id: ". $order->order_id,
'headers' => array('From' => 'system@client.site'),
);
drupal_mail_send($message);
$_SESSION['do_complete'] = FALSE;
$form_state['redirect'] = 'client/cart/error/'. $order->order_id;
}
else {
unset($_SESSION['TOKEN'], $_SESSION['PAYERID']);
$_SESSION['do_complete'] = TRUE;
$form_state['redirect'] = 'cart/checkout/complete';
}
This hopefully would catch the error so we can analyze it further because so far we left with nothing to tell client.
Comment | File | Size | Author |
---|---|---|---|
#26 | uc_paypal.patch | 2.08 KB | jfarhat |
#24 | uc_paypal.patch | 2.08 KB | jfarhat |
#9 | uc_paypal_error_handling_rev03.patch | 7.19 KB | dsobon |
#7 | uc_paypal_error_handling_rev02.patch | 7.16 KB | dsobon |
#2 | uc_paypal_error_handling.patch | 8.1 KB | dsobon |
Comments
Comment #1
TR CreditAttribution: TR commented#1300976: uc_paypal does not check nvp response on submit order request contains some details relevant to this issue.
Comment #2
dsobon CreditAttribution: dsobon commentedPatch included.
Adds the following:
* debug for all request / responses from paypal.
* add missing error handling.
Comment #3
theamoeba CreditAttribution: theamoeba commentedHi dsobon,
The patch had to failures in uc_paypal.module at line 834 and 940.
Comment #4
longwaveComment #5
longwavePatch needs work, the blank // comment lines are not needed, and _print_r_to_string() is not necessary either - just use print_r($data, TRUE).
Comment #6
dsobon CreditAttribution: dsobon commented-dev?
I've tested it against 2.4 and 2.6 - official releases - and it applies fine.
Comment #7
dsobon CreditAttribution: dsobon commentedupdated patch to include recommended changes as per post #5
Comment #8
TR CreditAttribution: TR commentedHi dsobon,
Thanks for working on this. It's looking really good.
The testbot isn't working at the moment, but if it were it would tell you that the patch is in the wrong format for automated testing. Drupal patches should be -p1 format, rooted at the base ubercart directory. Specifically, your patch starts off like this:
when it should look like this:
Likewise for the section patching uc_paypal.pages.inc.
Once this change is made, it applies properly to 6.x-2.x-dev, which is where we add new features like this. (Fixed-point releases like 6.x-2.6 are immutable - they will never receive this fix.) I've changed the version on this issue to reflect that.
I manually ran the patch through the SimpleTest cases, and it passed, but that doesn't mean much because we don't have any test cases for PayPal responses. I'll leave it to others to actually verify the functionality in this patch, as I don't use PayPal EC.
Comment #9
dsobon CreditAttribution: dsobon commentedUpdated patch as per post post #8
Comment #10
TR CreditAttribution: TR commentedComment #11
TR CreditAttribution: TR commentedComment #12
TR CreditAttribution: TR commentedAttempt to restart the bot...
Comment #13
TR CreditAttribution: TR commentedAnd again ...
Comment #14
TR CreditAttribution: TR commentedComment #15
TR CreditAttribution: TR commentedComment #16
TR CreditAttribution: TR commentedComment #17
TR CreditAttribution: TR commentedAs you can tell, I'm using this issue as a means to debug the testbot. The end goal is to get the patch in #9 tested so we can get this fix into Ubercart. This issue just happens to be the most current one with a seemingly good patch for 6.x-2.x, so it's the most convenient one to use for testing. Sorry for the distraction here - hopefully I can get this figured out and we can get back to the main issue.
Comment #18
TR CreditAttribution: TR commentedComment #19
TR CreditAttribution: TR commentedComment #20
TR CreditAttribution: TR commentedComment #21
longwaveComment #22
longwaveComment #23
TR CreditAttribution: TR commentedNow that the testbot is working properly and has passed the patch in #9, I'd like to see a review from some PayPal users to make sure this doesn't break anything. This is an improvement I'd really like to see added.
Comment #24
jfarhat CreditAttribution: jfarhat commentedIndeed there is an issue with the PayPal module, specifically in the Express Checkout API.
Symptoms:
When an Express Checkout process completes all orders succeeded, failed, or otherwise have a 'pending' status. For succeeded transactions the order details page doesn't show the PayPal transaction ID, the balance remains as the full order amount.
Source of the problem:
Tracing the issue we were able to narrow it down to the function uc_paypal_ec_submit_form_submit. We discovered that the PayPal response string is not processed at all.
Solution:
We processed the incoming response and made the appropriate calls to register the payment if succeeded, log the appropriate order comments. We found out that it worked beautifully.
Attached is a patch to solve the issue. Please let us know if that works out for you.
Joseph,
Kirkham Systems Inc.
Comment #26
jfarhat CreditAttribution: jfarhat commentedPatch resubmit with UTF-8
Comment #27
TR CreditAttribution: TR commentedYou have to set the issue status back to "needs review" in order to get the testbot to review it.
Comment #29
sugarbase CreditAttribution: sugarbase commentedLike the OP I have started getting some random PayPal Express orders moving to the 'pending' status without payment being completed.
Again nothing in the logs reporting the IPN & nothing on PayPals IPN history of the order too.
Currently double checking all completed orders match PayPal's 'payment received notification' emails prior to fulfilment, but it's not ideal. Also it will trigger the invoice & the customer may be lead to believe that the order has been completed.
Will any of the patches sort this or do I need to revert to PayPal WPS?
Drupal 6.26
Ubercart 6.x-2.9
Thanks.
Comment #30
longwaveThere is nothing you can revert, this has apparently never worked properly. You can help by testing out the patches in this issue and letting us know if they work for you.
Comment #31
TR CreditAttribution: TR commentedThis needs to be addressed in D8 first, then backported to D7. D6 is obsolete, we won't be fixing anything in D6 anymore.