EBusiness Process Overview

EBusiness Overview

eBusiness Overview

The EBusiness online payment is a centralized process that allows patrons to pay online for NAU goods and services using their credit card or electronic check. The EBusiness online payment process allows realtime payment authorization/billing over a secure Internet link.

The EBusiness online payment utilizes a third party processor called CyberSource.  CyberSource provides services designed to automate the commerce transaction process.  

The figure represents an overview of the EBusiness online payments from the NAU department’s perspective.

  1. The customer moves through the various departmental web pages. The department inserts the transaction into a “holding” table/file until the payment for the transaction is processed.
  2. The department passes six variables to the EBusiness server via an http post.
  3. Send control back to the url provided by the department. 
  4. Automatic postback of the authorized/billed transactions to the client via an http post (three variables are posted back). This is an optional feature. 
  5. The client can use this information to update their "pending orders" table.
There are a few different options in using eBusiness. The department can:
  • pass single description (Trans_Desc) or detailed items (array) to the eBusiness server
  • use the postback option ("auto-callback, see #4 above) or have no postback (rely on daily reports)
  • tie the eBusiness process into a website or use eBusiness in place of credit card "swipe machines."


EBusiness Security

Secure Socket Layer (SSL)

Who uses SSL? 

SSL is the de facto standard for encrypted and authenticated communications between clients and servers on the Internet. Virtually all online purchases and browser-based monetary transactions that occur on the Internet are secured by SSL. However, SSL is not just limited to securing e-commerce transactions; other examples of how SSL is used include secure the transmission of: PIN numbers, confidential account information, Business-to-Business (B2B) extranets, and Private organizations intranets.

How SSL Works 

When a client and server communicate, SSL ensures that the connection is private and secure by providing authentication and encryption. Authentication confirms that the server, and optionally the client, are who they say they are. Encryption creates a secure ‘tunnel’ between the two, which prevents any unauthorized system from reading the data.

SSL-enabled clients (such as a Netscape or Microsoft browser) and SSL-enabled servers (such as Apache or IIS) confirm each other’s identities using digital certificates. Digital certificates are issued by trusted third parties called Certificate Authorities (or CAs) and provide information about the individuals claimed identity, as well as their public key. By validating digital certificates both parties can ensure that an imposter has not intercepted a transmission and provided a false public key for which they have the correct private key.

The secure tunnel that SSL creates is an encrypted connection that ensures that all information sent between an SSL-enabled client and an SSL-enabled server remains private. SSL also provides a mechanism for detecting if someone has altered the data in transit. These message integrity checks ensure that the connection is reliable. If, at any point during a transmission, SSL detects that a connection is not secure, it will terminate the connection and the client and server will establish a new secure connection.

Basic Authentication

This technology utilizes the Web server content's directory structure. Typically, all files in the same directory are configured with the same access privileges. A requesting user provides a recognized user ID and password for access to files in a given directory. More restrictive access control can be enforced at the level of a single file within in a directory, given that the Web server software provides this capability. Each vendor's Web server software has its own method and syntax for defining and using this basic authentication mechanism.

Setting Up Basic Authentication on Unix

Please refer to the Apache documentation on authentication and authorization.

Setting up basic authentication on IIS (www4):

An account has been set up on www4 for EBusiness basic authentication (srvEBiz).  The proper security permissions need to be set up (via FrontPage) for the subweb that contains the postback file.


EBusiness Postback

The client can set up a “pending orders” database table to insert the transaction prior to it being passed to the EBusiness server for authorization/billing.

The client can receive an “immediate” (within 2 minutes) response as to whether a customer’s payment was authorized and billed.   The variables (unique_id, amount, date_time) will be passed back to the client via an http post.  This information can be used to update the client's “pending orders” table so the customer can receive their goods/services.

Basic Authentication is used along with SSL to ensure that the EBusiness server is talking to the server/postback url provided by the department. The department website must use a secure site (https).

To utilize the postback, the client will have to supply the userid, password and postback url.

This is an example of a database table that could be created to account for transactions that are passed to the EBusiness server.  The billed date_time would be passed back (along with the unique_id and amount) via the postback method after the transaction has been authorized/billed by CyberSource.









Application Fee


7/30/2002 9:31:22 AM

7/30/2002 9:34:07 AM



Application Fee


7/30/2002 11:28:45 AM

7/30/2002 11:54:53 AM



Application Fee


8/19/2002 8:27:44 AM

8/19/2002 8:28:31 AM



Application Fee


8/19/2002 9:11:55 AM



Application Fee


8/19/2002 9:14:21 AM

8/19/2002 9:47:02 AM



EBusiness Credit Card Processing

Credit Transaction


  1. Purchaser places order.
  2. Merchant securely transfers order information to CyberSource over the Internet via using a secure, encrypted messaging protocol (SCMP). CyberSource receives order information and performs requested services.
  3. CyberSource formats the transaction detail appropriately and securely routes the transaction authorization request through its payment gateway to the processor.
  4. The transaction is then routed to the issuing bank (purchaser's bank) to request transaction authorization.
  5. The transaction is authorized or declined by the issuing bank or card (Discover, American Express).
  6. CyberSource returns the message to the merchant.
  7. Issuing bank approves transfer of money to acquiring bank. The acquiring bank, in turn, credits the merchant's account.


E-Check Processing


     This diagram illustrates how real-time, electronic check processing works using CyberSource Payment Services.

  1. 'Payer' (customer/bill payer) is prompted to authorize electronic debit, enter bank routing number (ABA#) and account number.
  2. Merchant's sales system securely transfers order information to CyberSource over the Internet.
  3. CyberSource forwards bank routing number and account number to processor.
  4. The routing number and account number are validated, and the integrity of the account's checking history is verified. Processor forwards approve/decline results to CyberSource.
  5. CyberSource returns approval/decline message to merchant.
  6. If approved, CyberSource routes check for settlement through a processer to the Automated Clearinghouse System (ACH). Funds are deposited in approximately 1-3 business days.


Related Services

Not available to students Available to facultyAvailable to staff

EBusiness enables departments to accept online payments via credit card or electronic check.