ePayment Specifications
The merchant application must confirm to the following rules and specifications:
- The merchant pages are the responsibility of the merchant. ITS does not create or maintain these pages.
- The last page in the merchant application will only pass final information to the 51²è¹Ý ePayment system. The ePayment system will not "total up" or validate any data beyond some very core integrity constraints. This means that the merchant is fully responsible for establishing and finalizing all details of the transaction except collecting and verifying the credit card and eCheck information. Transaction details include but are not limited to: calculating shipping, verifying suitability of order, totaling and verifying the final shipping prices, calculating taxes.
- The merchant will not enclose the 51²è¹Ý ePayment system within in its own frames or attempt to interfere with the look and feel of the 51²è¹Ý ePayment system. Enclosing the ePayment system in frames prevents the user from seeing the SSL icon () in the browser’s border.
- The last merchant page must pass all required fields to the 51²è¹Ý ePayment System, and they must be passed using HTTP POST.
- The merchant application must manage all needed transaction information required for their business processes beyond what is contained in the required or optional fields. The merchant may handle this with a secondary field profile. This is coordinated with the Webmaster’s Office.
- The merchant’s pages will not collect or store credit card numbers or any personally-identifiable information. This is exclusively handled by the 51²è¹Ý ePayment system. “Personally identifiable information” includes but is not limited to credit card numbers, Social Security numbers, and driver’s license number. Exceptions must be approved by the Associate Vice President for Information Technology Services. This rule is critical. Non-approved exceptions are in violation of University Policy, and appropriate action will be taken to disable the merchant's site.
- The Webmaster’s Office must certify the merchant’s application before it can use the 51²è¹Ý ePayment system. This ensures that the 51²è¹Ý ePayment system can correctly process data passed to it by the merchant application. In certifying a merchant application, the Webmaster’s Office will test the merchant system by simulating orders. These simulated orders will verify that the merchant application passes the correct fields in the correct format to the 51²è¹Ý ePayment system. The Webmaster’s Office also verifies that the merchant application correctly transfers control to the 51²è¹Ý ePayment System. The Webmaster’s Office will not inspect code, verify correct math, verify optional fields, or verify the internal workings of the merchant application.
- The merchant must identify each transaction with a unique invoice number that complies with the invoice number schema. We provide an invoice number generator to simplify this.
- The merchant must always collect a billing address. The merchant may choose to also collect a shipping address if products or goods are to be shipped. Shipping address must be requested after the billing address. The ePayment application utilizes an address verification process. To prevent rejections, the billing name and address must match what is on the credit card or checking account. The merchant is strongly urged to put a statement by the billing address fields that instructs buyer to enter the same name and address that appear on credit card statements.
Following is a suggested statement:
Please make sure the name and address you have entered match your credit card statement information. The credit card transaction will not be accepted unless this information matches exactly. - Two important considerations for the country fields:
- A blank country field will cause the address to be validated as if it is a US address. Therefore, international transactions with a blank country field will fail.
- To guarantee US address verification, the country field must be blank, nonexistent, or contain "USA".
Required and Optional Fields
: required : optional
Invoice Number Schema
The invoice number is 14 alphanumeric digits. The first 2 digits are a code that shows the department from which the transaction originated. The next six digits is the current date in mmddyy format. November 30, 2001 would be 113001. The final six digits are a counter that increments by 1 for every new transaction. This counter will reset after each million transactions.
Note that if the month or day only have one digit, the digit should be preceded by a 0. For example, April would be 04, not 4.
An example transaction for OIT on December 2, 2002 could look like IT120202000032.
This invoice numbering convention is guaranteed to be unique for every transaction provided that no department will have more than a million transactions in a single day.
Following is an initial list of department codes:
Source | Department |
---|---|
AA | Affirmative Action |
AC | Accounting |
AD | Admissions |
AR | Aramark |
AT | Athletics |
BD | Budget Department |
BF | VP Business & Finance |
BN | Bookstore |
BS | Business Services |
C1 | Copy Center |
CB | Cox School of Business |
CC | Computer Corner |
CR | Career Center |
CS | Central Stores |
DC | Dedman College |
DE | Div of Eve and Summer Studies |
DV | Development and Ext Affairs |
ES | Enrollment Services |
FA | Student Financial Aid |
FB | Fort Burgwin |
GF | Gift Processing |
H1 | Housing & Residence Life |
HC | Health Center |
HR | Human Resources/Benefits |
IT | Information Technology Service |
LD | Long Distance |
LP | Lecture Programs |
LS | Law School |
MA | Meadows School of the Arts |
MC | Maguire Ethics Center |
MS | Material Stores |
PA | Purchasing |
PE | Pony Express |
PN | Park N Pony |
PO | Postal Services |
PP | CPPO |
PR | President's Office |
PS | Dept of Public Safety |
PT | Perkins School of Theology |
PV | Provost |
R1 | Registrar |
RS | Recreation Sports - SA |
SA | Student Affairs |
SL | Student Life |
SE | Engineering School |