ARB payment decline/expiration notifications

[blackwood821]

Hi,

Years ago when I started integrating with Authorize.Net there was no programmatic hook into being notified when a recurring payment was declined due to not enough funds or the card has expired. There were just email notifications and the silent post was but it didn't indicate a decline or expiration. I see now that there are Webhooks (which are supposed to replace the silent post) and the Account Updater Service. In the Webhooks documentation I see the following events:

• net.authorize.customer.subscription.suspended
• net.authorize.customer.subscription.terminated
• net.authorize.payment.fraud.declined

So here are my questions:

1. Can Webhooks handle notifications for when recurring payments are declined due to not enough funds available? If so which Webhook event is this?
2. Can Webhooks handle notifications for when recurring payments are declined due to an AVS mismatch (such as the credit card holder moved and updated their address with their bank).  If so which Webhook event is this?
3. Can Webhooks handle notifications for when recurring payments are declined because the credit card has expired?  If so which Webhook event is this?
4. Will the Account Updater Service solve number 2 above?
5. Are Webhooks + Account Updater Service the best solution for getting programmatic notifications for the scenarios I described above?

I see in the ARB documentation it says:

"Suspended -- When the credit card information for a subscription expires, the subscription becomes suspended. A suspended subscription is not charged until the merchant corrects the problem. The merchant has until the next run date to correct the problem, or the subscription is terminated."

So that suggests that the Webhook event net.authorize.customer.subscription.suspended would solve number 3 above (credit card expired) but not for the account not having enough funds available...

Any help is much appreciated.

[blackwood821]

@Anurag can you verify the behavior that @CoreyC mentioned?

[fbliss]

I can also verify that the webhooks are broken, and have been for at least a year - Auth.net seems to be uninterested in actually doing anything about it, which is a real huge problem for the business that I do work for - they have sent out subscription products that *haven't* been paid for because of the broken Webhooks situation, and are left trying to get the customer to pay for the subscription.  

@Anurag is there any update on this?  Why would you guys leave something in production broken like this?  This is costing real time, money, and headaches for my client - and they are considering dropping authorizet.net altogether as a result, and they aren't a small client.

It's extremely frustrating that I've seen several threads on this with promises to fix it and it hasn't be fixed.  Please, can you fix this already? :/

[Waterhouse]

I can also confirm that this is the way things are. It's very difficult to know whether a subscription has failed. If a subscription payment is declined after the first payment, there's currently no way to be notified of that fact. No webhook notification is sent, and the status of the subscription remains as active.

Here's my method for detecting a failed subscription transaction:

• For each customer, we save in our db the user's subscription id, subscription status etc.
• Run a cron task that:
  • Does a GetUnsettledTransactionList request to fetch all unsettled transactions
  • For each unsettled transaction with transactionStatus of declined:
    • Use the transId to do a GetTransactionDetails request
    • Check if the transaction type is AuthCaptureTransaction (all of our non subscription transactions are AuthOnlyTransactions followed by PriorAuthCaptureTransactions, so we know that an AuthCaptureTransaction is a subscription payment. This probably won't work for everyone.)
    • Get the customer id to fetch the user from our db (you have to pass the customer id to the create subscription request)
    • If the user is marked as active in our db, immdiately send a CancelSubscription request (since auto retry is broken and has unpredictable behavior) then mark the user as terminated in our db

This algorithm evolved over months of relying on webhooks to work properly and being sorely disappointed. There's essentially no way to replicate this stuff in sandbox, so you don't find out about it until you shoot yourself in the foot in production. If I could go back to 2017, I would roll my own subscription system with a job scheduler and transaction requests. I would've saved time in the long run from all the time I've spent dealing with arb not working properly. Case in point: this thread

[blackwood821]

@fbliss Thanks for confirming your results. I feel your frustration as I'm in the same boat.

@Waterhouse Thanks for also confirming the same behavior of webhooks. That is not what I was hoping to be confirmed but looks like 3 of you have now confirmed that webhooks don't notify you of declines after the first subscription payment which is incredibly unfortunate. Thanks for sharing your workaround for this. I might end up doing something similar if we don't hear from Authorize.Net on this thread which is also quite aggravating.

@Anurag Can you please comment on this thread?

[blackwood821]

@Anurag It's been 15 months and we still haven't heard back from you or anyone at Authorize.Net on this issue. Can someone please address this webhook issue??

[inLeague]

The documentation on this subject is a disaster area and there does not appear to be any way to force a test webhook transaction for something like a subscription cancel - just the /pings endpoint. 

This thread is enough to make us regret moving to Authorize.net. Could someone from Authorize.net weigh on how this is supposed to work?