cancel
Showing results for 
Search instead for 
Did you mean: 

Accept Hosted form return options

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?

 

 

wp
Contributor
26 REPLIES 26

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

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

wp
Contributor

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

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

JD
Member

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.

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.

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

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

denlopez88
Member

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.

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!!!