cancel
Showing results for 
Search instead for 
Did you mean: 

Help with Accept Hosted

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
Contributor
21 REPLIES 21

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.

 

Aaron
All Star

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.

 

 


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

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

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?

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

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

 

Thx

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.

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.