topic Re: Important Hosted Payment Form Discussion in Integration and Testing

Important Hosted Payment Form Discussion

RichardH — Tue, 08 Sep 2015 20:22:34 GMT

Use this thread to discuss changes to our Hosted Payment Form.

Richard

Re: Important Hosted Payment Form Discussion

jruser — Tue, 08 Sep 2015 21:55:20 GMT

1. What time is this change taking place?

2. Has this change already been made in test?

3. What will happen if someone passes in HTML, etc. after you make your change? Will the page still work?

It looks like this removes any option to make the hosted form blend with the rest of the site.

Re: Important Hosted Payment Form Discussion

RichardH — Tue, 08 Sep 2015 22:28:26 GMT

Hello @jruser

Yes, the change is already live in the sandbox.
Production will go live approximately 9pm Pacific
The payment form will continue to work, but we'll strip any custom html or MINT settings.

I would recommend reviewing KB A539 which provides more details on the change.

Richard

Re: Important Hosted Payment Form Discussion

karenb — Wed, 09 Sep 2015 07:21:14 GMT

We received the "Important Authorize.Net Notification" e-mail just a few minutes before 5 PM telling us that "support for HTML tags, JavaScript and CSS" on the hosted payment form, receipt page and email receipts "will be disabled later tonight." I then came here and discovered that "later tonight" meant 9 PM. 5 PM to 9 PM was a paltry FOUR HOURS advance notice at the close of the day before our payment interface with customers was reduced to gibberish. What kind of customer service is that? The e-mail says it's to "increase security", but whatever security issue there might be is nothing new and certainly could have been forewarned far earlier than just four hours before. Richard's post on this forum was at 1:22 PM but his brief sentence "Use this thread to discusss changes to our Hosted Payment Form" was worthlessly vague prior to receiving the e-mail.

Re: Important Hosted Payment Form Discussion

joatmon — Wed, 09 Sep 2015 13:21:26 GMT

This apparently disabled the captcha also, rendering my payment page non-functional. Less than 3 hours notice for me.

Re: Important Hosted Payment Form Discussion

joatmon — Wed, 09 Sep 2015 13:26:14 GMT

Merchant sign in seems to be down now also. This reminds me of a couple of years ago when you just arbitrarily killed relay response with no notice.

Re: Important Hosted Payment Form Discussion

afail — Wed, 09 Sep 2015 14:07:51 GMT

We use SIM and an IFRAME on our site for payment. We used the following CSS in the header:

html {overflow:hidden!important} to hide the scrollbar generated by the frame. Is there anyway to do this now?

Re: Important Hosted Payment Form Discussion

RichardH — Wed, 09 Sep 2015 16:12:34 GMT

Hello @afail

@afail wrote:

We use SIM and an IFRAME on our site for payment. We used the following CSS in the header:

html {overflow:hidden!important} to hide the scrollbar generated by the frame. Is there anyway to do this now?

Try applying overflow:hidden; to your iFrame.

Richard

Re: Important Hosted Payment Form Discussion

RichardH — Wed, 09 Sep 2015 16:15:05 GMT

Hello @joatmon

@joatmon wrote:

This apparently disabled the captcha also, rendering my payment page non-functional. Less than 3 hours notice for me.

We're not able to duplicate your issue. Are you testing in the sandbox or is this with your live production system?

Richard

Re: Important Hosted Payment Form Discussion

afail — Wed, 09 Sep 2015 16:16:27 GMT

Hi Richard,

Thanks for the reply. I actually need to override gateway/content/PaymentForm.css

which contains

html{
   overflow-y:scroll;
   overflow-x:auto;
}

I thought of using jquery on my side to do this, but I am prohibited since it would be cross site scripting.

Is there anyway we could have the the overflow-y set to auto instead of scroll?

Re: Important Hosted Payment Form Discussion

RaynorC1emen7 — Wed, 09 Sep 2015 16:32:58 GMT

Instead of using SIM with iframe, might be better off using DPM.

Re: Important Hosted Payment Form Discussion

mla — Wed, 09 Sep 2015 16:38:55 GMT

DPM appears to be completely broken right now?

Our users are no longer being redirected back to our site. They're receiving a static receipt on:

https://secure.authorize.net/gateway/transact.dll

Anyone else seeing this? Problem seemed to start exactly when the hosted payment changes went live last night.

Re: Important Hosted Payment Form Discussion

mla — Wed, 09 Sep 2015 16:48:46 GMT

As part of this change, are you also preventing HTML/JS/CSS in the DPM response page?

Because, uh, that isn't going work...

Re: Important Hosted Payment Form Discussion

penguinx64 — Wed, 09 Sep 2015 17:08:23 GMT

I have been seeing a problem starting 9/9/2015, possibly due to the latest update being rolled out as mentioned elsewhere, where the Relay Response URL set in the x_relay_url param for SIM transactions is getting transformed into all lowercase. Monitoring our http server logs, I see the Relay Response URL being requested from Authorize.net's server after the customer pays, but due to it being all lowercase, it is ending up in a 404.

This is causing a major problem for us as we keep track of our customer's payments and update the status according to the Relay Response. The effect of this is that no current payments are ending up getting marked as successful on our end.

Again, it looks like the Relay Response URL parameter contents for SIM transactions is getting translated to all lowercase, which is breaking processing on it.

Is this a bug, or the new intended behavior?

Re: Important Hosted Payment Form Discussion

mla — Wed, 09 Sep 2015 17:11:16 GMT

You guys need to roll back this change.

Re: Important Hosted Payment Form Discussion

RichardH — Wed, 09 Sep 2015 17:23:05 GMT

Hello @penguinx64

We are aware of the lower-case conversion issue and our product team is working on a solution.

I'd recommend subscribing to this topic so that you'll be alerted via email if there are updates. To subscribe, click Topic Options at the top of this thread and then select Subscribe. You'll then receive an email once anyone replies to your post.

Thanks,

Richard

Re: Important Hosted Payment Form Discussion

ianlenora — Wed, 09 Sep 2015 17:24:50 GMT

This is happening to our integration. We are not getting back a response and are stuck on a static page. This has taken down our ability to effectively process payments. This change MUST be rolled back or we will take direct impact on the revenue of our business.

We use the transact.dll, and we noticed at about midnight last night that we were not receiving any responses from authorize.net.

I believe we are using AIM however.

Re: Important Hosted Payment Form Discussion

afail — Wed, 09 Sep 2015 17:47:48 GMT

Our company has just invested months of time swiching all of our apps to SIM. For us to redo this all because of one line in a stylesheet seems drastic

Is there any reason the overflow-y can't be set to auto instead of scroll?

Re: Important Hosted Payment Form Discussion

jimr — Wed, 09 Sep 2015 17:54:30 GMT

We are seeing the exact same problem.

Re: Important Hosted Payment Form Discussion

ianlenora — Wed, 09 Sep 2015 18:06:08 GMT

We were able to find a work around.

Our relay URL is listed as 'site.com/paymentRelay' which is camel case.

Authorize.net is posting back to 'site.com/paymentrelay' which is all lower case, this causes a 404 in our system.

We changed our code to map to the url, 'site.com/paymentrelay' all lower case and confirmed that it worked.

To others facing the same issue, you could also try using an apache rewrite rule to change incoming requests from the all lower case incoming request (like '/paymentrelay' ), to the case you need (/paymetRelay).