Setting Up ePayment Processing

This chapter includes an overview and discusses how to:

Set up credit card types.
Re-encrypt credit card and bank account numbers.
Set up SF merchants.
Set up institution sets.
Set up item types for a payment.
Set up self-service payment messages.
Set up self-service options.

Understanding ePayment Processing

Student Financials enables your institution to receive payments for charges by eCheck or credit card through application centers, through cashiering, and over the web using self-service functionality. The rules your institution defines for authorizing and settling ePayment transactions as well as for processing ePayment credits are established when you set up your SF merchant and SF institution set parameters.

This section discusses how to define accepted credit card types.

Setting Up Credit Card Types

To set up credit card types, use the Credit Card Type component (CREDIT_CARD_TYPE).

Your institution must have contracts with credit card providers (such as VISA or Master Card) to be able to accept payments using their cards. To prevent users from attempting to record payments using unauthorized cards, you must define the credit card types accepted by your institution.

Page Used to Set Up Credit Card Types

Page Name	Object Name	Navigation	Usage
Credit Card Type	CREDIT_CARD_TYPE	Set Up SACR, Product Related, Student Financials, Credit Card Type	Define accepted credit card types.

Defining Accepted Credit Card Types

Access the Credit Card Type page.

Date Format

Select an expiration date format.

MM/DD/YYYY	Select to include the month, day, and year in the expiration date format.
MM/YYYY	Select to include only the month and year in the expiration date format.

Re-Encrypting Credit Card and Bank Account Numbers

To replace a known or suspected compromised encryption key, regenerate the encryption key and convert existing credit card and bank account numbers data using the new key. Periodic key changes can be essential to your institution's encryption key management. This section provides an overview of how to:

regenerate the encryption key
convert data using the regenerated encryption key

Understanding Encryption

PeopleSoft Enterprise Campus Solutions encryption uses PeopleTools Pluggable Cryptography, which is an advanced security framework that provides a security model for applications to encrypt credit card data.

Pluggable Cryptography enables you to secure critical PeopleSoft data and communicate securely with other businesses. It enables you to extend and improve cryptographic support for your data in PeopleTools, giving you strong cryptography with the flexibility to change and grow, by incrementally acquiring stronger and more diverse algorithms for encrypting data. In PeopleTools, pluggable cryptography capability is provided by PeopleSoft pluggable encryption technology (PET).

By using the Tools Pluggable Cryptography for strong encryption/decryption, the system encrypts data using 3DES algorithms and 168-bit encryption keys.

To replace a known or suspected compromised key, regenerate the encryption key and convert existing credit card and bank account numbers data using the new key. Periodic key changes can be essential to your institution's encryption key management.

This section provides an overview of how to regenerate the encryption key and convert credit card and bank account data using the new key.

Understanding Re-Encryption

When you change the encryption key at any time after the initial conversion, you must also re-encrypt all of your credit card and bank account numbers data using that key. Predefined encrypt and decrypt profiles are delivered for Campus Solutions re-encryption. These profiles specify multiple user-defined steps applying various algorithms and keys to the data in a specified order and supporting various encryption standards and third-party encryption libraries.

To change the credit card encryption key and re-encrypt the data, do the following:

Use the following parameters for Campus Solutions re-encryption.

Parameter	Value
Encrypt Profile ID	CS_CREDIT_CARD_ENCRYPT
Algorithm ID (encrypt)	3des_ks168_cbc_encrypt
Keyset ID	CSCreditCard
Decrypt Profile ID	CS_CREDIT_CARD_DECRYPT
Algorithm ID (decrypt)	3des_ks168_cbc_decrypt

Note. You can create your own profiles or modify the delivered ones. However, PeopleSoft does not recommend it. If you do, you must be very careful to use the appropriate values for whatever you create or modify.

Navigate to the Generate Encryption Key page (Set Up SACR, Common Definitions, Encryption, Generate Encryption Key).
Click the Generate Random Key button to generate a new random hexadecimal encryption key.

Clicking this button generates a new, random hexadecimal encryption key. You can modify this key. However, you must format it as a 24-byte string in hexadecimal notation. The first two characters must be 0x, and the remainder must be exactly 48 characters consisting of a combination of numeric digits and the lowercase letters a through f.
Copy the regenerated encryption key.
Navigate to the Algorithm page (PeopleTools, Security, Encryption, Algorithm Keyset) for the encrypt algorithm ID and keyset ID (3des_ks168_cbc_encrypt and CSCreditCard).
Paste the regenerated encryption key value in the Key Value field, replacing the previous value, and save the page.
Navigate to the Convert Encryption page (Set Up SACR, Common Definitions, Encryption, Convert Encryption).
Confirm that the encrypt and decrypt profile IDs are correct, then click the Run button to start the conversion process.

The Credit Card Conversion process converts each field in the grid. If the process fails for any reason, the process can be restarted in the standard way and the process picks up where it left off. If the process cannot be restarted, the process can be run from the beginning and it automatically bypasses fields that have already been processed.

Warning! You must complete steps 1-7 to encrypt and run the conversion process prior to completing the next steps, which set up decryption.
Navigate back to the Algorithm page (PeopleTools, Security, Encryption, Algorithm Keyset) for the decrypt algorithm ID and keyset ID (3des_ks168_cbc_decrypt and CSCreditCard).
Paste the regenerated encryption key value in the Key Value field, replacing the previous value, and save the page.

Pages Used to Re-Encrypt and Convert Data

Page Name	Object Name	Navigation	Usage
Generate Encryption Key	SSF_CC_ENCRYPT_KEY	Set Up SACR, Common Definitions, Encryption, Generate Encryption Key	Use this utility to change the key used to encrypt credit card and bank account numbers. Note. When you change the key, you must also run the conversion utility to re-encrypt credit card numbers using the new encryption key. Never change the key without also running the conversion.
Convert Encryption	SSF_CC_RUN_CNVRT	Set Up SACR, Common Definitions, Encryption, Convert Encryption	Perform conversion of credit card numbers to use a regenerated credit card encryption key.
Algorithm Keyset	CRYPT_KEYSET	PeopleTools, Security, Encryption, Algorithm Keyset	Copy the regenerated key to the key value field on this page for the encrypt profile prior to running the conversion process. After running the conversion process, copy the regenerated key to the key value field on this page for the decrypt profile.
Process Scheduler	PRCSRQSTDLG	Click the Run button on the Convert Encryption page.	Run the SSF_CC_CNVRT conversion process to convert existing credit card data using the regenerated credit card encryption key.

Regeneration the Encryption Key

Access the Generate Encryption Key page.

Generate Random Key

Click to have the system generate a random key in the format needed by the encryption algorithms used for credit card encryption and decryption profiles.

Converting Data to Use a Regenerated Encryption Key

Access the Convert Encryption page.

Decryption Profile ID andEncryption Profile ID

Default profile IDs are set on the SF Installation 2 page (Set Up SACR, Install, Student Fin Installation, SF Installation 2).

PeopleTools Pluggable Cryptography framework provides the delivered profiles of TRIPLE DES ENC B64 and TRIPLE DES DEC B64.

PeopleSoft Enterprise Campus Solutions has enhanced the PeopleTools profiles specifically for Campus Solutions re-encryption. The predefined, enhanced profiles delivered for Campus Solution are CS_CREDIT_CARD_DECRYPT and CS_CREDIT_CARD_ENCRYPT.

Profiles specify multiple user-defined steps applying various algorithms and keys to the data in a specified order and supporting various encryption standards and third-party encryption libraries.

The decrypt profile must be the same profile and have the same keys used to encrypt the data as it is. The encryption profile must contain the new keys and algorithm to which you are converting. Therefore, when using the delivered CS profiles, you must change the key value on the Algorithm Keyset page for the encrypt profile and associated algorithm, before running the conversion process. After running the conversion, you must modify the decrypt profile to include the new key.

Crypt Action

Decrypt, then Encrypt is the action set to occur when you run the Credit Card Conversion process. The process first decrypts the credit card and account numbers using the old algorithm and keys, and then encrypts it with the new set of algorithm and keys.

Setting Up SF Merchants

To set up SF merchants, use the SF Merchants component (MERCHANT_TBL).

An SF merchant (student financials merchant) is an entity within the Student Financials application that enables you to set up unique credit card and eCheck processing rules for different departments in your institution. Currently, you can use an SF merchant to set up credit card and eCheck processing for application centers, cashiering offices, and student self-service functions. The SF merchant definition provides information needed by the ePayment service provider and defines what services it performs and what customer information the system displays on the payment page.

To process credit cards and eChecks in Student Financials, you must establish at least two SF merchant definitions — one for credit card support and one for eCheck support. If you have different processing rules for credit card processing in the cashiering office than you do in the application center or in student self-service, then you will need to establish multiple credit card SF merchants to handle these different processing rules.

Page Used to Set Up SF Merchants

Page Name	Object Name	Navigation	Usage
SF Merchants	MERCHANT_TBL	Set Up SACR, Common Definitions, Self Service, Student Financials, SF Merchants	Define ePayment processing parameters. Used for application centers, cashiering offices, and student self service.

Defining ePayment Processing Parameters

Access the SF Merchants page.

Description

Enter a description of this SF Merchant setup.

Service Provider

Select a credit card service provider. Values are Cybersource, TouchNet, and Unsupported.

Process Server

Enter the IP name of the ePayment process server provided by the service provider.

IP Override

If the main ePayment process server is not operating, enter the IP address of an alternate server provided by the service provider.

Note. Do not populate this field unless it is necessary because the system uses this address instead of the IP name.

Process Option

Select the type of transaction that is governed by the SF Merchant rules you are defining: Credit Card or Electronic Check.

Merchant ID

Enter the merchant ID assigned to your institution when you established an account with the ePayment service provider. The ID may be shared by several SF Merchant definitions.

Note. If you intend to process both credit card and eCheck self-service transactions, you must set up two SF merchants, one with a process option of Credit Card and one with a process option of Electronic Check.

Credit Card

This group box appears if you select Credit Card in the Process Option field. Use it to enter credit-card-specific processing parameters.

Credit Card Authorization	Select to authorize credit card transactions in realtime, actually reserving or setting aside credit card funds. If you clear this check box, you must authorize credit card transactions in batch mode. When you select this check box, the Credit Card Settlement check box becomes available.
Credit Card Settlement	Select to settle credit card transactions in realtime, actually transferring funds to your institution as the transaction takes place. If you clear this check box, you must settle credit card transactions in batch mode.
Credit Card Credit	Select to credit in realtime when you void credit card payments originating from cashiering offices or application centers. Note. Reversed or refunded credit card payments originating from self-service cannot be credited in realtime and are not affected by the Credit Card Credit check box.
Perform Check Risk Service	Select to perform a risk assessment at the time of authorization. The risk assessment is an estimation of the veracity of the transaction. Factors such as improper address, too many transactions, or transactions dispersed geographically increase the risk of fraud.
Check Digit Edit	Select to verify the check digit of the credit card number being used prior to processing the transaction. If the check digit is incorrect, the customer receives an error message and is asked to correct the credit card number entered.
Check Risk Threshold	Enter an amount above which the credit card processing merchant is alerted to the possibility of fraud. When a transaction is processed, the credit card processing vendor returns a risk assessment. The check risk threshold is the allowable risk that a school is willing to assume for a given transaction.
Address Verification Flag	This field controls whether the system verifies the credit card billing address during credit card processing. The options are Address Verification Off and Address Verification On. Note. If you select address verification on and the address given does not match, authorization will be declined, but the credit card funds will be set aside.
Batch Transmission Error	Enter the maximum number of batch transmission errors that you want the system to allow before canceling the batch transmission.

Electronic Check

This group box appears if you select Electronic Check in the Process Option field. Use it to enter eCheck-specific processing parameters.

eCheck Debit	Select to process eCheck transactions in real time. If you clear this check box, you must run the eCheck Processing process to debit eCheck payments in batch.
Verification Level	Select the level of verification that the system uses for eCheck payments. Validation: Select to test the format and bank routing number of each eCheck payment and to compare the transaction information to the check-processing partner’s internal negative file. Verification: Select to perform all validation steps and to compare each transaction’s information with an external negative file to identify accounts that have a history of bad checks or that were closed for cause. Note. Validation and verification are optional. Neither process checks the status or the existence of an account nor do they guarantee that funds are available.
Settlement Method	Specify the default method that the system uses to deliver settlements to and from your students’ banks. Automated Clearing House: Select to deposit U.S. and Canadian transactions using the Automated Clearing House (ACH) or the Canadian Payment Association. Facsimile draft: Select to deposit transactions as facsimile drafts. Use this method when the issuing bank is not an ACH member. Best possible: Select to deposit transactions through the ACH system unless the student’s bank is not an ACH participant, in which case, the system creates a facsimile draft and deposits it.
Authentication Method	Define how the system authenticates eCheck payments. If you select Birthdate, PIN, or National ID Number, students must enter the required information to authenticate an eCheck payment. If you select No Authentication, students can submit eCheck payments without authentication. You define a student’s birthdate, national ID number and PIN in PeopleSoft Campus Community. The system always uses a student’s primary national ID number for authentication purposes. Note. Students should not use dashes when entering the national ID number. See Entering PINs. See Adding a Person to Your Campus Solutions Database. See Managing Biographical Information.

Self Service Options

Convenience Fee Option	Select one of the following options if you want to charge students a fee for each ePayment transaction. Fixed Amount: Select to charge a fixed convenience fee for each ePayment transaction. Percentage: Select to make the convenience fee equal a percentage of the ePayment transaction. Note. In most cases, the ePayment convenience fee is posted wherever the payment is applied. For example, if a payment is allocated to charges across multiple business units, the convenience fee is based on the total payment, but is distributed proportionately across the business units. If the payment is not allocated across business units but is directed to charges in one business unit, the convenience fee will be posted in the same business unit. If a payment is not manually allocated, the convenience fee is directed to the business unit with the highest priority.
Convenience Fee Amount	If you want to charge a fixed convenience fee amount, specify the amount as currency. (For example, using U.S. Dollars as the base currency, an entry of 1.50 results in a surcharge of 1.50 USD per transaction).
Convenience Fee Percentage	If you want to charge a percentage convenience fee, specify the percentage as a number greater than zero. In the previous example, the entry 5.5 results in a surcharge of 5.5 percent (5.5%) per transaction.
Minimum Payment Amount	Set the minimum amount that a student can pay during a single ePayment transaction.
Maximum Payment Amount	Set the maximum amount that a student can pay during a single ePayment transaction.

Default Options

Items in this group box relate to customer information that the system displays on the make a payment page for self-service transactions, and the Tender Details page for application fees and cashiering transactions.

Address Usage	Select the address usage type that you want to use to display default customer addresses on the payment page.
Default Email	ePayment processing vendors require an email address to process transactions. Select this check box to use the default email address entered in the Email ID field rather than requiring students to enter one. When you select this check box, the Email Address field does not appear on the Make a Payment self-service page.
Type of Name	Select the default name type that the system uses to look up and display the customer name on the Make a Payment page.
Phone Type	ePayment processing vendors require a phone number to process transactions over the web. Select the default phone type that the system uses to look up and display the customer phone number on the Make a Payment page.
Email ID	Enter the default generic email address that the system uses for all credit card transactions when you select the Default Email check box.

Setting Up Institution Sets

You use institution sets to define basic institution set parameters and to set up ePayment rules for institution sets. This setup is done in Campus Self Service.

See Setting Up Institution Sets.

Setting Up Item Types for ePayment

To enable eCheck and credit card processing, you must define miscellaneous parameters for item types. The system uses the following attributes from the credit card or eCheck Item Type, Miscellaneous page:

Charge Priority List (during Posting of the ePayment transaction).
Payment Overall Priority (during Posting of the ePayment transaction).
Tender Specific and Tender Specify Category (eCheck or credit card; this value controls what will be displayed on SF Institution Set 2 page for an eCheck item type or a credit card item type.

Setting Up Self-Service Payment Messages

To set up self-service payment messages, use the Payment Messages component (SF_PAYMENT_MESSAGE).

Self-service payment messages display to the student when an error is encountered processing a credit card transaction. The credit card processing vendor delivers the codes and default descriptions, but you must define your own message text.

Page Used to Set Up Self-Service Payment Messages

Page Name	Object Name	Navigation	Usage
Payment Messages	SF_PAYMENT_MESSAGE	Set Up SACR, Common Definitions, Self Service, Student Financials, Self-Service Payment Messages	Define self-service message text. Used for self service, application center, and cashiering.

Defining Self-Service Message Text

Access the Payment Messages page.

Code

Valid payment message codes are delivered by the credit card processing vendor and must not be modified. As new codes are made available by the vendor, you may add them to the list, but you must not create and add your own codes.

Description

You can modify the entries listed in this column to have up to a 30-character short description. The descriptions that you enter in this column are for internal use only. Students making a payment over the internet do not see these descriptions. Note that the default description for each authorization reply code is identical to the code itself.

Message Text

Enter the message text you want the system to display to students based on the authorization reply code sent by the credit card processing vendor. Unless text is entered, students receive an error indicator but no message. If you want students to contact you regarding certain credit card problems, this is where you would enter that information.

Delivered Valid Payment Message Codes

The following table lists the payment message codes delivered with your system.

Code	Definition
DAVSNO	The bank accepts the credit card, but the credit card processing vendor did not because the credit card did not pass the Address Verification System (AVS) check. The AVS result is no.
DCALL	You must call the payment processor to proceed with the transaction.
DCARDREFUSED	The bank declined the transaction.
DDISTDENY	A distributor denied the request to sell a particular product.
DINVALIDADDRESS	The city, state, or postal code entered was invalid.
DINVALIDCARD	The credit card number did not pass the credit card processing vendor's basic checks.
DINVALIDDATA	The data provided was not consistent with the request. For example, a student may have requested a product with negative cost, or an electronic license certificate (ELC) for a physical product.
DINVALIDPROD	Not enough information was provided to generate the download URL.
DMISSINGFIELD	The request contained an unpopulated required field.
DNOAUTH	A request was made to bill an order for which there is no corresponding, unused authorization record. This occurs if there was not a previously successful ics_auth request or if the previously successful authorization has already been used by another ics_bill request.
DNOBILL	A request was made to credit an order for which there is no recorded billing code.
DNTFDECLINED	The bank declined the transaction. For IBM Global Merchant (NetTrade Finance) customers only.
DPARSEADDRESS	The credit card processing vendor could not interpret the address information.
DRESTRICTED	One of the following problems may have occurred: The end user is on the U.S. List of Denied Countries or the U.S. List of Denied Persons. The ship-to country is in the U.S. Government denied countries list (CU, IR, IQ, LY, KP, SD, SY) The merchant supplied an export list for one or more of the offers in the order, but the shipping country the end user submitted is not in that list.
DSCORE	The score exceeds the limit.
ESYSTEM	A system error occurred. You must call your credit card processing vendor.
ESTIMEOUT	For ics_auth, if an auth was approved, it is not reversed. For ics_bill, during code cleanup an ics_credit is issued to balance out the ics_bill. For ics_credit, during code cleanup an ics_bill is issued to balance out the ics_credit.
FAMOUNTHIGH	The amount of the transaction requested is too high for the credit card processing vendor.
FAMOUNTLOW	The value entered in the amount field was not greater than zero.
FCONNECTION	The connection failed. The merchant ID and configuration must be checked.
FDECRYPT	Credit card decryption failed.
FINITIFAILED	A vendor error occurred. ICS_INIT failed.
FINVALIDADR1	The value entered for Address 1 was not valid.
FINVALIDCARD	The credit card number entered was too long.
FINVALIDCTRY	The country entered was not valid.
FINVALIDCURR	The currency was not valid.
FINVALIDEMAIL	The email address entered was not valid.
FINVALIDPHON	The phone number entered was not valid.
FINVALIDSERV	The service requested was not valid.
FINVALIDSTAT	The length of the state field was not valid.
FINVALIDZIP	The zip code entered was not valid.
FREFUNDERROR	The refund amount exceeded the amount settled.
FRQIDMISSING	The request ID is required for settlement.
FSENDFAILED	A vendor error occurred. ICS_SEND failed.
NMERCERR	The transaction ran without a merchant_id.
SOK	The transaction was successful.

Setting Up Self Service Options

You can use self service options to define business unit labels for self service payment pages. The values you enter here are used in the View By column headings on self-service pages.

See Setting Up Self-Service Options.

Description	Enter a description of this SF Merchant setup.
Service Provider	Select a credit card service provider. Values are Cybersource, TouchNet, and Unsupported.
Process Server	Enter the IP name of the ePayment process server provided by the service provider.
IP Override	If the main ePayment process server is not operating, enter the IP address of an alternate server provided by the service provider. Note. Do not populate this field unless it is necessary because the system uses this address instead of the IP name.
Process Option	Select the type of transaction that is governed by the SF Merchant rules you are defining: Credit Card or Electronic Check.
Merchant ID	Enter the merchant ID assigned to your institution when you established an account with the ePayment service provider. The ID may be shared by several SF Merchant definitions. Note. If you intend to process both credit card and eCheck self-service transactions, you must set up two SF merchants, one with a process option of Credit Card and one with a process option of Electronic Check.

Code	Valid payment message codes are delivered by the credit card processing vendor and must not be modified. As new codes are made available by the vendor, you may add them to the list, but you must not create and add your own codes.
Description	You can modify the entries listed in this column to have up to a 30-character short description. The descriptions that you enter in this column are for internal use only. Students making a payment over the internet do not see these descriptions. Note that the default description for each authorization reply code is identical to the code itself.
Message Text	Enter the message text you want the system to display to students based on the authorization reply code sent by the credit card processing vendor. Unless text is entered, students receive an error indicator but no message. If you want students to contact you regarding certain credit card problems, this is where you would enter that information.