2007 Jan 09 9:00 PM
We have added logic to process Discover Credit Cards (Copy function group V21G, function module CCARD_CHECK_AMEX and modified it for Discover credit card processing.)
That is working fine, the issue now is that the Discover Credit card numbers are not masked in VA02.
Visa and Master Card numbers are masked with *********.
Any idea what I'm overlooking to get the Discover cards masked? Is this a BASIS function or something I overlooked in the code?
Thanks,
Allen
2007 Jan 09 9:52 PM
Hello Allen
I am currently working in a project dealing with credit card payment of sales orders, too. Here in Europe (at least in Switzerland) it is not allowed to store credit card numbers within SAP systems. Also the customer is very keen on having no knowledge whatsoever about the credit card or its holder.
Coming back to your question the fact the credit card number is not masked for AMEX in transaction VA02 is most likely due to a <b>missing customizing entry</b> (presumably a <b>field status</b> for the corresponding field).
Regards
Uwe
2007 Jan 09 9:52 PM
From a previous Thread:
have a look at <b>http://en.wikipedia.org/wiki/Credit_card</b> for the checksum of Credit Card's. I think this function is implemented in CCARD_CHECK_LUHN_MOD_TEN. I think you should try to copy CCARD_CHECK_VISA to Z_CCARD_CHECK_DISCOVER and adapt this module to your needs.
- Guru
Reward points for helpful answers
2007 Jan 09 9:52 PM
Hello Allen
I am currently working in a project dealing with credit card payment of sales orders, too. Here in Europe (at least in Switzerland) it is not allowed to store credit card numbers within SAP systems. Also the customer is very keen on having no knowledge whatsoever about the credit card or its holder.
Coming back to your question the fact the credit card number is not masked for AMEX in transaction VA02 is most likely due to a <b>missing customizing entry</b> (presumably a <b>field status</b> for the corresponding field).
Regards
Uwe
2007 Jan 10 1:13 AM
I have found OSS Notes 633462 on encryption and masking.
(This note says that the credit card info must be stored encrypted, legal reasons, but does not say what legal system, guessing it's US, obviously different for you)
Some other notes are 894022, 662340 and 766703.
Some good info on the encryption logic, would assume you encrypt the data before transfering it out of SAP.
The missing customizing entry might be a possibility.
I don't do the configuration. I'll follow up on that.
Grrr, this should not be this difficult!
Must be something simple that is being overlooked.
Thanks.
2007 Jan 10 5:28 AM
Hello Allen
Since the authorization is done externally followed by creating the sales order via online interface in SAP we do not have any payment card information (except for the credit card type) in the SAP system and, therefore, do not need any encryption.
To fulfill the customizing requirements (CCNUM is mandatory) we simply use dummy credit card numbers (e.g. VIS_DUMMY for Visa).
If you look at the element list of screen
4441 (SAPMV45A)
you will see that the credit card dynpro fields have set attribute valueGROUP3 = '037'
(NOTE: on our ECC 5.0 system).At PBO of screen 4441 you will find the following module:
* Tabstrip Karte 4.0: Subscreen: Übersicht Verkauf Gut-/Lastschrift
* PBO *****************************************************************
PROCESS BEFORE OUTPUT.
* Aufruf der Funktionsbausteine zur Feldauswahl
MODULE FELDAUSWAHL.
At the end of module FELDAUSWAHL you will find:
* Userexit
PERFORM USEREXIT_FIELD_MODIFICATION.
Finally, here is the coding of this user-exit:
*---------------------------------------------------------------------*
* FORM USEREXIT_FIELD_MODIFICATION *
*---------------------------------------------------------------------*
* This userexit can be used to modify the attributes of *
* screen fields. *
* This form is processed for each field in the screen. *
* *
* The use of the fields screen-group1 to screen-group4 is: *
* *
* Screen-group1: Automatic modification contolles by transaction*
* MFAW. *
* Screen-group2: Contents 'LOO' for steploop-fields. *
* Screen-group3: Used for modififaction, which are dependent on *
* control tables or other fix information. *
* Screen-group4: Unused *
* *
* For field mofifications, which are dependent on the document *
* status, you can use the status field in the workareas *
* XVBAP for item status and XVBUK for header status. *
* *
* This form is called from module FELDAUSWAHL. *
* *
*---------------------------------------------------------------------*
FORM USEREXIT_FIELD_MODIFICATION.
* CASE SCREEN-GROUP3.
* WHEN '900'.
* IF VBAK-VBTYP NE 'A'.
* SCREEN-ACTIVE = 0.
* ENDIF.
* ENDCASE.
* CASE SCREEN-NAME.
* WHEN 'VBAK-VBELN'.
* SCREEN-ACTIVE = 0.
* ENDCASE.
ENDFORM.
*eject
Perhaps this it the place where to place the encryption logic.
Regards
Uwe
2007 Jan 10 1:59 PM
Thanks, there was a missing configuration entry. I don't do the configurations but followed up with the team that does.
Here was his reply "update view CCARDEC_V"
Thanks!