IGN E-Pay Guide
I. Purpose
II. Background
III. Disclaimer
IV.
Credit Card Transactions on the Internet
V. Building a Credit Card Application for the Internet:
Reference
Glossary
I. Purpose of Document
This guide has been prepared for the Department of Information Services (DIS)
customers on the Intergovernmental Network (IGN) that are considering
implementation of web-based credit card applications. Information about the
services that allow IGN customers to access and utilize the DIS E-Payment
service is located in various places. This guide is designed to explain the
basics of what customers need to know and to provide an easy road map for
getting detailed information on each detail.
Return to top
II. Background
Since June of 2000, DIS has provided a secure method for transacting credit card
payments via the Internet. This method has been available to all state agencies
on the State Governmental Network (SGN). In response to requests by state
governmental entities on the IGN the service was made available to IGN
customers in May 2002.
Return to top
III. Disclaimer
The material presented in this IGN E-Payment Customer Guide is for general
guidance only. DIS does not represent nor warrant that this is the only
information available or the only information that should be considered when
deciding to implement a web-based credit card system. DIS shall not be held
liable for any losses caused by reliance on the accuracy, reliability or
timeliness of this information. Portions of such information may not be useful
or applicable to an entity’s particular circumstance. Any person or entity that
relies on any information obtained from this Guide does so at his or her own
risk.
Return to top
IV. Credit Card Transactions on the Internet
The Office of the State Treasurer (OST) signed a contract with Bank of America
(B of A) Merchant Services in February 2000, enabling state agencies to accept
credit card payment for goods and services over the Internet. The first step to
building your credit card-ready Internet application is to become familiar with
the banking system and specific banking contracts your organization has in
place as well as your organization’s rules and regulations regarding credit
card transactions via the Internet.
Credit card processing enables the transfer of funds from a consumer’s bank to
the merchant’s bank. For a basic explanation of how this business is transacted
on the web visit Cybersource
Payment Service: How it Works.
In order to receive transferred funds from customer banks, the State Treasurer’s
bank, Bank of America, uses a transactions processor named “Vital”. Vital
processes the transaction with the customer’s bank causing a settlement to
arrive at the merchant’s bank. Vital is only one of several transactions
processors. Your bank should be aware of whether their transactions processor
does business with CyberSource.
CyberSource is called a “third-party credit card processor”. CyberSource's
online merchant Support Center will provide you with the information you need
to have your application utilize their services. The basics of the technology
and the general steps of credit card processing are outlined at their web site.
Please familiarize yourself with
Cybersource Support, accessible with the login “cybersource” and
password “cybersource”.
Note: An important issue to be aware of is the merchant’s responsibility in the
case of fraudulent credit card charges. On the topic of financial liability
Visa advises consumers, “You are not liable. Consumer protection varies from
country to country and from region to region. In card-not-present transactions
(mostly mail order and Internet purchases) Merchant banks are responsible for
any charge-backs. Generally, these charges are passed from the bank back to the
merchant.”
The Digital Government Applications Academy was created by the Department of
Information Services (DIS) to help agencies and state governmental entities to
accelerate and synchronize the deployment of their digital government services.
The Academy has basic information about building your Internet credit card
application. Informational documents are available for you to view at:
ATOM:
Applications Template and Outfit Model.
Return to top
V. Building a Credit Card Application for the
Internet
Step One: Define Business Requirements
Describe what your web application is to accomplish. Make your basic
requirements as complete as possible describing what, exactly, this application
will do and how it will fit your business strategy. Try to be specific
concerning such factors as the scope, the data sources, the number of financial
transactions and dollar amounts, and the benefits you hope to gain by using
credit cards. Be sure to talk with your IS, program, and fiscal shops. Your
organization’s Accounting Department and Budget Analyst can also be of great
assistance throughout the process. Be sure that your e-payment application is
in compliance with all applicable regulations and laws and be aware that the
application may be required to be economically feasible.
Return to top
Step Two: Design and Cost your Development and Production
Environments
At this point you need to make preliminary design decisions about your
application including the operating environment and system maintenance in order
to estimate their costs. Though not exhaustive, the following is a list of
minimum considerations you need to include in your planning and cost estimates:
-
Provision of an E-Payment application environment with: a web credit card
application, a web server, a database server, internet connectivity, capability
for communication with a third-party credit card service provider, such as
CyberSource.
-
Experienced credit card application design and development, and application
assistance.
-
Obtaining qualified Information Technology staff to provide and manage this
complex environment including provisions for such considerations as performance
and capacity management, recovery services, and 24-hour system support.
Development of web applications and support for the development environment
need to be provided. Establishment of help desk support for your client
(consumer) applications and establishment of a help desk for systems problems
to mitigate outages: local, Credit Card provider, bank servers, Internet
access, etc.
-
Availability Management
-
Change Management to track changes to application and changes to application
environments (development and production.)
-
Problem Management, i.e., tracking, alerting, escalating and solving problems
to identify performance degradation, for notification of identified events that
have or may have an adverse affect on service delivery to customers, and for
notification of failed processes.
-
Security Management to protect sensitive consumer information from unauthorized
external access and to avoid the broadcast on the Internet of the application
owner’s intellectual property, proprietary and confidential data. Credit card
systems should employ access control and secure the platform against known
security risks.
-
Physical Environment Management should ensure climate control, system from
power loss, fire, etc.
-
Restoration Management should provide for regular, scheduled data back-ups and
restoration.
-
Disaster Recovery should provide for a resumption of services after a
significant disaster at the production site. (CyberSource recommends a manual
process as backup in the event CyberSource or the Internet Service Provider
becomes unavailable.)
You may consider using DIS’ IGN E-Payment Service to satisfy many of these
requirements.
Return to top
Step Three: Prepare Economic Feasibility Study
In order for state agencies and institutions to accept credit card payments via
the Internet they must be continually authorized by the Office of Financial
Management (OFM). Your organization may require a similar review process. A
business case rationale may be required demonstrating the benefit to the
organization of accepting credit card payment. Your organization may also
consider conducting a pilot project in order to evaluate actual costs and
implementation impacts.
A resource you may like to review as you begin any economic feasibility study
process is the State Administrative and Accounting Manual (SAAM)
Chapter 40.
Return to top
Step Four: Set up your Bank Merchant Account and CyberSource
Merchant Account
As soon as you receive official approval from your governmental organization
(city or county) for your E-Commerce application, schedule a visit with your
accounting office to set up a Merchant Account with the organization’s bank.
Setting up a merchant account to handle Internet transactions is a
comprehensive process. Your accounting office is there to help you with the
coordination of numerous parties that must be contacted before your account can
actually process transactions.
Your organization’s bank may also contact CyberSource on your behalf. In any
case, your accounting office will assist you. CyberSource will then, in turn,
assign to your office a CyberSource merchant account ID. Once you receive the
CyberSource merchant account ID you will receive an e-mail from CyberSource
with specific instructions for configuring your account with CyberSource. This
will include specifying who is to receive reports, technical support bulletins,
service bulletins, and implementation services. CyberSource also provides
passwords to allow access to transaction reports and other Online Merchant
Services.
Important issues to be aware of when setting up your accounts include:
-
Consider who will be the agency fiscal contact(s) for the organization’s
banking account during the day-to-day processing. Include this person early in
the planning and implementation phases of your project.
-
Setting up a bank merchant account may take several weeks.
-
Make no assumptions about other merchant accounts. A merchant account that you
may currently have for "over-the-counter" transactions will not be sufficient
for Internet transactions. When contacting your accounting office, make sure
you request Internet Credit Card Processing.
-
You will receive two kinds of merchant account numbers also commonly known as
Merchant Ids or MIDS:
-
Your organization’s bank MID (a series of numbers that the bank uses)
-
CYBS MID which is assigned by CyberSource and is alphabetic
Please coordinate with your accounting office.
Return to top
Step Five: Application Design and Development
-
Design Recommendations
Credit card applications should guard against allowing consumers to submit
their order more than once. This will protect the consumer from multiple
charges to their credit card.
Credit card applications also typically send purchasers an order verification
by e-mail after their account has been successfully billed. This accomplishes
two aims: first, this satisfies the consumer’s expectation for a positive
notification verifying the purchase, and second, this also indicates to the
buyer that the purchase was made once and only once.
Credit Card Service Disruptions
Despite the best efforts of your Credit Card Service Provider, service
disruptions can occasionally occur. Individual bank processors can also
experience outages. When these disruptions occur, they may hamper your ability
to complete sales in a timely fashion. To capture these sales and ensure
customer satisfaction, CyberSource recommends that you consider implementing
some or all of the following best practices:
-
Accepting orders during the outage period,
-
Selectively Fulfilling orders, and
-
Referring customers to your customer service telephone center (run by your
organization).
Learn more by searching CyberSource “Electronic Payment Solutions” or
contact a sales representative for a consultation. Also see CyberSource
payment solution functional data using login name "cybersource" and
password "cybersource".
In the case of a failure at CyberSource, an Emergency Notification from
CyberSource will be passed on to DIS, and then, by DIS, to all interested
DIS-hosted customers. Notify your DIS account representative to request where
such messages should go to, e.g. your customer service desk, etc.
-
Retaining and Disclosing Customer Data
State offices are required to assure that information is protected according to
the Public Disclosure Act, which has been amended to exempt credit card numbers
from public disclosure.
See EXECUTIVE ORDER 00-03, PUBLIC RECORDS
PRIVACY PROTECTIONS. Your office may have similar regulations in place.
-
Credit Card Service Provider Software Installation
You may download the merchant software, called the Internet Commerce Suite
(ICS), from CyberSource to your development environment, at any point in the
process. You do not need to have a merchant account from OST in order to test
the ICS client software with your application. However, in order to process
actual transactions in “live” mode (that is, to conduct actual bank
transactions with real credit cards) you will need a CyberSource merchant ID.
After receiving your CyberSource Merchant ID you will receive a logon and
password that allows your staff to enter the CyberSource Online Support Center.
CyberSource controls this logon and password.
CyberSource provides customers with reference guides to their API for a variety
of languages including Perl, C and most UNIX platforms. DLLs, and COM objects
for Microsoft Windows and Windows NT, and plug-in components for a variety of
commerce platforms, including Microsoft SiteServer, Microsoft Active Server
Pages, IBM Net.Commerce, are provided.
The APIs for these implementations are documented and available from
CyberSource:
www.cybersource.com/support,
using login name "cybersource" and password "cybersource".
www.cybersource.com/solutions/electronic_payment/solutions/service.xml
Using ID/password cybersource/cybersource visit: www.cybersource.com/support_center/implementation/downloads/
Return to top
Step Six: Set Up Your Reconciliation Process
Your comptroller probably has a specific process for accounting for credit card
transactions. Your accounting office is concerned with proper accounting
practices for establishing a good audit trail. Be sure to get your accountants
together with your financial offices early in the design process. The process
of cash management/accountability is an integral part of offering goods and
services online to citizens and to businesses.
To review how business is transacted on the web, visit the site: Cybersource
Payment Service: How it Works.
Return to top
Step Seven: Application Testing
Before going “live” (i.e., conducting actual bank transactions with real credit
cards) extensive application testing is encouraged. While in the development
phase, a test credit card may be used to simulate an entire transaction with
CyberSource. Note: test transactions completed with a test credit card will
never reach the bank for a "real-time" authorization.
As a part of testing you will want to generate return codes to be sure your
application responds correctly to them. To find how to do this log into
CyberSource’s “Testing Information” screen (login,
password = cybersource, cybersource). Read “Testing Credit Card Services” and
“First Data (FDC) Testing Information.” You should point your application to
the CyberSource test server “ics2test.ic3.com”. By including fields with the
given values you can elicit the return codes you wish to get back.
Return to top
Step Eight: Implementation at DIS
Implementation of your system depends entirely upon the design decisions you
have made (Step Two) concerning your system architecture and the implications
of those decisions. For instance, have you chosen to run your application
employing a Unix or NT operating system? What provisions have you made to
provide security to protect customer data and your organization’s data and
application? What type of access will your users require? What support systems
need to be in place? This section will address implementation specific to DIS
hosted IGN E-Payments applications.
DIS’ E-Payment environment for IGN Customers is hosted on a Windows 2000 server.
The server configuration employed by DIS makes use of two shared Windows 2000
Internet Information Servers (IIS), one is a staging and the other a production
platform, and a SQL server database platform with a backup. Applications or
storefronts can be hosted through Microsoft's Site Server - Commerce Edition or
they may reside as stand-alone Active Server Page (ASP) applications. In either
deployment, the applications may utilize the Cybersource payment processing
service. If customers are connected to the IGN and wish to utilize the DIS
E-Payment service, the following describes the procedure to follow:
-
Complete a CSA and an SLA with DIS
Customers not currently doing business with the Washington State Department of
Information Services (DIS) need to complete and submit a Customer Service
Agreement (CSA). The online
Customer Service Agreement now makes it easier, faster and more
convenient for qualifying organizations to do business with DIS. Please
complete and submit the form as instructed.
After establishing a business relationship with DIS, customers may submit a
request for IGN E-Payment Service by completing the
E-Payment Application and e-mail it to the CSD Customer Service.
If there are further questions customers may e-mail CSD Customer Service or call
360-902-3440. Customers will be contacted and assisted with completing a
Service Level Agreement (SLA) describing customers and DIS’ responsibilities,
contacts, and procedures. This legal contract needs to be completed and signed
by the appropriate officials before service can be initiated.
-
VPN Connectivity
Using the Internet without encryption makes the data vulnerable to public
observation, tampering, or capturing. The DIS Virtual Private Network (VPN)
Service is safe and reliable because it uses encryption to securely send
transmissions. A "tunnel" is configured between the client workstation and the
DIS VPN Service gateway so the data is kept private as it travels over the
Internet. Additionally, the DIS VPN Service utilizes a secondary authentication
method, such as digital certificates or secure token cards/key fobs, to ensure
the authenticity of the end user. In this way the DIS VPN Service ensures that
the data is transmitted intact and that the end users transmitting the data are
who they say they are.
In order to secure the DIS E-Payment application web servers, they have been
isolated from direct Internet access. Since IGN application developers will
need access to the Staging Server to upload the application and periodic
updates, DIS provides VPN access for these individuals. Within the application
for IGN E-Payment Services customers will find a section where the names and
contact information for the two application developers are collected.
Within two or three business days after receipt of the signed SLA, customers
will be contacted by DIS to coordinate distribution of the following:
-
two secureID tokens, one for each requested user
-
a CD with client software and instructions for all supported platforms.
Customers may make as many copies of the CD as desired updates will be
available.
-
E-Payment Server System Administration
In addition to receiving VPN access, the system administrator for the E-Payment
servers will contact the IGN customer shortly after completion of the SLA. The
system administrator will discuss, in detail, the system needs and begin to set
up the IGN E-Payment Service account. Customers will not have access to the
account until they receive their VPN materials.
Items to discuss with the system administrator:
-
Database requirements
-
Staging vs. production servers functionality
-
Replication procedures
Customers may e-mail the
system administrators with questions or for instructions.
-
Fortress Access for your Test Customers & Customers
The IGN E-Payment Server that hosts your application is located inside the state
security perimeter and end-users will need to access application from the
Internet, the IGN, or both. In fact, there are two environments that will need
access from the Internet or IGN: first, “Staging” (testing) environment and,
second, the “Production” environment. To accomplish this, end users will be
utilizing a DIS secured access service known as “Fortress”.
IGN Customers need to designate an Agency Registration Authority (ARA) to
administer a Fortress account. That ARA will be receiving, from DIS, an account
ID and password and a special URL to visit in order to activate the account.
An ARA (Agency Registration Authority), has two administration functions:
-
Administer ATAs (Agency Technical Administrators) - This function allows DIS
customers to add and remove ATAs for this domain. (The Agency Technical
Administrator [ATA] plays a technical role in Fortress. The ATA also adds
applications to Fortress via an online form.)
-
Administer Applications - This function allows DIS customers to administer the
applications for their domain. Furthermore, it allows customers to change an
applications' status, and associate ATAs with their respective applications.
Keep in mind that the ARA will be administering access to a domain on the
“Staging” and on the “Production” environments. The ARA assigns ATAs to each of
the domains.
Procedure for the ARA to assign additional applications to your Fortress
account:
Fortress sees an "application" as everything on a specified web server. If there
is more than one application on the web server, it is necessary to create a
"virtual host" for each application so that Fortress can connect to each
application as if it was a separate web server. The virtual host can be either
a "hardware" virtual (separate IP address) or a "software" virtual (alias
header).
-
From the “MyATA” page, the ARA clicks on the “Add a new Web application to
Fortress” link.
-
The ATA fills out the fields on the form. Only those lines with a red asterisk
are required:
NOTE: Field level help is available on the form by clicking on the field number
(i.e. A1)
Section A2, line 1 - enter name, phone number and e-mail address.
Section S1 – enter a short name for application - this becomes part of the
application's Fortress URL as shown on the form.
Sections S2, S3 - just comments, but you must enter something.
Section T1, line 1 – “server” name is defined by the customer. Address is the IP
address or DNS name for customer’s server. If the server has more than one
application on it, put a "virtual host name" in the Virtual Host field to
identify to the server whose application is desired.
-
Click the "Submit" button at the bottom of the form.
-
The ARA for the customer agency may have to approve (activate) before it can be
used, according to the provisions made in the SLA.
How to change or delete an application:
-
From the MyATA page, select the application to change.
-
The ATA sets the application status to "delete" in section S4 if deleting or to
make any other changes as needed.
-
Click the "Submit" button on the screen
Return to top
Step Nine: Cybersource Site Management
The CyberSource Support Center “Manage Commerce Services”,
(password necessary, use “cybersource”, “cybersource”) provides information
concerning:
Startup Checklist, Merchant Bank Information, Tutorials, Best Practices,
Services Documentation, Quick References, Update Keys/Certificates, Product
Update Notification, etc.
CyberSource also makes available “Merchant Notifications” which detail outages
and upgrades by e-mail to the Primary Contact.
Return to top
Step Ten: Production Mode
The CyberSource software includes the Ecert (certificate generation) application
used to generate your public and private keys. These are the two keys used by
CyberSource to positively identify messages as coming from this particular
server. One key is held by the server and encrypted into the message; the other
is publicly available on a vendor site. The Ecert process generates a
certificate request and submits it to the CyberSource server. Upon receiving
the request the server replies with a signed certificate. Before attempting to
use the Ecert application CyberSource must set you up as a test merchant. DIS
will assist you with contacting your CyberSource support representative to
register as a test merchant if you have not already done so. DIS will also
assist with the Ecert process that is required for each DIS customer’s
installation.
See CyberSource's Web site “Update Keys and Certificates” for
specific instructions on how to run Ecert. (login=cybersource -
password=cybersource).
After you are assured that your development and testing is complete, and in
order to have CyberSource activate your account to process actual credit card
transactions, an e-mail must be sent to:
-
Your Merchant Support Representative at CyberSource stating your desire to turn
your account from test mode to “live.” Your support representative will confirm
your account is current and send a return e-mail stating your account is now
“live”. At this point, all transactions require a real credit card number and
transaction fees will be charged to your account.
-
CSD Customer Service with instructions to
move the DIS hosted E-Payments application from the "staging" to the
"production" environment.
Return to top
Reference
Access Washington (AW) provides an informative
online tool kit for Web development, including AW templates.
ATOM:
Applications Template and Outfit Model
E-Payments
services web site
CyberSource development guides (login: “cybersource” password: “cybersource”):
CyberSource Support for
the SCMP Checklist and the Application Programming Interface Developer's Guide.
CyberSource “Best Practices”.
Return to top
Glossary
-
Agency Registration Authority (ARA)
Secure Access Agency Registration Authority with the ability to add and remove
ATAs and to administer the applications for the domain.
-
Agency Technical Administrators (ATA)
Secure Access Agency Technical Administrator with the ability to create new
applications or edit/update the assigned applications in the domain.
-
Applications Template and Outfit Model (ATOM)
The
Applications Template and Outfitting Model (ATOM) provides a
step-by-step guide to building and implementing new Internet applications and
includes information on policies, business, technical, project management, and
authorizing requirements for government e-commerce applications.
-
Customer
Service Agreement (CSA)
DIS provides information and technology services for Washington state agencies,
local governments, Indian tribes, qualifying nonprofit corporations and Federal
agencies.
-
Digital Government Applications Academy
The Washington State
Digital Government Applications Academy (Academy) helps government
agencies accelerate the development and deployment of online government
services. The Academy is a unique learning environment where agencies come
together to imagine the future, then build it.
-
E-Payment
Customer Guide
Prepared for DIS customers that are considering implementing web-based credit
card applications. Tailored to the specific needs of state agencies, it
describes the steps necessary from requirements specification through
application installation on the state secure Web servers.
-
Fortress II
The DIS Fortress
Service is a Proxy/Authentication service that allows web resources on
the State Government Network to be published to the Internet.
-
Inter-Governmental Network (IGN)
The wide-area TCP/IP network created by the joining of many "local" (i.e. city,
county, and tribal ) government intra-nets through a series of DIS-managed
routers. The IGN contains some local governments but not all local governments.
Further, it may contain traffic from non-local government entities through the
interconnection of local government business partners with local governments.
-
Office of Financial Management (OFM)
Provides vital information, fiscal services and policy support that the
Governor, Legislature and state agencies need to serve the people of Washington
State. Website at:
http://www.ofm.wa.gov/
-
Office of the State Treasurer (OST)
As the state’s chief fiscal officer, the
Treasurer provides banking, cash management, investment, and accounting
services for state government.
-
Production Environment
The E-Payment server that hosts active applications accessed by end users.
-
Service Level Agreement (SLA)
A document detailing the expectations and responsibilities of both the provider
(DIS) and the customer (state agency or other Washington state governmental
entity) concerning the goods and/or services to be provided to the customer.
-
State Governmental Network (SGN)
The wide-area TCP/IP network created by the joining of many State agencies,
boards and commissions intra-nets through a series of DIS-managed routers. The
SGN contains only State government entities but not all State government
entities.
-
Staging Environment
The Microsoft Windows 2000 web server on which testing may be performed prior to
replication to the production machine. It is assumed that development will be
accomplished on a separate computer at the developer’s site.
-
Virtual Private Network (VPN)
The DIS VPN Service uses the Internet to inexpensively transmit encrypted data
between the client workstation and the DIS VPN Service gateway. Additionally,
the DIS VPN Service utilizes a secondary authentication method, such as digital
certificates or secure tokens, to ensure the authenticity of the end user.
Return to top