- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
How to add a logo to Accept Hosted Payment Form?
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.
โ03-16-2019 10:27 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ03-16-2019 10:56 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
โ03-16-2019 11:02 AM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ03-16-2019 12:10 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ03-17-2019 12:24 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
โ03-17-2019 03:04 PM - edited โ03-17-2019 03:15 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
โ03-17-2019 03:05 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ03-17-2019 03:34 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ03-17-2019 06:45 PM
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
โ03-17-2019 07:10 PM