Credit card number not masked in Table FPLTC

[former_member588480]

I checked in few case for sales order transaction VA02/VA03 credit card detail is masked But when i checked in table FPLTC , there are 3 entries corresponding entires maintained for the related Billing plan number / invoicing plan number of the sales order as shown below.

Here one of the entires higlited beblow is not masked in table FPLTC .

I have got the requirement to mask the entries in table FPLTC , that are not msked.

So as a ABAPer here I want to understand the functioanlity , why there is 3 entires maintained and why the last entry is not masked .

Can anyone please help me to understand this case as i could not find more details about this case in SCN and let me know incase for detail required from myside .

Thanks

Prabin

[svs_sap]

Hi,

Please mention how the masking performed at present? Is it via ABAP program with some conditions from custom tables?

[michael_piesche]

Prabin Pradhan, so this error only happens for returns? In that case I would check the copy control routines, there must be custom coding in place (see point 3.)

1) credit card data is entered manually for returns?

You say that business enters credit card data manually for a sales document? They obviously cant do this via standard "VA02 -> Payment Cards -> Manual Authorisation" functionality, because based on your screenshot CCAUA is empty and not 'X'. So there must be custom coding (either a z-transaction/z-report/modifications/user-exit/badi) that makes this functionality available.

2) What is the business process with credit card payment from sales order to invoice to return?

a) When payment is done via a credit card for a sales order, the sales document needs to have a reference to the credit card transaction (normally achieved through records in FPLA/FPLT/FPLTC). The sales document would have a minimum of two records in FPLTC, one for the card and the other for the transaction.

=> supported by SAP standard, basic customizing and custom authorisation FM will enable these functionalities

b) The invoice will get a copy of the transaction only (therefore just having one record in this example). The settlement amount will be posted to the linked financial accounts and the settlement run will make the final settlement of the authorisation through a payment service provider (that is if a two-step authorisation-settlement process has been implemented).

=> supported by SAP standard, basic customizing and custom settlement FM will enable these functionalities

c) When a return sales document is created (either based on the invoice or the order), and the credit card transaction needs to be fully or partially reversed, the return sales document will also need at least two records, one for the card and one for the transaction. The transaction for the return also needs to be a copy of the original sales document transaction (mainly it has to reference the same transaction) whereas the authorisation amount (return amount) cannot be higher than the settled amount.

=> the automatic creation of credit card transactions in a return order based on an invoice or a sales document are not supported by the SAP standard. Either a custom copy routine has to be implemented, or it has to be entered manually (manual entries are always error-prone).

3) Check for custom code in copying routines

To check whether there is a custom check and copy routine in place, that allows for the copy of credit card data, look at the following customizings and find the routines for your case based on the document flow of your return order (either it is based on invoice or on the sales document. In those routines, based on VBRK-RPLNR or VBAK-RPLNR, there should be custom coding in place, that will copy card and transaction data from the predecessing document to the return order.

SPRO -> Sales and Distribution -> Sales -> Maintain Copy Control for Sales Documents

• Copying Control: Sales Document to Sales Document (e.g. Targe RE Returns and Source TA / OR Standard order)
  Copying requirement (standard routine): 1 Header-same customer
  Copy Data to VBAK (standard routine): 51 General header data
  Copy Data to VBKD (standard routine): 101 Header business data
  Copy Data to VBPA (standard routine): 1 Partner header
• Copying Control: Billing Document to Sales Document (e.g. Target RE Returns and Source F2 Invoice)
  Copying requirement (standard routine): 21 Billing header
  Copy Data to VBAK (standard routine): 52 Billing doc.header
  Copy Data to VBKD (standard routine): 103 Bill.bus.header data
  Copy Data to VBPA (standard routine): 3 Bill.header partner

4) SAP standard copying routines logic regarding payment plans

The standard routines (if not customized/modified), will only address the existence of a payment card plan from the invoice or the sales document and throw out a warning when the copying requirement is performed. The standard routines do not copy any payment card data. SAP did not want to touch this highly company and process dependent subject of payment cards in returns and credit memos, and therefore leaves it up to the company to deal with this matter with custom code or internal process guidelines.

The following coding can be found in any SAP standard copy requirement routines when a payment plan is available in the predecessing document:

• Only a warning is displayed to alert the user
• There is no automatic SAP standard handling of payment card transactions from predecessing documents
• These standard codings will be replaced by custom coding to automatically deal with payment cards based on company and process dependent requirements

" The system will not copy card info from the reference document - Check 
 IF NOT VBAK-RPLNR IS INITIAL.  "CCARD   (or VBRK-RPLNR when copying from invoice to return)
    MESSAGE W045(V/).           "CCARD  
  ENDIF.                        "CCARD

You can also check the routines with transaction VOFM:

• VOFM -> Copying requirements -> Orders
• VOFM -> Data Transfer -> Orders

[michael_piesche]

prabinkumar

1. Analyse records with missing encryption compared to those with encryption
   Your observation in FPLTC must be a 'bug', and my assumption is, that it comes from custom coding.
   (Have you also already looked for SAP notes, support.sap.com, that might prove it could be a standard problem?)
   
   Have you compared records with encryption vs those without encryption and found any common denominators?
   - The record for the card (e.g. 000001 and UELNR/UELTR empty) obviously is never a problem, if I understand you correctly
   - But the records for the transactions (e.g. 900001/900002 and UELNR/UELTR filled) do sometimes have the issue
   - And based on your description, it can even be, that the first transaction (e.g. 900001) is encrypted,
   . whereas the second transaction (e.g 900002) is not encrypted for the same sales document
   
   How do sales orders with credit cards get created in the SAP system, and how do transactions get created?
   - For sales order creation, I assume those get created through Idoc from another system, having the plain text card number
   . or is the order created in SAP system through VA01 and the card number is actually typed in in plain text?
   - For transaction creation for sales orders, I assume these also get created through Idoc, but there could also be a
   . re-authorisation logic in place that gets executed when current auth-value is smaller than order-value through custom FMs
   . and there is also the possibility for manual authorisations
   
   Other sales document types with credit cards (e.g. invoice, returns) should always have copies of the original transaction, or be a reference to the original transaction, and therefore have inherited errors in regards to missing masking/encryption, but not create new errors.
   
   Things to look at when trying to find the process that creates the abnormalities:
   - What is the CCARD_GUID, this should be the most obvious: filled when CCNUM is masked/encrypted, empty when not
   - What is the authorisation type (CCAUA; blank being marked as 'done by the system', A being marked as 'done manually')
   . Authorisations by the 'system' is normally set when
   . a) a new order is replicated into the ERP system (e.g. from CRM by middleware or from hybris by Idoc)
   . b) an existing order is changed in the ERP system leading to an automatic transaction
   . -> check logic (or ask developer) of custom FMs for authorisation and settlement in cust. table TCCAA (FNAUT,FNSET)
   . 'Manual' Authorisations are normally set when the transaction is created by a user with VA02 -> Payment Cards -> Manual Authorisation
   - What is the call status (CCALL), what is the reaction (REACT)?
   - What is the merchant (MERCH), what is the card type (CCINS), what is the card category (CCTYP)?
   - What are the sales document types (e.g. order, return, credit memo request, invoice, cancelled invoice, credit for returns, credit memo)
   - Are there any change documents in CDHDR, CDPOS for when and by who those records where created?
   e.g. OBJECTCLAS = VERKBELEG
   . OBJECTID = salesdocumentnumber
   . TABNAME = FPLTC (or also FPLA, FPLT)
   . TABKEY = xxxYYYYYYYYYYzzzzzz (xxx = Client, YYYYYYYYYY = FPLNR, zzzzzz = FPLTR)
   . FNAME = CCNUM
   
   .
2. Reports to encrypt all ccnums in FPLTC and BSEGC
   You can use report CCARDEC_TRANSFORM_SD to check and encrypt values in FPLTC (SD) and report CCARDEC_TRANSFORM_FI to check and encrypt values in BSEGC (FI).

[michael_piesche]

The following information will help you to understand Data in FPLTC as well as how encryption works.

With this information, you should be able to either find an existing standard program or write a custom program to fix the current faulty records.

Credit Card and Transaction Data in table FPLTC

• VBAK/VBRK stores in field RPLNR the Number of the payment card plan from FPLA
• FPLA is the header for the payment card plan with the key FPLNR
• FPLT and FPLTC contain the entries of the payment card plan, whereas FPLT and FPLTC contain different data for the same item having the identical key with FPLNR and FPLTR, whereas FPLT contains document related business data including payment card plan hierarchy and FPLTC contains mainly the credit card data and the credit card transaction data
• A credit card is identified in FPLT as a root entry with empty parent fields:
  UELNR - Higher-level payment card plan number for billing
  UELTR - Higher-level item in billing plan
  The FPLTR number for card data starts with 1
• A transaction for a credit card is identified as a child entry with reference to a root entry by non-empty parent fields UELNR and UELTR
  The FPLTR number for transactions starts with 900001

Storing Credit Card Numbers / Alias/Token in SAP system

• Do you actually have real credit card numbers in your SAP system? That would expose the company by PCI DSS compliance regulations to certification
• I assume, that for the purpose of the screenshot, you actually changed the real value for the credit card number / alias/token.
• All American Express credit card numbers start with “37” or “34”.
• What you have as a CCNUM in your system is hopefully a alias/token handled by a payment service provider for the real credit card (which would not expose you to certification)
• Unless the alias/token is also a 'masked' representation of the real credit card number (e.g. the last 4 digits of alias/token and credit card are identical) there would be no real advantage of masking an alias/token at all
• Credit Card Numbers / Alias/Token are mainly used in SAP system for subsequent new transactions
  To reference the current transactions, there are reference numbers (AUTRA, AUNUM) and hopefully a UUID reference number from the payment service provider in a 'custom' SAP field to identify the transaction and communicate with the payment service provider for follow up transactions
• A masked version of a credit card number is mainly used to help identify the customer's card that was used, without giving away the entire card number

Credit Card encryption in SAP system

• In table FPLTC there is a field CCARD_GUID, which stores the reference to Encrypted Payment Card Data, if that is filled, the field CCNUM in FPLTC should not be filled, or contain the masked number
• During GUI processing or interface processing, a masked number gets replaced by the encryption logic with the real card number
• These are the FMs that decrypt the encrypted card numbers:
  FM CCARDEC_READ reads encrypted data based on CCARD_GUID
  FM CCARD_DEVELOPE decrypts and reveals card number
• These are the FMs that encrypts a plain text card number:
  FM CCARD_ENVELOPE encrypts a plain text card number
  FM CCARDEC_FIND checks by encryption hash, whether encrypted card data has been stored already, and if so, give the CCARD_GUID for that record
• Encryption is different from Masking, with Masking there is still the need to store the card number in plain text, with Encryption, the card number is encrypted and not stored as plain text in the database. However, whoever has access to decryption functions, can read the card numbers in plain text
• Masking of a plain text card number is done via FM CCARDEC_MASK masks a plain text card number together with the card type
• The report CCARDEC_CHECK helps to find certain errors with credit card encryption and encrypted credit card number data
• What system and release are you currently on? There are different encryption technologies: PAYCRD, CCARD and the latest PAYCRV with S/4HANA
• Encrypted card data is stored in different databases, depending on the encryption version:
  CCARDEC - Payment Cards in FI, SD and Customer Master
  PCA_SECURITY_RAW - Payment Cards and SAP Business Partner. In S/4HANA systems, you must execute a migration program.
  CCSEC_ ENC - Other payment card processes. The table is used if the indicator for periodic key replacement is not set in Customizing.
  CCSEC_ENCV - Other payment card processes. The table is used if the indicator for periodic key replacement is set in Customizing.
• Whats your customizing setting in "Cross-Application Components => Payment Cards => Basic Settings => Make Security Settings for Payment Cards"?
  Is it "Masked Display, and Encrypted When Saved."?
• Is encryption turned on for certain/all credit card types " ... => Maintain Payment Card Type"? (customizing table CCARDEC_CUST Encryption of Payment Card Type)

Further information:

• 1032588 - Secure handling of credit card data in ERP
  https://launchpad.support.sap.com/#/notes/1032588

• Migration and Encryption/Decryption programs:
  PCA_MASS_CRYPTING Encryption or Decoding as Mass Processing
  RCC_MIGRATION Migration of Payment Card Data in Business Partner Master Data
  RCCSEC_MIGRATION_001 Credit Card Lot Encryption
  RCCSEC_MIGRATION_002_003 Encryption of Card Data Supplements
  RCCSEC_MIGRATION_004 Promise to Pay Encryption
  RCCSEC_MIGRATION_005 Encryption of Payment Data - Payment Program
  RCCSEC_MIGRATION_006 Encryption of Information for Payment Medium
  RCCSEC_MIGRATION_007 Encryption of Payment Specification
  RCCSEC_MIGRATION_012 Encryption of Prepaid Accounts
  RCCSEC_MIGRATION_040 IS-M/AM: Encryption of Payment Cards From Order and Billing Docume
  RCCSEC_MIGRATION_042 IS-M: Encryption of Payment Cards in IAC Temporary Tables
  RCCSEC_MIGRATION_045 IS-M/SD: Encrypt Payment Cards in Order and Billing Document
  RCCSEC_MIGRATION_060 Include RCCSEC_MIGRATION_060
  RCCSEC_MIGRATION_070 HCM Infotype 0105 Credit Card Encryption Data Conversion
  RCCSEC_MIGRATION_075 Migration of Credit Card Encryption in Travel Management
  RCCSEC_MIGRATION_080 SSR PC encryption migration program
  RCCSEC_MIGRATION_121 Credit Card Encryption - T77REFDOC
  RCCSEC_MIGRATION_ITAGCY Agency Collections: Encryption of Credit Card Data

[former_member588480]

Thank you for all these information.

Please find my reponse below for your question .

Do you actually have real credit card numbers in your SAP system?

Yes , as shown in the screenshot for some record in FPLTC , credit card number(CCNUM) is not coming in encrypted format.that is the reason i am trying to figure out why this is happening for only record of FPLTC table.

I assume, that for the purpose of the screenshot, you actually changed the real value for the credit card number

Yes , you are right . I have changed the actual credit card number . actual amex card number start with “37” or “34”.

Whats your customizing setting in "Cross-Application Components => Payment Cards => Basic Settings => Make Security Settings for Payment Cards"?
Is it "Masked Display, and Encrypted When Saved."?

yes , it is Masked Display, and Encrypted When Saved . screenshot atatched .

Is encryption turned on for certain/all credit card types " ... => Maintain Payment Card Type"? (customizing table CCARDEC_CUST Encryption of Payment Card Type)

yes encryption is tuned on . screenshot attached .

What system and release are you currently on?

ECC system and 740 release .

As understood from your explanation , based on the confiuration under "Cross-Application Components => Payment Cards => Basic Settings => Make Security Settings for Payment Cards" system should automatically mask and encrpte the credit card value . Am i correct ? if yes then why some reord of table FPLTC is not getting masked and encrpted .

If No then what can be the reason , is it becasue of some custom code is running in the backround , that i have to check ?

Please correct me if my understanding is not right .

Also I noticed this issue is exist mostly when we have more than 2 record in table FPLCT for a single FPLNR value as i have mentioned earlier screenshot and especially incase of FPLTR = 900001 / 900002 not incase of 000001 . Not sure why ?

Currently as per the requirement , I have to stop this issue getting repeated in the furture so that new record will always get created with masked and encrypted credit card value in table FPLTC .

for existing credit card values in FPLTC table, which are not masked and encrypted , we are keeping it as it is , may be in furture I have to write a custom program to mask and encrypte those record.

Regards,

Prabin

[former_member588480]

Hi Michael Piesche

How do sales orders with credit cards get created in the SAP system, and how do transactions get created?

In our case Credit card details are entered manually by separate team once they get the credit details from Customrer.So we are sure that card details are not stored while creating sales order .

What is the CCARD_GUID

What is the authorisation type

What is the call status (CCALL), what is the reaction (REACT)

please find below screenshot for the above fields value detail

What are the sales document types

Document type is H (Return)

Are there any change documents in CDHDR, CDPOS for when and by who those records where created?

there is no entry for FNAME = CCNUM in CDPOS

I checked the logic in custom FMs for authorisation and settlement in cust. table TCCAA (FNAUT,FNSET) but Looks like there is no logic to change the credit card numner (CCNUM) . Not sure if I have to debug to check if there is any custom code related to CCNUM while saving credit card details in order?

Thank you for the Reports to encrypt all ccnums in FPLTC and BSEGC .

[michael_piesche]

prabinkumar, just to inform you, I changed both detailed comments to answers, as i think they serve a better purpose as answers than as comments.

[sam]

Hi Prabin,

First check how its currently getting masked for other 2 fields.Seems You have UI masking enabled.

There are below SAP ERP add-on solution for UI Masking applicable for GUI, Webdynpro, SAP UI5 ( Gateway )

ECC: UIM

S/4HANA: UISM

Once its installed, then you can configure from SPRO for Table Field, Data Element, Dypro-Fields based upon authorization.

Let me know if you need more detail.

Regards
Samir

[Lakshmipathi]

OSS note 1947100 will answer your query. Also, if you're hoping to connect with readers, please consider adding a picture to your profile. Here's how you do it:

https://www.youtube.com/watch?v=F5JdUbyjfMA&list=PLpQebylHrdh5s3gwy-h6RtymfDpoz3vDS.

By personalizing your profile with a photo of you, you encourage readers to respond.

[svs_sap]

Hi ,

There are new data masking solutions in SAP via UI5 . Check if any such thing applied in your landscape and masking performed on selective customers.

Regards,

Sharat