Help with Accept Hosted

[MalcolmEnt1]

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>

[MalcolmEnt1]

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.

[Aaron]

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.

[MalcolmEnt1]

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.

[Aaron]

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.

[MalcolmEnt1]

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?

[MalcolmEnt1]

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.

[Aaron]

---

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

1. Customer tries transaction and it fails.
2. Customer tries transaction and it succeeds.
3. 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.

[MalcolmEnt1]

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.

[MalcolmEnt1]

Any update on this latest question?

Thx

Jerry

[Aaron]

Sorry, no. Still testing on my end.