Mobile Payments Do Merchants Have the Hot Potato?
By Holly K. Towle
The mobile transformation has catalyzed an array of new payment methods
(NPM) emerging both in the United
States and around the world. The concept of mobile payments usually refers
to payments made with a mobile device,
such as a cellular phone, as well as various other elements, such as applications
that might be on the phone or are otherwise used by devices relating to the NPM.
Discussions about mobile payments usually cover the imperative of meeting the
needs of particular participants, such as
payment method organizations (e.g., a
card brand like Visa); clearinghouses and
networks (like ACH); issuers and acquirers of cards that work with an NPM (like
a “swipe” device for a mobile device);
issuers of NPMs that work without cards
(like a bar, QR, or other code); carriers
(like a telecom); and, of course, consumers. The discussion is relatively silent,
however, about merchants and their
needs and obligations.
But not entirely silent. Much has been
said about the need to offer NPMs that
merchants can use to make their customers happy. The silence centers on who has
or should have the “hot potato” of regulatory compliance. Is it the merchant?
Or is it one or more of the other participants? Another question is whether
the entity holding the hot potato ends
up with it because the law tossed it their
way—or because a contract made the
toss. Related questions are whether the
NPM is transparent enough for the hotpotato-holder to determine what laws
apply, and whether the relevant contracts,
technology, and equipment allow the hotpotato-holder to understand and achieve
legal compliance.
In reality, there will be many hotpotato-holders, and this article could be
written with great sympathy (given the
maze of regulations and costs of compliance) from the perspective of any of
photo: istockphoto
Published in The SciTech Lawyer, Volume 9, Number 3, Winter/Spring 2013. © 2013 American Bar Association. Reproduced with permission. All rights reserved. This information or any portion
thereof may not be copied or disseminated in any form or by any means or stored in an electronic database or retrieval system without the express written consent of the American Bar Association.
them. Because merchants are overlooked
more than other participants, this article takes a view from their perspective of
several issues that merchants may wish
to consider before accepting any NPM
arrangement.
The Bottom Line
NPM structures and contracts largely
appear to be ignoring the many issues
facing merchants. They also seem to
assume that merchants will have or
accept the same attitudes and risk
allocations for NPMs that they have traditionally accepted for credit and debit
cards.
Such assumptions are questionable
in a world where merchant attitudes are
changing and the success of a popular
NPM may plummet if merchants discover it lobs hot-potato risks to them
or risks that they cannot practically
address. Recent litigation by merchants
against payment organizations illustrates
that merchant attitudes are changing.
NPMs that anticipate what merchants
(and other participants) will be legally
required to do and that “bake in” an ability for achieving regulatory compliance
should have a greater chance of longterm success.
Accordingly, this article addresses a
dozen questions merchants might ask
when offered an NPM. I focus on only a
few such questions because the mobile
payment combination of money, consumers, advertising, electronics, and
old and new payments alternatives can
trigger a staggering number of compliance-costly federal and state laws and
regulations per NPM. The fact that regulators might be standing back to see
what develops before taking enforcement
action is akin to an ephemeral reprieve.
Industry lore to the effect that mobile
payments fall between so many cracks
Holly K. Towle is a partner with
K&L Gates LLP, an international law
firm. She is listed among the top 25
information technology lawyers in the
Best of the Best USA and is included
in the Financial Institutions Law and
Information Technology sections of The
Best Lawyers in America.
that they are unregulated is a myth.
What Is the Actual Transaction, and
Who Has the Related Regulatory
Compliance Obligations?
It is a serious mistake to assume that all
NPMs are the same or even similar. Each
is unique, and small factual differences
can switch on or off different legal or contractual rules and exceptions. Merchants
asked to accept any NPM should ask this
question: Do I know what the NPM actually is as a legal matter, and do I have any
legal compliance obligations—or exposure for someone else’s noncompliance?
Answers are not easy or readily apparent, and the NPM contract might or
might not reflect the actual NPM structure or applicable laws. This is a new
frontier.
For example: assume that you (the
reader) are a merchant and are asked
to let your customers use their mobile
phones with a new terminal or card
reader the NPM gave you. You’re not
really sure what payment method the
NPM utilizes, but you get paid by the
NPM provider within a few days. Something obviously worked, but what
actually happened and what did you do,
by law or contract, and did any of that
trigger any legal obligations you did not
meet? Go further:
• Federal Regulation E (12 C.F.R.
Part 1005) applies to consumer
debit card transactions and certain
“asset accounts,” gift cards, loyalty
programs, and so on. It requires
you to provide a paper receipt for
debit card transactions. Did you
comply (and did the paper comply with Reg. E and debit card
rules)? Could you have complied
(did the NPM have printing functionality)? Some card rules allow
delivery of e-receipts, but bow to
applicable law. One law is the federal Electronic Signatures in Global
and National Commerce Act
(ESIGN), which allows substituting
an “e-receipt,” but only if particular
disclosures and consumer consents
are first obtained. Who complied with ESIGN (and if it was
supposed to be you, what feature
of the NPM allowed you to do that,
and how long would the line have
become while you did it)?
• Is the NPM provider a service provider you can even use, i.e., does it
appear on any required, approved
list of service providers or agents
for the transactions at issue and if
not, why not?
• Maybe you relied on an NPM code
relating to consumers who registered for an NPM account and
then associated one or multiple
payment methods with their NPM
account. You have no idea what
payment method was used by the
consumer and NPM for the transaction with you—you simply got
a “We’re good to go” code, and
you believed it and delivered merchandise. At that time, did you or
someone else have a compliance
obligation (by law or contract) that
was not met? If the answers are
“you” and “yes,” did the structure
allow you to achieve compliance,
or are you sailing on hope that
somehow the NPM took care of
it all?
• Will use of the NPM put you in
breach of processing contracts you
already have?
None of these and other questions
can be answered generically. They vary
per NPM and per the relevant laws and
contracts (including card organization
and payment system rules).
Is Anyone Engaging in Prohibited
Laundering?
When a credit card is part of a transaction, card organization rules and some
laws preclude “laundering.” In this context, that means submitting, or allowing
someone else to submit for a merchant,
credit card slips for transactions that were
not actually between the submitting merchant and the cardholder.
For example, assume Merchant 1, a
small shoe store, doesn’t have an agreement allowing it to accept credit cards. It
arranges for Company 2, an NPM provider that has a merchant agreement
Published in The SciTech Lawyer, Volume 9, Number 3, Winter/Spring 2013. © 2013 American Bar Association. Reproduced with permission. All rights reserved. This information or any portion
thereof may not be copied or disseminated in any form or by any means or stored in an electronic database or retrieval system without the express written consent of the American Bar Association.
with Bank Y, to turn in all shoe transaction sales slips to Bank Y as if they were
for Company 2’s transactions with cardholders. That’s laundering under card
rules that prohibit it: Bank Y thinks every
slip was for a sale of Company 2’s merchandise or services, i.e., Company 2 is
laundering the shoe store’s sales slips.
That, at least, was a common view
until 2011. Current Visa and MasterCard
Payment Service Provider (Visa) or Payment Facilitator (MasterCard) (PSP/PF)
structures allow laundering by creating
transparency. Company 2 must register with the relevant card organizations
as a PSP and/or PF and may turn into
Bank Y the shoe store slips and slips for
many other merchants (“sponsored merchants”). Bank Y will know Company 2
is doing that, and both Company 2 and
each sponsored merchant must comply
with PSP/PF rules.
The PSP/PF structure involves more
than meets the eye. The good news is
that there is now a structure allowing one
company to submit slips for another. The
bad news, at least for Company 2, is that
the rules allocate to it very serious risks
that might or might not create an acceptable business model.
Everyone involved with an NPM
should attempt to avoid violating the
laundering rules. If the vehicle for doing
so is use of a PSP/PF structure, everyone
should attempt to determine their role
and compliance obligations.
Who Has PCI Obligations and
Liabilities?
PCI (payment card industry) is widely
known as the data security standard
for debit and credit cards. That standard (PCI DSS) is actually just one of
the ever-increasing number of other PCI
standards. For example, there’s a PCI
payment application data security standard (PA-DSS), hardware standards, and
tokenization “guidance” (a tokenization
structure tries to substitute a different
number (token) for the card number
so that PCI-covered card data bypass
the merchant; if done correctly, that
eliminates the merchant’s compliance
obligation for data, thereby, falling outside PCI DSS “scope”).
In May 2012, the PCI Standards
Council issued “Accepting Mobile Payments with a Smartphone or Tablet,” the
premise of which is that mobile devices
are insecure and that point-to-point
encryption is advisable:
Mobile devices are not necessarily designed to be secure input or
storage devices for cardholder data.
Your mobile payment solution thus
requires additional technology,
including encryption, to secure
cardholder data acceptance.
In September 2012, the PCI Standards Council issued the “PCI Mobile
Payment Acceptance Security Guidelines” to provide software developers and
mobile device manufacturers guidance
on designing controls for merchants to
accept mobile payments securely.
Merchants offered an NPM should
not assume it is PCI compliant. To the
contrary, they should investigate which
PCI standards apply to what and to
whom. Some NPMs tout PCI compliance but fail to say for whom they are
complying: themselves (in which case the
merchant is still at risk): the merchant, or
someone else?
From the merchant’s perspective, the
goal is to become comfortable that the
NPM structure achieves compliance for
the merchant, or that it takes the data
the merchant is handling “out of scope”
of PCI; that the NPM provider, software and hardware, and so forth are PCI
approved; and that the contract with the
NPM appropriately memorializes and
supports all of that and the oral explanations provided by the NPM.
Are There Other Data Security
Obligations?
PCI standards are not the only data
security rules relevant to NPMs. NPMs
tend to operate against a general background of federal and state laws and card
organization and payment system rules
requiring or expecting data security generally and also regarding particular data
types (e.g., driver’s license, bank account
number, SSN, payment card number, etc.). Merchants will want to know
whether they or someone else must meet
particular data collection, transmission,
use, and security requirements, and if so,
which ones? The answer will impact the
viability of the NPM for the merchant
and NPM sustainability. For example,
does the NPM meet security guidance of
these types:
• “MasterCard Best Practices for
Mobile Point of Sale Acceptance”
(May 5, 2012) (focusing on development and deployment of Mobile
Point-of-Sale acceptance solutions,
the goal is to introduce best practices to facilitate MPOS growth by
recommending actions, practices,
and product features consistent
with other acceptance channels;
and to not supersede MasterCard
rules or applicable laws).
• “PCI Mobile Payment Acceptance Security Guidelines” v.1
(Sept. 9, 2012) (focusing on “payment applications that operate on
any consumer electronic handheld
device (e.g., mobile phone, tablet,
or PDA) that is not solely dedicated
to payment-acceptance transaction
processing and where the electronic handheld device has access
to clear-text data”).
If the NPM Involves a Credit or
Debit Card Transaction, Will the
Transaction Fall Under “Card
Present” or “Not Present” Merchant
Risk Allocation Rules, or Something
Else?
When credit cards were first introduced, many merchants were reluctant to
accept them and preferred sticking with
checks. As an inducement to broaden
acceptance, card organizations created
the “card present” (face-to-face) riskallocation rule that shields a merchant
from the risk of counterfeit cards or an
imposter’s use of a valid card, if the merchant complies with all acceptance and
authorization rules. In card-not-present
situations such as e-commerce, the rule is
the opposite, and the merchant typically
bears that risk.
So what is a “mobile transaction?”
Certain aspects of such transactions are
Published in The SciTech Lawyer, Volume 9, Number 3, Winter/Spring 2013. © 2013 American Bar Association. Reproduced with permission. All rights reserved. This information or any portion
thereof may not be copied or disseminated in any form or by any means or stored in an electronic database or retrieval system without the express written consent of the American Bar Association.
created or conducted in a non-face-toface environment (e.g., registering for an
NPM account online), and other aspects
that occur in a face-to-face environment (e.g., using the NPM at a physical
store) where the card is present but not
necessarily pulled out for review. Visa
definitions for contactless mobile payments imply that the “card present” rule
may apply at least to that type of transaction, although the authorization/
acceptance rules will change (such as to
requiring the cardholder to enter a passcode instead of signing). The question
may become moot given the move to
“EMV” cards discussed in the following
question, below, although the difficulties
inherent in that move may cause deadlines to be missed and cause the “card
present/not present” rules to linger longer than currently expected (e.g., an
EMV-ready merchant won’t be able to
comply with EMV acceptance/authentication rules if particular issuers are still
issuing magnetic stripe cards).
The point is that at least some of the
card organizations have begun to create
special rules for mobile transactions that
should be reviewed to see to whom each
NPM allocates the counterfeit/imposter risk and whether that allocation (and
therefore the NPM) is acceptable to the
merchant.
Will the NPM Be Made Irrelevant by
the Sea Change That Might Occur
via the EMV Train Heading for
Merchants?
EMV (Europay, MasterCard, and Visa)
specifications for payment cards were
first published more than a decade ago
and generally refer to “chip and pin”
technology. As explained in an EMV
whitepaper:
The distinguishing feature of EMV
is that the consumer payment
application is resident in a secure
chip that is embedded in a plastic payment card, often referred to
as a chip card or smart card, or in
a personal device such as a mobile
phone. The chip provides three
key elements: it can store information; it can perform processing;
and because it is a secure element,
it is able to store secret information securely, and perform
cryptographic processing. These
capabilities provide the means
for secure consumer payments.
(Emphasis added.)
In order to execute a payment,
the chip must connect to a chip
reader in an acceptance terminal. There are two possible means
by which this physical connection may be made, which are often
referred to as contact or contactless.
With contact, the chip must come
into physical contact with the chip
reader for the payment transaction
to occur. With contactless, the chip
must come within sufficient proximity of the reader (a maximum
of 4cm) for information to flow
between the chip and the acceptance terminal.
Payment card infrastructure in the
United States has been based for years on
equipment reading the magnetic stripe
on the back of cards, so the United States
has been slow in converting to EMV. In
2011, however, at least Visa (and likely
MasterCard, whose terms are harder to
locate) added both a “carrot” and a “stick”
to the conversion process.
The Carrot: Visa, for example, will
offer merchants the carrot of decreasing
their PCI obligations. As explained by
Visa, it will:
eliminate the requirement for eligible merchants to annually validate
their compliance with the PCI
Data Security Standard for any
year in which at least 75 percent
of the merchant’s Visa transactions originate from chip-enabled
terminals. To qualify, terminals must be enabled to support
both contact and contactless chip
acceptance, including mobile contactless payments based on Near
Field Communication (NFC)
technology. Contact chip-only or
contactless-only terminals will
not qualify for the US program.
Everyone
involved with
an NPM should
attempt to avoid
violating the
laundering
rules.
Qualifying merchants must continue to protect sensitive data in
their care by ensuring their systems
do not store [other sensitive data
and adhere to PCI DSS generally].
This ability to avoid some PCI compliance may accelerate adoption of both
EMV and mobile payments and might
steer physical, point-of-sale merchants
towards Near Field Communication technology. All of this is scheduled to happen
quickly, e.g., by April 1, 2013, Visa will
require US processors and sub-processor
service providers for banks that acquire
card “slips” to be able to support merchant
acceptance of chip transactions. Whether
it will actually happen that quickly is
debatable given the extra issues US law
poses for EMV programming designed
for less complex legal regimes.
The Stick: This article has previously
explained that under the traditional “card
present/card not present” risk allocation,
face-to-face merchants who properly
accept a card do not bear the counterfeit card and imposter risks. That is
scheduled to change in 2015. Unless a
merchant converts to EMV card acceptance, the merchant will bear that risk (at
least with respect to EMV cards).
If Technologies Will Be Mandated,
What About Patents?
”Food fight” is the easiest way to characterize the number of patents impacting
mobile payments. A patent holder has the
Published in The SciTech Lawyer, Volume 9, Number 3, Winter/Spring 2013. © 2013 American Bar Association. Reproduced with permission. All rights reserved. This information or any portion
thereof may not be copied or disseminated in any form or by any means or stored in an electronic database or retrieval system without the express written consent of the American Bar Association.
exclusive right to “use” the patented invention, so merchants “using” equipment
or apps violating a patent have a potential infringement risk. So do persons who
“make” or “have made” the device or app
containing the patented invention (e.g.,
Apple recently sued Samsung, the handset maker, as opposed to handset users).
Any infringer may be sued, so a question
for merchants and other participants is,
“What indemnification is included, or not,
in the NPM contract?”
Who Has the Authentication Hot
Potato?
As discussed previously, regarding “card
present/not present” and EMV rules, the
question of who bears the imposter risk
is a hot potato simply no one wants to
catch. The potato won’t land in thin air,
however, so a question for NPM providers and merchants is “Who has the
risk by law or contract for the particular
NPM?” This comes down to who bears
the risk of determining whether the customer using an NPM for payment really,
really is the person whom the NPM
thinks she is?
The merchant can be in the best and
worst position to attempt to determine
identity (no one can actually determine
it absent dipping into biometrics, which
would require a different article). In general, card organization rules preclude
merchants from collecting identification
data. This is ironic at a time when the FTC
views failure to have adequate authentication methods as being, potentially,
an unfair act.1 States also have conflicting laws that vary by particular data type
and collection method (e.g., SSN vs. driver’s license vs. biometric vs. “swiped” vs.
viewed but not memorialized, etc.). Visa
rules include a verification method for
mobile payment devices, which appears
to focus on the device as opposed to the
merchant. If so, it should not come as a
surprise to NPM providers that a contract
asking the merchant to accept the identification risk may well be questioned.
Does the NPM Allow Lawful
Sending of Text Messages?
An NPM typically sends text messages for transactional or promotional
purposes. Just as a consumer might
carry her paper “bakery card” in her
wallet so that she can have it “punched”
every time she buys a loaf at her favorite bakery, so she might want that loyalty
feature to be part of her electronic wallet. A hot-potato question here is who
has the obligation to comply with laws
relevant to text messages and “loyalty”
programs, and if it’s the merchant, does
the NPM contain a means for merchants
to do so?
This is a version of the first question
in this article regarding “whose transaction is it,” only this time the question
is whose loyalty program or text is it?
Federal and state laws govern “loyalty”
programs, and, even for some exempt
programs, certain disclosures must be
made. These features can also attract
marketing, privacy, behavioral advertising, “unfair acts or deceptive practices,”
and many other compliance issues.
For now, simply note that any text,
transactional or promotional, is potentially a “call” under the Telephone
Consumer Protection Act and is regulated by the Federal Communications
Commission and/or the FTC. The
TPCA is nothing to be sneezed at: it
includes statutory damages and unexpected details regarding what must be in
a consent.
Does the NPM Deal With Privacy
Issues Such That Those Allocated
to the Merchant Can Be Readily
Ascertained?
The FTC currently views data that can
be tied to an individual’s device, such as
a mobile phone, as “personal information” that is subject to privacy and data
protection laws even if the information
does not actually identify the individual.
The FTC and/or California regulators
believe that mobile app providers are
“online services” subject to laws such as
California’s Privacy Protection Act, the
federal Children’s Online Privacy Protection Act, and privacy principles based
on unfair acts and deceptive practices
rules. Merchants and other participants
should review applications involved
with the NPM in light of potential privacy issues. For example:
• What information will be collected
by the app, the phone provider, and
anyone else along the route that
data will travel?
• Will there be “tracking” or “location” data?
• What do relevant privacy policies need to say? If the merchant is
required to provide its own policy,
what information, assurances, and
“place” in the NPM enables that?
• Does the app meet privacy guidance for mobile phones issued by
industry and/or any app stores
through which the app can be
downloaded?
• If the app can be accessed via social
media credentials (e.g., Facebook),
does the app meet the privacy and
other “developer” rules of the social
network?
Is the NPM Structured So That the
ESIGN Disclosure Rule Will Have
Been Satisfied Before the Customer
Gets to the Merchant?
As noted in the first question, ESIGN
precludes providing information
electronically that was supposed to
have been provided “in writing” to a
“consumer.” Electronics may not be substituted for the paper unless a lengthy
“e-dealings” disclosure is first made and
the consumer consents to disclosure and
confirms it (in a special way) before the
other information (that was supposed to
be on paper) is provided. Some NPMs
allow customers to sign up with merchants or others for products or services
that require such “written” information,
so a question will be whether the NPM
is structured to satisfy ESIGN.
Ironically, even when ESIGN’s consumer rule does not apply, there are
other laws to consider (e.g., the Uniform Electronic Transactions Act,
UETA) and regulations are increasingly imposing technical rules for
electronic transactions creating similar issues (some of these might not be
lawful under ESIGN, but that is a story
for another day). Again, the question is
whether the NPM accomplishes compliance with whatever is out there.
The answer might be “no,” given
Published in The SciTech Lawyer, Volume 9, Number 3, Winter/Spring 2013. © 2013 American Bar Association. Reproduced with permission. All rights reserved. This information or any portion
thereof may not be copied or disseminated in any form or by any means or stored in an electronic database or retrieval system without the express written consent of the American Bar Association.
the myriad rules that vary with product, service, and merchant types, i.e., it
may be impossible or impractical for the
NPM provider to envision and program
for that entire world in advance. If so,
the question turns to whether the NPM
is configured such that the merchant or
others can comply with their particular
compliance regimes without extensive
customization. Or are both approaches
an impossible pipe dream?
Does the NPM Allow and Facilitate
Compliance by Merchants With
Obligations That Legally Are the
Merchants’?
As noted in the first question, a primary
risk of NPMs is that it is not always clear
what the NPM is, so it can be very difficult for each participant to figure out
what is going on and what each is supposed to do.
The problem is greater for merchant
participants. If and when they can determine that X law applies, they might
discover that the NPM offers no way to
achieve their compliance. To avoid condemning any NPM, I’ll illustrate the
point with a foreign law that won’t even
be implemented until 2014, i.e., the new
EU Consumer Rights Directive that EU
member states are required to adopt
and publish by December 13, 2013, and
apply as of June 13, 2014.
This new directive is, in US terminology, a consumer protection statute that
regulates the acquisition of goods, services, and digital content in face-to-face,
non-face-to-face (called distance contracts), and off-premise contracts (such
as door-to-door sales). Detailed and
extensive disclosures must be made by
the “trader” (merchant). A recital notes
that in a mobile phone transaction,
the merchant might want to link off to
a website that can better contain the
extensive information—does the NPM
accommodate that? Are “spots” for the
obvious disclosures (such as merchant
identification and taxes, etc.) included
in the NPM programming? Another
section restricts surcharges by the merchant such that it may not exceed the
“cost borne by the trader for the use of
such means.” Does the NPM allow the
merchant to ascertain what those costs,
or their equivalent, are?
NPMs desiring widespread acceptance and a long life may want or
need to design for the types of legal
obligations merchants face so that merchants can know that they have been
addressed, or that they will have the
ability to use anticipatory NPM customization options to meet their own
unique needs.
Will that be difficult and costly for
the NPM provider? Absolutely. Will that
inhibit or even prevent competition?
Absolutely. The compliance complexity
and costs are dramatic for mobile payments, and the creativity of small players
may well be lost along the regulatory
way. For players that can afford compliance, failure to deal with this issue
might be a defining factor in the acceptability of the NPM. Merchants might
not accept or might abandon NPMs that
do not invest in facilitating merchants’
understanding, and in helping them to
meet their compliance needs.
The Good News and the Bad News
The good news of the mobile payments
arena is that it is new, creative, and
evolving every day to create incredible
systems and services that can benefit
all aspects of society, including those
often overlooked, such as “unbanked”
consumers.
The bad news is that it’s not as simple
as having an innovative, user-friendly,
and logical NPM that consumers love.
To protect the very consumers who
eschew cumbersome details, consumer
protection and fraud prevention laws
permeate this arena. The mantra is that
only bank structures are actually regulated and that, as yet, mobile payments
are a land of opportunity for any developer with the great idea.
Only the opportunity part is true.
The “only banks are regulated” part
is not true. Regulators may be holding back to see what happens before
bringing enforcement actions against
The silence
centers on
who has or
should have
the “hot potato”
of regulatory
compliance.
nonbanks. However, that will not necessarily deter class action plaintiffs, and
even regulatory forbearance (if any) is
not certain or fulsome.
We’re talking money. There’s a reason
it’s regulated, including by criminal laws.
The NPMs that become widely accepted
and that will be more than a flash-inthe-pan are likely to be those that take
seriously the needs of all participants,
including merchants. If the path toward
a new payments future is to allow the
range of competitors to include large
and small players while also allowing
merchants to test a variety of NPMs,
regulators may wish to make that officially possible. This can be achieved by
issuing enabling regulations or interpretations, creating safe harbors, and
issuing “no action” letters.
A substitute for the “fingers-crossed”
world in which all participants are currently living would be welcomed and
beneficial to all, including consumers. Consumers will only benefit from
NPMs if these new payment vehicles
can be provided at a cost, including
compliance costs, affordable by all. u
Endnotes
1. See discussion in Raymond T. Nimmer
& Holly K. Towle, The Law of Electronic
Commercial Transactions at chapters 6 and 16
(2003–2012, A.S. Pratt & Sons). Privacy laws
are discussed in chapter 12.
Published in The SciTech Lawyer, Volume 9, Number 3, Winter/Spring 2013. © 2013 American Bar Association. Reproduced with permission. All rights reserved. This information or any portion
thereof may not be copied or disseminated in any form or by any means or stored in an electronic database or retrieval system without the express written consent of the American Bar Association.