forked from w3c/payment-method-basic-card
-
Notifications
You must be signed in to change notification settings - Fork 0
/
index.html
461 lines (461 loc) · 18.1 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
<!DOCTYPE html>
<html>
<head>
<title>
Payment Method: Basic Card
</title>
<meta charset='utf-8'>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' async
class='remove'></script>
<script class='remove'>
const respecConfig = {
editors: [
{
name: "Adrian Bateman",
company: "Microsoft Corporation",
w3cid: 42763,
},
{
name: "Zach Koch",
company: "Google",
w3cid: 76588,
},
{
name: "Roy McElmurry",
company: "Facebook",
w3cid: 88345,
},
{
name: "Marcos Cáceres",
company: "Mozilla",
w3cid: 39125,
},
],
github: "https://github.com/w3c/payment-method-basic-card/",
previousMaturity: "FPWD",
previousPublishDate: "2016-04-21",
specStatus: "ED",
wg: "Web Payments Working Group",
wgPatentURI: "https://www.w3.org/2004/01/pp-impl/83744/status",
wgURI: "https://www.w3.org/Payments/WG/",
testSuiteURI: "https://w3c-test.org/payment-method-basic-card",
localBiblio: {
"card-network-ids": {
"href": "https://www.w3.org/Payments/card-network-ids",
"publisher": "W3C",
"title": "Card Network Identifiers Approved for use with Payment Request API"
}
},
};
</script>
</head>
<body>
<section id='abstract'>
<p>
This specification describes data structures and formats, and a simple
processing model, to facilitate card-based payments on the Web. It is
used by other specifications to facilitate monetary transactions with a
"basic card", such as credit, debit, or prepaid card.
</p>
</section>
<section id='sotd'>
<p>
The working group maintains <a href=
"https://github.com/w3c/payment-method-basic-card/issues?utf8=%E2%9C%93&q=is%3Aopen%20is%3Aissue%20-label%3A%22Priority%3A%20Postponed%22%20">
a list of all bug reports that the group has not yet addressed</a>.
Pull requests with proposed specification text for outstanding issues
are strongly encouraged.
</p>
<div class="note" title="Sending comments on this document">
<p>
If you wish to make comments regarding this document, please raise
them as <a href=
"https://github.com/w3c/payment-method-basic-card/issues">GitHub
issues</a>. Only send comments by email if you are unable to raise
issues on GitHub (see links below). All comments are welcome.
</p>
</div>
</section>
<section class='informative'>
<h2>
Introduction
</h2>
<p>
This specification defines the "basic-card" payment method for use, for
instance, with the <a data-cite="payment-request">Payment Request
API</a>. With it, merchants can request the card details (card holder
name, card number, etc.) from the end user as an alternative to
collecting the same information through a [[!HTML]] form.
</p>
<p>
The basic card payment method provides information to merchant websites
that can be used for multiple transactions over a potentially very long
period of time, typically on the order of several years at a time. At
the time of the development of this specification, it is commonplace
for merchant sites to store this information long-term to reduce the
friction of a user entering a credit card number for every future
purchase.
</p>
<p>
The decision whether to retain credit card information for future
transactions remains a matter of local policy for web sites; however,
the introduction of a programmatic way to retrieve credit card
information from a web browser affects some key factors that typically
motivate storage of such information.
</p>
<p>
Because the web browser will retain credit card information, and make
it available – subject to user approval – whenever a merchant needs it,
the friction that merchants seek to avoid is reduced. This can also
potentially reduce some liability considerations of storing information
on a persistent basis, such as financial liability that can result from
unauthorized access to the databases used to store credit card
information.
</p>
<p>
Additionally, web sites that call the <a data-cite=
"payment-request">Payment Request API</a> for each transaction avoid
the friction that can result when users’ credit card numbers and/or
expiration dates are updated. From a user’s perspective, this avoids
the hassle of having to update a large number of merchant web sites any
time they are issued a new card.
</p>
<p>
Finally, by letting the web browser determine user authentication
information, the merchant site is relieved of the duty of ensuring that
a time-local and sufficiently strong authentication has occurred.
Additionally, payment handlers can make use of local affordances, such
as biometrics and hardware tokens, to authenticate users in a way that
is more convenient, more secure, and lower friction than web sites
currently can.
</p>
</section>
<section id="method-id">
<h2>
Payment Method Identifier
</h2>
<p>
The <dfn data-cite=
"!payment-method-id#standardized-payment-method-identifiers">standardized
payment method identifier</dfn> for this specification is
"<code><dfn>basic-card</dfn></code>".
</p>
</section>
<section>
<h2>
Model
</h2>
<p>
This section defines concepts used in this specification, and how those
concepts are represented in an API via [[!WEBIDL]].
</p>
<p>
A <dfn>card</dfn> is a physical or virtual payment instrument that has
<a>details</a>, a <a>type</a>, and belongs to a <a>network</a>.
</p>
<p>
The <dfn>details</dfn> of a <a>card</a> are the <dfn data-cite=
"!ISO7812-1">primary account number</dfn> (PAN), <dfn>card holder's
name</dfn>, <dfn>security code</dfn> (sometimes known as the CVV, CVC,
CVN, CVE or CID), <dfn>expiry month</dfn>, <dfn>expiry year</dfn>, and
optionally a <dfn>billing address</dfn>. These are represented as the
members of the <a>BasicCardResponse</a> dictionary.
</p>
<p>
A <a>card</a> can be of <dfn data-lt="types">type</dfn> "credit",
"debit", or "prepaid", as derived from the issuer identification number
(the first eight digits of the <a>primary account number</a>). The
different types are represented as the <a>BasicCardType</a> enum.
</p>
<aside class="note" title="Determining the card type">
<p>
Commercial databases and web services are available to look up issuer
identification numbers, which in turn return the <a>type</a> of card.
</p>
</aside>
<p>
A <a>card</a> is identified as belonging to a <dfn data-lt=
"networks">network</dfn> via its issuer identification number
[[!ISO7812-1]] (e.g., those belonging to "visa" start with a "4"). In
an API, each network is represented by a string matching one of the
<a href="https://www.w3.org/Payments/card-network-ids">card network
identifiers</a> [[!card-network-ids]].
</p>
<aside class="note" title="Common issuer identification numbers (IIN)">
<p>
Issuer identification numbers (IIN) are maintained by ISO but are not
available to the general public. However, Wikipedia maintains a list
of the common <a href=
"https://en.wikipedia.org/wiki/Payment_card_number#Issuer_identification_number_.28IIN.29">
credit card issuer identification numbers</a>.
</p>
</aside>
<p>
A payment handler's <dfn data-lt="known">known networks</dfn> are
<a>networks</a> it supports. A payment handler MAY support zero or more
networks from the [[!card-network-ids]] list.
</p>
</section>
<section data-dfn-for="BasicCardRequest" data-link-for="BasicCardRequest">
<h2>
<dfn>BasicCardRequest</dfn> dictionary
</h2>
<pre class="idl">
dictionary BasicCardRequest {
sequence<DOMString> supportedNetworks;
sequence<BasicCardType> supportedTypes;
};
</pre>
<p>
The <a>BasicCardRequest</a> dictionary contains the following members:
</p>
<dl>
<dt>
<dfn>supportedNetworks</dfn>
</dt>
<dd>
A sequence of identifiers for card networks that the merchant
accepts. W3C maintains a <a data-cite="card-network-ids">list of
approved card network identifiers</a>.
</dd>
<dt>
<dfn>supportedTypes</dfn>
</dt>
<dd>
A sequence of card <a>types</a> that the merchant accepts.
</dd>
</dl>
</section>
<section data-link-for="BasicCardRequest">
<h2>
Interfacing with a payment handler
</h2>
<p>
The <dfn>steps to check instrument support</dfn> with
<a>BasicCardRequest</a> <var>data</var> are given by the following
algorithm.
</p>
<ol class="algorithm">
<li>If the <a>card</a>'s <a>network</a> is not one of the
<a>networks</a> in <var>requestedNetworks</var> and
<var>requestedNetworks</var> is not empty, return <code>false</code>.
</li>
<li>Otherwise, if the <a>card</a>'s <a>type</a> is not one of the
<a>types</a> in <var>requestedTypes</var> and <var>requestedTypes</var>
is not empty, return <code>false</code>.
</li>
<li>Otherwise, return <code>true</code>.
</li>
</ol>
<p>
The <dfn>steps to respond to a payment request</dfn> are given by the
following algorithm. If the end user inputs or selects a <a>card</a>
that meets the constraints of <a>BasicCardRequest</a> <var>data</var>,
the algorithm returns a card as a <a>BasicCardResponse</a>.
</p>
<ol class="algorithm" data-link-for="BasicCardResponse">
<li data-link-for="BasicCardRequest">Let <var>requestedNetworks</var>
be <var>data</var>["<a>supportedNetworks</a>"].
</li>
<li data-link-for="BasicCardRequest">Let <var>requestedTypes</var> be
<var>data</var>["<a>supportedTypes</a>"].
</li>
<li>Let <var>card</var> be a <a>BasicCardResponse</a>.
</li>
<li>Set <var>card</var>["<a>cardNumber</a>"] to a string of digits of
length between 10 to 19 items representing the <a>primary account
number</a>. The <a>primary account number</a> SHOULD be one of the <a>
types</a> from <var>requestedTypes</var>, or any <a>type</a> if
<var>requestedTypes</var> is empty.
</li>
<li>Check that <var>card</var>["<a>cardNumber</a>"] is from one of the
<a>networks</a> in <var>requestedNetworks</var>, or any <a>network</a>
if <var>requestedNetworks</var> is empty. Optionally, validate
<var>card</var>'s <a>details</a> to make sure they adhere to any
<a>type</a> and/or <a>network</a> requirements.
<div class="note" title="Validation of inputs">
<p>
The validation a user agent performs on the card's <a>details</a>
is a quality of implementation detail and outside the scope of
this specification. There is nevertheless an expectation that
user agents will make a best effort to check that a card number
is valid as per the Luhn algorithm [[!ISO7812-1]], check the
length is correct for the expected <a>type</a>, check that the
issuer identification number is correct for the selected
<a>network</a>, check that the expiry date on the card hasn't
lapsed, and so on.
</p>
</div>
</li>
<li>Set <var>card</var>["<a>cardholderName</a>"] to the <a>card
holder's name</a>, or the empty string if the user chooses not to
provide it.
</li>
<li>Set <var>card</var>["<a>cardSecurityCode</a>"] to a three or more
digit string, or the empty string if the user chooses not to provide
it.
</li>
<li>Set <var>card</var>["<a>expiryMonth</a>"] to two-digit string
ranging from "<code>01</code>" to "<code>12</code>", or the empty
string if the user chooses not to provide it or the <a>type</a> doesn't
require an expiry month.
</li>
<li>Set <var>card</var>["<a>expiryYear</a>"] to a four-digit string in
the range "<code>0000</code>" to "<code>9999</code>", or the empty
string if the user chooses not to provide it or the <a>type</a> doesn't
require an expiry year.
</li>
<li>Optionally, set <var>card</var>["<a>billingAddress</a>"] to the
result running the steps to <a data-cite=
"payment-request#dfn-create-a-payment-address">create a payment
address</a>. Alternatively, if a billing address is not required for
this card <a>type</a>, then set
<var>card</var>["<a>billingAddress</a>"] to null.
</li>
<li>Return <var>card</var>.
</li>
</ol>
</section>
<section data-dfn-for="BasicCardType" data-link-for="BasicCardType">
<h2>
<dfn>BasicCardType</dfn> enum
</h2>
<pre class="idl">
enum BasicCardType { "credit", "debit", "prepaid" };
</pre>
<dl>
<dt>
"<dfn>credit</dfn>"
</dt>
<dd>
A credit card.
</dd>
<dt>
"<dfn>debit</dfn>"
</dt>
<dd>
A debit card.
</dd>
<dt>
"<dfn>prepaid</dfn>"
</dt>
<dd>
A prepaid card.
</dd>
</dl>
</section>
<section data-dfn-for="BasicCardResponse" data-link-for=
"BasicCardResponse">
<h2>
<dfn>BasicCardResponse</dfn> dictionary
</h2>
<pre class="idl">
dictionary BasicCardResponse {
required DOMString cardNumber;
DOMString cardholderName;
DOMString cardSecurityCode;
DOMString expiryMonth;
DOMString expiryYear;
PaymentAddress? billingAddress;
};
</pre>
<dl>
<dt>
<dfn>cardholderName</dfn> member
</dt>
<dd>
The <a>card holder's name</a> as it appears on the <a>card</a>.
</dd>
<dt>
<dfn>cardNumber</dfn> member
</dt>
<dd>
The <a>primary account number</a> for the <a>card</a> as a string of
digits that ranges from 10 to 19 digits.
</dd>
<dt>
<dfn>expiryMonth</dfn> member
</dt>
<dd>
A two-digit string for the <a>expiry month</a> of the card in the
range "<code>01</code>" to "<code>12</code>".
</dd>
<dt>
<dfn>expiryYear</dfn> member
</dt>
<dd>
A four-digit string for the <a>expiry year</a> of the card in the
range "<code>0000</code>" to "<code>9999</code>".
</dd>
<dt>
<dfn>cardSecurityCode</dfn> member
</dt>
<dd>
A three or more digit string for the <a>security code</a> of the
<a>card</a>.
</dd>
<dt>
<dfn>billingAddress</dfn> member
</dt>
<dd>
A <code><dfn data-cite=
"!payment-request#dom-paymentaddress">PaymentAddress</dfn></code>
that represents the <a>billing address</a> associated with the
<a>card</a>, or null.
</dd>
</dl>
</section>
<section id="conformance">
<p>
There is only one class of product that can claim conformance to this
specification: a <dfn>payment handler</dfn>.
</p>
<p>
A conforming <a>payment handler</a> MUST:
</p>
<ul>
<li data-tests=
"payment-method-basic-card/payment-request-canmakepayment-method.https.html">
when queried, claim to support the "<a>basic-card</a>" <a>standardized
payment method identifier</a>.
</li>
<li data-tests=
"payment-method-basic-card/basiccardresponse-member-formats-manual.https.html">
return <a>BasicCardResponse</a>s whose members are formatted as per
their definition in this specification.
</li>
</ul>
</section>
<section id="security">
<h2>
Security and Privacy Considerations
</h2>
<p>
Due to differences in quality of implementation" and the end user's
ability to input data into unconstrained input fields, merchants are
expected to revalidate all <a>BasicCardResponse</a> returned by APIs
that make use of this specification.
</p>
<p>
In particular, merchants need to treat the values of any <a>details</a>
with the same scrutiny that they would apply to a [[HTML]]
<code>input</code> element, by, for example, sanitizing all the members
of a <a>BasicCardResponse</a> before rendering them anywhere.
</p>
<p>
Owners of web sites SHOULD NOT store the payer's card information
except where warranted, such as storage for future and recurring
payments. When card information is stored, web site owners SHOULD take
measures to prevent its disclosure.
</p>
<p class="note" title=
"Payment Card Industry Data Security Standard Compliance">
Depending on jurisdiction, users of this specification (implementers,
merchants, payment processors, etc.) can be subject to <abbr class=
"Payment Card Industry Data Security Standard">PCI DSS</abbr> or other
regulations. Discussion of those considerations are outside the scope
of this document.
</p>
</section>
</body>
</html>