SSDCS validations

SSDCS provides input validation, session validation, and PAN validation.

Input validation

Input validation occurs on the fields that are passed in, as described in the following table. All alphabetical characters accept uppercase and lowercase letters. If a field is listed as N/A, its input is discarded immediately after invoking the servlet because its result is always computed and its previous result is not desired. Unless otherwise specified, numeric validation does not validate negative numbers.

Input validation that occurs on the fields

Field Name Extensible Validation
ssdcsAuthenticationToken Yes Alphanumeric
ssdcsCssUrl Yes This must be the same domain name as the request, with an optional port. The remainder of the URL must consist of alphanumeric characters, a period, a slash, an underscore, or a hyphen, and it must end with .css.
ssdcsRedirectUrl Yes This must begin with /jsp/, end with .jsp, and contain only alphabetical characters or underscores in between.
ssdcsDataType Yes Alphanumeric plus underscore.
ssdcsDataTypeDetail By data type Known DataType: Alphanumeric plus underscore, space, and hyphen

Unknown DataType: No match allowed.

ssdcsDataToTokenize By data type Known DataType: Numeric. Prior to validation, all special characters are stripped.

Unknown DataType: No match allowed.

ssdcsToken Yes Alphanumeric
ssdcsDisplayValue By data type Known DataType: Numeric

Unknown DataType: No match allowed.

ssdcsResultCode No INITIAL, FAIL, or SUCCESS
ssdcsFailReason No N/A
ssdcsResultDescription No N/A
ssdcsTabIndex Yes Numeric, including negative numbers
ssdcsAdditionalResultData No N/A
ssdcsAutoSubmit No Y or N
ssdcsDbg Yes Y or N

Validation patterns are stored in the ESAPI.properties file, and have Validator.ssdcs. as a prefix. The ESAPI reference implementation will internally use the patterns that have Validator. as a prefix. If the property is not configured, the defaults listed in the previous table are used. The Extensible column in the previous table indicates the fields that support extensibility by data type by additionally prefixing the value of ssdcsDataType in the Validation property. The ssdcsDataType will be checked first to see if the validation is extended. For example, to set a different validator for credit card numbers:


Validator.ssdcs.ssdcsCreditCardNumber.ssdcsDataToTokenize
Validator.ssdcs.ssdcsDataToTokenize

Session validation

Before SSDCS processes any PAN, it validates with Sterling Selling and Fulfillment Foundation that the session token passed to it in the ssdcsAuthenticationToken field is a valid session. This token is created using the createAccessToken API call. For information about the createAccessToken API, refer to the Sterling Selling and Fulfillment Foundation Javadocs. If the session is not valid, the Sterling Selling and Fulfillment Foundation servlet returns an INVALID_SESSION error.

Credit card, debit card, and stored value card validation

SSDCS runs the Luhn algorithm to validate that credit card numbers and debit card numbers are entered correctly. An interface is also exposed to enable the implementation of an alternative validation algorithm (for example, to validate a stored value card). The ssdcs.ue.PanValidator user exit property is used to configure the implementation of this interface. When this is implemented, the built-in algorithm will be skipped and the implementation will return the result. This user exit may defer validation to the internal Luhn algorithm by not returning a validation value for credit cards and debit cards. Stored value cards may use the user exit to validate them. However, only credit cards and debit cards run the internal Luhn algorithm, after or instead of the user exit call. By default, all the stored value card numbers are valid.

Both the interface and the default logic will also compute the Credit Card Type as part of the validation, if possible. For example, all Visa credit cards begin with a 4, so if the credit card number passes validation, then the card type will be returned as Visa.

Note: The ssdcs.ue.PanValidator user exit contains the name of the payment type configured in the Sterling Selling and Fulfillment Suite in its input, which is populated from the ssdcsDataTypeDetail field. This field is provided to customize branching logic, based on the payment type being tokenized. IBM® recommends that if the payment type is an unknown type, you revert to a default logic that will still provide validation.