Integration and Testing

[redcart]

Hello,

We've been using the SIM integration with hosted payment form for years and were able to use our own logo on the hosted payment form.  Now that we're migrating from the old SIM integration to the new Accept Hosted (redirect method) payment form, I don't see any way to add a custom logo to the top of the form.  Is this feature available with Accept Hosted like it was with SIM?  If so, how can we add the logo?

If it's not available, this seems like a downgrade instead of an upgrade and will likely result in many unhappy clients on our end.  We have thousands of clients that use this integration with our shopping cart system.  Please advise.  

[Renaissance]

@redcart 

Not available. Only option is to use an iframe. I have decided that for my current project I am going to implement an iframe.  You have a mass market application, and most likely this involves some CMS features where  your customer can change the appearance.  Not sure how this will affect your implementation or if it is possible for you. If you do use it maybe we can figure out some things together. I'm having some quirky issues at the moment. 

[redcart]

Thanks for the reply!  That's a little disappointing.  I assumed that this "new and improved" integration would be exactly that. You're correct that our clients are able to customize the look and feel of their cart system.  With the SIM integration, we had them upload their logo to their Authorize.net interface and then they added the logo url to their Authnet integration settings in our application.  We then sent that logo url over via the SIM interface and it worked well.  Maybe this is something that I can add in a feature suggestion somewhere?

[Renaissance]

Yes it is, but it has been requested a million times. I've seen post after post where people do not like the limitations of the new form with the redirect method. I'd say auth.net is well aware of the issue at this point.  

Depending on the level of customization you offer, it may be quite possible to implement the iframe.  You will be sending out a new version of your application, with updated code? The issues you will have with the iframe will be if the customer has a lot of control over the width/height of the page where the payment takes place.  It is possible that if they make the page too small, the entire form won't be visible. 

It will likely take some additional tweaking for your needs, and there may be issues I haven't had yet. But if you load in an iframe the customer's logo will be right there like it is on other pages.  I do consider this an upgrade, after working on both products.  Accept Hosted is much easier to use and the added features to enhance transaction reporting are a real plus.

Aesthetically, the new hosted form is not as nice as the old one with the redirect method. But if you use an iframe the experience is enhanced big time. You can have the page outside of the iframe look however you want, and from the consumer's perspective there is no impression of ever being redirected. It is a seamless transaction on one website to them. 

[redcart]

Techinically, the iframe method would help us get closer to the look and feel that we're looking for. But the reason why we can't do the iframe approach is because of the additional level of PCI compliance that it puts us and our clients in. So unfortunately, the hosted payment form redirect method is our only option at this point. 

[Renaissance]

There is no PCI step up with Accept Hosted using an iframe. The only way you step up is if you use an Accept.js integration method that involves tokenizing cc data in the browser. So if you have a payment form hosted on YOUR server where the customer enters cc data that is tokenized in the browser, and then the tokenized data is passed to authorize then you are SAQ A-EP. Using the same integration you are now and merely changing from redirect to iframe you are still straight SAQ A.

[Renaissance]

And the all caps isn’t meant to yell. I’m on a phone with no functions to bold text.

[redcart]

Thanks!  For some reason, I thought embedding in an iframe automatically put you in the SAQ A-EP category.  If that's not the case, that would be very good to know. I also remember reading something about iframes being bad for this particular use case, but I don't remember exactly what the reason was or where I read it. 

[Renaissance]

Yes you are SAQ A for what you are doing as am I for what I am doing. There are a few requirements in the SAQ A scope that were specifically added to address the additional layer of risk posed by an iframe. They pertain to changing default passwords for access to system components if I remember correctly.
Whatever they are, even though they were added primarily to address the iframe, all SAQ A scope
integrations are required to comply. That’s why I say you are not upping the requirements at all. The thing you have to avoid is any element of the payment page originating from your server.

[Renaissance]

Got interrupted by a call from a friend who wouldn’t wait.

The reason it isn’t good is probably tied to the fact that you have a url that has to be set in your API call. It has to match the url of the page hosting the iframe. Being a mass market product, your clients will have a variety of site names. The workaround there is to have in their admin setting a place for them to enter the address of their homepage, and then to have the file where the iframe is located have the same name and relative location for everyone. Have it set so that when they copy and paste their homepage url in their admin area, it gets tied to a constant in your application. Then you could dynamically set the file path.

So for instance, you might have the payment page in a folder called payment, one folder down from the root. Your client has https://redcartstore.com. They paste this in their admin, and it gets tied to a constant “BASE_URL” or some such name. Then in the prefab API call you build into your app, you would have the url set to BASE_URL . “/payment/checkout.php

There would have to be some intermediate sanitization steps to prevent people from
Breaking things. Some might copy a url that ends with index.php. You’d want to axe that. You’d also want to make sure it is consistent whether Urls end with a / or not, as this would determine how you reference the relative path.

The other thing that will get you is what I mentioned before, them being able to add styling and content customizations. It is possible for them to make the payment page not fully visible. For that I would design your app and then pretend to be your clients and try to break it in every way you can think of. A dozen or so iterations of deliberately breaking it would give you an idea of the constraints you need to put in.