PeopleSoft Student Financials 9.0 PeopleBook

Setting Up ePayment Processing

This chapter includes an overview of ePayment processing and discusses how to:

Set up credit card types.
Re-encrypt credit card, bank account numbers, Security Code data, and Security Key.
Set up payment merchants.
Set up payment applications.
Test payment and hosted payment transactions.
Set up Student Financials merchants.
Set up institution sets.
Set up item types for an ePayment transaction.
Set up self-service options.

Understanding ePayment Processing

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

Note. For information about ePayment transactions made through an external user interface using SF web services (for example AAWS application fee payment):

See Using Student Financials Web Services for Hosted ePayment Transactions.

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.

This section discusses how to define accepted credit card types.

Page Used to Set Up Credit Card Types

Page Name	Definition 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 (Set Up SACR, Product Related, Student Financials, Credit Card Type).

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, Bank Account Numbers, Security Code Data, and Security Key

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

This section provides overviews of encryption and re-encryption and discusses how to:

Regenerate the encryption key.
Convert data to use a regenerated encryption key.

Understanding Encryption

PeopleSoft 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, bank account numbers, and Security Code 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, bank account numbers, and Security Code 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, bank account numbers, and Security Code 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.

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, we do not recommend it. If you do, you must be very careful to use the appropriate values for whatever you create or modify.

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

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 CSCredi Card).
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.

See Also

PeopleSoft PeopleTools PeopleBook: Security Administration

Defining Keyword Edit Tables and a Null Due Date

Processing ePayment Transactions

Pages Used to Re-Encrypt and Convert Data

Page Name	Definition 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, bank account numbers, Security Code data, and Security Key. 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.

Regenerating the Encryption Key

Access the Generate Encryption Key page (Set Up SACR, Common Definitions, Encryption, Generate Encryption Key).

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 (Set Up SACR, Common Definitions, Encryption, Convert Encryption).

Decryption Profile ID and Encryption 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 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, account numbers, and Security Code data using the old algorithm and keys, and then encrypts it with the new set of algorithm and keys.

Setting Up Payment Merchants

A flexible interface supports the processing of credit card and eCheck transactions. The interface uses a flexible adapter-based model to support the transmission of electronic payment transactions. You can use either the Integration Broker-based interface or the Business Interlinks interface to send electronic payment transactions to third party payment processors. The Integration Broker interface provides Security Code support but the Business Interlinks interface does not.

Warning! Before you read this section, refer to the Setting Up Adapters chapter in the Application Fundamentals PeopleBook for information about the Adapter Type Table and Adapter Table components. The components are used to define the adapters that are used in electronic payment and hosted payment processing.

See Setting Up Adapters.

To set up Payment merchants, use the Payment Merchant (SCC_MERCHANT) component.

This section discusses how to define Payment merchants.

Page Used to Set Up Payment Merchants

Page Name	Definition Name	Navigation	Usage
Payment Merchant	SCC_MERCHANT	Set Up SACR, Common Definitions, Electronic Payments, Payment Merchant, Payment Merchant	Define electronic payment merchants.

Defining Electronic Payment Merchants

Access the Payment Merchant page (Set Up SACR, Common Definitions, Electronic Payments, Payment Merchant, Payment Merchant).

Service Provider

Select a service provider: Cybersource, TouchNet, or Unsupported.

This field is informational only.

3rd party Merchant ID

Enter the merchant name.

Hosted Payment Provider

Select this check box to identify the payment merchant as a hosted payment provider.

If you select this check box:

The Hosted Payment Setup group box becomes available.

The Security Code Supported check box in the Credit Card group box is not available, because that control is established (as well as collected) at the hosted payment (third party) site.

See Understanding ePayment Transactions.

Hosted Payment Setup

This group box is available only if the Hosted Payment Provider check box is selected.

Adapter	Select the adapter to be used by the hosted payment merchant to process hosted payment transactions.
Browser Requirements Message and Browser Requirements Detail	Enter a browser-related message, or browser-related detail about browser requirements, that an application can display to a user before the user is transferred to the third party hosted site.
Browser Requirements Message	For schools that use hosted payment, the message that you enter here appears on the Make a Payment - Confirm Payment page if the Display Browser Message check box is selected on the Electronic Payments (Institution Set) setup page.
Browser Requirements Detail	For schools that use hosted payment, the detail that you provide here appears when students click the Browser Requirements link on the Make a Payment - Confirm Payment page if the Display Browser Message check box is selected on the Electronic Payments (Institution Set) setup page. See Defining Self-Service ePayments for Institution Sets.

Electronic Payment Setup

Service Operation	Select the service operation to be used by the adapter when processing the electronic or hosted payment transaction request. This field is required only if you use the Integration Broker based adapter (SCC_INT_BROKER).
Adapter	Select the adapter to be used by this merchant to process electronic payment transactions using the electronic payment interface.
Insert All Transactions	Click this button to insert all transactions into the Supported Transactions group box.
Security Key Required	Use this check box to indicate that a special security token or password is needed to process transactions. If you select this check box, the Security Key Setup group box becomes available.

Security Key Setup

This group box is available only if you select the Security Key Required check box.

Key

This field contains the security token or password that might be required by a third party payment processor. This field is encrypted using the encryption profiles from the SF Installation table.

Supported Transactions

The following services are available for the ePayment API. Check with your third party provider for a list of supported services.

Value

Select a value for the supported transactions.

Credit Card transactions:

1: Authorize Only
2: Authorize and Bill
3: Bill Only
4: Credit Only

eCheck transactions:

5: Make Payment
6: Apply Credit

Hosted transactions:

91: Get Token
92: Authorize Only
93: Credit Only

Electronic Check

Verification Level

Select the level of verification that the system uses for eCheck payments.

If a valid value is not entered on the transaction request, the value that you select here is used.

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

Select the default method that the system uses to deliver settlements to and from your students' banks.

If a valid value is not entered on the transaction request, the value that you select here is used.

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.

ACH Class

Select the default value for ACH Class data element used by eCheck transactions. If a valid value is not entered on the transaction request, the value that you select here is used.

The values are:

ARC (Accounts Receivable Entries): Checks received by a merchant through mail or drop box and presented as a HYPERLINK "http://www.nationalach.com" ACH entry.
POP (Point-of-Purchase): A check presented in-person to a merchant for purchase is presented as a HYPERLINK "http://www.nationalach.com" ACH entry instead of a physical check.
TEL (Telephone Initiated-Entry) Verbal authorization by telephone to issue a HYPERLINK "http://www.nationalach.com" ACH entry such as checks by phone.
WEB (Web Initiated-Entry): Electronic authorization through the Internet to create a HYPERLINK "http://www.nationalach.com" ACH.

Credit Card

Security Code Supported

Select this check box to indicate that the merchant supports the sending of Security Code values.

You must clear this check box for merchants using Business Interlink based integration technology.

Because the Security Code is captured at the third party site for hosted payment transactions, this check box is not available for hosted payment providers—that is, where the Hosted Payment Provider check box is selected.

See Processing ePayment Transactions.

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 is declined, but the credit card funds are set aside.

If a valid value is not entered on the transaction request, the value that you select here is used for credit card transactions.

This field also appears on the SF Merchants page.

Additional Setup Options

Process Server	This field holds the location of the Process Server used by the Business Interlink based credit card and eCheck transactions. This field is only relevant if you are using the Business Interlinks and the Business Interlink adapter (SCC_BUS_INTERLINK).
IP Override	This field is used by the credit card and eCheck business interlinks and is passed through the ip_address input property. This field is also used as a default ip address for transactions processed by the Integration Broker based adapter for electronic payment transactions that require this field.

See Electronic Payment Integration Developer's Reference Guide. The guide is posted to My Oracle Support.

See Also

Processing ePayment Transactions

Setting Up Payment Applications

This section explains how to set up payment applications.

Page Used to Set Up Payment Applications

Page Name	Definition Name	Navigation	Usage
Payment Application	SCC_PAYMENT_APPL	Set Up SACR, Common Definitions, Electronic Payments, Payment Applications, Payment Application	Set up payment applications.

Setting Up Payment Applications

Access the Payment Application page (Set Up SACR, Common Definitions, Electronic Payments, Payment Applications, Payment Application).

Admissions Application Web Service Fee Processing

The hosted payment framework identifies the source of a transaction through its Payment Application registry. Payment applications are also used to derive the adapter that retrieves payment-related information, perform updates to the application transaction tables, and navigate the user back to the appropriate component/url.

Payment Applications and the corresponding payment application adapters are considered system data and follow a naming convention. The records should be prefixed with the appropriate Owner ID (SAD).

The AAWS payment application adapter selects the SF Payment records to fill in the ePayment Request class and updates the SF Payment using the attributes of the ePayment Response class after the transaction handle is returned by the third party.

The ADM_APPL_NBR is passed to the payment application adapter as the application key. When instantiated, the adapter selects the maximum SF_PMT_REF_NBR from the SAD_APL_TND_STG. It relies on the ePaymentBase class to set the Request class properties for use of the hosted payment framework in formulating the string required to transfer to the third party.

Some attributes, like address, name, and phone, are not stored in the SF Payment but are part of the ePayment Request class. These values are passed to the third party and displayed as payment defaults to the applicant in the third party host page. To fill these attributes, a Constituent class gathers the payment defaults based on the SF Merchant attributes.

For inbound transactions, the AAWS Payment Application adapter relies on its super class to update the SF Payment with the session ID and last 4 digits of the credit card or account number. The AAWS fee process does not store the last 4 digits of the credit card/account number.

See Setting Up Adapters.

See Managing PeopleSoft Admission Transactions chapter. At the time of publication of this PeopleBook (March 2012), the latest version of this chapter is available on My Oracle Support as part of the Bundle 23 Recruiting and Admissions doc package (CS_Bundle_23_Recruiting_and_Admissions _9_0.pdf)-Doc ID 1371376.1.

See Using Admission Applications Web Services chapter. At the time of publication of this PeopleBook (March 2012), the latest version of this chapter is available on My Oracle Support as part of the Bundle 23 Recruiting and Admissions doc package (CS_Bundle_23_Recruiting_and_Admissions _9_0.pdf)-Doc ID 1371376.1.

Testing Payment and Hosted Payment Transactions

The Electronic Payment Test component allows testing of ePayment and hosted payment transactions. This page also serves as a run control page for the batch testing component (SCC_EPAY_TST – Epayment Batch Test).

Page Used to Test Payment and Hosted Payment Transactions

Page Name	Definition Name	Navigation	Usage
Electronic Payment Test	SCC_EPAYMENT_TEST	Set Up SACR, Common Definitions, Electronic Payments, Electronic Payment Test	Test ePayment and hosted payment transactions.

Testing ePayment and Hosted Payment Transactions

Access the Electronic Payment Test page (Set Up SACR, Common Definitions, Electronic Payments, Electronic Payment Test).

Post to Hosted Payment URL

Click this button to cause a redirect to the third party URL where a sample payment can be made. The third party site should redirect you back to this page after the payment is made. You can then authorize the payment by using the Trans. Type field to select the Authorize Only (92) transaction.

Note. The Session ID field should be updated after you select either Authorize Only (92) or Credit Only (93) transaction.

This button is available only for payment merchants who are hosted payment providers.

Submit

Click this button to submit the transaction using the Electronic Payment API.

Run

Click this button to run the batch electronic payment test program. This program tests credit card and eCheck transactions (Authorize and Debit) to make sure that these transactions function correctly in a batch environment (this is more relevant when using the Business Interlink adapter).

When you initiate the batch run job, be sure to select only Transaction Type 1 – Authorize Only (CC) or Transaction Type 5 – Make a Payment (ACH).

Merchant Options

Merchant Setup ID

Select a Merchant Setup ID. Values are defined in the Payment Merchant setup component (Set Up SACR, Common Definitions, Electronic Payments, Payment Merchant, Payment Merchant).

Note. The remaining fields in this section are informational only and appear based on the setup in the Payment Merchant setup component and the Adapter Type Table and Adapter Table setup components.

Testing Options

Trans. Type (transaction type)	Select the type of transaction to be processed. The valid values for this field are defined in the Supported Transactions section of the Payment Merchant setup page (Set Up SACR, Common Definitions, Electronic Payments, Payment Merchant, Payment Merchant).
Merchant Ref ID	Enter a value that uniquely identifies the transaction that is sent to the third party processor. If this field is left blank it is programmatically populated with a uniquely generated ID.

Transaction Response

This section of the page contains the results of the transaction request. The fields all appear based on properties of the Transaction Response class that is returned from the Electronic Payment Manager class.

See Also

Setting Up Payment Merchants

Setting Up SF Merchants

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

This section provides an overview of SF merchants and discusses how to define ePayment processing parameters.

Understanding SF Merchants

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. You can use an SF merchant to set up credit card and eCheck processing for 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 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	Definition Name	Navigation	Usage
SF Merchants	MERCHANT_TBL	Set Up SACR, Common Definitions, Self Service, Student Financials, SF Merchants	Define ePayment processing parameters. Used for cashiering offices and student self service.

Defining ePayment Processing Parameters

Access the SF Merchants page (Set Up SACR, Common Definitions, Self Service, Student Financials, SF Merchants).

Process Option

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

Payment Merchant

Enter the Payment Merchant that you wish to use for this SF Merchant. The ID can 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.

Hosted Payment Provider

If the payment merchant that you select on this page is a hosted payment provider and you selected the Hosted Payment Provider check box on the Payment Merchant page, the check box on this page appears selected and unavailable for edit.

If the payment merchant that you select on this page is not a hosted payment merchant, the Hosted Payment Provider check box appears on this page but is cleared and is not available for edit.

Security Code Supported

If you select the Security Code Supported check box on the Payment Merchant page to indicate that the merchant supports the sending of Security Code values, the check box on this page appears selected and unavailable for edit.

This check box does not appear for hosted payment providers.

Batch Transmission Error

Enter the maximum number of batch transmission errors that you want the system to allow before canceling the batch transmission.

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. Check with your third party provider for a list of supported services.

Note. For AAWS application fee payments, the Real-Time Authorization and Real-Time Capture check boxes are selected by default and are not available for edit. The Real-Time Credit check box is available but should not be selected for AAWS application fee payments.

Real-Time Authorization	Select to authorize credit card transactions in real time, 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 Real-Time Capture check box becomes available. For hosted payment providers, this check box is selected and is not available for edit.
Real-Time Capture	Select to capture credit card transactions in real time, actually transferring funds to your institution as the transaction takes place. If you clear this check box, you must capture credit card transactions in batch mode. For hosted payment providers, this check box is selected and is not available for edit.
Real-Time Credit	Select to credit in real time when you void credit card payments originating from cashiering offices. Note. Do not select this check box for self-service transactions because you can only process credits for self-service transactions in batch.
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. This check box is not available for hosted payment providers.
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. This check box is not available for hosted payment providers.
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. This check box is not available for hosted payment providers.
Security Code Required	This check box is available only for credit card merchants. The check box does not appear if the merchant is a hosted payment provider. If you select this check box, the Security Code field is available as a required field on all pages that accept credit card transactions—Cashiering, Make a Payment, and Purchase Miscellaneous Items. The Security Code field does not appear on any inquiry pages. Note. The Security Code is supported only if you use the Integration Broker interface for credit card processing. Do not select the check box if you use Business Interlinks.
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. This field appears on this page and the Payment Merchant page.

Electronic Check

This group box appears if you select Electronic Check in the Process Option field. Use it to enter eCheck-specific processing parameters. Check with your third party provider for a list of supported services.

Real-Time 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.

Authentication Method or Shared Secret

Define how the system authenticates eCheck payments.

For Integration Broker and Business Interlinks, the field appears as Authentication Method.

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, or 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.

For Hosted Payment, the field appears as Shared Secret.

When the third party payment provider authenticates the student on their site, they use the Shared Secret provided by Campus Solutions to verify the student. Valid values are and Birth Date, Constituent Birth Date, and PIN.

See Entering PINs.

See Adding a Person to Your Campus Solutions Database.

See Managing Biographical Information.

Self Service Options

Convenience fee does not apply for AAWS application fee processing.

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 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 cashiering transactions.

Contact Type	Select the contact type representing the address for an External Org ID.
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.

See Electronic Payment Integration Developer's Reference Guide. The guide is posted to My Oracle Support.

See Also

Processing ePayment Transactions

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 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.

Process Option	Select the type of transaction that is governed by the SF Merchant rules that you are defining: Credit Card or Electronic Check.
Payment Merchant	Enter the Payment Merchant that you wish to use for this SF Merchant. The ID can 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.
Hosted Payment Provider	If the payment merchant that you select on this page is a hosted payment provider and you selected the Hosted Payment Provider check box on the Payment Merchant page, the check box on this page appears selected and unavailable for edit. If the payment merchant that you select on this page is not a hosted payment merchant, the Hosted Payment Provider check box appears on this page but is cleared and is not available for edit.
Security Code Supported	If you select the Security Code Supported check box on the Payment Merchant page to indicate that the merchant supports the sending of Security Code values, the check box on this page appears selected and unavailable for edit. This check box does not appear for hosted payment providers.
Batch Transmission Error	Enter the maximum number of batch transmission errors that you want the system to allow before canceling the batch transmission.