Copied to clipboard

Flag this post as spam?

This post will be reported to the moderators as potential spam to be looked at


These support forums are now closed for new topics and comments.
Please head on over to http://eureka.ucommerce.net/ for support.

  • Phil Dye 149 posts 325 karma points
    Jul 12, 2012 @ 11:08
    Phil Dye
    0

    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

     

  • Søren Spelling Lund 1797 posts 2786 karma points
    Jul 13, 2012 @ 18:47
    Søren Spelling Lund
    0

    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?

  • Phil Dye 149 posts 325 karma points
    Jul 16, 2012 @ 09:59
    Phil Dye
    0

    Soren,

    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...?!

    Phil

     

  • Phil Dye 149 posts 325 karma points
    Jul 16, 2012 @ 16:45
    Phil Dye
    0

    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.

    Phil

  • Søren Spelling Lund 1797 posts 2786 karma points
    Jul 18, 2012 @ 12:29
    Søren Spelling Lund
    0

    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

  • Phil Dye 149 posts 325 karma points
    Jul 19, 2012 @ 16:37
    Phil Dye
    0

    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

  • Phil Dye 149 posts 325 karma points
    Jul 19, 2012 @ 18:15
    Phil Dye
    0

    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

     

     

  • Phil Dye 149 posts 325 karma points
    Jul 19, 2012 @ 18:43
    Phil Dye
    0

    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

     

  • Søren Spelling Lund 1797 posts 2786 karma points
    Jul 20, 2012 @ 12:38
    Søren Spelling Lund
    0

    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.

  • Phil Dye 149 posts 325 karma points
    Jul 20, 2012 @ 12:46
    Phil Dye
    0

    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...

  • Søren Spelling Lund 1797 posts 2786 karma points
    Jul 20, 2012 @ 14:37
    Søren Spelling Lund
    0

    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

  • Søren Spelling Lund 1797 posts 2786 karma points
    Jul 20, 2012 @ 15:34
    Søren Spelling Lund
    0

    I've uploaded the build awaiting QA if you're feeling adventurous.

  • Phil Dye 149 posts 325 karma points
    Jul 20, 2012 @ 15:36
    Phil Dye
    0

    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

  • Phil Dye 149 posts 325 karma points
    Jul 23, 2012 @ 11:57
    Phil Dye
    0

    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

  • Søren Spelling Lund 1797 posts 2786 karma points
    Aug 07, 2012 @ 11:03
    Søren Spelling Lund
    0

    Awesome. Seems like PayPal Sandbox is back so I'll give proper QA to be sure.

Please Sign in or register to post replies

Write your reply to:

Draft