Accept Hosted form return options

[wp]

Hi,

Trying to integrate Accept Hosted and not understanding how to get the transaction response back if using the full window redirect mode (as opposed to iframe or lightbox).  When the app redirects to the hosted page and the credit card info is entered and submitted, it displays an authorize.net confirmation/receipt page with a continue button.  Nothing gets posted back to my site as far as I can tell.  Clicking the Continue button does a GET to whatever page was specified as the "url" parameter in the hostedPaymentReturnOptions setting.

Are we supposed to suppress the authorize.net receipt and have it redirect right to our own page on success in order to get the response data?  If so, not quite sure how to do that as I have specified "showReceipt" as false along with a valid URL in the "url" parameter and it still displays that authorize.net receipt page.  The documentation regarding this is unclear.  It says

"The value of the showReceipt field determines 
whether the receipt page is shown. If the value 
of the receiptPage field is false, a return URL 
must be provided. Otherwise the receipt page will be shown."

But there is no receiptPage parameter listed in the parameters column on the reference page.  I tried passing that parameter anyway and it caused an error.

So how do I get the transaction response data communicated back to my server if using the full page redirect method?

[Aaron]

Hi @wp,

You're correct that the URLs you specify for the "continue" or "cancel" buttons are just used for GET requests, so no parameters are passed from our system. You could encode your own parameters like customer ID or session ID or something into the URL on a per-request basis, though. That way, when the customer follows it back to your site, you have the information you need to correlate it on your side.

You can also register for Webhooks notifications to know when the transaction has succeeded.

Your other option to suppress the receipt page isn't working correctly as you've noticed. We're already looking into that on our end.

With regards to the documentation and the "receiptPage" paremeter. My guess is that it's referring to the "showReceipt" parameter. Maybe somewhere along the line, the parameter name changed, but the documentation didn't? Either way, I've asked for clarfication, so we should get that updated soon.

[wp]

---

@Aaron wrote:

Your other option to suppress the receipt page isn't working correctly as you've noticed. We're already looking into that on our end.

---

So when you guys get it working as intended, will the behavior be as I described it.....the transaction response will post to the URL we provide?  Or will it be another GET redirect without transaction data?

[Aaron]

@wp,

The URL that would be used there is the same as the URL for the "Continue" button, so my understanding is that it's just like the other use of that button, i.e. a GET request.

I can see the usefulness of passing more info, though. If you'd like, I'd welcome you to submit something along those lines to our Ideas forum, where we can consider that for a future enhancement.

[wp]

@Aaron So when you say that your understanding is that it works as a GET request, are you saying that is definitely how it works or that you believe so but aren't 100% sure?  Just wondering if I should wait for a fix to the receipt page suppression bug so I can grab the response data directly, which I'd prefer, or if it will never work that way even when the receipt suppression bug is fixed.

I just think it would be strange for it *not* to be a POST because otherwise I'm not sure how one would display their own custom receipt page without confirmation that the transaction was successful and the associated approval data.  A webhook would not be guaranteed to fire in the millseconds between the payment approval and the redirect to the custom receipt page.

[wp]

@Aaron  So in the absence of a working option to post the data directly to my own receipt page on approval, I'm struggling to see how to connect the dots here when the hosted form is in full page mode.  Hoping you can enlighten me because I have to get this running ASAP or find a new solution.

As discussed previously, the ideal would be that upon approval the full response data (including my fields) are posted back immediately to my own receiving URL so I can display my own receipt.  Not sure how one could otherwise display a custom receipt without having that response data posted back immediately. But until (hopefully not if) that is fixed/made available, webhooks appear to be the only option.

The problem is that the webhook payload only contains a few fields, none of which echo back any of my own data.  So when I get that notification, I can't identify which transaction it connects to on my end.

{
	"notificationId": "1aa5653e-07ea-4d17-9b98-f1e3fc9e31f0",
	"eventType": "net.authorize.payment.authcapture.created",
	"eventDate": "2017-01-07T18:24:36.6967811Z",
	"webhookId": "25622758-f715-4434-92f1-3b3247571fd4",
	"payload": {
		"responseCode": 1,
		"authCode": "5I5760",
		"avsResponse": "Y",
		"authAmount": 100.00,
		"entityName": "transaction",
		"id": "60014143092"
	}
}

I should mention that this application is to be used by multiple authorize.net merchants, so I can't assume all incoming notifications pertain to a specific merchant and just hardcode those credentials. I have to know which account it came from, so I have to have some identifying data in the payload that will tell me that.

I had what I thought was a bright idea to register the webhook URL with a querystring on the end but the registration attempt gives an error about it being an invalid URL, which it's definitely not.

{
  "status": 400,
  "reason": "INVALID_DATA",
  "message": "Field validation errors",
  "correlationId": "cebe5228-2ed6-4a1d-8b92-ee73002732e1",
  "details": [
    {
      "message": "Invalid Url entered. Only valid HTTP(s) Urls are supported."
    }
  ]
}

So what is the recommended way to do this?  Pretty sure I must be missing something obvious.  It has to be its own full page form though, can't be iframe or popup.

[vedranmimic]

wp,

It is mistake indeed, there is no "receiptPage" parameter in "hostedPaymentReturnOptions". it should be "showReceipt" parameter there in documentation.

The only way to get transaction info back from authorize is using iframe communicator, meaning - using iframe as well. However, there is another "bug" in documentation here; parameter "hostedPaymentIFrameCommunicatorUrl" cannot have a string value like "https://mysite.com/special", but it has to be json-like string of this format: "{'url': 'https://mysite.com/special' }". I've learned it the harder way :)

And finally...accept hosted is still not officially released and it seems it is not working for live accounts...This one, i have learned in very very hard way...

Regards,

Vedran

[wp]

@vedranmimic Ugh, is that a fact that it doesn't work live?  I really hope that's not the case.  With the amount of bugginess I'm seeing though, I'm starting to believe that this is not a fully baked solution.

@RichardH or @Aaron or anyone from authorize.net:   Any input here?  Are we wasting our time wrangling with a solution that is not going to work in production?

[Aaron]

@wp and @vedranmimic,

I'm not aware of any issues using Accept Hosted on a live account. That should work just the same way as it does on the sandbox account. If it's not working that way for you, check in the merchant interface for the live account to make sure that the live account has a "Signature Key" associated with it.

Accept Hosted is officially released, but in more of a public beta form. That means that we consider it production ready but with some limitations. I'll go into more detail about the limitations here, but first off, thanks so much for the time you've both taken to write these posts and emails. They're super helpful to us, so even if they don't get you the good news you want to hear, they allow us to clearly identify issues and provide the feedback of how they affect developers. That's what we really need to hear with a new product or feature. It takes time to write a coherent clear message giving constructive feedback like you both have, so I really appreciate the effort.

You've identified a few issues here:

1. The token request fails if the account doesn't already have a "Signature Key" created in the merchant interface.
2. Following any URL from the payment form is just a GET request, not a POST with relevant data.
3. There's no Accept Hosted specific additional way to receive this data (like a simultaneous post from our system to a URL on your system when the transaction is approved).
4. Our general purpose notification system (Webhooks) doesn't provide the info in the notification that you would need in this scenario to know which transaction you're being notified about.
5. Webhooks doesn't let you register a URL with query strings embedded in it.
6. Documentation could be clearer (and includes a couple of errors)

The good news is that all of these are being addressed, but the bad news is that not all of the improvements will appear right away.

Documentation updates are probably the quickest to get out, so we're trying to update that ASAP.  @vedranmimic already touched on the known errors (the reference to "receiptPage" should read "showReceipt"; the hostedPaymentIFrameCommunicatorUrl needs to be passed a JSON object). However, there's a lot more that's been written and that we're trying to include to clarify usage based on feedback like this.

As far as other fixes go: We do have plans to pass more data back in the redirect scenario when the continue or cancel buttons are clicked. However, even if/when both of those buttons turn into POST requests instead of GET requests and submit all of the transaction data to your server, that still won't cover the scenario where a customer submits a card and gets authorization, only to immediately close the browser or have the computer crash. There still needs to be some out of band notification to you that a transaction took place. That's where Webhooks comes in.

You're correct that the existing Webhooks notification by itself doesn't include enough info for you to tie it to a specific customer's payment session. There are already requests to specify more info to be included in the notification (and to allow query strings to be included in a Webhooks URL). However, what we recommend is to take the transaction ID included in the notification and do a getTransactionDetailsRequest for the full transaction details. Using something like the invoiceNumber or purchaseOrderNumber from the transaction details would let you correlate to your customer.

@wp, hopefully this is enough further info for you to determine if this solution will work for you. Currently in a redirect scenario, confirmation of a successful transaction will only be available if a customer clicks on the continue/return button, via Webhooks notification, or via the merchant interface. Detailed transaction info will only be available via Webhooks notification (with subsequent getTransactionDetailsRequest) or via the merchant interface.

If Accept Hosted isn't going to work for you in a redirect scenario, there are other options including calling the Accept Hosted form within an IFrame. If that's still not suitable, the Accept.js solution allows you full control over the payment form and the payment processing while keeping the actual payment details out of your server, thus reducing PCI scope.

If there's any outstanding questions, or anything you still need answered, please let me know.

Again, thanks for the feedback!

[wp]

@Aaron Thanks for the detailed response, much appreciated.  A few reactions/questions:

---

I'm not aware of any issues using Accept Hosted on a live account. That should work just the same way as it does on the sandbox account. If it's not working that way for you, check in the merchant interface for the live account to make sure that the live account has a "Signature Key" associated with it. 

---

Glad to hear it should work in production.  Would love @vedranmimic to weigh in about exactly what he is experiencing so it could be confirmed whether there is or is not a bigger issue.

---

As far as other fixes go: We do have plans to pass more data back in the redirect scenario when the continue or cancel buttons are clicked. However, even if/when both of those buttons turn into POST requests instead of GET requests and submit all of the transaction data to your server, that still won't cover the scenario where a customer submits a card and gets authorization, only to immediately close the browser or have the computer crash. There still needs to be some out of band notification to you that a transaction took place. That's where Webhooks comes in.

---

Agreed that we can't rely on the customer clicking those buttons.  But I meant something slightly different, I was talking about the data being posted immediately to my receiving url on the server-side as soon as the transaction is processed.  So once the customer clicks Pay, the data is submitted to authorize.net, approved/declined, then the response is immediately posted to my script which receives it and displays the output page to the customer.  This doesn't require the customer to click anything, nor does closing the browser impact the process since the POST happens server to server.  It's the only way I can imagine a custom receipt page working, because that receipt page needs to have the full response data before it can render, and you can't rely on a webhook having fired in the milliseconds between the transaction approval and the redirect to the custom receipt page.

So will it at some point work the way I'm describing it?  Or if not, what will be the mechanism for handling custom receipts?

---

You're correct that the existing Webhooks notification by itself doesn't include enough info for you to tie it to a specific customer's payment session. There are already requests to specify more info to be included in the notification (and to allow query strings to be included in a Webhooks URL). However, what we recommend is to take the transaction ID included in the notification and do a getTransactionDetailsRequest for the full transaction details. Using something like the invoiceNumber or purchaseOrderNumber from the transaction details would let you correlate to your customer.

---

This would be fine in a single-merchant scenario but since this particular application is designed for multi-merchant use, I don't know the authentication credentials to use for the API request to get the transaction details.  That's why I need the notification to echo back an identifier from my own data so I can correlate it to a specific account on my end and then grab all the remaining data from there. 

What is the likelihood something like this can be made available ASAP (like today/tomorrow) - either as additional payload data or via a webhook url that supports a querystring?

---

If Accept Hosted isn't going to work for you in a redirect scenario, there are other options including calling the Accept Hosted form within an IFrame. If that's still not suitable, the Accept.js solution allows you full control over the payment form and the payment processing while keeping the actual payment details out of your server, thus reducing PCI scope.

---

Considered both, but my understanding is Accept.js leaves the credit card input form on our server which increases PCI exposure.  I started with iFrame but it was unclear as to how to implement all the moving parts required for the resizing and communications etc. There's lots of bootstrap and other scripts/styles/pages in that sample app that are unrelated to and unnecessary for the iFrame payment functionality.  That's the problem with big multipurpose sample applications - trying to extract out just the parts you need from the parts you don't is very tedious and error prone.  It would be much clearer to see a separate implementation of each hosted form approach containing just the most minimal, bare-bones, unstyled markup and scripting code needed to implement it.

 Does such a thing exist anywhere?