Introduction

Emarket is a Transact (formerly CASHNet) module that allows departments to collect money for approved services/products/fees via online storefronts or checkouts.

Storefront

Customers are linked out from a department website to a customized storefront where they can select and pay for items via credit card or ACH (electronic funds transfer). Currently there is a 2.95% surcharge fee assessed on all credit card transactions.

Checkout

In a checkout setup, online payers will view and select items on an NMSU website or third party website. When it is time to collect the payers’ payment information, they will be passed to Transact. Transaction information is passed to Transact behind the scenes including what the payer is buying, how much they should pay and any other information collected from them during the transaction process.

Emarket sites are PCI compliant and funds are deposited directly to the general ledger.

How it Works

Departments are asked to complete a Questionnaire for an eMarket site. The requested information includes:

• a brief description of the purpose of the eMarket site
• targeted customer base
• method of payment

University Accounts Receivable Office Role

The UAR Office will:

• ask the department to complete an information gathering form which includes providing the chosen site name, the items, descriptions, amounts, any information they wish to collect on the transaction, and any custom messages they want displayed in their storefrontcontact the department and set up a meeting to discuss setup and design
• create the site in a test environment for the department to view and request any changes
• move the site from “test” to production once the department is satisfied with the setup
• provide the department with the URL to their site

Requesting Department’s Role

The Department will:

• provide UAR with a completed information gathering form which will include a list of products/services, the description, the amount, and any additional information they wish to collect for each transaction such as buyer’s name, address, etc.
• provide any images they wish to display with their products/services
• review and thoroughly test the site in the test environment
• request any final changes
• place a link on their website to direct their customers to their eMarket site

Types of Products/Services in eMarket

Products/Services Allowed

Emarket may be used for a variety of approved products, services, or fees such as:

• conferences
• membership fees
• event tickets
• physical goods

Products/Services not Allowed

• Emarket is not intended for payment towards charges posted to a student’s account
• Fees charged to all students enrolled in a course are considered course fees and should be submitted to the Budget Office for approval and subsequent posting to students’ accounts. New fees of any type charged to students must be approved by the Budget Office.

Storefront Site Overview

Banner

A banner is a graphic at the top of your storefront page. Departments may use the same banner that appears on their website for their storefront.

Item Codes & References (inventory and fulfillment)

All items within a store are tied to an “item code” which will include a print description of the item, the amount, and the GL account code where the payment will be deposited. Additional information can be collected for each item such as name, address, email, etc of the buyer. These are called “reference fields” and can be required or optional.

If a physical item is being sold, there is a setting to require “fulfillment” of the product. This will place the order in a pending status and not charge the customer until the department operator fulfills the item by making sure the product is available. If the product is a physical item, once it is sent to the buyer the item may be fulfilled. Emarket can also track inventory for products where a limited number may be sold.

Custom Messages

There are several places within the storefront where custom messages can be placed. Messages are simply explanatory text or a change to the wording of a button within your storefront.

Categories

If there are several products/services offered within a store, they can be organized into categories so customers can find them easier. An example might be a category of “Tickets” and within that category, are several types of tickets available for sale.

Store Scheduler

Stores may be brought online/offline via the store scheduler. Online means a store is visible to your customers; offline means the store will display a custom message that it is currently unavailable.

Reports

Reports can be generated and emailed to the end user on the payment activity within their storefront. Reports are based on a combination of selected criteria such as date range, transaction type, item code, amount, or GL account code. Reports may be run in summary or detail mode and formatted using Excel, Word, or PDF.

Checkout Overview

Checkouts can be customized to a department’s specifications and include the items, references, and other transactional data necessary to report against or extract to your student or financial system, provided no additional interfaces need to be designed.

Checkout requests are the information passed from a department’s front-end store to the Transact Payments Checkout site. An HTML form must be created to send the information to the Transact Payments database. These forms can be very simple or extremely complex, but all requests will have the same basic parameters.

The main challenge with a Checkout is that the catalog page cannot be seen in the testing environment. The user will skip all of the initial pages and will be taken directly to the page where they will select their payment method. Therefore, it may be difficult to visualize the store’s progress, and you may find it useful to keep a spreadsheet of each item and the appropriate references for them.