cancel
Showing results for 
Search instead for 
Did you mean: 

Accept Hosted Payment Form billing field entries suddenly being ignored upon submit in sandbox

We recently noticed that billing info was suddenly being totally ignored on this hosted page because a regression test that had been working for many weeks suddenly began failing when the magic "Decline" zip code 46282 was apparently no longer being received, even though we are entering it into the UI.

 

I just verified that using the OLD Auth.Net iFrame, all entries are captured and works as expected.

 

Since there should be nothing we can do from outside the hosted form to cause it to not send the field values properly, can someone let us know what might be going on?

 

We are planning a major release in the next few weeks to move all of our Auth.Net customers to the NEW API, but that also hinges on seeing the hosted pages working properly in regression tests for some period before that time.

 

 

tbas55
Contributor
15 REPLIES 15

so here's XML as we are sending, actually a bit more succinct:

 

<?xml version="1.0" encoding="utf-16"?>
<getHostedPaymentPageRequest xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
	<merchantAuthentication>
		<name>2R9rTB6mKKvk</name>
		<transactionKey>****************</transactionKey>
	</merchantAuthentication>
	<transactionRequest>
		<transactionType>authOnlyTransaction</transactionType>
		<amount>7.06</amount>
		<order>
			<invoiceNumber>1</invoiceNumber>
			<description>olb_wireless_functional_2017-11-14_1a4d1d64-a22b-42ff-9489-c741249d1653</description>
		</order>
		<customer>
			<id>100106293</id>
		</customer>
		<userFields>
			<userField>
				<name>IDI_FieldName</name>
				<value>IDI_fieldValue</value>
			</userField>
		</userFields>
	</transactionRequest>
	<hostedPaymentSettings>
		<setting>
			<settingName>hostedPaymentReturnOptions</settingName>
			<settingValue>{"showReceipt": false,"url":"https://tbau.idi.com:8081/paymentgatewayapp/olb_wireless_functional/PaymentProcessor/Index","cancelUrl":"https://tbau.idi.com:8081/paymentgatewayapp/olb_wireless_functional/PaymentProcessor/IFrameNotifier?idiEnvironment_TxnID=olb_wireless_functional_2017-11-14_1a4d1d64-a22b-42ff-9489-c741249d1653"}</settingValue>
		</setting>
		<setting>
			<settingName>hostedPaymentOrderOptions</settingName>
			<settingValue>{"show": false}</settingValue>
		</setting>
		<setting>
			<settingName>hostedPaymentPaymentOptions</settingName>
			<settingValue>{"cardCodeRequired": true}</settingValue>
		</setting>
		<setting>
			<settingName>hostedPaymentIFrameCommunicatorUrl</settingName>
			<settingValue>{"url": "https://tbau.idi.com:8081/paymentgatewayapp/olb_wireless_functional/PaymentProcessor/IFrameNotifier?idiEnvironment_TxnID=olb_wireless_functional_2017-11-14_1a4d1d64-a22b-42ff-9489-c741249d1653"}</settingValue>
		</setting>
	</hostedPaymentSettings>
</getHostedPaymentPageRequest>

 

Hi @tbas55,

 

Thanks for the XML. That's really helpful!

 

Looking back at the previous code you posted, I'm guessing that's the output of our .Net SDK. That SDK will look like it's putting in things that it doesn't actually send down the wire. So, just outputting an object to JSON is a little confusing for me to look at. But, even that was enough for me to figure out what was happening once I tried a similar request on my end.

 

You're not specifying the hostedPaymentBillingAddressOptions setting (which would look like this:)

    {
        "settingName": "hostedPaymentBillingAddressOptions",
        "settingValue": "{\"show\": true}"
    },

 

 

In the Accept Hosted documentation, we document that setting as not being a required setting, and with a default of "true". And, just like you'd expect, if you don't send the setting, you do still see the form fields displayed. But, just like you've seen, when you fill them in nothing is passed on once you click the "Pay" button.

 

So, there's clearly a part of our code that treats the null value of that setting different than the explicit "true" value. I'll escalate this and see about getting it fixed.

 

To work around this, you have two options. The easiest is probably to explicitly send that hostedPaymentBillingAddressOptions setting set to true. Or, you can prepopulate the address information in the billTo element. If you do that, then the address fields are saved whether or not you have the hostedPaymentBillingAddressOptions setting present.

 

You mentioned that prepopulating never worked for you. I can't imagine why that would be the case, but we can look into that. First, try prepopulating now, and see if the same change that broke the earlier behavior for you might have changed something on that front.

 

This is a really good catch, and I'm very thankful you reported it. Thanks for being patient and jumping through the hoops necessary for us to figure it out.

Thanks for all the info and I will try setting hostedPaymentBillingAddressOptions although I want to re-iterate that we've never set that before and the zip entered on the UI was working OK until very recently.

 

I also must clarify that pre-populating also worked OK for us (as well as changing the zip via the UI).  I only removed the pre-populating to see if that made the "changing via the UI" start working again.

 

So because of all that and the description in the hostedPaymentBillingAddressOptions, I do not have a warm and fuzzy feeling about this, but I will give it a try.

 

If you have deployed code recently that began treating a null/default "true" value for "show" billing info slightly differently than explicitly setting the value "show: true", I suppose this could solve the problem.


@tbas55 wrote:

 

 

So because of all that and the description in the hostedPaymentBillingAddressOptions, I do not have a warm and fuzzy feeling about this, but I will give it a try.

 

If you have deployed code recently that began treating a null/default "true" value for "show" billing info slightly differently than explicitly setting the value "show: true", I suppose this could solve the problem.


Sorry if I wasn't clear in my earlier post, but there were indeed code changes for Accept Hosted that were released this month.

 

It's clear from your experience and my testing that part of the release included a regression that is treating the null value for that setting differently than it did before. Not sending the setting would have worked fine before. It doesn't now. That's a regression introduced in the most recent release that we're now aware of thanks to your help.

 

Explicitly sending the setting {"show": true} in hostedPaymentBillingAddressOptions will work around this bug until such time as it's fixed on our end.

Hi Aaron, thank you very much for both the additional clarification AND the workaround.

 

It appears to be working again and that should fix our regression tests going forward.

 

We appreciate all the help.

 

-tom

 

Trans IDInvoice NumberTrans StatusSubmit DateCustomerCardPayment MethodPayment Amount
600342480051
Captured/Pending Settlement
15-Nov-2017 09:54:41JENSVolley, BILL-BoyVXXXX1111
USD .06

Hi Aaron--

 

We were having the same problem, and this fix resolved it.  However, now we are experiencing a different issue.  After a customer creates a new payment profile, the next time they attempt to use that profile to pay through the Accept Hosted Payment Form, the following error message is displayed: "PaymentProfile cannot be sent with billing data."

 

This error does not occur if we don't explicitly add settings for hostedPaymentBillingAddressOptions; however, in that case, our payment profiles are created without billing information.

 

Here is a sample of the XML we are sending to create the token:

 

<?xml version="1.0" encoding="UTF-8"?>
<getHostedPaymentPageRequest xmlns="AnetApi/xml/v1/schema/AnetApiSchema.xsd">
  <merchantAuthentication>
    <name><![CDATA[XXXXX]]></name>
    <transactionKey>xxxx</transactionKey>
  </merchantAuthentication>
  <clientId><![CDATA[sdk-php-1.9.3]]></clientId>
  <refId><![CDATA[XXXXX]]></refId>
  <transactionRequest>
    <transactionType><![CDATA[authCaptureTransaction]]></transactionType>
    <amount>450</amount>
    <profile>
      <customerProfileId><![CDATA[XXXXX]]></customerProfileId>
    </profile>
  </transactionRequest>
  <hostedPaymentSettings>
    <setting>
      <settingName><![CDATA[hostedPaymentReturnOptions]]></settingName>
      <settingValue><![CDATA[{"showReceipt":false}]]></settingValue>
    </setting>
    <setting>
      <settingName><![CDATA[hostedPaymentPaymentOptions]]></settingName>
      <settingValue><![CDATA[{"cardCodeRequired":true,"showCreditCard":true,"showBankAccount":false}]]></settingValue>
    </setting>
    <setting>
      <settingName><![CDATA[hostedPaymentBillingAddressOptions]]></settingName>
      <settingValue><![CDATA[{"show":true,"required":false}]]></settingValue>
    </setting>
    <setting>
      <settingName><![CDATA[hostedPaymentOrderOptions]]></settingName>
      <settingValue><![CDATA[{"show":true,"merchantName":"XXXXX"}]]></settingValue>
    </setting>
    <setting>
      <settingName><![CDATA[hostedPaymentIFrameCommunicatorUrl]]></settingName>
      <settingValue><![CDATA[{"url":"https:\/\/dev.xxxxx.org\/acceptIFrameCommunicator.html"}]]></settingValue>
    </setting>
  </hostedPaymentSettings>
</getHostedPaymentPageRequest>

Thanks for any help you can provide!  Note that we do not have address information in scope for the customer at the time we are displaying the Accept Hosted Payment Form, so we aren't explicitly setting a BillTo when requesting the token, unlike others in this thread.