So many questions...

[CheekyWarbler]

Hi people,

We're trying to integrate Authorize.net into our software (a Rails app) but are coming across so many issues. Our app already integrates with half a dozen other payment providers, so we're fairly familar with the basics of payment processing. We're just _really_ struggling with Authorize.net,mainly down to the documentation I think. I've spent hours already trawling through the docs for answers to all the questions below. Any answers to any of the following would be appreciated greatly:

1) Is there a specific tool for testing webhooks? Other payment providers we've used have tools to form and fire webhook calls.

2) Is there a log of webhook calls I can see from the sandbox interface?

3) I've seen people talking about calls to https://apitest.authorize.net/rest/v1/notifications and suchlike as a means of listing webhook calls that have been sent, but...

3.a) I can't find any documentation for that stuff.

3.b) When I tried the Postman pack on GitHub and made the call I got a bunch of records back that bore no resemblance to any test transactions I'd ever made.

4) Should transactions I trigger from our app via the getHostedPaymentPageRequest call and then a redirect, trigger webhook calls upon completion?

5) If I'm using the getHostedPaymentPageRequest and redirect method, am I right in thinking that it's then completely impossible to ever find out the transaction id without having code that downloads all transactions and looking for one that matches in some way?

6) How do eCheck's payments work with regards to getting back a transaction id?

7) Does the system send webhook notifications as eChecks progress through the system?

8) Am I right in that the sandbox still has no support for testing eChecks?

9) What kind of timescale are we generally talking about between a payment being made and a webhook hitting our servers? Seconds, hours, days?

10) I'm making test transactions from our app, getting to the success / thankyou page after entering card details, returning to our website, then checking in the sandbox for transactions and seeing nothing - is that right?

I could go on, but that's enough for now. :-)

[mmcguire]

I'll give it a try,

1. There is not a specific tool for testing webhooks. However there are free ones out there - like webhookinbox.com
2. A log of webhooks sent is available via api only, look for "Retrieve Notification History"
https://developer.authorize.net/api/reference/features/webhooks.html#API_Calls
3.a & b See #2
3.c If you used https://apitest.authorize.net/rest/v1/notifications, then it will give you details on webhooks notifications that were sent out but does not support the webhook contents in the payload.
4. Yes, if 1) a successful transaction is processed 2) you are signed up for the webhook for the type of transaction that was processed.
5. Yes, when HostedPayments is invoked via redirect mode, the only way to find out transact id is from receipt page.
6. eCheck transactions have the same response format & behavior as credit cards, with minor eCheck related differences in the fields returned.
7. Payment related webhooks apply to eCheck. There are no webhooks that are specific only to eCheck.
8. The sandbox does have support for testing eChecks.
https://developer.authorize.net/hello_world/testing_guide_new/
9. Normally you would see it in a few minutes if not sooner.
10. Transactions made in test mode are not stored and will not show in the merchant interface. So yes, that is correct.

[CheekyWarbler]

Thanks for that.

That's all great information.

Could you just confirm one more thing?

Looking at the range of webhook events that are possible it seems like the only actual capability of webhooks is to tell you when a payment is started (created). It then looks like we're in the dark as to what is going on with the payment unless we make periodic called to get the transaction status ourselves... Is that right?

Where we have used systems such as GoCardless (a UK direct debit solution) , we get individual webhook calls as the payment progresses.  So we might get a _created_ on monday, an _accepted_ on wednesday, a _funds_received_ on a thursday and a _in_your_account_ on the following monday.

Am I right that with Authorize.net we just get the initial _created_ and then we need to manually ask every day _whats_the_status_ ? and watch as the status chages over time?

Is that even the case for standard credit / debit card payments? i.e. With a credit card payment, do we get a _created_ webhook call and then have to check oursleves periodically whether the payment was a success? i.e. Is perfectly possible to get a _created_ payment webhook call, and then when we make an API call to check the status, find that it was declined?

Or put another way. Do we get a paymet.created webhook call (A) when a payment attempt is started, regardless of how it then goes, or (B) only on completion of a successful payment.

Sorry about all the questions. :-)

I feel like I'm missing a whole slew of documentation with the fine details in.

[inLeague]

Am I right that with Authorize.net we just get the initial _created_ and then we need to manually ask every day _whats_the_status_ ? and watch as the status chages over time?

Yup. 

We are in the same boat - working on a software integration and expected a lot better, both from functionality and the documentation, for the largest payment provider by customer base in 2019.

There's no way to distinguish an incoming transactionAuthCapture webhook for a subscripition/recurring payment from a regular transaction unless you ping Authorize.net's API back upon receiving the webhook - which sort of defeats the point of a webhook in the first place.

The Authorize.net interface doesn't contain any tools for testing your webhooks.  There's a button that says 'test webhook' but it just pings the endpoint with a generic transactionAuthCapture payload, even if the webhook is for a different event.

The documentation is incomplete, and in many places, unreadable.

We had high expectaitons coming in but if I had to go back and do it all over, I wouldn't go near Authorize.net.

[CheekyWarbler]

Oh joy :-)

Could you also confirm the following piece of insanity...

I'm using the "sandbox" / "test" environment at the moment as I'm developing our application.

I've managed to make a payment form, use their JS library to transform the payment data into opaqueData, submitted this to our server, then created a transaction request, which was all successful.

I got the impression from the "documentaion" that we would then get a transaction ID back in the response so we could follow up, check the status for asynchronous payments like eChecks.

BUT, when I look at "response->transactionResponse->transId" it's always zero.

So, am I right that in the sandbox / test environment the system never bothers to actually store the test transactions or even return a faked transaction ID? i.e. the entire sandbox environment and all test api calls are efectively piped to dev/null and forgotten. 

I had wanted to store the transactionId and they do crazy things like try to get the status of the transaction at a later date.

[chickadee79]

You would get a transaction ID of 0 if you run the transaction while your account is in Test Mode, or send the transaction as a Test Mode transaction. Test Mode is never recommended in the Sandbox as the platform itself is a testing environment. Make sure everything is in Live Mode and try again. 

[CheekyWarbler]

Thanks.

Light is slowly dawning on me....

Test mode and Sandbox mode are not synonymous are they...?

So we have Real accounts and Sandbox accounts. And for each of those, the account can be in Live mode or Test mode.

So in total we have:

A) Real account, live mode

B) Real account, test mode

C) Sandbox account, live mode

D) Sandbox account, test mode

Then, we use the jstest. path below for the Sandbox environment, and the plan js. path for the Real environment?

https://jstest.authorize.net/v1/Accept.js

https://js.authorize.net/v1/Accept.js

Soooo the 'test' in the jstest path is nothing to do with the test / live mode distinction? A more accurate name would probably have been jssandbox.authorize.net/blah... ?

Soooooo, the switch between test and live mode (for both Real and Sandbox accounts) is then the toggle I see in the admin control center when I log in to the website and not something I trigger on a per request basis...?

[mmcguire]

Authorize.Net will send payment webhooks for the initial authorization and any follow on requests (such as void, capture, etc) made for the same transaction.

You are correct, there are no settlement related webhooks. This would be the _accepted_ example in your list.

The following actions happen at the aquirer / merchant account level and Authorize.Net does not send webhooks for these events as it is not in the Authorize.Net system.

-a _funds_received_

-in_your_account_

[CheekyWarbler]

Hi, thanks.

But I presume I can repeatedly make calls to "Get Transaction Details" until I see a status of "settledSuccessfully" and THEN I will know that the recipient actually has the money?

Or have I missed something obvious? It seems a bit of a long winded way to answer the basic question of  "have I actually got the money?".

This is especially true in our case I think as we'll be dealing primarily with eChecks.

Mu current eCheck plan is thus to make the initial payment request and then have a background task running once a day to ask for the status of all outstanding payments until I get a "settledSuccessfully".

You mention certain events as being "not in the Authorize.net system".... the implication being that there may in fact be no way to know when an eCheck has completed successfully other than looking at your own bank statement manually. Is that a correct interpretation?

Thanks again for all your time people.

[kaseras33]

The trouble is that due to the fact I am the usage of Ember.Js in my app, the prototype capabilities in AcceptCore.Js reaction parsing here.