PeopleSoft Student Financials 9.0 PeopleBook

Using Student Financials Web Services for Hosted ePayment Transactions

This chapter provides an overview of Student Financials web services and discusses how to process AAWS application fees.

Understanding Student Financials Web Services

Student Financials provides the SSF_EPAYMENT_TRANS web service with two adapter-based service operations—SSF_INITIATE_EPAYMENT and SSF_COMPLETE_EPAYMENT. These service operations allow an external user interface to use the hosted payment framework to collect payment information through a third party payment processor, authorize the payment, record the transaction in the SF_PAYMENT tables, and record the transaction in the General Ledger. Note that these transactions do not originate in Campus Solutions, but in an external UI—for example, Admissions Application Web Service (AAWS) online application.

For detailed information about the hosted payment framework, refer to the Electronic Payment Integration Developer's Reference Guide which is available on My Oracle Support.

The processing of hosted payment transactions that do originate in Campus Solutions is discussed in the Processing ePayment Transactions chapter.

See Processing ePayment Transactions.

For information about setting up SF merchants,

See Setting Up SF Merchants.

See Generating Direct to GL Entries.

See Setting Up Adapters.

Processing AAWS Application Fees

This section provides an overview of AAWS application fees and discusses how to use SF web services for AAWS application fee payment.

To use the AAWS application fee payment process, you must implement hosted payment with your provider.

Understanding AAWS Application Fees

Admissions Application Web Services (AAWS) is a set of web services that allow schools to post application data collected through their own online application into Campus Solutions. This is done by initially storing application data in a set of tables (Staging Data) that mirrors the current Admissions application stack (Production Data) as the application information is collected and saved. After the student submits the application, the data is validated and promoted to the current admissions production tables.

As part of the online application process, an application fee may be assessed and a payment required from the applicant before the application can be submitted and processed. The timing of the presentment of the fee amount and subsequent collection of payment requires a fee calculation method based on the staging records (as opposed to the Production Data used by the Cobol application fee calculation process).

Electronic payments for the application fee must be authorized at the time of payment to verify the availability of funds before the application can be processed. So that schools are not faced with PCI compliance issues inherent in such electronic payment processing, AAWS has the ability to connect with a third party host that performs the electronic data collection and storage.

Because of the timing of the AAWS fee calculation and payment—payment for an application is collected before the application is promoted to production—an Emplid is not assigned to the applicant at the time the fee is calculated/paid. Because most Student Financials tables, including the SF account tables are keyed by Common ID (contains either an Emplid or External Org ID), these transactions cannot be recorded as part of a student account. The application transaction, however, must still be recorded in the General Ledger. The Direct to GL process allows schools to bypass the creation of a student account. Any transactions recorded directly to the General Ledger must be refunded manually. The transaction does not show in the Self Service Account Inquiry, or the Customer Account Inquiry.

See Setting Up Application Processing Centers.

See Entering Application Data.

See Setting Up Application Fees.

See Generating Direct to GL Entries.

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.

Using SF Web Services for AAWS Application Fee Payment

This section provides a high level overview of the steps involved when an applicant makes a payment for an AAWS application fee through an external user interface.

The setup of the AAWS Application Fee and Waiver Processing group box on the Application Center Table page controls how an online application fee payment or waiver is processed.

The applicant has entered the required information and is ready to submit the application. Based on the Application Center setup, the applicant sees the relevant buttons on the external UI—for example: Request a Waiver, Make a Payment, or Pay at a Later Time.

When the applicant clicks the button to make a payment:

The AAWS Submit web service (SAD_SUBMITAPPL) calls the Application Fee Calculation API which calculates the fee. The Submit web service returns the amount and currency code to the external UI which displays the fee.
The Get List Of Values web service is called to determine the payment methods. These values are set up by the institution.

The applicant views the fee amount and selects a payment method. The applicant must make payment in full. Similarly, if the applicant has multiple applications, separate payments must be made for each.

When the applicant clicks the button to make the payment, the external UI calls the SSF_INITIATE_EPAYMENT web service. This web service returns values to the external UI which then redirects the applicant to the third party hosted site. The SF_PAYMENT record is created at this point. The tender rows are created in the AAWS staging records.

The applicant, who is no longer on the external UI site but on the third party hosted site, enters his or her epayment information. For echeck, the shared secret is the date of birth in the staging tables.

The applicant clicks to continue from the third party page and the payment processor redirects to the external UI. The external UI calls the SSF_COMPLETE_EPAYMENT web service. The SSF_COMPLETE_EPAYMENT web service leverages the hosted payment framework to interpret the results of the payment and call the Payment Application adapter to update the session ID and the last 4 digits of the account on the SF Payment. It also calls the SF Payment Transaction Manager to complete the payment. If the transaction is successful, the payment is authorized and posted to the GL. The payment transaction adapter updates the application-related data based on the attributes of the SF Payment.

For detailed information about the AAWS application fee payment process, including the SF web services:

For information about how the Application Data staging page fields are updated when an online application fee or waiver is processed,

For information about the Direct to GL process,

See Generating Direct to GL Entries.