cancel
Showing results for 
Search instead for 
Did you mean: 

Replacing SIM

Hi All

I'm updating our products which currently use AIM and SIM to use the new API's. AIM now uses Authorize.Net API and was a breeze. For SIM the recommendation is to use Accept Hosted and that is being a bit more problematic. I've looked at the possibilities for Accept Hosted and have gone for a redirect as I really want to avoid the IFrame Communicator URL if possible. So, I create the token which is fine, go to the Auth.net server to pay which is fine and get taken back to my receipt page specified in hostedPaymentSettings->settings->url. I can include in this url an order id in the query string to retrieve from my database the order details. Now what I would like to do is query Auth.net to see if the order was successful or not and have read that getTransactionDetailsRequest is the way to do that so I can specify a refId while creating the token to use in this call. But it seems that I also have to specify a transId and I don't have that information yet. Am I missing something here? In the sandbox while testing the transId is always going to be "000000" anyway, but even if I specify that as the transId I get an error...

"code":"E00040","text":"The record cannot be found."

 

Vince

ectdeveloper
Member
1 ACCEPTED SOLUTION

Accepted Solutions
You need to put your sandbox in live mode so that you get a transaction id. The other half of your solution is accomplished using webhooks. You get the results pinged to your server with a webhook, and when the webhook hits your server you pull out the transaction Id from the json payload. The run the method call.

These things are extremely reliable. My clients production account has never had an issue. I have a remote server I test things on, and it has puny resources. I would hate to fathom how many I’ve tested at this point. Way up in the 100s. The only “failures” I’ve had, are when I have a large list of test orders populated on my orders page and am refreshing the screen trying to catch them when they come in. What happens there is this test account has a limited amount of entry processes, and due to customer data encryption/decryption functions every time I refresh the page when I’ve got a list like that, 100s of Php scripts are ran.

So to make it short, authorize never fails, ever. As long as your server has reasonable uptime you will never miss one. The first one will come in a few seconds. If your server doesn’t respond then there will be more attempts on 3 second intervals, then 3 minutes, and there is a redelivery schedule that goes on for 3 or more days.

I read others comments where they are skeptical or report problems, but that’s not my experience at all and I highly recommend them. I have a 99%+ success rate with the 1% due to my own actions overwhelming my server because I refresh my orders page too many times too rapidly.

View solution in original post

Renaissance
All Star
4 REPLIES 4
You need to put your sandbox in live mode so that you get a transaction id. The other half of your solution is accomplished using webhooks. You get the results pinged to your server with a webhook, and when the webhook hits your server you pull out the transaction Id from the json payload. The run the method call.

These things are extremely reliable. My clients production account has never had an issue. I have a remote server I test things on, and it has puny resources. I would hate to fathom how many I’ve tested at this point. Way up in the 100s. The only “failures” I’ve had, are when I have a large list of test orders populated on my orders page and am refreshing the screen trying to catch them when they come in. What happens there is this test account has a limited amount of entry processes, and due to customer data encryption/decryption functions every time I refresh the page when I’ve got a list like that, 100s of Php scripts are ran.

So to make it short, authorize never fails, ever. As long as your server has reasonable uptime you will never miss one. The first one will come in a few seconds. If your server doesn’t respond then there will be more attempts on 3 second intervals, then 3 minutes, and there is a redelivery schedule that goes on for 3 or more days.

I read others comments where they are skeptical or report problems, but that’s not my experience at all and I highly recommend them. I have a 99%+ success rate with the 1% due to my own actions overwhelming my server because I refresh my orders page too many times too rapidly.
Renaissance
All Star

Thanks very much and that's got me further I think. I have set up webhooks and now after paying my webhook url gets a message along the lines of ...

 

{"notificationId":"f01504c9-etc","eventType":"net.authorize.payment.authcapture.created","eventDate":"2019-02-15T12:19:08.4541614Z","webhookId":"39310bc7-etc","payload":{"responseCode":1,"authCode":"PMQJ6S","avsResponse":"Y","authAmount":13.25,"entityName":"transaction","id":"60116726091"}}

 

My problem now is tying that to the original order. I set a refId when creating the original token to initiate the transaction but that isn't included in the webhook. If anyone has any idea please let me know.

 

Vince

The solution to that is to pass the internal order number as the invoice number, using an OrderType object. You extract the transid from the payload you just posted, then you run a getTransactionDetails(); method call. The invoice number can be retrieved there. I think the invoice number now also may come back in the webhook. I get a lot more data from authorize than the invoice number so I have to run the method call anyways.

Sorted - and all the information was in your original post so I should have read it more thoroughly. Thanks again so much for your help Renaissance!!