Declined subscriptions sending XML datafeed postback

bret_ortonbret_orton Member
in Bugs & Feature Requests edited April 2009
A client noticed a subscription customer who's been declined at Authorize.net for recurring subscription charges, and I can see Foxycart error logs in the FC admin area for those same recurring transactions; they show declined transaction errors.

However, I'm also seeing successful XML data postbacks that have been stored in the client's database that were processed, as well as what seems to be valid transactions in the FC admin transaction reports.

Any thoughts would be awesome. -- any issue with me posting the transaction IDs if they'd help?

Thank you'all,
Bret.
Comments
  • brettbrett FoxyCart Team
    Hi Bret.
    Whisper us the IDs if you could.
    Just to clarify, you're saying that Auth.net is declining them, but FC is thinking they're approved?
  • brettbrett FoxyCart Team
    (Response to whisper)
    Hmmm... Definitely interesting. Could you perhaps email or whisper us a screenshot of what it looks like in Auth.net? You'll probably want to blur out any customer data just to be safe, but it'd be very helpful if we could confirm exactly what Auth.net is showing.

    Is this happening with every subscription payment, or just certain ones? If it's not everything, is it perhaps specific to an individual customer? Is it possible that the transaction was initially authorized but subsequently denied?
  • I just requested the Auth.net screenshot from the client and will post when I get it, as well as if they've spotted other declined recurring charges doing this. The only odd thing I can see is that both the transaction IDs show up in the FC error report as being declined, but also show up in the FC transaction report as seeming to have completed (which I'm guessing is why the XML datafeed post came through).

    Thanks again, Brett and Foxy guys. I'll post that screen cap when I get it.
    - bret
  • lukeluke FoxyCart Team
    Hey Bret. This sounds vaguely familiar. Check with your client to see if they have special AVS (address verification) settings turned on in the gateway. There are some gateways that "decline" a transaction while still sending back the "Everything is ok" go code. Are they using authorization only or the standard authorize? We've also heard of some gateways responding with an OK code while still holding the transaction back because of AVS settings (or similar settings) and the transactions then need to be approved manually on the gateway side.

    If there are any other clues you have to this, please pass them our way. We'll look into things as we're able from our side.
  • lukeluke FoxyCart Team
    Thanks for bringing this to our attention, Bret. It looks like we made a small change on March 1st to the subscription processor in version 040 which was supposed to only be for 050. This was causing failed subscription transactions to save to the database, even though the transaction did not go through. We've fixed the problem and apologize for any frustration or confusion this may have caused you our your client.

    We recommend you upgrade your client to version 050 as the subscription model has been completely redesigned and is much improved. More info on upgrading can be found here: http://wiki.foxycart.com/docs:upgrading

    Thanks again for letting us know about this.
  • Thanks Luke,

    I went through the FC error reports again and it looked like it was pretty much happening to all subscription transactions. The only thing I noticed from the auth.net screen caps I received was a "Submit date/time: 02-Apr-2009 06:38:36" and a "Settlement Date and Time: 03-Apr-2009 04:11:31" -- was thinking the whole day Auth.net took to settle the transaction could have caused the issue; where they send an OK right away, but then, a day later, send a "BAD". Anyway....

    And yes, I've been testing out parts of the 050 on a local cart (the user api) but that's about it, so far. Looks pretty sweet though.

    Take care you and thanks again for the help.
    - bret
Sign In or Register to comment.