GWT PCI Compliance Toolkit

[Evan Ruff]

Hey guys,

I'm the project lead on CRE Secure's new iFrame Hosted Payment Page
solution (http://www.cresecure.com). I've been a big GWT guy since
back around 1.5RC1 so I've had a special eye on the GWT-centric issues
around PCI Compliance, especially from a application control/look-and-
feel standpoint. The current solution is packaged as a JAR and
contains a number of hooks to help with the GWT integration. The
solution gives the developer maximum control over the form, rendering,
display and callback of the entire payment process, all while
maintaining PCI compliance without leaving your application.

We're looking to release the platform sometime in early October and
are looking for early beta testers to help test our implementation. We
are certified to the Authroize.net Platform and the Chase Paymentech
(Tampa and Salem) Platform and are looking to get the JAR into
people's hands a soon as possible. If you accept credit cards in your
application and are not yet PCI Compliant, we'd like to help you get
there.

Send me an email or reply to this thread and we'll get in touch. We've
got a demo up and running that I'd love to walk through to show
exactly what it can do. Also, if anyone has any PCI Compliance
questions feel free to drop me a line our check out our site at
http://www.cresecure.com.

Thanks!

Evan Ruff
evan...@hendersonsawmill.com
Enterprise Development
CRE Secure

[Duong BaTien]

Please announce your release and put me duong....@gmail.com in your
list. We use GWT to develop a new E-Commerce system.

Duong BaTien
DBGROUPS and BudhNet

[Evan Ruff]

Hey Duong,

We're preparing to roll out our PCI compliance solution. I was wondering which gateway you are using to process your payments.

Thanks!

Evan

--~--~---------~--~----~------------~-------~--~----~
 This message is part of the topic "GWT PCI Compliance Toolkit" in the Google Group "Google Web Toolkit"
for which you requested email updates.
To stop receiving email updates for this topic, please visit the topic
at http://groups.google.com/group/google-web-toolkit/t/6f7acb94e3fd1b8e
-~----------~----~----~----~------~----~------~--~---

[Duong BaTien]

We are still in development mode and have not fully committed to any
yet. Please keep in touch.

Duong BaTien
DBGROUPS and BudhNet

> --
>
> You received this message because you are subscribed to the Google
> Groups "Google Web Toolkit" group.
> To post to this group, send email to google-web-
> too...@googlegroups.com.
> To unsubscribe from this group, send email to google-web-toolkit
> +unsub...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/google-web-toolkit?hl=.

[Yozons Support on Gmail]

Isn't most PCI compliance related to the server?  GWT only holds the information a short time to make a payment and shouldn't normally hold on to the data after submitting it for processing.  How does your GWT help with PCI compliance since this would also require your server and server code to be compliant.  Furthermore, if using a payment gateway, you shouldn't even have to store the payment information locally and thus avoid most PCI compliance issues.

[Evan Ruff]

Yozons,

You're running into one of the most common PCI Compliance
misconceptions: just because you don't store the card data does not
mean you're compliant. If the application touches the card data IN ANY
WAY, even just to immediately transmit to the gateway, you must have
your application served in a PCI-Compliant data center, be subjected
to PCI change control guidelines and have your application undergo PCI-
DSS auditing.

Our solution pulls the handling of the actual card data out of the
scope of the application. Because the style and functional operation
of the module is defined by your application, the secure processing is
completely transparent to the user. The customer experience is
completely maintained on your site. The card data is handled 100% on
the CRE Secure side, giving your application PCI Compliance and still
allowing the application to process card data.

Thanks!

Evan

[Yozons Support on Gmail]

This has gone off-topic, so I won't belabor my point, but the PCI principles clearly show it's more geared towards the server-side, as the browser itself never had to be "PCI compliant" or any such rubbish.  And no GWT interface tool can ensure PCI compliance either.  A server that has gone through the compliance analysis is key, so if that part is taken over with the GWT interface, then I surely understand that.

The core of the PCI DSS is a group of principles and accompanying requirements, around which the specific elements of the DSS are organized:

Build and Maintain a Secure Network

Requirement 1: Install and maintain a firewall configuration to protect cardholder data
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters

Protect Cardholder Data

Requirement 3: Protect stored cardholder data
Requirement 4: Encrypt transmission of cardholder data across open, public networks

Maintain a Vulnerability Management Program

Requirement 5: Use and regularly update anti-virus software
Requirement 6: Develop and maintain secure systems and applications

Implement Strong Access Control Measures

Requirement 7: Restrict access to cardholder data by business need-to-know
Requirement 8: Assign a unique ID to each person with computer access
Requirement 9: Restrict physical access to cardholder data

Regularly Monitor and Test Networks

Requirement 10: Track and monitor all access to network resources and cardholder data
Requirement 11: Regularly test security systems and processes

Maintain an Information Security Policy

Requirement 12: Maintain a policy that addresses information security

[Evan Ruff]

Yozons,

I think we are actually on-topic here. PCI Compliance is something that every application must deal with. Because of the hybrid nature of GWT applications, there are certain challenges that are unique to the platform.  

I think you might be misunderstanding the problem with PCI Compliance, especially from a GWT standpoint. It is not possible to connect a GWT Widget (such as a payment form) directly to an external payment processor through RPC due to the cross-domain security policies of the browser. These requests must be routed through the hosting server. Because the payment details touch the server, the application must conform to PCI guidelines. 

When the credit card data touches the server-side service, you are immediately subjected to SAQ-C (at least). The overview in your post is extremely high level without the specific requirements for compliance. I've included a link to the full PCI-DSS and SAQ below. While a vast majority of the SAQ-C requirements focus on server software implementation, Section 9 of the PCI-DSS lays out a number of PHYSICAL requirements that must followed at the data center level. 

Hosting your application at a PCI-Compliant data center is extremely expensive; furthermore, cloud-based environments such as EC2 or Google App Engine are, by nature, not PCI Compliant. CRE Secure aims to eliminate the entire PCI Compliance variable by collecting and processing the payment data in our hosted environment, all while maintaining the customer experience on your site.

If you'd like to see a demo of our solution working in a GWT application, please drop me an email.

Thanks,

Evan

evan...@crecommerce.com

SAQ-C : https://www.pcisecuritystandards.org/saq/docs/aoc_saq_c.doc

PCI-DSS: https://www.pcisecuritystandards.org/security_standards/pci_dss_download.html

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.

[Yozons Support on Gmail]

The real benefit of your service is that you've provided a GWT widget/module we can install by downloading it from your secure server so that the CC information is entered on my page, but your widget actually captures the CC info and submits it for processing to your server directly so our web site never touches CC data and thus can avoid PCI compliance?  But it somehow is able to communicate with my code (some sort of event listener?) to tell me success/failure of the payment?

I know that most merchant services companies offer tools like this, though most are "redirect to their site" to do the payment, and then redirect back to your site with success/failure.  Is this how you differ from what they offer?

[Evan Ruff]

Exactly!

Not only do we tell you sucess/failure, we tell you every event that goes through the forum.

The module displays the payment form in an iframe. The form includes a style sheet located on your site to match the look and feel of your application. When the user interacts with the form, CRE Secure uses some cross-domain mojo to pass back status to your application through JSNI and up to the GWT layer. All error messages, whatCVV2 requests, completion messages and cancel messages are handled on your site in any way you choose. All of this is done in a PCI compliant manner. The user never has any jarring interruption, visual disconnects or continuity issues around payment.

CRE Secure distributes a JAR file that you can drop into your application. You the implement the four functions our CRESecureProcessor interface and pass it to the included CRESecureManager. CRESecureManager does all the marshaling of the JNSI functions, frame creation, etc.

Currently, we have a 1.0 release in production processing cards now. We're pushing out 1.1 this week with a number of improvements to make the implementation experience a little smoother. We're currently looking for people that are using GWT, collect credit cards and don't want to deal with the hassle of PCI compliance.

Evan

evan...@crecommerce.com

On Tue, Nov 17, 2009 at 2:12 PM, Yozons Support on Gmail <yoz...@gmail.com> wrote:

The real benefit of your service is that you've provided a GWT widget/module we can install by downloading it from your secure server so that the CC information is entered on my page, but your widget actually captures the CC info and submits it for processing to your server directly so our web site never touches CC data and thus can avoid PCI compliance?  But it somehow is able to communicate with my code (some sort of event listener?) to tell me success/failure of the payment?

I know that most merchant services companies offer tools like this, though most are "redirect to their site" to do the payment, and then redirect back to your site with success/failure.  Is this how you differ from what they offer?