Setting Up Payment Applications
This section discusses how to set up payment applications.
|
Page Name |
Definition Name |
Navigation |
Usage |
|---|---|---|---|
|
Payment Application |
SCC_PAYMENT_APPL |
|
Set up payment applications. |
|
SF Electronic Payments |
SSF_ELEC_PMTS |
|
Set up electronic payments for self service. |
Access the 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.
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 sends the user back to the appropriate component or 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 (for example, SAD).
Processing Admissions Application Web Service Fee
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:
Access the SF Electronic Payment Trans page ().
This example illustrates the fields and controls on the SF Electronic Payment Transaction page. You can find definitions for the fields and controls later on this page.
The Payment Application ID allows the hosted payment framework to instantiate the payment application adapter.
The system uses the Payment Application ID and other values selected on the SF Electronic Payment Trans setup page to create a Payment Application Key. The Payment Application Key allows the adapter to retrieve, validate, and update the transaction. These data elements must be passed to the third-party payment provider, and the third-party payment provider must pass it back to Campus Solutions.
Field or Control |
Description |
|---|---|
Payment Application (payment application ID) |
Campus Solutions provides the following Payment Application IDs:
|
Default Posting Type |
For payments related to requests for official transcripts
through Fluid user interface, select GL Posting.
|
GL Transaction Source |
For payments related to requests for official transcripts
through Fluid user interface, select Official Transcript Fee.
|