cancel
Showing results for 
Search instead for 
Did you mean: 

Accept Hosted Redirect Method - Transaction Status Notifications

Hello,

 

I'm in the process of converting from the old SIM integration method to the new Accept Hosted Redirect method where the payment form is hosted on Authorize.net's web site. I have everything working to the point where the customer is able to enter their credit card and they can click to pay.  However, I'm currently unable to figure out how to have Authorize.net communicate the transaction status back to my application so that the app can process the order accordingly. 

 

I saw some other threads where people suggested using web hooks to accomplish this, but I currently don't see any way to link the transaction to a specific order id in our application.  Questions:

 

1) Is there a way to have Authorize.net simply send a notification back to my application when the transaction is processed successfully or declined without depending on the user to click the "Continue" button?  If so, how?

 

2) If the only option is to use the web hooks api, how specifically can I use that to link back to original transaction to match it up with the original order in our application?  Is there a way that I can pass our unique order id with the transaction so that it's passed back via the web hook?

 

Thank you!

 

Tommy

redcart
Contributor
12 REPLIES 12

hey @redcart 

 

1. Yes, but a qualified yes. The answer is webhooks but it will not notify you if a transaction is declined, only if successful.

 

2. Pass your internal order number as the invoice number in the API call. Then on your webhooks endpoint have a getTransactionDetails method call script that retrieves the invoice number and updates the appropriate record in your db. This solves the qualification on item 1. of your question, because you know which orders were declined (or where the customer abandoned the payment page) by the fact the records are not updated as paid. As for the only method, the iframe integration will return transaction information. I still recommend webhooks. 

 

Click on my name and skim through my ever expanding collection of posts and you will find some that detail how to use webhooks. 

Renaissance
All Star

 

Thanks for the replly!  I started going down the path of using web hooks and I have it mostly working if I create the web hook manually in the UI.  But I'm running into a bit of a road block when trying to create the web hook programmatically through the rest api. When I try to make a php curl post to create a new web hook, it simply returns the existing web hook that was already created via the UI. I'm using vanilla php curl instead of any specific Authnet php library. 

 

Do you have an example code to create a new web hook using vanilla curl?

 

Endpoint:

https://apitest.authorize.net/rest/v1/webhooks

Method:

POST

Encoded JSON data vars:

{"name":"Test Payment Notifications","url":"https:\/\/the-url.php","eventTypes":["net.authorize.payment.authorization.created","net.authorize.payment.capture.created","net.authorize.payment.authcapture.created","net.authorize.payment.priorAuthCapture.created","net.authorize.payment.refund.created","net.authorize.payment.void.created"],"status":"active"} 

When posting it just returns the list of web hooks as if I'm calling GET instead of POST. Any help would be appreciated. 

So there are a few things here. One is you don’t want to be making manual calls to get transaction data. You want it to be automated. Those HTTP requests are for manual calls. They have their use but aren’t what you want to do to get your transactions updated.

To automate, you set up an endpoint in the interface (can also do that with curl but for me it’s convenient to just use the interface. Less debugging if things don’t work). Then on your endpoint you put in a programming script to process the transaction data that hits it. Then every time an order is placed your endpoint will be sent a webhook, your script will execute, and the order will he updated in your records.

I have some curl code I use occasionally but am getting breakfast and don’t have it in front of me at the moment. When I’ve got some downtime at home (I’m slammed and don’t have much) I will shoot it to you. For now I would set up your endpoint and start running test transactions. Set your endpoint to active and have your script capture the data being sent. Build it one step at a time. First step is to capture the payload that hits your endpoint. Next step is to extract what you need. You may only need to extract the invoice number (I think this is in the payload). I get the transaction Id so that I can pull the entire transaction with an API call. There are endless ways to extract data so just use what works for you. Once you’ve got it down getting what you need from the payload, then you build your record updating component of the script. The final step after that works is to implement the sha512 hash verification, so that when you’re live your endpoint only acts on legitimate information.

 

Thanks Renaissance!  But I think I'm further along than you think I am.  I already have the Accept Hosted integration working and am able to grab data off the payload from the web hook on my server to grab the transaction data.  All that good.  The problem I'm trying to solve is creating the web hook through the API instead of manually through the Authnet UI. The reason why I have to do this is because my application is already being used on thousands of sites using the SIM integration method and I don't want to have to force all customers to have to go into their Authorize.net back-ends and manually create and manage web hooks on their own.  I want the application to verify that the proper web hook already exists on the account and if it doesn't, create it programmatically.  I'm already getting a list of web hooks through the API and that part works great.  The only thing I can't seem to get to work is creating the webhook. For some reason, my POST for the create returns the same thing as if I was doing a GET to the same api endpoint:

 

POST https://apitest.authorize.net/rest/v1/webhooks

This is why I think I just have a curl opt setting wrong with my curl code. Either that or the documentation for the Create Webhook endpoint isn't correct.  Here's a list of the curl settings I'm currently using:

$headers = array(
				'Accept: application/json',
				'Content-Type: application/json',
				'Authorization: '.sprintf('Basic %s', $base64credentials),
'Content-Length: ' . strlen($data)
		);

$ch = curl_init('https://apitest.authorize.net/rest/v1/webhooks');
curl_setopt($curl, CURLOPT_POST, 1);
curl_setopt($curl, CURLOPT_POSTFIELDS, $data);
curl_setopt($ch, CURLOPT_HTTPHEADER, $headers);
curl_setopt($ch, CURLOPT_TIMEOUT, 120);
curl_setopt($ch, CURLOPT_HEADER, 0); 
curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, 1);
curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, 1);
		
$response = curl_exec($ch); 
$httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
curl_close ($ch);

 

And I think I just spotted the problem after pasting in my code.  Notice the $curl vs $ch variables. Oops! :)

So you are issuing a new version of your application that uses Accept Hosted? That's cool.  Was this triggered by the mass hysteria over md5 to sha512? 

 

Yep - Accept Hosted will be replacing our old SIM integration.  And yes, it was triggered by the mass hysteria over MD5 to sha512 and the fact that Authorize.net keeps telling all of our clients that SIM is being deprecated. 

 

From what I'm seeing, I think the old SIM hosted payment form looked a lot better.  I haven't had a chance to look at the the options for customizing the Accept Hosted payment form yet (programmatically) but I'm hoping there's ways to improve it.  Currently I think it looks like crap and I know my customers aren't going to like it in it's current state. 

The options are quite limited. Changing a few colors and text. The way to pretty it up is to use an iframe. I think SIM will last for a long time. It has no EOL announced. I still recommend Accept Hosted to everyone. I’m going to be working with the iframe at some point. The redirect method is such a no brainer that it solves payment easily, but it is better to offer a consistent feel with the rest of the site.

@Renaissance, I just joined the group after reading numerous posts of yours.  I am new and this might not be the best way to get your help.