cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

Webhook notifications not being sent

I'm currently dealing with an Accept Hosted payment solution for my company's website (coded in PHP), which using the iframe method. The transaction type is set to "authCaptureTransaction" and has a webhook endpoint set up to receive notifications for only one event:

 

net.authorize.payment.authcapture.created

 

which is used to send a confirmation email to the customer. However, we are not receiving the webhook notifications for transactions which have not yet been authorized. This is a problem since many of our transactions get marked as suspicious before going through. I want the confirmation email to be sent to the customer as soon as the transaction has been created, not after the payment has been authorized. The documentation doesn't say much about these notification events.

 

Can someone shed some more light on when exactly these notifications get sent, and how to ensure the webhook endpoint always receives a notification right after the transaction is created?

takumi
Member
2 ACCEPTED SOLUTIONS

Accepted Solutions

@Renaissance 

 

Thanks for your help! I ended up figuring out the issue -- If a transaction is marked as "Suspicious Transaction" (and many are for us), the net.authorize.payment.authcapture.created event does not occur, ever.

 

Our payment system uses 'authCaptureTransaction' as the transaction type, so naturally I set up my webhook endpoint to listen for net.authorize.payment.authcapture.created. But in reality, what happens is that if the transaction is marked as suspicious, the net.authorize.payment.fraud.held event is triggered instead. Then, sometime later, after the transaction has been approved, the net.authorize.payment.fraud.approved event is triggered.

 

I know it's only semantics, but the webhook event names don't really seem to properly communicate this. The docs also don't mention that the net.authorize.payment.authcapture.created event is abandoned entirely if the fraud detection system decides to hold a transaction.

 

 

View solution in original post

@takumi

You are welcome. The solution you found was what I was referring to when I said this in the post above-



You could set up a FDS events. I think that would help you.

I was referring to fraud detection. Glad you were able to get it working. Could you mark this thread as solved?

View solution in original post

9 REPLIES 9

@takumi 

 

You could set up a FDS events. I think that would help you.  My first client uses authonly, and the suspicious transactions are processed as normal.  I would double triple check that you are not receiving anything. Also, you can use the merchant interface to set up automatic emails.  They will receive an invoice in the email (not attached as a pdf but part of the HTML of the email, and it looks exactly like what you print from the interface). Any custom text you want can be put in the email through the interface. 

Renaissance
All Star

Thanks for your response! Unfortunately the automatic emails don't provide much in terms of customization; all other emails from our website use the same HTML template, so it is preferred to send the confirmations on our end.

 

I used the notifications REST API (https://api.authorize.net/rest/v1/notifications) to double check; no notifications have been created for any of the affected orders. I'm not sure that switching to authorization only will help in our case, since the webhooks seem to not send until payment has been authorized.

 

It's a bit confusing that the API says that the event "Notifies you that an authorization transaction was created.", but the event doesn't actually get triggered when the transaction was created. Is there really no event that just gets triggered when the transaction is created?

@takumi

The authorization is the transaction. Anything that generates a transaction Id is a transaction. If you are not getting a webhook for transactions you have something configured wrong somewhere. To be 100% clear, if you run a sandbox or production payment form, enter cardholder data and on the next page there is a transaction id and/or there is a transaction id in your auth.net interface, you should be able to get a webhook for that exact event.
If you need something to happen before the payment is authorized or captured, you just put that directly in your script. If it is independent of auth.net you donโ€™t care what auth.net does and can do whatever you want.

@Renaissance 

 

Thanks for your help! I ended up figuring out the issue -- If a transaction is marked as "Suspicious Transaction" (and many are for us), the net.authorize.payment.authcapture.created event does not occur, ever.

 

Our payment system uses 'authCaptureTransaction' as the transaction type, so naturally I set up my webhook endpoint to listen for net.authorize.payment.authcapture.created. But in reality, what happens is that if the transaction is marked as suspicious, the net.authorize.payment.fraud.held event is triggered instead. Then, sometime later, after the transaction has been approved, the net.authorize.payment.fraud.approved event is triggered.

 

I know it's only semantics, but the webhook event names don't really seem to properly communicate this. The docs also don't mention that the net.authorize.payment.authcapture.created event is abandoned entirely if the fraud detection system decides to hold a transaction.

 

 

@takumi

You are welcome. The solution you found was what I was referring to when I said this in the post above-



You could set up a FDS events. I think that would help you.

I was referring to fraud detection. Glad you were able to get it working. Could you mark this thread as solved?

This is getting more and more irritating had five notification back to back visit official site

Capital One, one of the most reliable banks in entire America now has an authorized website, check here. 

I definitely enjoying every little bit of it. It is a great website and nice share. 

 

prepaidcardstatus

 

prepaidcardstatus login

nemonboi
Member