Setting Up Hosted Payment

Application Fees are optionally required during application submission as configured in the Application Center Setup page. If fees are required to be paid then a prerequisite is to set up the hosted payment adapter and merchant which will facilitate the online payment.

Firstly, create a new HTML object in Application Designer. The HTML object is used to store user interface specific HTML and JavaScript which will direct the self-service user interface during the payment integration flow. Refer to the User Interface Considerations section for detailed technical information on what this HTML object may need to contain.

See User Interface Considerations

Next, set up a new hosted payment adapter for AAWS pointing to the same application class as the one used for PIA Self Service. This step is required because the HTML definition (created in the first step) is attached to the adapter itself.

Access the Adapter Table page (select Set Up SACR, then select System Administration, then select Utilities, then select Adapter Registry).

Image: Hosted Payment Adapter Setup page

This example illustrates the fields and controls on the Hosted Payment Adapter Setup page.

Next, attach the new HTML definition to the Hosted Payment Adapter settings. Access the Hosted Payment Adapter page (select Set Up SACR, then select Common Definitions, then select Electronic Payments, then select Hosted Payment Adapter Setting).

Image: Hosted Payment Adapter page

This example illustrates the fields and controls on the Hosted Payment Adapter page.

The parameters page should be set up according to your third-party payment provider’s requirements.

Image: Parameters page

This example illustrates the fields and controls on the Parameters page.

Next, the hosted payment adapter is attached to a Payment Merchant. If you are already using the hosted payment framework for Student Financials’ Self Service or Cashiering, you will still need to set up new Payment Merchants with a different set of Third Party Merchant IDs. Your third party will require return URLs in order to navigate the user back to the online application. These return URLs are typically tied to the Third Party Merchant ID defined in the Payment Merchant.

Note that the hosted payment adapters as delivered in Feature Pack 2 (Bundle 16) use the Get Token (91) and Authorize Only (92) transactions defined in the Electronic Payment Setup section of the Payment Merchant setup. If you plan to use these adapters as delivered, you will need to set up this section in the same manner as defined in the Electronic Payment Integration Developer’s Reference Guide. In addition, you will need to set up the corresponding Integration Broker Related objects for these transactions. Please refer to the Electronic Payment Integration Developer’s Reference Guide for more details.

You are required to configure one for each payment method you accept (credit card or electronic check).

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

Image: Payment Merchant page

This example illustrates the fields and controls on the Payment Merchant page.

Finally, payment merchants are attached to SF merchants which are associated with the Admissions Application Center.

Credit transactions (Credit Only – 93 as defined above) can only be generated for transactions posted to the student account. Since payments received through the online admissions application are posted to the General Ledger directly, credit transactions are not supported for these application fee payments.

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

Image: SF Merchants page

This example illustrates the fields and controls on the SF Merchants page.

Note: Convenience fees are not currently supported for online application fee payment.