- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Solved! Go to Solution.
โ02-13-2019 05:52 AM
Accepted Solutions
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ02-13-2019 12:44 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ02-13-2019 12:44 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks very much Renaissance 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
โ02-15-2019 06:05 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
โ02-15-2019 06:31 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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!!
โ02-15-2019 07:09 AM