RKL eSolutions | Insights, Tips and Trends from a top Sage Reseller and Technology Specialist

Sage Exchange from Sage Payment Solutions

Written by Joe Noll | Aug 31, 2012 7:20:00 AM

I am writing this blog post as a summary of several inquiries and discussions we have had recently with several clients working on eCommerce projects that include the need for Credit Card processing. To be more specific CC processing using Sage Exchange from Sage Payment Solutions. To be even more specific the use of iFrame with Sage Exchange. I thought these might be useful comments for everyone. I want to give credit to 2 of my team members, Bill Collinson and Shawn Carney for their input regarding this post.

These statements are based on recent discussions with Sage Payment Solutions, our experience with PCI/PA-DSS compliance here at RKL eSolutions LLC, and also having several of our team members that were part of the original PCI/PA-DSS compliance effort for Sage 500 ERP (formerly MAS 500) while at Sage. However, we are not a PCI Compliance services organization and I would encourage you to seek additional counsel on the subject depending on how you decide to proceed. Sage Exchange is now integrated with all of the Sage ERP Products.

Hosted Payment Capture in an iFrame

This is an area of differing interpretations of the PCI / PA-DSS rules. At this point in time, the conservative view is that even if you’re using a hosted payment processor, such as Sage Exchange with iFrame, Google Payments, or PayPal, having that payment capture occur within an iFrame requires some level of PCI audit of your website. The idea at work here is that the iFrame represents a point of vulnerability, in that a hacker who gains control of your page can redirect that iFrame to a malicious site that can mimic an authentic payment capture. Because the identity of the payment capture site is obscured by the presentation within an iFrame it is theoretically easier to spoof a malicious substitute.

Sage Exchange current position, according the “Can I use iFrame?” page is that the more stringent QSA (PCI Auditing firms) will not exempt a site that uses iFrames to encapsulate the payment capture, and therefore they take the high road and say that the only solution that fully inherits their PCI compliance is that of the payment page that is external to your own page. This is consistent with the view of most major payment processors that offer a fully compliant payment solution.

Impact of using Sage Exchange in an iFrame

Should you decide that you still need to incorporate the payment capture into a frame on your checkout pages, the good news is that you probably don’t need a full PA-DSS audit. For one thing, you are likely a Level 3 or 4 merchant, not a software vendor incorporating a payment solution into their product. So the responsibility on you is a combination of self-evaluation of your adherence to the PCI standards and quarterly (at a minimum) network security audits by a certified firm.

I encourage you to explore fully the information for merchants on the PCI Security Standards Council website. We also have to recommend that you consult a firm that specializes in helping merchants evaluate their PCI compliance needs to more definitively define what your responsibilities are.