PayPal causing Transaction XML Datafeed to run twice

Hi. We have both PayPal and regular checkout as options on our store. I just set up a custom inventory control in our transaction datafeed, and it was working perfectly in tests. I put it up on our live site and it has been working correctly intermittently. It wasn't clear to me what the problem was until I added an email alert with detailed transaction and inventory information to audit the activity. I just discovered that everything works find when customers use normal checkout, but each time a customer uses PayPal as their payment option the transaction datafeed runs twice instead of once. For paypal transactions, I am getting two email alerts 5 seconds apart for the same transaction, and it basically doubles the deduction of inventory on a specified product.

I haven't been able to isolate why PayPal transactions are making the datafeed run twice, nor how I can prevent this. Do you have any insight and suggestions for what I might be able to do to solve this as soon as possible? Thank you!
Comments
  • GeoffreyGeoffrey Member
    edited July 2016
    Update: I just ran some live test transactions myself, using PayPal Express Checkout and the transaction datafeed is definitely running twice upon transaction completion every time the PayPal Express Checkout is used. I wondered if it might have been related to PayPal IPN or API connection settings, so I disabled both the IPN and API connections with FoxyCart that were active, but the result was the same after an additional test transaction.

    One other very strange thing I noticed is that immediately after issuing a refund on these transactions, I received yet another alert email from my datafeed indicating that the transaction datafeed had been run a third time for some reason. I did this on two separate occasions and this happened exactly the same way both times. Here is an example of what the alert emails are showing me:

    For transaction completed at 6:21pm EST

    1st Alert Email (received 6:21pm):

    REFERENCE TRANSACTION #: 1069643704
    Transaction Date: 2016-07-30 17:21:54
    Payment Gateway: paypal_ec

    Product Code: V21501-sample
    Amount Variation: 5g sample
    Quantity Ordered: 1
    Previous Inventory Level: 12
    New Inventory Level: 11
    2nd Alert Email (received 6:21pm):

    REFERENCE TRANSACTION #: 1069643704
    Transaction Date: 2016-07-30 17:21:58
    Payment Gateway: paypal_ec

    Product Code: V21501-sample
    Amount Variation: 5g sample
    Quantity Ordered: 1
    Previous Inventory Level: 11
    New Inventory Level: 10
    !! After issuing refund on this transaction via PayPal at 6:26pm !!

    3rd Alert Email (received 6:26pm):

    REFERENCE TRANSACTION #: 1069643704
    Transaction Date: 2016-07-30 17:21:58
    Payment Gateway: paypal_ec

    Product Code: V21501-sample
    Amount Variation: 5g sample
    Quantity Ordered: 1
    Previous Inventory Level: 10
    New Inventory Level: 9
    Note the transaction date timestamp difference of 4 seconds between the 1st alert email and the 2nd alert email. Note also that the 3rd alert email has the same transaction date timestamp as the 2nd alert email. The 3rd alert email came instantly after processing a transaction refund both times I tested this, and indicates that it further deducted from the inventory count a third time. We have yet to process a refund on any other live PayPal orders that have deducted from product inventory, but I suspect we would see this same bizarre datafeed behavior if we did. I have no idea how a refund processed at PayPal would even be able to trigger the transaction XML datafeed on our store, but it's kind of alarming to see this happen. The above example I have provided here was transacted after I had disabled both the PayPal IPN and API connections with FoxyCart. I don't understand how PayPal would have any way of sending transaction information back to our store without those connections active.

    Please take a look at this as soon as possible and let me know what you find out. If you have additional questions, I am happy to provide as much information as necessary. Thank you.
  • fc_adamfc_adam FoxyCart Team
    @Geoffrey,

    I'm sorry for the confusion here. For hosted gateways, where the customer is redirected off to another third-party payment page - we don't always know straight away if the transaction was successful or not when the customer makes it to the receipt. In those cases, the transaction is in a pending state - as we haven't received final confirmation. When the gateway finally does send us a notification of the final state, we then finalise the transaction accordingly and take the necessary actions.

    The datafeed is one of those actions. The datafeed includes a status node, which denotes what state the transaction is in. For normal gateways on the checkout - they're always considered successful. For those hosted gateways though, the status field becomes key, and could be either pending, rejected or approved. So for your example, the first transaction would have been marked as "pending" for the status, and the second would have been "approved".

    Within your datafeed endpoint, you'll want to check the contents of that status node to decide if you should action the inventory modification for that particular feed. You can see some additional details on this here: https://wiki.foxycart.com/v/2.0/transaction_xml_datafeed#hosted_gateways
  • @fc_adam,

    Ah, ok this makes sense. Can you explain to me why the refund would trigger the datafeed though? I'm not sure I understand why it would do that. Does the refund action fall within one of status entries?
  • fc_adamfc_adam FoxyCart Team
    @Geoffrey,

    Oh sorry for missing that in my previous reply. To be honest, I'm not sure that it should be sending a datafeed in that instance. I'll double-check with the gateway team and we'll follow-up with you on that. Thanks for bringing that to our attention.
  • @fc_adam,

    OK. Thanks. I managed to solve the this easily with the condition:


    //Skip if PayPal & Status != Approved
    if ($payment_gateway == 'paypal_ec' && $status != 'approved') continue;


    If the refund is triggering a datafeed as well, I figure this approach should still prevent it from running the inventory script.
  • brettbrett FoxyCart Team
    Hey @Geoffrey. Quick heads up we've opened a ticket for the refund issue on our end. We'll update you when there's movement.
  • @brett, thanks for looking into this. Just want to add that even with the conditional rule I mentioned above, the PayPal refunds are still triggering my inventory script. So it seems that when the refund pings the datafeed, the transaction is still marked as "status == approved". I have already observed one live transaction on which this has occurred since last posting. Would be great if you guys could get this fixed, or offer a functional way of preventing the refunds from triggering my inventory script. Thanks!
  • fc_adamfc_adam FoxyCart Team
    @Geoffrey,

    Thanks for the update and sorry for the continued inconvenience. Discussing this with the team we agree that the datafeed shouldn't be triggering for those refund actions. We're working on a fix for that to prevent it happening. We do have plans to support native refunds too in the future in which case the datafeed would serve a purpose and have a unique status, but for the interim we'll stop it sending.
  • @fc_adam,

    Any new status on this? I had this happen a couple more times today, and one of them was from a refund that had already been initiated on 8/5. In that case I think what happened was that the refund for the transaction was initiated through PayPal on 8/5, which triggered the datafeed once at that time. But the refund had a status of pending until today, and when that status changed to complete it triggered the datafeed a second time. It's getting really confusing to sort out the inventory errors this is causing. Please let me know when you anticipate having a fix in place for this. Thanks!
  • fc_adamfc_adam FoxyCart Team
    @Geoffrey,

    Thanks for updating us. No new update from our side just yet, but I'll connect with the team and see if we can bump it up the list for you.
  • @fc_adam,

    Would love to see some progress on this. I know you guys have a lot to do. Hate to be a squeaky wheel, but this one keeps bugging me. I just had to reset inventory count on 24 products because of a tiny partial refund on a huge paypal transaction. Hoping for a fix soon.
  • fc_adamfc_adam FoxyCart Team
    @Geoffrey,

    I'm sorry this issue is persisting for you. We are currently discussing this issue to find the best solution - I'll ping the ticket again to let the team know that this is still actively affecting you.
  • @fc_adam,

    I came up with a partial (99%) solution to the PayPal refund issue. Since we rarely process refunds on the same day as an order takes place, I used this bypass in our datafeed endpoint to successfully prevent the refund from triggering the inventory scripts:


    $transaction_date = (string)$transaction->transaction_date;
    $compare_date = substr($transaction_date, 0, 10);
    $today = date('Y-m-d');

    if ($payment_gateway == 'paypal_ec' && $compare_date != $today) continue;
  • fc_adamfc_adam FoxyCart Team
    @Geoffrey,

    Ah that's an interesting solution! Sorry this has taken us so long to handle - it's fallen into a larger discussion we're currently having with handling refunds natively within FoxyCart which we're currently also building out. I'm glad you were able to find a stopgap solution at least to prevent it affecting you actively.
  • @fc_adam ,

    This problem with PayPal has reared it's head again. Everything was humming along just fine until sometime between 3:50pm and 7:00pm CST on 10/12/16 (last Wednesday). In any case, every paypal transaction we've had since 7:00pm CST on 10/12 has triggered our datafeed shipping script twice. I noticed the problem today, and I have to correct inventory counts for about 22 transactions now.

    Looking for differences between the transactions before and after 10/12 timeframe I mentioned, I noticed that the checkout data is showing the following change:

    _fcpm : paypal_ec|checkout (prior to 7:00pm on 10/12)

    has now become:

    _fcpm : paypal_ec|cart (after 7:00pm on 10/12)

    From my transaction audit messages, I can see that the problem is once again that PayPal is triggering the datafeed on submission and again when the status is "approved". I previously resolved this by using the following condition in my datafeed endpoint:

    //Skip if PayPal & Status != Approved
    if ($payment_gateway == 'paypal_ec' && $status != 'approved') continue;


    Apparently this no longer works correctly since that change of_fcpm value described above. What exactly did you guys (or PayPal) change to make this stop working? I would appreciate your assistance in finding a solution that will work under the new conditions. Thanks for your help.
  • fc_romanfc_roman Member, FoxyCart Team
    @Geoffrey,

    Sorry to hear about the datafeed duplication. A release published earlier today should fix this issue —please let us know whether it did for you. Thank you and sorry about the inconvenience.
  • @fc_roman,

    That appears to have fixed the problem. Thanks!
Sign In or Register to comment.