Accept Hosted receipt page styling

[dsandberg]

Are there any options for styling the Accept Hosted receipt page, outside of those that can be provided in the XML for the getHostedPaymentPageRequest API?  In testing payments and receipts in the Sandbox, I'm not happy with several aspects of the receipt layout, such as the overly large font size, and the fact that it contains grammatical errors like "Thank-you for your business!" (with a pointless dash in between the words "Thank" and "you").  Errors like that make it appear that the receipt was put together by people without a command of English, which not only would make us look bad, but could cause users to worry that they've been redirected to some sort of hacked payment website.

I've tried making changes to the receipt page fonts (at least) in the Account setup, but it appears those settings don't have anything to do with the Accept Hosted pages; the example pages associated with them also bear no resemblance to anything in Accept Hosted.

Please note that we cannot suppress the receipt since we are by necessity using full page redirects to Accept Hosted, rather than using an iframe or a popup.  We are ferventing hoping that suppressing the receipt page with full page redirects will become possible soon, as we would greatly prefer to not see that receipt page at all; but if users are going to be forced to see that receipt page, we would at least like to have it look professional, which the current one does not.

[robertgadach]

We are in the same boat. A number of our customers have voiced their disatisfaction over the receipt page text and necessity. Is there any way to change the wording on the page? or allow the redirect via full page instead of iframe/lightbox?

[lightwave365]

I completely agree. This is unacceptable to not be able to customize this receipt page that looks like it could be illegitimate from a foreign country that doesn't understand that "Thank you" does not have a hypen in the middle!

Do any of the settings in the merchant account even work for this Accept Hosted solution? It appears that those settings are only for the legacy and if so they should be correctly labeled as such or divded into a new settings page altogether.

[Renaissance]

I’m not going to disagree that I would like to be able to style the form. With that said, I am not fully sure that stying the form using the redirect method can be accomplished in any economical or logistically efficient way without defeating one major purpose of this integration, which is SAQ A scope PCI compliance. There are various interpretations of the key requirement that reads something like “all elements of the payment page(s) delivered to the customer’s browser must originate directly and only from a PCI DSS compliant third-party service provider”. The issue that this creates is that if you are allowed to insert custom css into the payment form, then that stying or code, whatever you want to call it , originates from you. So to make it work, authorize would have to validate every line of css that gets put in for any client. They wouldn’t have one form, they would have 100,000
Forms or 1 million that would need to be maintained everytime someone’s client gets a whim to make the font 2px larger. I think this is a recent nuance that has entered the mix in the past 2 to 3 years.
To offer some advice- one lets hope that some of the imperfections such as the hyphen you don’t like get addressed, but outside of that I would wager very high that my clients’ customers and all of your client’s customers prefer the security of their credit card data over having a pretty place to enter it that is by any margin less secure. So for your UI and customer experience issues I would suggest to emphasize that. I think it would be quite reassuring to tell them this rationale, both in person and on a disclosure on your website. You are following security protocols in the strictest possible manner for their maximum security.

And absolutely, when people are redirected it sends chills up their spine if, and this is a big if, they are not given a heads up that it’s about to happen. This definitely needs to be addressed and doing so is easy. On the final page hosted on your server, where the next step initiates the redirect, place a block of text informing the customer that they will briefly be redirected to your secure payment gateway authorize.net. I also recommend putting the merchant seal near this disclosure. They can click on that and learn who authorize.net is. Then when they are redirected and see the new url accept.authorize.net or however it is worded, they will know that they have been redirected to a safe environment.

[lightwave365]

While I do agree with your points they could have at least provided some rudimentary style options in the merchant account. Provide a color selector and you can choose whatever color you want without comprosmising security. There's only a few areas of hard-coded text on both pages. Provide an input for escaped text. This is 5-8 style settings at most. It's not rocket science.

Or just make the merchant account easier to work with so you know what's legacy and what is new.

[Renaissance]

I do understand what you’re saying. And 5 to 8 settings isn’t much, but if you multiply that by the number of people using this integration it becomes huge. Authorize would have to validate every line of CSS entered by anyone.

I did a little digging on this, and the interpretation of that rule is not as contested as I thought. It seems to be on almost complete consensus that any styling of payment pages outside of an iframe is outside of SAQ A, unless the CSS is verified by the solution provider. I found one company I had never heard of before that offered customization. They have a pdf about their process and how this is achieved. To make a long story short, they are tying themselves in knots and their process involves an automated security check of CSS each time a form is loaded. On this pdf they give the disclaimer “the validation process could take several minutes and result in payment cancellation.”

And I agree that in general, it is hard for CSS to compromise a site. But when you account for the fact that CSS has features such as url() and @imports it does become possible. To me this is one of those cases where everyone has to be punished to prevent the 1 out of 10,000 who would actually pull something shady. It is really a shame. I would like to add some custom styling. For my clients SAQ A-EQ is not an option, so I am thinking that in the future if we can get our own server for a decent rate I may do an iframe integration. Iframe is still SAQ A, but for our specific app requiremts 2,6, and 8 would go from N/A to requiring validation. I think right now we could affirm all of those as well, but I would still feel better on a dedicated environment where system admin didn’t have access.

[lightwave365]

No, that's not I mean. Don't let the users set the actual CSS. Have a bunch of presets.

Background Color - only can use from a color selector. They hardcode in the 'background-color' and use our selection as a token.

Text - Escape the text, use it as a token.

Font Size: Dropdown of 8 pt - 72 pt. They hardocode in the 'font-size' and use our selection as a token.

There are many ways to supply minimal styles, with little validation required, and give the developer something to work with for their customers. They'd rather just push their Accept.JS solution so they don't have to do any work. That's their 'solution' for all of this.

[BobCoder]

Create 1 normal style, like PayPal has even without customisation.
Put logo, your style etc.
Current one looks like unaccepted test task from a student who did not passed exam. Don't have $100 for middle indian coder to create 1 normal form?

[BobCoder]

Don't have money to style form? - Ask community to help. We would be glad to do it for you, but PLEASE do something with this ugly form.

[Suusyyz]

In any case, I think each of us can make our own time management efficient.