Versions Compared

Version Old Version 9 New Version 10
Changes made by

Cecilia Do

Cecilia Do

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

For the CCCS Test environment, we are connecting to the vendor's test system. No payments go out to the banks. Settlement is run every 10 minutes.

Modifications

  1. The transactions initiated in ICVerify prior to production implementation will be refundable for 30 days. The transactions initiated in Authorize.Net will have a refund cutoff of 120 days. Please note that this is counted from the transaction's settlement date.
  2. Authorize.Net's policy is to not display or pass back the expiration date. Therefore, in CCCS, the transactions initiated in Authorize.Net will have have a masked expiration date (e.g. XXXXX).
  3. The vendor payment page will include an optional email address field for the customer's address. If one is provided, a receipt of the authorization will be sent to the customer.
  4. Upon a successful payment, Authorize.Net will display a receipt page to the customer. There will be a button to take the user back to the CCCS Online Application or department storefront as appropriate.
  5. For the Payment Gateway department storefronts:
    1. The storefront css stylesheets will continue to be used. It may need tweaking for the vendor payment page.
    2. The storefront banner will be passed to the vendor for display. However, because the width of the vendor payment page is 580 pixels, you may want to consider adjusting your current banner.
    3. The payment description display will be the screen_header and the non-refundable message (if applicable). If a screen_header is not provided, then the CCCS program profile name will be used.
    4. The error message for code 998 is currently "ICVerify (credit card server) not available." We are proposing to change this to be more general: "Credit card service not available."
    5. There is a Payment Gateway job that performs a department post-back for Gateway sessions that were not posted back (for example, the user has already timed out and may have closed the payment window). This job is scheduled to be run every 10 minutes, and the storefront will receive a post-back between 10-15 20 minutes of the user initially landing on the payment page. Although the Authorize.Net payment page timeout is 60 minutes, we will maintain this existing job to post back to the departments.

...

  1. Authorize.Net admin will need to enable AVS
  2. All payments will be declined while AVS is enabled
  3. Less flexible
  4. Allows users to test real amounts

Testing Schedule

Department

Contact

Schedule

Test Results

Engineering

John Romine

 

 

Graduate Division

Eric Taggart

 

 

Housing

Markus Quon
Jorge Romo

 

 

Paul Merage

Gary Striano

 

 

Undergrad Admissions

Linda Snyder

 

 

...

Test Case

Description

Expected Outcome

Comments

Post data Data

  1. Multiple programs if applicable
  2. Tax if applicable
  3. Different total amounts if applicable
  4. Different account-fund distribution if applicable
  5. Distribution override and no override if applicable

 

 

CCCS maintenance Maintenance

  1. Emergency downtime
  2. Scheduled downtime
  3. Routine maintenance

Response with appropriate error code and message

 

...

Test Case

Description

Expected Outcome

Comments

Disabled JavaScript


Display page with instructions on how to enable JavaScript

 

Redirect timeout Timeout

Exceed [department timestamp + duration] window

  1. Post to department
  2. Redirect user back to storefront

 

CCCS maintenance Maintenance

  1. Emergency downtime
  2. Scheduled downtime
  3. Routine maintenance
  1. Post to department
  2. Redirect user back to storefront

 

...

Test Case

Description

Expected Outcome

Comments

Page Display

  1. Banner
    1. 580 pixels wide
  2. Stylesheet
    1. May need to tweak
  3. Payment description
    1. screen_header
      1. if not supplied, then program profile name
Authorized payment
    1. refundable flag

 

 

Authorized Payment

In the vendor's test environment, by default, all payments are authorized.

The vendor transmits post-backs in real time for authorized payments.

Note
titlePost-Back and Receipt Display Is Asynchronous

The Payment Gateway posts back to the department when it receives the vendor's post. The redirect back to the department will occur after the user presses the button on the vendor receipt page.

  1. Vendor display user receipt
    1. Button for user to go back to the storefront
  2. Gateway post-back to department storefront
  3. If user entered valid email, receive email receipt

  Declined

payment Canceled Payment

This is a function added by CCCS, since Authorize.Net doesn't offer a cancel option.

  1. Gateway post-back to department storefront
  2. Redirect user back to storefront

 

Declined Payment

The decline options are described above.

 

 

 

 

 

 

 

 

 .

The vendor does not transmit post-backs for declined payments. As long as a payment is declined, the user will not receive a receipt and the vendor will not transmit a post-back to CCCS.

There is no limit to the number of attempts.

  1. The Gateway department post-back job is scheduled to run every 10 minutes.
    1. If there is no vendor response for a particular session within 10-20 minutes, then the post-back job will post the record back to the department.
  2. If an authorization is made, see outcome for "Authorized Payment"

 

Close Window

 

See outcome for "Declined Payment"

 

Timeout

The vendor timeout is 1 hour. After this, the next payment attempt will error out.

See outcome for "Declined Payment"