|
|
|
Merchants
planning to accept and/or process credit card payments over
the internet should consider the following:
-
The
method of transmission of card data from cardholder to
payment server. Secure, encrypted transmission is
recommended, and required by many card processors, including
PayNet. This insures that cardholder data cannot be intercepted.
SSL (Secure Socket Layer) protocol is the current standard.
If your payment pages are located on the servers of a
payment gateway such as Authorizenet or Versign Payment
Services, then SSL is included with the gateway service.
If you plan to host your own payment pages, and send the
data to the payment gateway through an API, then you will
need to make those payment pages secure. Your website
developer should be able to incorporate SSL without difficulty.
-
The
method of communication with card processor for authorization
and settlement. Don't confuse the method of obtaining
card information with the method of processing. You can
take card numbers over the Internet, and then process
them by traditional means.
-
Traditional
point-of-sale terminals are sufficient for low-volume
operations, and can be implemented at low cost. But
they can't handle batch processing, don't handle import
or export of data, and must dial out for each and every
transaction. Also, at this time, most point-of-sale
systems do not support the transmission of Electronic
Commerce Indicators, the part of a transaction that
identifies it as an Electronic Commerce transactions.
Mastercard and Visa both require these indicators on
Internet-based transactions.
-
PC
software, which generally uses a dial-up connection
to the processor, can integrate with locally hosted
websites and other existing systems, and can efficiently
handle batch processing of transactions generated offline.
You can import to and export from such programs, and
several contain internal databases, which hold cardholder
data for recurring or installment sales. Not all PC
software supports the Electronic Commerce Indicators.
-
Internet
Payment Gateways are best for real-time online authorization
and/or settlement, when goods or services are delivered
automatically, for websites that are hosted elsewhere,
and when manual entry of transaction data from multiple
locations is desirable. Most payment gateways include:
- One
or two methods of integrating the gateway to your
website. "Weblink" methods use HTML to link your site
to customizable payment pages ocated on a gateway's
servers. API methods use application program interfaces
to transmit data from payment pages located on your
servers to the gateway.
- A
"virtual terminal" that allows you to enter sales
one-by-one from any Internet-connected browser.
- A
way to upload batches of transactions for authorization
and/or settlement in comma- or tab-delimited text
files.
- Reporting
and search functions.
All
Internet payment gateways support the Electronic Commerce
Indicators.
-
Timing
of authorization in relation to settlement. Online,
real-time authorization and settlement of card
transactions (essentially automatic processing)
is technically feasible, but often inappropriate. Federal
and state laws generally prohibit settlement of credit
card transactions until goods are shipped or services
rendered. This may necessitate a delay between authorization
and settlement. In addition, you may want to review address
verification responses, fraud screening and other details
of orders. In such cases, authorizations should be obtained
in advance, and settled only after review and fulfillment.
In such cases, processing system defaults that provide
for automatic settlement of authorized transactions must
be overridden.
-
The
potential for fraud. Merchants are liable for unauthorized
use of cards. The Address Verification Service (AVS) can
help deter fraud, but is not foolproof. In addition, merchants
should consider shipping only to credit card billing addresses
and requiring signatures upon delivery. Merchants prone
to high rates of fraud should consider using advanced
fraud screening programs such as those offered by Verisign,
CyberSource, Cybercash and other vendors. These systems
consider numerous characteristics of an order (not just
the credit card information) to assign a risk score to
a transaction. They are highly customizable, and check
against negative databases containing billions of other
transactions.
-
The
imposition of special terms. Special terms, such as
"no refunds," "exchanges only" or "non-refundable deposit"
are enforceable in a bank card sale only if the terms
are printed prominently on a document that the cardholder
signs. When appropriate and feasible, merchants should
consider obtaining such documents from cardholders.
-
The
necessity of transmitting Level II (or, in the future,
Level III) Corporate Purchasing Card data. Merchants
who accept Corporate cards, or Corporate Purchasing Cards,
can minimize costs by having their card processor set
up their accounts properly for the acceptance of Corporate
cards, and by submitting order numbers, customer codes
and sales tax amounts (Level II data) with all Corporate
card transactions. The processing system, of course, must
be capable of transmitting such data. If Corporate card-using
customers are expected to demand itemization of charges
in the future, then the merchant should look forward to
submitting Level III (itemized) data.
-
All
costs associated with a credit card merchant account.
An awareness of Interchange rates and other costs and
account terms is essential. In general, a quoted discount
rate is just the beginning. Look for authorization
and other per-item fees, batch or deposit fees
and monthly or annual fees. Look for monthly minimums,
as well as limits on processing volume, transaction
amount, or average transaction amount. Find out how much
will be charged on non-qualified transactions,
or those that fail to qualify for your base discount rate.
(These surcharges are frequently marked up.) Determine
if you will be charged your discount rates on net
sales, after refunds, on gross sales, before refunds,
or on gross sales plus refunds. Finally, determine
when you will be paid, and whether your fees will be deducted
from deposits, or charged weekly or monthly. For more
information, see
If you're shopping and
Pricing sections.
-
The
card processing bank or agent. You must have an agreement
with a merchant-processing bank (also known as "acquiring
bank"). It may be reasonable, or even preferable, to deal
with a bank's agent, which may or may not be a party to
the agreement. Mastercard and Visa require all agents
to be registered, and reputable agents follow regulations
requiring disclosure of their bank affiliation(s) in all
solicitations. In any case, the bank or agent - through
its relationships with so-called "front-end" authorization
and data capture vendors - should be able to support any
and all processing methods you choose to employ. Merchants
should know from whom to expect service, and what sort
of service to expect. Do you deal with the agent or with
the bank directly? In either case, do you have a dedicated
sales representative, who is responsive, accountable and
armed with the tools necessary to service your account?
Or will you be dealing with a customer service help desk?
What sort of reporting will you receive? Monthly statements
should be expected, and other reporting options, such
as fax-back, software dial-up or Internet browser access
to account information, may be available.
|
|
|
|
|
|
Agent
of Harris Bank, Chicago, IL & Card Payment System, New York,
NY
© 2002, PayNet Merchant Services, Inc.,
2000 Town Center, Suite 2260, Southfield, MI 48075
|
|
|
