Securing eCommerce

Electronic commerce, commonly known as e-commerce, is the use of the Internet to facilitate transactions for the sale and payment of goods and services. E-commerce is a card-not-present (CNP) payment channel and may include:

  • Securing eCommerceE-commerce websites accessible from any web-browser, including "mobile-device friendly" versions accessible via the browser on smart phones, tablets, and other consumer mobile devices
  • "App" versions of your e-commerce website, i.e., apps downloadable to the consumer's mobile device or saving of the URL as an application icon on a mobile device that has online payment functionality (consumer mobile payments)

An e-commerce solution comprises the software, hardware, processes, services, and methodology that enable and support these transactions. Merchants choosing to sell their goods and services online are limited to the following e-commerce implementations:

  • Shared-management
    • URL redirection to a third-party hosted payment page - the cardholder is redirected from the merchant’s website to a third-party page. The cardholder then enters their account data into a payment page hosted by the third-party payment service provider (PSP).

      The Redirect Process
      1. Merchant website sends a redirect command to the customer’s browser.
      2. The customer’s browser then requests a payment form from the PSP.
      3. The PSP creates the payment form and sends to the customer’s browser.
      4. The customer’s browser displays the PSP’s payment form.
      5. The customer enters account data and sends to the PSP.
      6. The PSP receives the account data, sends it to the payment system for authorization and send transaction result to merchant & customer.
      7. Merchant processes customer's purchase or service orders.

        Example Redirect Payment Flow
        Figure 1 – Example Redirect Payment Flow
    • An Inline Frame (or “IFrame”) that allows a payment form hosted by a third party to be embedded within the merchant’s web page(s)

      The IFrame Process
      1. The merchant website creates an IFrame within the current webpage. The customer’s browser requests the payment form from the PSP.
      2. The PSP creates a payment form and sends to the customer’s browser within the IFrame.
      3. The customer’s browser displays the payment form within the IFrame located on the merchant page.
      4. The customer enters their payment details into the IFrame containing the PSP’s payment form.
      5. The PSP receives the account data and sends it to the payment system for authorization.
      6. The PSP receives the account data, sends it to the payment system for authorization and send transaction result to merchant & customer.
      7. Merchant processes customer's purchase or service orders.

        Example Redirect Payment Flow
        Figure 1 – Example Iframe Payment Flow
  • Merchants may develop their own e-commerce website, use a third-party developed website solution, or use a combination of both using the allowed shared-management ecommerce implementation.
  • Wholly outsourced e-commerce implementations - Merchants may also decide to engage a third party to perform services that support their e-commerce solution. The service provider or the services may be considered in scope for a merchant’s PCI DSS compliance if the security of the solution is impacted by this service and the service provider has not performed its own assessment. For more information, see section on “PCI Compliance Policy for TPSP.”

No matter which option a merchant may choose, there are several key considerations to keep in mind regarding the security of cardholder data, including:

  • No option completely removes a merchant's PCI DSS responsibilities. Regardless of the extent of outsourcing to third parties, the merchant retains responsibility for ensuring that payment card data is protected. A merchant is responsible for performing due diligence to ensure the service provider is protecting the CHD shared with it in accordance with PCI DSS. Whether a merchant must conduct an onsite assessment or is eligible for a Self-Assessment Questionnaire (SAQ) is determined by the acquirer or payment card brands.
  • Third-party relationships and the PCI DSS responsibilities of the merchant and each third party should be clearly documented in a contract or service-level agreement to ensure that each party understands and implements the appropriate PCI DSS controls. More information on these relationships can be found in the Third-Party Security Assurance Information Supplement on the PCI SSC website.
  • It is recommended the merchant monitor connections and redirections between the merchant and the third party since the connections can be compromised. The merchant should ensure that no unexpected changes have occurred and that the integrity of the e-commerce solution is maintained.
  • It is recommended that e-commerce payment applications, such as shopping carts, be validated according to PA-DSS, and confirmed to be included on PCI SSC's list of Validated Payment Applications. For in-house developed e-commerce applications, PA-DSS should be used as a best practice during development.

The university prohibits the following options:

  1. Proprietary/custom-developed shopping cart/payment application
  2. Commercial shopping cart/payment application fully managed by the merchant/university
  3. Cardholder data storage (see data types on definition of cardholder data)
  4. Shared-management e-commerce utilizing the following:
    1. Embedded content within the merchant’s page(s) using non-IFrame tags.
    2. Direct Post Method (Form)
    3. JavaScript Form
    4. Merchant gateway with third-party embedded application programming interfaces (APIs) or Electronic Data Interchange (EDI)