2

I am attempting to setup a network of web applications that all provide some kind of purchasing system. In an effort to avoid having to run vulnerability scans on each web application's server, I would instead like to just give each web application a token value that is created on a payment processing server, which would be the only PCI compliant server on the network.

The web application would then send this token through to the payment processing server, where it would then be decrypted and charged.

I would also like to not store the card details on the payment processing server, so my proposed process is as follows:

  • Web application client (SPA) collects the card details and makes a request for an encrypted token directly to the payment processing server.

    {
      "number": "4242424242424242",
      "exp_month": "12",
      "exp_year": "2018",
      "cvv": "123"
    }
    
  • The payment processing server encrypts this data (for example let's use AES256 and password "test") and returns the token to the web application client.

    {
      "token": "DmR7/sQW7+EqKc1MvdaMgQ/DPVNIJuGTpoe2uwEfA4UJTdcaXuf63GhLyTvfihK77iTknNQArUHRVhm7kdET1KjetIg7Qj/aImlPXqM6GzwlgVljoofxtuHa8rRkU4/TqKHC+mfabYQrs4E+eb39qIeIenosPTr2b/+I+IOSZ6s="
    }
    
  • The web application client then sends this token to the web application server, along with the order information.

    {
      "token": "DmR7/sQW7+EqKc1MvdaMgQ/DPVNIJuGTpoe2uwEfA4UJTdcaXuf63GhLyTvfihK77iTknNQArUHRVhm7kdET1KjetIg7Qj/aImlPXqM6GzwlgVljoofxtuHa8rRkU4/TqKHC+mfabYQrs4E+eb39qIeIenosPTr2b/+I+IOSZ6s=",
      "items": [
        {
          "id": 5,
          "quantity": 1
        }
      ]
    }
    
  • The web application server receives the order details, and then requests a payment through to the payment processing server.

    {
      "token": "DmR7/sQW7+EqKc1MvdaMgQ/DPVNIJuGTpoe2uwEfA4UJTdcaXuf63GhLyTvfihK77iTknNQArUHRVhm7kdET1KjetIg7Qj/aImlPXqM6GzwlgVljoofxtuHa8rRkU4/TqKHC+mfabYQrs4E+eb39qIeIenosPTr2b/+I+IOSZ6s=",
      "provider": "stripe",
      "currency": "aud",
      "price": 123.45
    }
    
  • The payment processing server then decrypts the token to discover the card details to charge, and proceeds with the charge. The payment processing server returns back whether the charge was successful and the web application server is then free to mark the order as processed.

In this scenario my main concern is whether passing the encrypted card details to the web application server is considered an issue for PCI compliance?

I am aware that I could use a service like Stripe.js to just retrieve a dumb token (literally just a reference to Stripe, no card data at all) however the payment processing system may support multiple providers, some of which may not have any tokenisation systems in place, and so I need to cover all bases here.

Thanks.

  • 1
    Someone will probably provide you with a better answer, but AFAIR from my previous job, a server doesn't fall in the PCI scope if it only sees encrypted card data that it cannot decrypt (i.e. it cannot access the decryption key) – christophetd Apr 11 '17 at 10:42
  • 2
    @christophetd but you have to be able to prove that any asset that handles the encrypted stream cannot decrypt. So, not in scope, but still needs analysis and documentation to define it as out of scope. – schroeder Apr 11 '17 at 10:51
4

In this scenario my main concern is whether passing the encrypted card details to the web application server is considered an issue for PCI compliance?

In the scenario you've described, you are not passing encrypted card details. You are passing a token, generated by the payment processor and passed back to you through the web client, which represents a lookup to the actual card data once passed (by you) back to the processor.

In this scenario, presumably the shopping cart page which contains the iframe or javascript which causes the customer's browser to send card details to the processor is served by your server. In that case, you are still subject to PCI compliance, per SAQ A-EP (emphasis mine):

SAQ A-EP has been developed to address requirements applicable to e-commerce merchants with a website(s) that does not itself receive cardholder data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the consumer’s cardholder data.

SAQ A-EP merchants are e-commerce merchants who partially outsource their e-commerce payment channel to PCI DSS validated third parties and do not electronically store, process, or transmit any cardholder data on their systems or premises.

  • But I am passing encrypted card details to the web application server, it just doesn't have the key to decrypt it. I am proposing to use this method so that at no point do I have to store the card details on the payment processing server, instead the request wishing to charge the card supplies the card details. And thank you for the second section - does this mean that if I served the payment form in an iframe from the payment processing server, that it would no longer require the web application server to be PCI compliant? – mitchdav Apr 12 '17 at 13:14
  • 1
    @mitchdav Correct. Tokens and encrypted card details when you don't have the key are not enough to trigger PCI Scope just by crossing your server. However, if your web site is integrating to the payment processor, as is implied by your description above, then the handoff is enough to trigger PCI scope. – gowenfawr Apr 12 '17 at 13:17
  • 2
    I agree with @gowenfawr. Just one point of clarification. When he says "you don't have the key" that means the organization and those within it. Simply storing encrypted card data on a server segmented from the keys doesn't remove it from scope. The only time encrypted data is out of scope is if the organization has no access to the encryption keys. – Timee Apr 13 '17 at 15:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.