Credit Card Encryption - executing tcode SSFA

Hi all,
I have searched SDN and various other site for information on what the correct sequence is to execute the tcode SSFA.  We have applied the OSS Note 66462 requirements (see below) but cannot figure out how to execute step 5 - can anyone please give any advice?
To activate encryption, your system must meet the following requirements:
1. For Release 4.6C, you must import Support Package SAPKH46C46 and
2. Kernel 4.6D must have patch level 1329 (see Note 565111).
3. For Release 470, you must import Support Package SAPKH47022.
4. For Release ERP 500, you must import Support Package SAPKH50007.
5. Download and install SAPCRYPTOLIB (see Note 662340). You must use the CCARD application when you use Transaction SSFA to set up encryption.
For what it is worth - we are on 4.6C and AFS3.0B

The Basis and Security people got this done

Similar Messages

  • Credit card file upload(Tcode: PRCC) in a batch process

    Hi all,
    Is it possible to make credit card file upload(Tcode: PRCC) in a batch process.
    when i tried doing so got message "frontend function cannot be created in batch mode" .
    I am aware that it is because this program is using "GUI_UPLOAD" function module which is for front end only and not for background processing.
    But as this is standard program I cannot change method of uploading flat file.
    Please suggest me any method to solve my requirement. I need to make credit card file upload in a batch process.
    Thanks ,
    Snehal

    Check mark parameter 'File is not local' for SAP to read file from application server (file is read using open dataset instead of gui_upload). This would allow you to run this tcode in background.

  • Credit card encryption not working

    Hi CRM - Payment card experts,
    We have a issue, where in the CRM is interfaced with Paymetric for credit card processing. As per the design, the credit card encryption should work. But, i see no encryption happening in the crm order.
    Please suggest, where could  be the problem.
    Thanks.
    Regards,
    Phaniraj

    Hi,
    Can you please be more specific with your problem.
    Can you please let us know where exaclty you are doing the card number encryption(BAPI/BADI/RFC/FM).
    Please let us know if you are calling some third party for doing this encryption.
    If you are doing the encryption internally(not calling any external third party) than you can check by debugging whether your encryption code is getting called or not,
    If its a third party validation/encryption than check for the rfc connections.
    If you want to write the new logic for encryption than write it in the same place where card number validation(Luhn's formula credit card validation) code is written.
    Regards,
    Arshi
    Edited by: Arshi Arshi on Jun 15, 2009 9:38 AM
    Edited by: Arshi Arshi on Jun 15, 2009 9:42 AM

  • Credit Card Encryption & System Copy

    Hi All,
    We have done a system copy from PRD back to QA (credit card encryption is activated on both servers). The customer would like to be able to read the PRD data including the credit card details but of course the QA system can only de-crypt its own data and not the PRD data. Is there a way of de-crypting the PRD data that is already within QA and then re-encrypt using QA key?
    I didn't set up the original encryption so I am learning about this as I go.
    Thanks.

    >
    Natalie wrote:
    > Well, I have advised this to my customer, but at the end of the day the customer owns the system and he wants to be able to see the Productive data in the QA system.
    Well, the upper management of this customer is finally (legally) responsible to ensure that access to this sensitive data is controlled and restricted (no matter where it is stored - if the data is replicated then all storages need to be protected with the same strong mechanisms).
    Usually access to non-productive systems is much easier (less restrictive). So, the customer is taking quite a huge risk that this sensitive data might be less protected than (legally) required.
    Aside of legal consequences the loss of trust / reputation might impose an even higher (business) risk. I would consider twice ... (but I'm not the CEO nor the CIO of that customer) ...
    PS: for your own protection I'd strongly recommend that you inform the customer on those risks (in written form) and let him sign-off that you've warned him ... (otherwise you might be kept liable as well - if being engaged as adviser / consultant).

  • Credit Card Encryption through RFC calls to third party software

    Dear All,
       I am working on credit card encryption in CRM. At our firm, we have SAP R/3 which is integrated with third party server for performing credit card encryption using RFC calls. We want to perform similar thing in SAP CRM. I was looking into SAP standard mechanism to perform encryption and it seems they use class CL_PCA_SECURITY -> External Encryption to encrypt credit card. Are there any BADIs available for me to change behaviour of this call and call our listeners (for third party server) instead of what standard SAP is calling. Here is what in the code:
    call C function 'SSFENVELOPE'
      CALL 'SSF_ABAP_SERVICE'                                 "#EC CI_CCALL
           ID 'OPCODE'             FIELD   SSF_OPCODES-ENVELOPE
           ID 'SECTOOLKIT'         FIELD   SSFTOOLKIT
           ID 'STRFORMAT'          FIELD   STR_FORMAT
           ID 'STRFORMATL'         FIELD   STR_FORMAT_L
           ID 'BINENC'             FIELD   B_INENC
           ID 'IOSPEC'             FIELD   IO_SPEC
           ID 'OSTRINPUTDATAL'     FIELD   OSTR_INPUT_DATA_L
           ID 'STRPAB'             FIELD   STR_PAB
           ID 'STRPABL'            FIELD   STR_PAB_L
           ID 'STRPABPASSWORD'     FIELD   STR_PAB_PASSWORD
           ID 'STRPABPASSWORDL'    FIELD   STR_PAB_PASSWORD_L
           ID 'OSTRENVELOPEDDATAL' FIELD   OSTR_ENVELOPED_DATA_L
           ID 'CRC'                FIELD   CRC
           ID 'OSTRINPUTDATA'      FIELD   OSTR_INPUT_DATA-SYS
           ID 'RECIPIENTLIST'      FIELD   RCPTAB-SYS
           ID 'OSTRENVELOPEDDATA'  FIELD   OSTR_ENVELOPED_DATA-SYS
           ID 'STRSYMENCRALG'      FIELD   STR_SYM_ENCR_ALG
           ID 'STRSYMENCRALGL'     FIELD   STR_SYM_ENCR_ALG_L.

    Vivek,
    While it may be technically possible to accomplish what you are suggesting (leveraging the encryption functionality provided by your third-party server) I would recommend strongly that you consider a token-based solution instead.  You can learn more about tokenization on this [blog|/people/eric.bushman4/blog/2009/01/02/tokenization-as-a-means-of-securing-credit-card-numbers ].
    There are many reasons why a token-based solution is superior to using application specific encryption (as outlined in the blog), but specifically in the case you describe where an SAP CRM and SAP R/3 are involved there is one specific reason to consider:
    When order data is replicated between SAP CRM and SAP R/3 the systems will attempt to decrypt the credit card numbers prior to passing the data and therefore the RAW card number will be stored in the middleware logs.  This is especially true when using SAP's native credit card encryption logic in the CRM and R/3-ECC applications. 
    For example, let's say a user enters a credit card as the form of payment during Order Creation in CRM.  At Order Save the system will send the credit card information to your third-party server for an authorization attempt and the results will be returned to CRM.  As the Order is saved and committed to the CRM database the standard SAP encryption functionality can be leveraged to encrypt the card data.  Based on your middleware configuration, eventually the Order data (including the credit card details) will be sent to the R/3 or ECC system.  In order to do so the CRM system will first decrypt the card number meaning that the CRM middleware logs will contain RAW card numbers.  When the Order is created in R/3 or ECC the native credit card encryption functionality in R/3 or ECC could be used to encrypt the card number prior to the Order being stored in the database.
    Should you choose to use a third-party server you may find, depending on how the third-party vendor's logic works in SAP, that you must utilize a BADI to decrypt the card number in CRM so that the CRM middleware has a RAW card and so that when the Orders is saved in the R/3 or ECC system it can be encrypted again with the third-party vendor solution.  In either case the RAW card number is present in all systems for some period of time and potentially stored in logs thus exposing your systems to risk and greater PCI audit scrutiny.
    Eric Bushman
    VP, Solutions Engineering
    [Paymetric|https://www.paymetric.com]

  • Credit card encryption-decryption

    We are going in for credit card enryption.Once a credit card is encrypted,can it be decrypted back again?Is there any transaction to do that?
    Jen

    Hi Jennifer
    The link will answer your question
    http://help.sap.com/saphelp_47x200/helpdata/en/68/de611988ac11d194be00a0c92946ae/frameset.htm
    Thanks
    G. Lakshmipathi

  • Credit card encryption in table BUT0CC & CCARD

    Hi,
    We are on SAP IS-UT release 604. We are capturing Customer credit card information at business partner level (FPP2). The credit card information is displayed as masked on the BP screens. However this is not stored as encrypted in underlying SAP tables BUT0CC and CCARD.
    Can you please let me know how it is possible to store encrypted card in these tables?
    Thanks
    Shadab

    Shadab,
    there are various notes available explaining how to encrypt data in SAP:  e.g. 662340, 842087, 836079, ...
    You migh also check-out the IMG activity SPRO -> Cross Application Components -> Payment Cards ->           
    Basic Settings -> Maintain Payment Card Type -> "Encryption" (Flag)
    Cheers,
    Fritz

  • Credit Card Encryption Question

    Question from my customer (on EBS 11i):
    I have a question about the Visa VCF 4 Transaction Loader. We are working
    on automating this process and have installed a secured storage area to
    hold the file. It is my understanding that the bank is going to send us an
    encrypted file.
    Is the Visa VCF 4 Transaction Loader can process a PGP encrypted file?
    Your help is appreciated - thanks!

    The answer is that you do not store the ciphertext in the card number field. You create a reference number which is 25 bytes long that substitutes for the card number, and is stored in the card number field. The reference number, in turn, is also stored in a custom table with the ciphertext. The reference number is a unique key to that table.
    You then create translation routines to encrypt/decrypt the ciphertext based on the reference number that you stored. These routines would be passed the card number field, which contains the reference number. The input parameter list for these routines are standard. The routines that do the encryption/decryption are configured to be called at the appropriate times.
    - Brendan

  • Credit Card Payment at time of SO creation - Basic questions

    Most of our customers pay by credit card at the time of Sales order creation. (80% of times)
    Now sometimes they pickup the order at the same time and sometimes we follow the normal delivery process and ship material to them.
    Now we are not sure what document type or process flow will fit this process.
    Should we be using two different document types/ process to meet this requirement.
    Thought of using standard order type but then as they have already paid at the time of order creation we Dont want to send Invoice at Billing stage
    Shall we use Rush order or cash order for our requirement. (But they dont pickup material all the time, sometime we ship)
    Also if we maintain credit card information at Customer Master level, will it flow down to sales order and Biiling process.
    Thanks in advance.

    Jeet,
    I have worked with over 350 SAP customers over the last 14 years who have implemented the SAP Payment Card Processing business logic.  The majority of them use an integrated solution so that SAP submits the Authorization requests through SAP's Cross Application Payment Card Interface (CA-PCI) during Sales Order Save.  Some of them use external devices\applications to perform the Authorizations outside of SAP and simply use the SAP business logic to record those transactions.
    I would recommend you consider continuing to use the SAP Payment Card Processing business logic with your external Authorization process so that you can take advantage of the GL posting automation that SAP performs when an Invoice is posted to Accounting.  Namely that SAP will CREDIT the Customer AR account and DEBIT the Credit Card Receivable account for the card type used.  This is of great benefit to the Merchant because it eliminates the need for someone to MANUALLY post the payments to clear the open items on the Customer AR account once the Settlement deposit is received.
    Another advantage is that, when researching customer orders in SAP, you'll be able to see the card details that were used for payment.  Just be certain to activate SAP's credit card encryption logic or use a third-party Tokenization solution to secure the data.
    Eric Bushman
    [www.paymetric.com|http://www.paymetric.com]

  • How to see masked Credit Card number in Sales Order !!

    Hi,
    In our SAP system credit card enceryption is activated. Certain users want to see the credit card number in the sales order change/display screen.We are in SAP ECC 6.0.
    Please let me know how we can achieve this.
    Thanks
    Ambuj

    Dear Ambuj,
    There is no possibility to view the credit card number unmasked in the sales order. You will always get the masked number even if you have C4 authorisation ('C4' action for the V_VBAK_AAT authorisation object). You can view the unmasked credit card number in transaction XD02/XD03.
    If you use BAPISDORDER_GETDETAILEDLIST to view the order then the C4 authorisation will be checked and the unmasked number will be displayed (if the user has this authorisation).
    If you have access to OSS notes then please check 836079 (FAQ: Credit card encryption and master data) and 766703 (FAQ: Credit card encryption in R/3 systems).
    I hope this helps.
    Best regards,
    Ian Kehoe.

  • Is there any off the shelf credit card enryption/decrption tool available ?

    Since, Credit Card (CC) processing is very critical , my company is looking for options which are available in the market -ready to use !!!
    Is there any off the shelf credit card enryption/decrption tool available ?

    What is "credit card encryption/decryption"?
    1) Are you willing to encrypt and decrypt credit card numbers in a safe way, to store them in a database?
    - JCE and crypto
    2) Are you willing to communicate with the credit card companies to perform credit card transactions in a safe way?
    - Contact them; there are third-party companies that sell solutions for communicating with Visa, Mastercard etc; the credit card company can tell you what company they recommend
    3) Are you trying to validate the credit card numbers (no online processing needed, just validate the card numbers in Javascript)
    - search for Luhn's algorithm

  • Credit Card config and encryption

    Hi frnds
    I would appreciate if anyone can provide the config steps for credit card and also the step for encrytion. If you have a doc on it then please mail it to [email protected]

    hi
    CREDIT CARDS
    Go thr below links:
    PAYMENT CARDS:
    http://help.sap.com/printdocu/core/Print46c/en/data/pdf/SDBILIVPC/SDBILIVPC.pdf
    http://help.sap.com/saphelp_erp2005vp/helpdata/en/93/745309546011d1a7020000e829fd11/frameset.htm
    Overview
    This document attempts to explain in the brief the credit card processing in SAP.
    SAP provides a flexible and secure payment card interface that works with the
    software of selected partners that provide merchant processes and clearing house
    services. In SAP the credit card processing is integrated with the sales and
    distribution module.
    Payment card configuration
    Much of what is required for credit card processing to work with VISA, Master
    Card, and American Express is already set up in SAP.
    For all credit card configurations refer to
    Define Card Types
    Transaction SPRO IMG ‡ Sales and Distribution ‡ Billing ‡ Payment Cards
    Here we define the type of cards that can be used in the system. A four-letter
    code is given for each card type. E.g. MAST for Master Card, VSAJ for Visa
    Japan. A function module for checking the card number is also specified here.
    1. Define Card Types
    Credit Card Configuration And Processing In SAP
    Maintain Card Categories
    (a) Define card Categories: Here we specify the card category of the
    payment card. With this the system automatically determines the card
    category when you enter a card number in master data or sales
    documents.
    (b) Determine card categories: Here we specify the acceptable number
    ranges for different card types. Also card categories are assigned to the
    card types. Even though SAP comes with card checking algorithms
    (Function Modules) for standard card types this configuration setting
    is particularly useful to those cards that do not contain any standard
    checking algorithm already set up in SAP.
    2. Determine Card Categories
    Maintain Payment Card Plan Type
    In this step, you assign the payment plan type for payment cards, the payment
    card plan type, to all sales document types in which you will be using payment
    cards. You cannot process payment cards if you have not made this assignment
    The standard system contains payment plan type 03 for processing payment
    cards. 3. Show the screen where this assignment is done.
    Credit Card Configuration And Processing In SAP
    3. Maintain Payment Plan Type
    Maintain Blocking Reasons
    In this step, you define blocking reasons for payment cards. You enter these in
    the payer master record to block cards. The standard system contains blocking
    reason 01 for lost cards.
    Risk Management for Payment Cards
    Transaction SPRO IMG ‡ Sales and Distribution ‡ Billing ‡ Payment Cards
    ‡ Authorization and settlement ‡ Risk Management for payment cards.
    Risk Management plays a central role within Sales, providing you with checks
    and functions to minimize your credit risk. In addition to letters of credit and
    export credit insurance, payment cards are among the payment guarantee forms
    that you can use to insure payment for sales order items. SAP comes with predefined
    payment forms of guarantee as shown below. Customer can also
    maintain other forms of payment suited for their line of business.
    Credit Card Configuration And Processing In SAP
    Define forms of payment guarantee
    3. Define forms of payment guarantee
    Maintain payment guarantee procedures
    In this step, you define Payment guarantee procedure. These procedure controls,
    which form of payment guarantee, are valid for a particular customer, and for a
    particular sales document type.
    The various settings done under this configuration are
    Define payment guarantee procedures
    Maintain customer determination procedure
    Maintain document determination procedure
    Assign sales document types
    Determine payment guarantee procedures
    Maintain authorization requirements*
    Here requirements* are set to tell the system how and when to carry out
    authorization when a sales order is saved. SAP comes with two requirements
    Form routine 1. Carry out authorization only when the sales document is
    complete. The system carries authorization when the order is saved.
    Form routine 2. Carry out authorization only when the sales document is
    complete, but the authorization for all the complete documents is carried out in
    batch.
    Additional requirements* can be assigned here as per the business requirements.
    *Requirements are ABAP/4 code. Requirements for various functions can be accessed using transaction VOFM
    Credit Card Configuration And Processing In SAP
    4. Maintain Card Authorization Requirements
    Maintain Checking Groups
    How and when authorizations are carried out depends on the setting you make in
    the customizing for maintain checking group routines.
    The three main settings that influence authorization are:
    a) Authorization requirements
    b) Authorization horizon
    c) Preauthorization
    There are two settings under this setting.
    Define checking group: Here a checking group is defined and the
    authorization requirement (described in the previous section), Authorization
    horizon (described below) and preauthorization settings are done for this
    checking group.
    5. Define Checking Group
    Credit Card Configuration And Processing In SAP
    Here you can see a checking group C1 is defined with the authorization
    requirement 902. Checking the pre-authorization tells the system to carryout preauthorization
    if the order fulfillment date falls outside the horizon. The
    authorization horizon specifies the number of days before the material
    availability date, or billing date, that the system is to initiate authorization. If a
    sales order is saved within the authorization horizon, the system carries out
    authorization immediately. If a sales order is saved before the authorization
    horizon comes into effect, the system does not authorize at all, or carries out
    preauthorization.
    6. Preauthorization Concept
    In this example, the system has been set to authorize one day before delivery
    creation. The system does not carry out authorization when the order is saved on
    Day 0, rather on Day 2. Note that the authorization validity period has been set to
    14 days in Customizing IMG‡ Authorization and settlement‡ Specify
    authorization validity periods. The transaction will have to be reauthorized if
    delivery activities take longer than 14 days.
    Assign checking groups: Here the checking groups defined earlier are
    assigned to different sales document types as shown 8.
    Specify authorization validity periods
    Here number of days that an authorization can remain valid for different card
    types are maintained. Refer to 9.
    Credit Card Configuration And Processing In SAP
    8. Assign checking groups
    9. Assign validity period for authorization for different card types
    Credit Card Configuration And Processing In SAP
    Account Determination
    Transaction SPRO IMG ‡ Sales and Distribution ‡ Billing ‡ Payment Cards‡
    Authorization and settlement ‡ Maintain Clearing House
    In the following steps, you set the condition technique for determining
    clearinghouse reconciliation accounts for authorization and settlement. The
    system uses the entries here to determine the clearing account for the payment
    card charges. When settlement is run, the postings in the receivable account for
    the payment card will be credited and a consolidated debit will be created and
    posted to the clearinghouse account. These accounts are a special type of general
    ledger account that is posted from Sales and Distribution.
    Here, you maintain:
    • Maintain field catalog.
    • Condition tables and the fields that they contain
    • Access sequences and condition types
    • Account determination procedures
    • You then assign these accounts to condition types.
    Add to field catalog
    Here you maintain the fields that can be used in the condition table. 10.
    Shows the transaction to maintain the field catalog.
    10. Maintain Field Catalog.
    Maintain condition tables
    Here condition tables are maintained with fields that are added to the field
    catalog. SAP comes pre-configured with two condition tables 4 and 6. Refer
    11.
    Credit Card Configuration And Processing In SAP
    11. Maintain Condition Table
    Maintain access sequences
    In this step we define an access sequence and link the access sequence with the
    condition tables.
    Here an access sequence is defined. SAP comes with the access sequence A001.
    12. Define Access Sequence
    Once the new access sequence is defined, it is linked to the condition tables as
    shown in the next screen.
    Credit Card Configuration And Processing In SAP
    13. Maintain Access For Access Sequence
    Selecting an access and clicking fields will display the fields for the selected
    access as shown below for access 10 as shown above.
    14. Display Access Fields
    Maintain condition types
    Here condition types are defined and the access sequence to linked to it.
    Condition types are contained in account determination procedures and control
    which access sequences the system uses to find condition records.
    These are The condition tables.
    Credit Card Configuration And Processing In SAP
    15. Define condition type
    Maintain account determination procedure
    In this step an account determination procedure is defined and linked to the
    condition type (which in turn is linked to the access sequence).
    Define account determination procedure
    16. Assign account determination procedure.
    Here an account determination procedure CC01 is defined and the condition type
    CC01 is assigned to it.
    Access sequence linked to the condition type
    Credit Card Configuration And Processing In SAP
    Assign account determination procedures
    In this customizing the previously set up account determination procedure is
    assigned to different billing documents.
    Assign Accounts (G/L)
    G/L accounts are assigned here for the combination of Sales organization, Card
    type, chart of accounts and condition types as shown in the 17.
    17. Assign G/L accounts
    Set authorization / settlement control per account
    Each G/L account is assigned an authorization and a settlement function module.
    The system will read the configuration a call the authorization and settlement
    function module during authorization and settlement respectively.
    Credit Card Configuration And Processing In SAP
    18. Set Authorization and settlement function module
    Maintain merchant IDs per account
    A merchant may have one or more IDs for each clearinghouse with which it does
    business. Here, you assign these different merchant IDs to their related
    receivables accounts.
    19. Assign Merchant ID’s
    Credit Card Configuration And Processing In SAP
    Authorization and Settlement in SAP
    20. Sales Order Cycle With Credit Card Authorization
    When an order is placed through the front-end system, the order information,
    credit card information, billing information, shipping information is passed to
    SAP. SAP processes the order calculates the taxes, the shipping costs and reads
    the configuration information settings and executes the function module setup as
    described in Fig. 18. The function module formats the data and makes a RFC *
    call to the payment application**.
    The payment application screens the order for fraud, encrypts the data and
    communicates with the third party processor who in turns communicates with
    the card association and card issuer.
    *RFC (Remote Function Call)
    *Payment Application: Middle ware between SAP and third party processor/bank.
    Credit Card Configuration And Processing In SAP
    The third party processor responds back with the response whether the
    transaction is approved or declined or referred.
    Note: When any item in the order does not have a confirmed quantity, then
    authorization is not carried out for the full amount. A small dollar amount
    usually ($1) is used as the authorization amount. During the rescheduling run
    the system will check for the material availability. If the material can be
    delivered within the horizon date, a full authorization for the order is carried
    out.
    Approved: When the credit card transaction is approved the systems checks for
    the material availability, confirms the material for the ordered quantity and saves
    the order.
    Declined: The material availability check for the material is not made, and the
    order is rejected.
    Referred: The order is saved and is blocked for delivery. In this situation is
    merchant calls the bank checks for the available credit on the card and a manual
    authorization is carried out.
    21. Sales Order Entry Screen in SAP
    Payment Card
    Information
    Credit Card Configuration And Processing In SAP
    The first line in payment card screen is the card check performed by SAP system,
    using the card check algorithm function module as described in 1. And the
    remaining lines represent the actual authorizations that are carried out.
    22. Payment Card Screen
    Path Header ‡ Payment Cards.
    Settlement
    Legally the merchant can charge the credit card after the order has been
    completely processed. In SAP this happens after a delivery is created and the
    goods has been shipped. In case there is not enough authorization for the order
    to be delivered, the system goes out the get the authorization for the remaining
    amount.
    In SAP settlement is initiated using the transaction FCC1. All the valid
    authorization is submitted in a batch to the payment application at scheduled
    intervals as specified by the third party processor.
    The payment application encrypts this data and communicates with the third
    party processor. The third party processor checks if the settlement request has a
    valid authorization against it. The third party processor then transfers the fund
    from the cardholder’s bank to the merchant bank.
    Authorization
    Response
    Credit Card Configuration And Processing In SAP

  • Encrypt Credit card data - table level

    Hi Team,
    We want to encrypt the credit card data, please let me know how to do this.
    We want to encrypt the data at the table level so that the specific column cannot be viewed by others and also encrypting the column at the OS level.
    11i Version:
    Database: 10.2.0.5.0
    Apps: 11.5.10.2
    Thanks,

    Hi;
    1. Check what Shree has been posted
    2. If those note are not help you can try to use Scrambling- Data masking,see
    Re: How to prevent DBA from Seeing salary data
    3. If even its not help than rise SR ;)
    PS:Please dont forget to change thread status to answered if it possible when u belive your thread has been answered, it pretend to lose time of other forums user while they are searching open question which is not answered,thanks for understanding
    Regard
    Helios

  • Credit Card Number - Encryption

    Hello,
    I have a custom table (Z - table) which stores credit card related information. This table is getting updated from multiple programs. I would like to make the credit card number stored in encrypted form. Can any settings be done at table level which will ensure that credit card number is stored in encrypted form ?
    Thanks
    John

    hi,
    go thru this link..
    http://it.toolbox.com/wiki/index.php/How_to_encrypt_credit_cards_and_other_information_in_SAP_R/3_for_PCI_compliance_on_DB2_on_zOS_and_other_platforms
    hope this helps...

  • Bank Account number encryption similar to Credit card

    Hi All,
    Standard SAP supports the encryption of credit card in ECC and CRM but not for bank account details. Does anyone have experience in implementing/enhance the program to encrypt/decrypt bank account number or bank key?
    Cheers
    Vinod

    Any comments please?

Maybe you are looking for