Return to Navigation

Setting Up Payment Applications

This section discusses how to set up payment applications.

Page Name

Definition Name

Navigation

Usage

Payment Application

SCC_PAYMENT_APPL

select Set Up SACR, then select Common Definitions, then select Electronic Payments, then select Payment Applications, then select Payment Application

Set up payment applications.

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

Image: Payment Application page

This example illustrates the fields and controls on the Payment Application page. You can find definitions for the fields and controls later on this page.

Payment Application page

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: