B2B Mobile Transaction PCI Compliance Guidelines

The Payment Card Industry Data Security Standards (PCI DSS) provides specific guidelines on the regulations for the transfer and storage of payment card data in mobile payments. This article provides guidance for PayPal White Label Wallet (WLW) issuers regarding the data flow that is in scope for PCI regulation and different strategies available for mitigating that scope.

B2B API merchant PCI DSS scope

PayPal's WLW server-side architecture typically involves in-scope PCI DSS data elements passing through the merchant's mobile application server environment during card enrollment, as highlighted in the following diagram.

PCI Scope Diagram

As the diagram demonstrates, Account Data is sent by the wallet app in order to be handled by the merchant's app service layer before continuing on to the WLW platform for vaulting and/or processing. The transmission of that account data may be subject to PCI DSS regulations, depending on the types of payment instruments and the current applicable PCI Data Security Standard requirements. Merchants must ensue that the PCI DSS Cardholder Data Environment (CDE) surrounding the app service layer is accurately reflected and reported as part of annual Self-Assessment Questionnaires or on-site assessment by a PCI DSS QSA.

Implementation strategies

PayPal encourages its WLW partners to assess their existing infrastructure to determine the best approach for ensuring that consumer cardholder data is handled in compliance with PCI DSS regulations.

The following sections outline three possible approaches to use when implementing a WLW development strategy related to PCI regulations. Each approach has advantages and disadvantages based on a merchant's existing architecture and road map. When deciding on a strategy, consider:

  • Is your current non-mobile payments environment already addressing PCI?
  • What is your PCI level?
  • What will each strategy cost?

The three implementation strategies described here are:

External vaulting model

If your existing infrastructure is not designed to support a secure cardholder data environment, one approach is to use an external vaulting model to minimize or remove the PCI scope in your environment altogether. In the external vaulting model, the account data is sent directly from the consumer app to an external tokenization service such as Braintree through a client SDK. Then, a tokenized nonce is returned for vaulting by the issuing partner. In this way, the cardholder data is never exposed in the app service layer and, therefore, not subject to PCI.

Example process

The following describe the steps used to construct an external vaulting PCI model with the Braintree SDK:

  1. Implement the Braintree SDK in the device app.
  2. Braintree SDK sends PAN directly to Braintree Server, where it is vaulted.
  3. Braintree returns a nonce to the app which can then be used to register the payment account in the wallet and use that payment account for subsequent transactions.

Tokenized Model Diagram

Advantages Disadvantages
  • Minimizes PCI burden
  • Simpler implementation
  • Smaller app footprint
  • Incurs per-transaction cost
  • Requires client SDK in app

PAN Encryption

Many payment processors support an account data encryption strategy in which the processor provides an encryption tool for which they maintain the private decryption key. In this model, sensitive account data is encrypted in the app at the time of input and is transmitted through the app service layer and the PayPal WLW platform to the payment processor, where it will be decrypted and validated for enrollment in the customer's wallet. PayPal will vault the returned payment token and use it for subsequent transactions in which that account is the selected tender.

Like external vaulting, this strategy reduces PCI burden because the account data is never exposed in the merchant's app service layer.

Advantages Disadvantages
  • Reduces PCI burden
  • Simpler implementation
  • Incurs per transaction cost
  • Requires in-app encryption tool

In-house PCI policy development

If your existing server environment already addresses PCI compliance or you are prepared to demonstrate adherance to PCI DSS requirements in your cardholder data environment, PayPal strongly recommends consulting a Qualified Security Assessor (QSA) for strategy recommendations.

Note: The information provided in this section reflects the guidance and requirements of the PCI Security Standards Counsel. Please visit the official website for current applicability and validation.

Determine your PCI levels

Merchants are assigned to one of four levels based on their annual card transaction volume, as shown in the following table.

PCI Level Transactions
Level 1 6 million+ transactions across all channels.
Level 2 1 - 6 million transactions across all channels.
Level 3 20,000 - 1 million e-commerce transactions
Level 4 Less than 20,000 ecommerce transactions
or
Less than 1 million traditional transactions

Note: Any merchant that has experienced a data breach is automatically assigned to Level 1 regardless of transaction volume and credit card companies reserve the right to assign a merchant to level 1 at their discretion.

PCI assessments

A merchant's PCI level determines the extent to which that merchant is assessed for compliance with PCI data security standards. It does not mean that the merchant has less stringent requirements; only whether the merchant is acceptable to independently validate that the requirements have been met.

Level 1 merchants are required to submit to an on-site audit by a Qualified Security Assessor (QSA). The audit ensures that the merchant has documented a set of policies and standards that demonstrate its compliance in controlling its cardholder data environment (CDE). The audit also runs diagnostic tests to validate that the documented processes are being followed.

Non-Level 1 merchants can submit a Self Assessment Questionnaire (SAQ) to demonstrate their compliance. The SAQ allows the merchant to answer yes or no to a series of prompts regarding the merchant's business type, transaction types, and handling of cardholder data within its CDE. The SAQ is very often adequate for PCI certification of non-level 1 merchants.

When building an in-house PCI DSS compliance strategy, consider the following best practices.

  • Reduce CDE through segmentation

    Wherever sensitive account data resides or is in transit, Network and Access Segmentation of your app server reduces CDE which in turn requires fewer controls to be in place for compliance.

  • Avoid storing sensitive account data

    Regardless of the way in which you plan to move account data through your system, the number of controls necessary for PCI compliance may be reduced by not storing account data in your app server environment. For most mobile payments environments, vaulting of account data is not necessary.

Advantages Disadvantages
No per-transaction fee
  • Ongoing annual compliance assessments and updates
  • Complicated implementation

Security Best Practices

PayPal urges any mobile payments application project to employ the highest standards of security when handling any level of sensitive consumer data and consider the following measures in their implementations.

Data Storage

As a cloud-based platform, one goal is to store as little information as required on the mobile device and rely on the secure application services for maintaining confidentiality and integrity of information. Always protect information appropriately while being used by the mobile application.

Tier I II III
Data Types
  • Card Data (PAN, Expiry, CVV)
  • Consumer Password/Passcode
  • Consumer Address
  • PII
  • NPI
  • Tokenized Card Data
  • PayPal URI Strings (non-card referencing)
  • Consumer Username
  • Offer Data
  • Loyalty Data
Approved Mobile Storage Locations None None Any
Storage protection required
  • Wipe Card Data from memory after use
  • Mask login credentials on entry
N/A N/A
Purge on app in background Required Not Required Not Required
Purge on session termination Required Required Not Required
Purge on device unlink Required Required Required
Purge on app removal Required Required Required

Unintentional data storage

Data can be captured in a variety of artifacts - many unintended. If data is ever transmitted as query string parameters, as opposed to in the body of a POST request, then these are liable to be logged in various places, for example, within the user's browser history.

Verify the types and protections of data stored in log/debug files, cookies, web history, web cache, property lists, files and QLite databases.

Clear App Memory of All Sensitive Data

Ensure sensitive data that is input into the device during registration and account management operations is not persisted in the app’s memory following completion of the operation.

Specifically, when sensitive data is input by a mobile wallet user for the purpose of populating Customer or PaymentAccount data objects, create a mutable copy in the app memory from which the data can be retrieved when needed for the operation, then wipe the app memory to clear the values once the operation has completed.

Secure Data Entry

Consider masking sensitive account data upon entry into the mobile device, preferably per-digit. This includes:

  • Credit Card Number
  • Credit Card Expiration Date
  • Credit Card Security Code

If the mobile application enters the background directly from a sensitive account data entry screen, protect against automatic OS-level screenshot capture of any card holder data.

A rule of thumb is to mask and/or provide partial (e.g. last 4) card holder data when presenting or storing.

Code Protections

Code obfuscation protects the code base from decompiling and modification using obfuscation algorithms, overlapping checksums injections, flattened code paths, and embeds platform-specific anti-debug and anti-piracy code. Using checksums, digital signatures and other validation mechanisms on files used in the application can help detect whether data files have been tampered with in an attempt to manipulate the application, and can also ensure any data files are authentic by enforcing a signature embedded within the application.

Consider randomizing tools like ASLR, introduced in iOS 4.3, to randomize how an app is loaded and maintained in memory. ASLR randomizes the address space used in the application, making it difficult to execute malicious code without first causing the application to crash. It also complicates the process of dumping allocated memory of the application.

OWASP Top Mobile Controls

The Open Web Application Security project (OWASP) and the European Network and Information Security Agency (ENISA) collaborated to build a joint set of controls for protecting mobile applications. Current OWASP Top Mobile Controls include:

  1. Identify and protect sensitive data on the mobile device.
  2. Handle password credentials securely on the device.
  3. Ensure sensitive data is protected in transit.
  4. Implement user authentication, authorization and session management correctly.
  5. Secure data integration with third party services and applications.
  6. Pay specific attention to the collection and storage of consent for the collection and use of the user's data.
  7. Implement controls to prevent unauthorized access to paid-for resources.
  8. Ensure secure distribution/provisioning of mobile applications.
  9. Carefully check any runtime interpretation of code for errors.

Additional information

Feedback