topic Re: Accept Hosted form return options in Integration and Testing

Accept Hosted form return options

wp — Fri, 06 Jan 2017 19:20:08 GMT

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?

Re: Accept Hosted form return options

Aaron — Fri, 06 Jan 2017 21:09:34 GMT

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.

Re: Accept Hosted form return options

wp — Fri, 06 Jan 2017 21:28:42 GMT

@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?

Re: Accept Hosted form return options

Aaron — Fri, 06 Jan 2017 22:40:05 GMT

@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.

Re: Accept Hosted form return options

wp — Sat, 07 Jan 2017 15:38:49 GMT

@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.

Re: Accept Hosted form return options

wp — Sun, 08 Jan 2017 19:02:40 GMT

@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.

Re: Accept Hosted form return options

vedranmimic — Tue, 10 Jan 2017 13:59:12 GMT

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

Re: Accept Hosted form return options

wp — Tue, 10 Jan 2017 14:25:05 GMT

@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?

Re: Accept Hosted form return options

Aaron — Tue, 10 Jan 2017 17:38:45 GMT

@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:

The token request fails if the account doesn't already have a "Signature Key" created in the merchant interface.
Following any URL from the payment form is just a GET request, not a POST with relevant data.
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).
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.
Webhooks doesn't let you register a URL with query strings embedded in it.
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!

Re: Accept Hosted form return options

wp — Tue, 10 Jan 2017 19:01:29 GMT

@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?

Re: Accept Hosted form return options

Aaron — Tue, 10 Jan 2017 19:57:22 GMT

@wp wrote:
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?

At some point there will be more info passed as part of the redirect scenario. At this point, I can't tell you what that would be or how that would work. At the minimum, it's likely that the cancel and continue buttons could be configured to do a form POST, but whether there would be a separate notification fired, I don't know. A Webhook won't be guaranteed to fire within milliseconds, but then again, an Accept Hosted specific notification that's out of band probably couldn't be guaranteed to fire within milliseconds either.

Let me make it clear in case it wasn't before. A custom receipt page is currently not a supported scenario when presenting the payment form as a simple page redirect. The documentation isn't clear there, but will be clarified soon. We'd love to be able to offer that functionality, though, and providing transaction confirmation and details back to your server is obviously key to that process.

In the scenario of a custom receipt page on a redirected form, a hypothetical POST issued by the continue or cancel button could provide enough info to build the receipt page or other confirmation page, and the Webhooks notification could provide the notification in the event of the customer abandoning after the transaction. So for most scenarios (that aren't yours) an Accept Hosted specific out of band notification wouldn't really provide anything that Webhooks doesn't already provide.

@wp wrote:
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.

Yeah, that's more tricky. First off, do you mean you don't have the authentication details at all? Or that you just don't know which merchant you're receiving the Webhook for? I'm assuming that you have the actual credentials since you'd be using them in the token request. In that case, the Webhook notification itself includes a "webhookId", which would be specific to the merchant that requested it. Using that webhookId and matching that to the ID received when the Webhook was created, you'd know for which merchant you'd need to query the transaction details.

If you don't have the credentials at all, then I'm not sure what an appropriate workaround would be. I'd need to know more about how merchants are using your app to be able to think of ideas.

@wp wrote:
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?

The possibility of any changes to the operation of Webhooks in the next couple of days is zero, unfortunately. Hopefully that webhooksId provides a workaround, though. Another possible workaround is to register Webhooks on multiple URLs. Even though you can't register a query string, you could still register multiple Webhooks with URLs like http://myserver.com/webhooklistener/merchant1, http://myserver.com/webhooklistener/merchant2, etc.

@wp wrote:
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?

I don't have a clear example like that here, but it would be great if some interested observer were to chime in with sample code for how they did it. I'll ask around, and if I can find anything, I'll share whatever I can find.

Accept.js works with a form that is created by your server, and served to the browser from your server, but the payment information from the form is never submitted back to your server, so it's not in the same scope as if you were receiving the payment data. However, since it is depending on the operation of a form that you have control over, it is in a different scope for PCI compliance than a hosted form like Accept Hosted.

Re: Accept Hosted form return options

wp — Tue, 10 Jan 2017 20:25:59 GMT

@Aaron Did not realize about the webhook ID being static, I assumed it was the ID of that particular notification and would change each time. That should definitely do the trick then. My app creates the webhook as part of the initial setup of the account so it can easily store the ID and later use it to link back to the merchant. Sounds like exactly what I need, thanks for the tip.

And yes, please do have the docs clarified about the redirect option not supporting custom receipts....I don't recall seeing that anywhere.

And if/when you have some simpler iframe code, I'd still love to see that - especially knowing now that there is no custom receipt option otherwise.

Re: Accept Hosted form return options

genben2016 — Tue, 10 Jan 2017 23:13:02 GMT

@Aaron can you please give a quick example on how the accept host form will notice the hostedPaymentIFrameCommunicatorUrl when a payment transaction approved or failed?

there is no clear documentation clearly describe this topic: it seems the URL varialbe is being used to notice, like src="iCommunicator.html#action=resizeWindow&width=1887&height=690", so what would be the URL like when payment success or fail?

Re: Accept Hosted form return options

JD — Sat, 29 Apr 2017 21:26:10 GMT

Hi guys

I had similar issues today and after reading this thread battled through the mess of code in the example.

Here is a guide to what I did to get the iFrame working without the receipt page, hope it helps someone: http://stackoverflow.com/questions/43700622/how-to-implement-authorize-net-hosted-payments-iframe-laravel/43700623#43700623

Re: Accept Hosted form return options

innosoft2fusion — Tue, 13 Jun 2017 22:15:39 GMT

This thread outlines every single frustration that I've had with this integration so far. The IFrame aspect is a huge miss in my mind and making it so diffucult to do a custom receipt page with the redirect method is a HUGE downside of this integration. Coming from SIM(which has it's own issues) I would say you definitely need to improve documentation with how much the methods have changed for this integration.

Re: Accept Hosted form return options

Aaron — Tue, 13 Jun 2017 22:28:37 GMT

Hi @innosoft2fusion,

Thanks for the feedback. Although I don't have any specific enhancements or changes I can report today, rest assured that this feedback doesn't go unnoticed.

Re: Accept Hosted form return options

innosoft2fusion — Mon, 19 Jun 2017 18:19:15 GMT

Thanks, no ability for custom receipts is a deal breaker for our clients.

Re: Accept Hosted form return options

denlopez88 — Fri, 23 Jun 2017 17:33:19 GMT

Hi guys, another question regarding Accept Hosted form using the full windows feature, i want to be able to add an invoice number to the transactionRequest but although i see it in the documentation as a possible parameter under order i get an error every time I added as follows:

{
    "getHostedPaymentPageRequest": {
        "merchantAuthentication": {
            "name": "3fHh95RmE",
            "transactionKey": "3p5mZ7fBN46F7Jt6"
        },
        "transactionRequest": {
            "transactionType": "authCaptureTransaction",
            "amount": "20.00",
            "customer": {
                "email": "bmcmanus@mail.com"
            },
            "order": {
                "invoiceNumber": "5554446655564"
            },
            "billTo": {
                "firstName": "Ellen",
                "lastName": "Johnson",
                "company": "Souveniropolis",
                "address": "14 Main Street",
                "city": "Pecan Springs",
                "state": "TX",
                "zip": "44628",
                "country": "USA"
            }
        },
        "hostedPaymentSettings": {
            "setting": [{
                "settingName": "hostedPaymentBillingAddressOptions",
                "settingValue": "{\"show\": true, \"required\":true}"
            }, {
                "settingName": "hostedPaymentButtonOptions",
                "settingValue": "{\"text\": \"Pay\"}"
            }, {
                "settingName": "hostedPaymentCustomerOptions",
                "settingValue": "{\"showEmail\":true,\"requiredEmail\":true}"
            }, {
                "settingName": "hostedPaymentPaymentOptions",
                "settingValue": "{\"cardCodeRequired\":true}"
            }, {
                "settingName": "hostedPaymentReturnOptions",
                "settingValue": "{\"url\":\"https://www.mysite.com/continue\",\"urlText\":\"Continue\",\"cancelUrl\":\"https://mysite.com/cancel\",\"cancelUrlText\":\"Cancel\"}"
            }, {
                "settingName": "hostedPaymentSecurityOptions",
                "settingValue": "{\"captcha\": false}"
            }, {
                "settingName": "hostedPaymentShippingAddressOptions",
                "settingValue": "{\"show\":false,\"required\":true}"
            }, {
                "settingName": "hostedPaymentStyleOptions",
                "settingValue": "{\"bgColor\": \"EE00EE\"}"
            }]
        }
    }
}

the error is pretty clear:

{
    "messages": {
        "resultCode": "Error",
        "message": [
            {
                "code": "E00003",
                "text": "The element 'transactionRequest' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd' has invalid child element 'order' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'. List of possible elements expected: 'billTo, shipTo, customerIP, cardholderAuthentication, retail, employeeId, transactionSettings, userFields, surcharge, merchantDescriptor, subMerchant' in namespace 'AnetApi/xml/v1/schema/AnetApiSchema.xsd'."
            }
        ]
    }
}

In the reference guide under Get an Accept Payment Page:

order	Contains information about the order. 
invoiceNumber	Merchant-defined invoice number associated with the order. 
description	Description of the item purchased.

Any help would be most appreciated

Re: Accept Hosted form return options

Aaron — Fri, 23 Jun 2017 18:39:58 GMT

Hi @denlopez88,

This should work if you just get the elements in the right order. Despite what you might think from seeing that we have a JSON interface, not everything about it works the same way as other JSON things you might have dealt with. One artifiact of the way it's implemented on our end is that order of elements matters.

The order in the API reference should be the correct one, so if you follow that and it still doesn't work, let us know.

Re: Accept Hosted form return options

denlopez88 — Fri, 23 Jun 2017 18:51:57 GMT

Hi Aaron,

Yes you are completely right, the order of the parameters do matter although from the reference guide there is no way of infering that. This is my code edited..

"transactionRequest": {
                            "transactionType": "authCaptureTransaction",
                            "amount": "20.00",
                             "order": {
                                "invoiceNumber": "5554446655564"
                            },
                            "customer": {
                                "email": "bmcmanus@mail.com"
                            },
                            "billTo": {
                                "firstName": "Ellen",
                                "lastName": "Johnson",
                                "company": "Souveniropolis",
                                "address": "14 Main Street",
                                "city": "Pecan Springs",
                                "state": "TX",
                                "zip": "44628",
                                "country": "USA"
                            }
                        },

Thanks!!!