topic Re: Help with Accept Hosted in Integration and Testing

Help with Accept Hosted

MalcolmEnt1 — Fri, 20 Jan 2017 18:12:26 GMT

After taking a breather once the recurring CIM API was implemented and working, I'm now readdressing the SIM replacement GetHostedPaymentPage.

As with the other APIs, I started with the sample Java class for the specific API. I added the options I needed as specified in the API doc. But yet again, I'm getting that extremely 'useful' error message: "An error occurred". This time it gives me an E00001 which is similarly useful.

I finally started removing options here and there and realized that i doesn't like my IFrameCommunicator option. If I remove that option, the API succeeds. If I add it back in, it fails. I've tried to verify spelling, etc. I can't see anything obvious. This is the same IFrameCommunicator that works in the CIM APIs. Here is the log dump of the failing API. Please let me know what I have wrong in this. (BTW... I'm using the actual production site now with my real apiLogin, not the sandbox).

2017-01-19 19:04:37 DEBUG wire:64 - >> "<?xml version="1.0" encoding="UTF-8" standalone="yes"?>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "<getHostedPaymentPageRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "    <merchantAuthentication>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "        <name>--------</name>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "        <transactionKey>----------------</transactionKey>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "    </merchantAuthentication>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "    <clientId>sdk-java-1.9.2</clientId>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "    <transactionRequest>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "        <transactionType>authCaptureTransaction</transactionType>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "        <amount>1.00</amount>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "    </transactionRequest>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "    <hostedPaymentSettings>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "        <setting>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "            <settingName>hostedPaymentButtonOptions</settingName>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "            <settingValue>{"text": "Pay"}</settingValue>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "        </setting>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "        <setting>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "            <settingName>hostedPaymentOrderOptions</settingName>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "            <settingValue>{"show": true}</settingValue>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "        </setting>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "        <setting>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "            <settingName>hostedPaymentShippingAddressOptions</settingName>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "            <settingValue>{"show": false, "required": false}</settingValue>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "        </setting>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "        <setting>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "            <settingName>hostedPaymentIFrameCommunicatorUrl</settingName>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "            <settingValue>https://handlemyleads.com/payment/jsp/guest/iCommunicator.jsp</settingValue>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "        </setting>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "        <setting>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "            <settingName>hostedPaymentReturnOptions</settingName>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "            <settingValue>{"showReceipt" : false, "url":"https://handlemyleads.com/jsp/guest/payReceipt.jsp"}</settingValue>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "        </setting>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "    </hostedPaymentSettings>[\n]"
2017-01-19 19:04:37 DEBUG wire:64 - >> "</getHostedPaymentPageRequest>[\n]"
1a dataSourceName: jdbc/cis
1a dataSourceName: jdbc/cis
2017-01-19 19:04:37 DEBUG wire:78 - << "HTTP/1.1 200 OK[EOL]"
2017-01-19 19:04:37 DEBUG wire:78 - << "Cache-Control: private[EOL]"
2017-01-19 19:04:37 DEBUG wire:78 - << "Content-Type: application/xml; charset=utf-8[EOL]"
2017-01-19 19:04:37 DEBUG wire:78 - << "Server: Microsoft-IIS/7.5[EOL]"
2017-01-19 19:04:37 DEBUG wire:78 - << "Access-Control-Allow-Origin: *[EOL]"
2017-01-19 19:04:37 DEBUG wire:78 - << "Access-Control-Allow-Methods: PUT,OPTIONS,POST,GET[EOL]"
2017-01-19 19:04:37 DEBUG wire:78 - << "Access-Control-Allow-Headers: x-requested-with,cache-control,content-type,origin,method,SOAPAction[EOL]"
2017-01-19 19:04:37 DEBUG wire:78 - << "X-AspNet-Version: 4.0.30319[EOL]"
2017-01-19 19:04:37 DEBUG wire:78 - << "X-Powered-By: ASP.NET[EOL]"
2017-01-19 19:04:37 DEBUG wire:78 - << "X-Cnection: close[EOL]"
2017-01-19 19:04:37 DEBUG wire:78 - << "Content-Length: 405[EOL]"
2017-01-19 19:04:37 DEBUG wire:78 - << "Date: Fri, 20 Jan 2017 01:04:37 GMT[EOL]"
2017-01-19 19:04:37 DEBUG wire:78 - << "Connection: keep-alive[EOL]"
2017-01-19 19:04:37 DEBUG wire:78 - << "[EOL]"
2017-01-19 19:04:37 DEBUG DefaultClientConnection:229 - Receiving response: HTTP/1.1 200 OK
2017-01-19 19:04:37 DEBUG headers:232 - << HTTP/1.1 200 OK
2017-01-19 19:04:37 DEBUG headers:235 - << Cache-Control: private
2017-01-19 19:04:37 DEBUG headers:235 - << Content-Type: application/xml; charset=utf-8
2017-01-19 19:04:37 DEBUG headers:235 - << Server: Microsoft-IIS/7.5
2017-01-19 19:04:37 DEBUG headers:235 - << Access-Control-Allow-Origin: *
2017-01-19 19:04:37 DEBUG headers:235 - << Access-Control-Allow-Methods: PUT,OPTIONS,POST,GET
2017-01-19 19:04:37 DEBUG headers:235 - << Access-Control-Allow-Headers: x-requested-with,cache-control,content-type,origin,method,SOAPAction
2017-01-19 19:04:37 DEBUG headers:235 - << X-AspNet-Version: 4.0.30319
2017-01-19 19:04:37 DEBUG headers:235 - << X-Powered-By: ASP.NET
2017-01-19 19:04:37 DEBUG headers:235 - << X-Cnection: close
2017-01-19 19:04:37 DEBUG headers:235 - << Content-Length: 405
2017-01-19 19:04:37 DEBUG headers:235 - << Date: Fri, 20 Jan 2017 01:04:37 GMT
2017-01-19 19:04:37 DEBUG headers:235 - << Connection: keep-alive
2017-01-19 19:04:37 DEBUG DefaultHttpClient:540 - Connection can be kept alive indefinitely
2017-01-19 19:04:37 DEBUG wire:78 - << "[0xef][0xbb][0xbf]<"
2017-01-19 19:04:37 DEBUG wire:78 - << "?xml version="1.0" encoding="utf-8"?><getHostedPaymentPageResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><messages><resultCode>Error</resultCode><message><code>E00001</code><text>An error occurred during processing. Please try again.</text></message></messages></getHostedPaymentPageResponse>"
2017-01-19 19:04:37 DEBUG SingleClientConnManager:250 - Releasing connection org.apache.http.impl.conn.SingleClientConnManager$ConnAdapter@6f2348
2017-01-19 19:04:37 DEBUG HttpCallTask:14 - Raw Response: '<?xml version="1.0" encoding="utf-8"?><getHostedPaymentPageResponse xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd"><messages><resultCode>Error</resultCode><message><code>E00001</code><text>An error occurred during processing. Please try again.</text></message></messages></getHostedPaymentPageResponse>

Re: Help with Accept Hosted

Aaron — Fri, 20 Jan 2017 18:30:14 GMT

Hi Jerry,

Thankfully, this should be an easy one. (But, we'll see...)

The format for all of the Hosted Form Parameter Settings is to send the values into our API as JSON objects. I don't have the Java SDK up in front of me right now, so I don't know if you're just setting properties and it's building the JSON appropriately, or if you're passing whole JSON objects. If it's building the JSON for you, you'd expect that if you pass it a URL, it would format that URL appropriately. However, from your logs, it's definitely not doing that. What it should be sending is something like this:

<settingName>hostedPaymentIFrameCommunicatorUrl</settingName>
<settingValue>{"url": "https://handlemyleads.com/payment/jsp/guest/iCommunicator.jsp"}</settingValue>

Could you pass the whole JSON object ( {"url": "https://handlemyleads.com/payment/jsp/guest/iCommunicator.jsp"} ) and see if that fixes it? If so, we'll move on to figuring out if that's a problem with the SDK or just the effect of our (poor but rapidly improving) documentation.

Re: Help with Accept Hosted

MalcolmEnt1 — Fri, 20 Jan 2017 18:54:54 GMT

That was it.... I can't believe I missed that. Thanks so much.

One thing I can beg for, though.... How about an error message that says "option value is not a JSON object"? (Please?? for people like me that are still clueless.... :-) )

Thanks again for all of your help.

Re: Help with Accept Hosted

Aaron — Fri, 20 Jan 2017 22:34:48 GMT

@MalcolmEnt1 wrote:
One thing I can beg for, though.... How about an error message that says "option value is not a JSON object"? (Please?? for people like me that are still clueless.... :-) )

Added to the list!

Re: Help with Accept Hosted

MalcolmEnt1 — Fri, 20 Jan 2017 23:30:13 GMT

One more question that is a bit more high level philosophy. What is the recommended way on the Accept Hosted page for being notified about success/failure/authCode, etc for the transaction itself? It appears that the relay response 'backdoor' callback I had in SIM is no longer in use on this. I guess one option is to provide my own payReceipt and cancelText urls. But I can't find any documentation on what, if any, parameters, such as authCode, are passed on the request for those URLs. And it doesn't appear that anything other than 'continue' is passed to the IFrameCommunicator unless I'm missing something there as well. Somehow I need to know if the payment went through so I can log the payment on the user's account.

What is the 'right' way to be notified of success/failure of the payment?

Thanks.

Jerry

Re: Help with Accept Hosted

MalcolmEnt1 — Sat, 21 Jan 2017 01:20:48 GMT

One more question.... What is the equivalent of SIM's TEST_MODE? I see a couple of profile APIs that have a ValidationMode where TEST_MODE is one of the options. But it is definitely not pervasive. I don't want to have to toggle back to the sandbox just to test something now that I'm in production mode since it won't have the same customer profiles, etc that I need. What is the recommended way to do a 'TEST_MODE' transaction both in CIM and in the AcceptHosted page? And does it basically work the same as SIM's test mode?

Re: Help with Accept Hosted

RichardH — Sat, 21 Jan 2017 02:40:11 GMT

Hello @MalcolmEnt1

Two parts to the answer.

First, when creating customer profiles, you can set validationMode to liveMode and the gateway will perform $0 transaction to validate the card is good otherwise a customer profile is not created. If you set validationMode to test mode, the gateway will only perform some basic calculations to ensure the card number is valid.

But don't confuse this with setting your gateway to test mode or including test mode as true in the request. When you do this, you instruct the gateway to only validate credentials. No transaction is attempted and there is nothing saved at the gateway. We never recommend using test mode.

The sandbox a test system that is separate from production.

Richard

RIchard

Re: Help with Accept Hosted

MalcolmEnt1 — Mon, 23 Jan 2017 00:27:37 GMT

Thanks for the test mode explanation. Any help on the previous question about how to know whether the accepHosted transaction was approved?

Thx

Re: Help with Accept Hosted

Aaron — Mon, 23 Jan 2017 17:31:24 GMT

In a nutshell:

1. If/when you pass a URL for a continue or cancel button, the form creates those buttons as just links. When the customer clicks on those in the browser, that just creates a GET request to that URL on your site. No parameters are passed to you application through that process, unless you specifically embedded data in the continue or cancel URLs that you passed to us when you requested the token. For example, if you sent urls of "http://mysite.com/session1234/success" and "http://mysite.com/session1234/cancel", that would provide your server with a session ID and the disposition of the transaction.

2. When you host the form in an IFrame, you have the option of passing a URL to a page with a script in it. The form will embed that "IFrame Communicator" page inside the form so that it can send stuff to it. Then, since your IFrame Communicator page would be hosted on the same domain as your page that called the form in the first place, your Communicator page can send data back to that "grandparent" page about the results of the transaction, allowing that grandparent page to take action. All of this is necessary to get around browser limitations on cross-site scripting.

What the form is sending to the Communicator page is not documented in the Accept Hosted documentation yet, but we're trying to get it in there ASAP.

Re: Help with Accept Hosted

Aaron — Mon, 23 Jan 2017 18:08:31 GMT

An excerpt from a newer draft of the documentation:

Displaying the Form

The hosted form is designed so that you have the freedom to integrate it into your site in almost any way. You can embed it as an IFrame into your existing page. You can use a light-box layout, in which the form pops up in front of the rest of your site, but not in a new window. Finally, you can use the full window by redirecting the browser to our form URL. Whatever method is used, the form is called by passing the received token to our system in an HTTP form POST. The only form field that must be included in that form is an input field named "token". Insert the complete token that you've received back from getHostedPaymentPageRequest as the value of that field.

FORM POST URLS:

Sandbox: https://test.authorize.net/payment/payment

Production: https://accept.authorize.net/payment/payment

Our sample application on GitHub shows examples of how to present the form in different modes, including examples of how to open the hosted form in a lightbox.

Transaction Response

The payment form will automatically validate the input provided by the customer and provide the customer the opportunity to change it before submitting the payment for processing. In the event of a payment decline or error, the customer remains on the form with the opportunity to revise their input and try again.

If the transaction processing is successful, the customer is presented with an optional receipt page, and a Continue button which returns control to the merchant’s site. Additionally, the customer may optionally be presented with a Cancel button to return to the merchant’s site before the transaction is processed.

If the customer returns to the merchant’s site, the information passed to the merchant depends on the method used to integrate the form.

IFRAME/LIGHTBOX METHOD

For security reasons, web browsers do not allow JavaScript communication between two pages that are hosted on different domains, even if one is embedded within another. Therefore, our hosted form cannot directly provide information to the page that encapsulates it.

However, it is beneficial to provide some small amount of information indirectly through a third page. You can embed our hosted form in an IFrame, which enables us to embed your IFrameCommunicator page inside our hosted form. This channel of communication allows us to send messages to your IFrameCommunicator page. As long as your communicator page is hosted on the same domain as your main page, it can communicate with your main page.

This channel of communication is used to pass a few basic messages to a listener script running on your page that calls the form:

Ideal height and width of the window - enables you to resize the frame and avoid any scrollbars from appearing.
Request Succeeded - returned when the transaction is completed at Authorize.Net. Transaction response parameters (such as transaction ID) are returned.
Request Cancelled - returned when the merchant cancels the hosted form.

Note: If you plan to use IFrame, you must send the hostedPaymentIFrameCommunicatorUrl parameter in the getHostedPaymentPageRequestmethod.

Note: You must use HTTPS when using IFrameCommunicator.

REDIRECT METHOD

When not using an IFrame, the continue/return URL and cancel URL create buttons that when clicked cause the browser to perform a simple GET request to that URL. No other information about the transaction is provided directly. When using the redirect method, an Authorize.Net generated receipt will be shown and cannot be disabled.

ALL METHODS

With any of the form integration methods, information specific to the customer can be passed back to the merchant’s server by embedding it in the continue/return URL or the cancel URL. By embedding information into the URL that is provided in the token request, the merchant server can identify the specific customer and transaction that has been processed when the customer returns. Any name-value pairs embedded in the URL should be URL-encoded to ensure correct processing in the form request.

Additionally, developers can register for Webhooks to receive real-time notifications when transactions are either declined or approved. Using Webhooks notifications, a developer would still be notified if a transaction was processed but the customer closed the browser before following the return URL.

Re: Help with Accept Hosted

MalcolmEnt1 — Mon, 23 Jan 2017 23:37:25 GMT

Thanks, Aaron,

I am receiving a message in my popup javascript via the IFrameCommunicator when a transaction is approved. Turns out that it's a set of JSON objects:

action=transactResponse&response={"accountType":"MasterCard","accountNumber":"XXXX4010","transId":"xxxxxx","authorization":"xxxxx","billTo":{"firstName":"Jerry","lastName":"Malcolm","address":"13016 xxxxxxxxx","city":"Austin","state":"Tx","zip":"787xx"},"shipTo":{},"totalAmount":"1.00","dateTime":"1/23/2017 7:33:34 PM"}

Up to now, I have not been working with JSON other than the trivial coding of settings in some of the requests. I know I can go find a JSON package that likely will parse this response into XML or give me an easy way to pull values out of it. But being the lazy person I am... I suspect there might be some utility class already available somewhere in the Authnet API code that can process this JSON string and make it easier to retrieve the data. Or am I on my own to download a JSON parser? Not complaining... but with all of the helper code provided to send/receive API requests, it just seems odd that there would not be anything to assist with this response (??).

Thanks.

Re: Help with Accept Hosted

Aaron — Mon, 23 Jan 2017 23:51:09 GMT

If you're looking to process it within the script, JavaScript has a built-in JSON.parse() function to convert the string into an object. If you're passing the whole JSON object back to the application on the server and trying to get the application to deal with it, then you'll need a parser library in your application.

Might be easiest to let JavaScript turn it into an object, and then deliver that object to your application in whatever format your application wants.

Re: Help with Accept Hosted

MalcolmEnt1 — Tue, 24 Jan 2017 00:06:06 GMT

I'll just let javascript handle it for me and pass the extracted parms to the server.

I understand that the docs for this are in progress. Are there any docs yet that define all the possibilities I might get on this response? e.g. if the card is expired, what fields is the response object going to contain? Since I'm kinda 'reverse engineering' from the one 'approved' transaction I received, I'm afraid there are going to be some totally different response objects come in that I want to be sure to handle as well.

Thanks.

Re: Help with Accept Hosted

Aaron — Tue, 24 Jan 2017 00:10:17 GMT

Nothing yet, I'm afraid. It's extremely high priority for me, though, so I hope to have something sooner rather than later.

In the meantime, feel free to use our testing guide to simulate whatever responses you want to know about and see how the responses differ. I hope they don't differ in format, only in value, but if you see anything funky, please let me know.

Re: Help with Accept Hosted

MalcolmEnt1 — Tue, 24 Jan 2017 01:15:04 GMT

It's going to be difficult for me to go back to the sandbox. I've only got one instance running, and it's now live with the CIM functionality. I can't take it down and move back to the sandbox. I'd have to create a completely separate parallel instance to test in the sandbox. Therefore, I think I'll just let it ride for a bit and handle 'accepted' transactions and just fail on anything that doesn't look like it was accepted. I'll clean it up once your docs are all available.

That does bring up one additional question... In every API in CIM I have the standard line of code:

if (response.getMessages().getResultCode() == MessageTypeEnum.OK)

There is not a 'messages' section in the JSON response block I'm getting on the acceptHosted and therefore no resultCode. I guess I can possibly just look at one of the other fields in the response, such as "authorization", and somehow determine from that whether it was accepted or rejected. But without a little guidance, I'm a bit nervous. Is there some field in what I'm getting that I can safely rely on to always tell me "OK" vs. "ERROR"? And if so, what value do I look for to determine the transaction result?

Re: Help with Accept Hosted

MalcolmEnt1 — Tue, 24 Jan 2017 01:24:28 GMT

Aaron,

I know you are thinking 'when will this guy go away????....' :-)

It just occurred to me after sending the last post that I might be overthinking this. Is it the case that I will NEVER get this message unless the transaction is approved? i.e. you just put any error messages up in the IFrame window until/unless the transaction is approved and then notify me, and therefore I simply don't need to handle error messages, etc?

If I'm wrong here and I can still get error messages as well via this IFrameCommunicator process, then ignore above, and the question in my previous post is still pending.

Re: Help with Accept Hosted

Aaron — Tue, 24 Jan 2017 02:18:13 GMT

@MalcolmEnt1 wrote:

Is it the case that I will NEVER get this message unless the transaction is approved? i.e. you just put any error messages up in the IFrame window until/unless the transaction is approved and then notify me, and therefore I simply don't need to handle error messages, etc?

This is my current assumption. There's really three scenarios:

Customer tries transaction and it fails.
Customer tries transaction and it succeeds.
Customer cancels transaction.

Transaction failures are handled in the form, giving the customer the ability to correct and retry without having to return to the merchant.

Transaction success... well, you've seen what happens in that case.

Customer cancels - If the customer clicks on the cancel button and you have a cancel URL, you've got some notification there. If the customer just closes the browser window and walks away, well, there's very little we can do about that.

Given all this, I'm guessing what you're getting from the script is the only thing you get since it's the only scenario where that kind of notification is really needed. I still plan to fully test it myself to be sure, though.

@MalcolmEnt1 wrote:

I know you are thinking 'when will this guy go away????....' :-)

Ha ha! No worries!

Again, it's a great help to have people point out where things are confusing so that we can improve it for anyone else.

Re: Help with Accept Hosted

MalcolmEnt1 — Tue, 24 Jan 2017 21:45:38 GMT

I'm not getting any iFrameCommunicator messages if Cancel is pressed on the AcceptHosted popup. So I have no way to close the popup window.

I noticed that I only get the accept transaction message we were discussing yesterday if I set "showReceipt" setting to 'false'. So I suspect there is some other flag I need to turn on or off to start receiving the cancel message (??)

I'm getting a resize message. So I know the iFrameCommunicator is functioning. However, when the window resizes, the buttons at the bottom are half cut off. That's not as urgent an issue as the cancel message (or lack thereof) issue.

Thanks.

Re: Help with Accept Hosted

MalcolmEnt1 — Wed, 25 Jan 2017 20:22:09 GMT

Any update on this latest question?

Thx

Jerry

Re: Help with Accept Hosted

Aaron — Wed, 25 Jan 2017 20:52:51 GMT

Sorry, no. Still testing on my end.