## 13.2.5.1.3  Payment Card Security According to PCI-DSS
##  Note
The Payment Card Industry Data Security Standard (PCI-DSS) was jointly developed by major credit card companies in order to create a set of common industry security requirements for the protection of cardholder data. Compliance with this standard is relevant for companies processing credit card data. For more information, see http:/ /www.pcisecuritystandards.org .
The following sections of the security guide support you in implementing payment card security aspects and outline steps that need to be considered to be compliant with the PCI-DSS.
Please note that the PCI-DSS covers more than the steps and considerations given here. Complying with the PCI-DSS lies completely within the customer's responsibility, and we cannot guarantee the customer's compliance with the PCI-DSS.
For current information about PCI-DSS in general, see SAP Note 1609917 .
Contract Accounts Receivable and Payable (FI-CA) processes all payment transactions with your business partners. For this purpose, Contract Accounts Receivable and Payable also processes credit card data. For processing credit card transactions, Contract Accounts Receivable and Payable follows the rules laid down by the Payment Card Industry Data Security Standard.
Credit card data arrives in Contract Accounts Receivable in the following ways:
- You receive documents, which already contain credit card data in their supplements, by means of the IDoc interface or by means of BAPIs.
- You receive payments that already contain credit card data with the payment lot transfer program ( RFKKZE00 ).
- External payment collectors and external cash desk services transfer credit card data using enterprise services with the payment to Contract Accounts Receivable and Payable.
- Financial Customer Care transfers credit card data for documents from SAP Customer Relationship Management using RFC.
- Customers or your employees add credit card data as follows:
- Employees enter credit card data in the master records of business partners and prepaid accounts.
- Employees enter payment card data in the Maintain Bank Data ( FPP4 ) transaction.
- Employees enter credit card data for payments in the cash desk, in the cash journal, in payment specifications and in promises to pay.
- Customers enter credit card data online in SAP Biller Direct. SAP Biller Direct transfers the data to Contract Accounts Receivable and Payable.
- You adopt billable items with payment information using the generated RFC interfaces /1FE/ &lt;billable item class&gt; \_BIT\_CREATE\_API .
The program for payment (such as the payment run or the cash desk) generates payment documents with supplements containing the credit card data. Contract Accounts Receivable and Payable transfers this credit card data to the payment card company or the clearing house using transaction FPPCDS (creation of file) or FPCS (online transfer).
Contract Accounts Receivable and Payable stores the data as follows:
| Object                                                                          | Table(s)                                                                                |
|---------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------|
| Business Partner Master Record                                                  | BUT0CC CCARD                                                                            |
| Payments in Payment Lot or Credit Card Lot                                      | DFKKZP                                                                                  |
| Document                                                                        | DFKKOPC DFKKOPKC DFKK_PCARD                                                             |
| Payment Data for a Payment Run                                                  | DPAYH                                                                                   |
| Payment Data for a Payment Using SAP Biller Direct or Fi- nancial Customer Care | DFKKOPC                                                                                 |
| Payment Specifications                                                          | DFKKIP_GRP                                                                              |
| Promises to pay                                                                 | DFKKPPD_PAY                                                                             |
| Master Record of Prepaid Account                                                | FKKPREPACC                                                                              |
| Billable Items                                                                  | Generated tables: • /1FE/0 <billable item class> 0PY • /1FE/0 <billable item class> 1PY |
You must restrict the display of the necessary objects by assigning authorizations, while at the same time ensuring that this authorization protection cannot be circumvented by database programs or customerspecific ABAP reports.
You can also make additional security settings for payment card data. For more information, see SAP Note 1032588 and the SAP S/4HANA Security Guide, section 'Payment Card Security'.
## Archiving
Only masked credit card information can be archived. Clear text credit card information should not be archived. Archiving encrypted credit card information is problematic because archived data should not be changed. Encrypted credit card information has to be re-encrypted with a different key, for example, with key rotation, as required by PCI-DSS. This change of data is not possible in an archive.
In technologies that are agnostic to the semantics of the data, such as Process Integration (PI), ABAP Web Services, or Forward Error Handling (FEH), archiving has to be disabled. IDocs that contain credit card information should not be archived.
## Interfaces (IDoc/Services)
##  Caution
According to PCI-DSS, IDoc segments are not allowed to store payment card numbers in clear text. However, during processing of an IDoc in the IDoc Framework, all values are stored temporarily, including the clear text credit card number.
For more information about how to process customer-specific IDocs containing credit card information, go to https:/ /help.sap.com/s4hana\_op\_2021, enter Handling Sensitive Data in IDocs into the search bar, press Enter , and open the search result with that title.
If you exchange data between systems using IDoc messages, and this data contains unencrypted credit card information, you have to implement access restrictions and a deletion concept at the level of the file system.
Contract Accounts Receivable and Payable processes payment card data in the following interfaces:
| Type of Interface   | Technical Name                                | Description                                                                           |
|---------------------|-----------------------------------------------|---------------------------------------------------------------------------------------|
| BAPI                | BAPI_CTRACPREPAIDACCOUNT_CREA                 | BAPI - FI-CA Prepaid Account: Create                                                  |
| BAPI                | BAPI_CTRACPREPAIDACCOUNT_CHNG                 | BAPI - FI-CA Prepaid Account: Change                                                  |
| BAPI                | BAPI_CTRACPREPAIDACCOUNT_GETD                 | BAPI - FI-CA Prepaid Account: Read detailed data                                      |
| BAPI                | BAPI_CTRACDOCUMENT_CREATE                     | BAPI: FI-CA Post Document                                                             |
| RFC                 | FKK_PREP_PCARD_STORE                          | Prepaid: Store Payment Data in DFKK_PCARD                                             |
| RFC                 | Event 1421 (function module FKK_SAMPLE_1421 ) | Parallel Billing Call Settlement                                                      |
| RFC                 | FKK_BUPA_MAINTAIN_SINGLE                      | Maintain Business Partner                                                             |
| RFC                 | /1FE/ <billable item class> _BIT_CREATE_API   | Generated RFC interfaces for transfer- ring billable items with payment infor- mation |
| Enterprise Service   | CashPointPaymentCreateNotifica tion_In   | External Cash Point Payment                                  |
|----------------------|------------------------------------------|--------------------------------------------------------------|
| Web Service          | ECC_CASHPOINTPAYMENTCRTNO                | External Cash Point Payment                                  |
| File                 | Report RFKKPCDS                          | Payment cards: Settlement                                    |
| ALE/IDoc             | ALE_CTRACDOCUMENT_CREATE                 | BAPI -> IDoc: ALE_CTRACDOCUMENT_CREATE(FI- CA Post document) |
## RFC Debugging
##  Caution
Disable RFC debugging when you process credit card information in a productive system. Do not activate the Set RFC Trace option in your productive system. If this option is active, the system saves all input data of an RFC call in clear text to a file. If credit card numbers (PAN) are included in calls to some function module, then this data would be stored to this file. Since these numbers have to be stored encrypted according to the PCI-DSS standard, activating this option would result in no longer being PCI compliant.
## Forward Error Handling (FEH)
##  Caution
Disable Forward Error Handling for all services that contain credit card numbers in SAP Customizing.
## Card Verification Values (CVV)
##  Caution
Do not process asynchronous services that contain a card verification code ( CAV2 , CID , CVC2 , CVV2 ) or their values.
Note that in SAP services, these values correspond to the GDT . PaymentCardVerificationValueText The reason is that the payload of asynchronous services is persisted in the database until the service is processed and persisting card verification values is not allowed according to PCI-DSS.
Synchronous services can be processed because their payload is not persisted.
## Access Logs
You can configure your system so that it logs access to payment card data via Dynpro and Web Dynpro. You make the settings in the SAP Customizing Implementation Guide under Cross-Application Components Payment Cards Basic Settings Make Security Settings for Payment Cards . Choose a security level for which payment card data is to be displayed masked, and set the indicator Additional authorization check for masked display .
You can use the CCSEC\_LOG\_SHOW transaction to evaluate access to payment card data. To evaluate the access log, a user requires authorization for activity 71 of authorization object B\_CCSEC .
For payment card data, you can also use Read Access Logging (RAL), which covers a large number of access channels, such as Remote Function Call and Web services.