University of Missouri E-Commerce Procedures

Seven Steps to Implementing an E-Commerce Solution Using QuikPAY

  1. The customer completes the online e-commerce service request form. Pressing the Submit button emails the form to the e-commerce support team.
  2. The e-commerce support team reviews the request and contacts the customer. The e-commerce team schedules a phone call with you. We discuss the following:
    • The University’s payment processing solution, QuikPAY, from Nelnet Business Solutions (NBS)
    • Security guidelines and audit requirements
    • Information regarding the implementation time line
    • Pricing

    If you want to use a vendor-purchased front-end application, the system e-commerce team arranges contact between the vendor and Nelnet Business Solutions. NBS requires you to sign a nondisclosure agreement before you can receive NBS documentation.

    If you want to use a payment processing solution other than QuikPAY, provide the Treasurer’s Office with vendor contact information, proof of vendor PCI compliance, and application documentation. The Treasurer’s Office, Commerce Bank, Information Security & Access Management (ISAM), and the e-commerce team evaluate the vendor product for compliance with the University’s e-commerce security guidelines. The Treasurer’s Office contacts you within two weeks as to whether the vendor product meets University of Missouri e-commerce requirements.

    Final approval for all e-commerce activity requests will come from the Treasurer’s Office.

  3. The e-commerce support team sends information to the customer.
    • Pricing information
    • E-commerce security guide
    • Nelnet Business Solutions technical documentation to interface with QuikPAY:
      • Pass-through authentication from customer’s application to QuikPAY
      • Receipt redirect from QuikPAY to customer’s application
      • Code examples of the pass-through authentication and receipt redirect
      • QuikPAY generic test site URL
      • Nondisclosure agreement (sent to customers using a vendor front-end application)
  4. The e-commerce team schedules the application in a future QuikPAY implementation phase and notifies the customer of the tentative project time frame. The formal implementation typically lasts from six to eight weeks, including testing. You should begin development of the front-end application one or two months prior to the QuikPAY project kick-off.
  5. The e-commerce team works with Nelnet Business Solutions to schedule the project kick-off meeting and notifies you. Prior to the project kick-off meeting:The e-commerce team
    • sends you the following documents: business requirements checklist, merchant ID request form, and project plan
    • requests you to provide a PeopleSoft item type for feeds to PeopleSoft student financials (when applicable)

    The customer completes and returns the business requirements checklist and merchant ID request form.

  6. During the formal implementation:The e-commerce team
    • works with the Nelnet Business Solutions project manager to complete the project tasks and meet objectives defined in the project time line
    • submits a request to the Treasurer’s Office for a merchant ID and YourPay account
    • requests ISAM schedule an audit during the project acceptance testing phase
    • notifies the help desk about the project scope
    • provides accounting information for Nelnet Business Solutions invoice recharge processing
    • downloads a PEM file from YourPay and registers it with QuikPAY
    • provides QuikPAY API technical support to customers and campus e-commerce contacts
    • provides QuikPAY API support to their campus customers
    • participates in the project status calls

    The customer

    • modifies the front-end application to transfer data to and receive data from QuikPAY according to the QuikPAY API specifications
    • meets all project deadlines as outlined in the Nelnet Business Solutions project plan
    • completes the security documents when requested by ISAM
    • works with ISAM to meet audit requirements as outlined in the e-commerce security guidelines
    • participates in the project status calls
    • develops reconciliation procedures


    • schedules and conducts audits
    • notifies the e-commerce team of successful audits
    • advises the customer of the system changes needed to successfully meet the audit requirements
  7. Go live. The application is available for production use.

How an E-Commerce Credit Card Payment Works

This is an example of how a credit card payment is processed from an e-commerce web application using QuikPAY. The web application could be designed for a variety of business needs, including a shopping cart, conference registration, or to accept donations.


  1. The customer uses a web application to select goods or services for purchase. The customer clicks a “pay now” button to initiate payment.
  2. The customer is transferred to QuikPAY. The customer enters the credit card account number and expiration date. The customer presses the “confirm” button to submit the payment.
  3. QuikPAY passes the transaction to the merchant bank’s processor, YourPay.
  4. YourPay submits the transaction to the credit card interchange.
  5. The credit card interchange submits the transaction to the issuer for authorization.
  6. The credit card issuer approves or declines the transaction and passes the results back through the credit card interchange.
  7. The credit card interchange passes the authorization results to YourPay.
  8. YourPay passes the transaction results to QuikPAY.
  9. QuikPAY stores the transaction results and sends them to the web application.
  10. The web application presents a transaction successful or declined message to the customer.
  11. The credit card interchange passes the funds to the University’s Commerce bank account.
  12. Successful transaction information is sent to the University through QuikPAY real-time notification and end-of-day files. The data is stored in the University’s Oracle databases.
  13. A University process creates feeder files to the general ledger for all QuikPAY transactions and, optionally, to CSAR or PeopleSoft student financials.
  14. QuikPAY transactions are posted to PeopleSoft general ledger.
  15. When applicable, QuikPAY transactions are posted to PeopleSoft student financials.