We're building an application (App-A) that will allow a user to enter credit card information. This application will live on a non PCI compliant zone.
We have another application (App-B) that also does credit card processing and this application is in a 100% PCI compliant zone.
If we want to leverage the functionalities of App-B, we'll need to embed it in App-A.
What I want to know is - are we still considered PCI compliant if App-A sends data to App-B via HTML 5 postMessage API.
It depends, the key on this is to ensure that the card data is not stored in any insecure (or generally readable mechanism). Vendors such as stripe.com, recurly.com and others have used JSON-P or other secure post technologies combined with one-time tokens to represent the transaction to avoid merchants processing actual card data. These work very similar to the method you describe & allow the zone for App-A to be classified as a lower compliance required level. To that end a post of the card data to App-B without storing or processing on App-A shouldn't be an issue.
Ensure, however, that on App-B you have a strong method to validate the source domain. The postMessage API itself isn't an end-all to allowing cross-origin data.
Broadly speaking, the scope of PCI is any system that stores, processes or transmits cardholder data AND any system that is connected to an in-scope system.
If there is communication between App-A and App-B then they are connected (at least on the network level).
There are certain, limited, circumstances where this network level connection can be deemed to not bring the second system in to scope but these would have to be discussed with a QSA or whoever is doing the assessment. If you are self-assessing it may be worth consulting with a QSA for some advice - they will have seen many situations similar to the one you are describing and will be able to offer the right advice.
