Webhooks - Only receive from a specific transaction source

[ddeisz]

We are using Accept Hosted and webhooks in our web shop.

A customer of ours wants to setup a sub-shop for a customer of theirs that will use their customer's Authorize.Net merchant account.  This same Authorize.Net account is already receiving/processing transactions from another source(s).  Their customer has not told us how these transactions are coming to their Authorize.Net account.  We do know that there are not currently any webhooks defined in this Authorize.Net account, nor is there a silent post URL configured.

If we add a payment webhook URL endpoint, will we get information sent to this endpoint for not only the Accept Hosted transactions that we care about, but also the other transactions from the other source(s)?

If the answer to the above is yes, aside from using a different Authorize.Net account, is there another way to limit which transactions are sent to the payment webhook URL?

[Renaissance]

@ddeisz

Webhooks will be triggered for all events subscribed to. This means that if you subscribe to auth-capture then auth-capture transactions will trigger webhooks for that account. It is the API credentials and events that determine what goes where.

You can engineer any function you want. There are probably dozens of ways to get only updates for the orders tied to that account. You have to remember that all a webhook does is deliver a payload. Any updates to your records will be accomplished by processing that payload.

You could pass an order description for the sub customer and then update records based on the description text, for example.

[ddeisz]

So, if transactions are created from various sources (some not under my control), but all are using the same API login ID and transaction key, when I add a webhook endpoint and subscribe to auth-capture transactions, then the endpoint will receive the "payload" for all auth-capture transactions for this Authorize.Net merchant account, regardless of the source of the transaction?

Is the only way I can be sure that the payloads I receive are for transactions related to sales from my shop is to use a different Authorize.Net merchant account?

[Renaissance]

To ensure that you only receive webhooks that is a tentative yes. What I am saying is that the source code of your api call can be configured to pass a retrievable value tied to each merchant. You can have 2 merchants on one account.

There is NO consequence to receiving a Webhook. All consequences of receiving a webhook are the result of processing the webhook. You have your webhooks processing script discriminate. If you only want them processed for one merchant, you code that in. If you want merchant a to be processed one way and merchant b another, you code that in. And I repeat, a webhook that isn’t processed is = to a webhook that was never sent. If you receive the webhook but do not process it, the result of receiving that webhook is the same as what would happen if you didn’t receive the webhook at all.

[ddeisz]

Thanks for the reply.

I understand about not processing the webhook because it's just a notification and I would have to explicitly go out and get the details of the transaction given the payload that was sent in the webhook.

However, my question was about stopping the webhook from even being sent unless it was related to a transaction from a specific source.

Since it appears that is not possible from the Authorize.Net merchant interface side, the only way I can be sure the notifications I receive are only for the transactions I generated is by using a separate Authorize.Net merchant account.

[Renaissance]

@ddeisz

You could programmatically activate and deactivate the webhooks. If merchant a gets a webhook and merchant b does not, you do it like this- when a transaction is created for merchant a, webhooks are programmatically activated. Then the webhook is processed, and at the end of the script you programmatically deactivate it.

That would give you the result you want.

[ddeisz]

In theory you could do that, but in practice I think it would be prone to concurrency issues.  Keep in mind we are using the Accept Hosted solution.

Here are just three examples that would cause problems...

Scenario 1:

A user opens an Accept Hosted payment page so the webhook is activated, but then either delays completing the transaction or simply closes out without completing the transaction.  The webhook is left activated.

Scenario 2:

Two or more users open Accept Hosted payment pages at or near the same time so the webhook gets activated.  First user completes the transaction, so the webhook is deactivated, but now further webhooks for the other users who have not yet completed their transactions are not received.

Scenario 3:

Two or more users open Accept Hosted payment pages at or near the same time so the webhook is activated.  First user completes the transaction, but because we are keeping track of started vs. completed transactions, we don't deactivate the webhook.  But, the other users delay completing the transaction or simply abandon the transaction / close the browser without completing, so the webhook is left activated.

Of course these aren't unsolvable scenarios, but there's also time, resource, and cost considerations on how far we are willing to take the development effort.

Given that, I think we'll stick with requiring a separate merchant account in this situation.

But I do appreciate your input, so thank you!

[dembele89]

I actually have integrated Authorize.Dot internet into my software and feature used Auth&Capture, Refunds provider here. When a consumer a create a Refund request from portal i need to save that in my database