We're seeing a problem with our first uCommerce site, that not all orders are being completed when the PayPal callback is made.
There seem to be about 10% of orders affected each day; I can see from IIS logs that the browser passes off to PayPal ok, but they never return, and nor do we receive a callback to PaymentProcessor.axd, yet the client receives a 'payment received' email from PayPal.
I do see a batch of posts quite some time later to PaymentProcessor.axd for relevant PaymentId's (eg POST /8/806/PaymentProcessor.axd) that return a 200 status code, but the orders for these still haven't completed.
As our first uCommerce site, I'm not too sure how or where to start debugging next... Help please!
This is running 2.6.1.0. There's nothing of vague relevance in umbracoLog, except a repeated entry for a different order;
Could not find the Payment with PaymentMethodName: '8', and one of PaymentId: '782' or PaymentGuid: ''. UCommerce.EntitiesV2.Payment Extract(System.Web.HttpRequest) at UCommerce.Transactions.Payments.UrlPaymentExtractor.Extract(HttpRequest httpRequest) at UCommerce.Transactions.Payments.GenericPaymentHandler.Execute(HttpContext context, IPaymentWindow& paymentWindow, Payment& payment) at UCommerce.Transactions.Payments.PaymentProcessor.ProcessRequest(HttpContext context)
Is it possible that the failure on this one is somehow blocking PayPal from making callbacks for some other transactions? There is simply no row in uCommerce_Payment for PaymentId 782...?!
We've just had another similar order reported. The IIS log entries (gfx etc excluded) show;
2012-07-16 11:31:31 POST /shop/checkout/cart.aspx 2012-07-16 11:33:37 POST /shop/checkout/shipping.aspx 2012-07-16 11:34:07 POST /shop/checkout/submit.aspx 2012-07-16 11:34:10 GET /8/814e91f7-287c-44b6-962d-a925f5817865/PaymentRequest.axd
Note that we never get the expected POST to /8/866/PaymentProcessor.axd to complete the order, yet the customer has paid at PayPal. I appreciate this could well be a PayPal issue, but I need to be able to rule out any possible local cause first.
We've worked out that the delayed PaymentProcessor.axd callbacks are due to the site using Authorization mode, not Sale. When the payments are 'captured' in PayPal, the callbacks happen (in batches, we see many requests in the space of a few seconds).
Most of the time, these complete their respective orders OK, but a few fail. The callback returns a 200 status code, and the IPN logs show success, with nothing unusual in the IPN message data.
We're running some more tests to see is the Authorization (rather than Sale) is a possible cause, but I suspect not, since most transactions complete fine once captured.
We've narrowed it down to failing transactions have 'transaction_entity=payment' in the IPN callback, rather than 'transaction_entity=auth', as required by the code in PaymentProcessor.axd (UCommerce.Transactions.Payments.PayPal.ProcessCallback).
There seem to be no docs about what this field is, or why it should vary on some transactions.
Interesting. This has not cropped up in any of our tests. Maybe it's related to the card being used? I'm not sure if a debitcard would behave differently than a creditcard.
I'll give the docs you provided a read and see, if I can come up with a work around.
Thanks Soren; I have a hunch that it might be related to "non-account" payments, ie users just checking out without a PayPal account, but I'm not sure...
Phil, I have implemented a fix for this, but unfortunately IPN is broken in the PayPal Sandbox environment, so I can't test the fix as of yet. Apprently this has been going on for more than week at this point so I'm not sure when I can complete QA.
We've deployed this live this morning and run a test transaction, which all went OK. The change you made should in theory resolve the 1-in-n failures as well, but obviously only time will tell...
PayPal callbacks failing
We're seeing a problem with our first uCommerce site, that not all orders are being completed when the PayPal callback is made.
There seem to be about 10% of orders affected each day; I can see from IIS logs that the browser passes off to PayPal ok, but they never return, and nor do we receive a callback to PaymentProcessor.axd, yet the client receives a 'payment received' email from PayPal.
I do see a batch of posts quite some time later to PaymentProcessor.axd for relevant PaymentId's (eg POST /8/806/PaymentProcessor.axd) that return a 200 status code, but the orders for these still haven't completed.
As our first uCommerce site, I'm not too sure how or where to start debugging next... Help please!
Phil
Which version are you running?
We did release a fix for a similar issue in version 2.6.0.
Any information in the "umbracoLog" table?
Soren,
This is running 2.6.1.0. There's nothing of vague relevance in umbracoLog, except a repeated entry for a different order;
Is it possible that the failure on this one is somehow blocking PayPal from making callbacks for some other transactions? There is simply no row in uCommerce_Payment for PaymentId 782...?!
Phil
We've just had another similar order reported. The IIS log entries (gfx etc excluded) show;
Note that we never get the expected POST to /8/866/PaymentProcessor.axd to complete the order, yet the customer has paid at PayPal. I appreciate this could well be a PayPal issue, but I need to be able to rule out any possible local cause first.
Phil
You want requests to PaymentProcessor.axd in your logs. The PaymentRequest handler is the one that handles the outgoing portion of the transaction.
If you log into the PayPal account and check the IPN history do you get anything interesting there? It's under Account / History / IPN History
Soren,
We've worked out that the delayed PaymentProcessor.axd callbacks are due to the site using Authorization mode, not Sale. When the payments are 'captured' in PayPal, the callbacks happen (in batches, we see many requests in the space of a few seconds).
Most of the time, these complete their respective orders OK, but a few fail. The callback returns a 200 status code, and the IPN logs show success, with nothing unusual in the IPN message data.
We're running some more tests to see is the Authorization (rather than Sale) is a possible cause, but I suspect not, since most transactions complete fine once captured.
Phil
We've narrowed it down to failing transactions have 'transaction_entity=payment' in the IPN callback, rather than 'transaction_entity=auth', as required by the code in PaymentProcessor.axd (UCommerce.Transactions.Payments.PayPal.ProcessCallback).
There seem to be no docs about what this field is, or why it should vary on some transactions.
Phil
There seem to be few docs on what transaction_entity is for, but the recommended approach (the integration guide at https://cms.paypal.com/cms_content/US/en_US/files/developer/PP_OrderMgmt_IntegrationGuide.pdf and sample code at https://www.x.com/developers/PayPal/documentation-tools/code-sample/216623) is to use payment_status to determine whether a transaction has been paid (mindful that for Authorization, not Sale transactions, this may be Pending as well as Completed).
I still don't get why we sometimes see transaction_entity=payment and not auth, but it looks like a logic problem in the PaymentProcessor?
Phil
Interesting. This has not cropped up in any of our tests. Maybe it's related to the card being used? I'm not sure if a debitcard would behave differently than a creditcard.
I'll give the docs you provided a read and see, if I can come up with a work around.
Thanks Soren; I have a hunch that it might be related to "non-account" payments, ie users just checking out without a PayPal account, but I'm not sure...
Phil, I have implemented a fix for this, but unfortunately IPN is broken in the PayPal Sandbox environment, so I can't test the fix as of yet. Apprently this has been going on for more than week at this point so I'm not sure when I can complete QA.
I'll post when I know more.
You can follow the situation on the PayPal forums.
I've uploaded the build awaiting QA if you're feeling adventurous.
Thanks Soren; probably not that brave on a Friday afternoon ;-) I'll take a look, and we'll get it ready to go Monday morning perhaps...
Phil
Soren,
We've deployed this live this morning and run a test transaction, which all went OK. The change you made should in theory resolve the 1-in-n failures as well, but obviously only time will tell...
Phil
Awesome. Seems like PayPal Sandbox is back so I'll give proper QA to be sure.
is working on a reply...
This forum is in read-only mode while we transition to the new forum.
You can continue this topic on the new forum by tapping the "Continue discussion" link below.