This repository has been archived by the owner on Jan 25, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 29
/
index.html
2421 lines (2234 loc) · 82.5 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
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<title>Web Payments Use Cases</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<script src='../respec-w3c-common.js' class='remove'></script>
<script src='../respec-webpayments.js' class='remove'></script>
<script class='remove'>
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "ED",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "web-payments-use-cases",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
// previousPublishDate: "1977-03-15",
// previousMaturity: "CG-DRAFT",
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// if you want to have extra CSS, append them to this list
// it is recommended that the respec.css stylesheet be kept
//extraCSS: [],
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "Manu Sporny", url: "https://manu.sporny.org/",
company: "Digital Bazaar, Inc.", companyURL: "http://digitalbazaar.com/" },
{ name: "Ian Jacobs", url: "http://www.w3.org/People/Jacobs/",
company: "W3C", companyURL: "http://www.w3.org/" },
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
authors: [
{ name: "Ian Jacobs", url: "http://www.w3.org/People/Jacobs/",
company: "W3C", companyURL: "http://www.w3.org/" },
{ name: "Manu Sporny", url: "https://manu.sporny.org/",
company: "Digital Bazaar", companyURL: "http://digitalbazaar.com/" },
{ name: "Qian Sun", url: "",
company: "Alibaba", companyURL: "http://www.alibabagroup.com/" },
{ name: "David Ezell", url: "http://example.org/",
company: "NACS", companyURL: "http://www.nacsonline.com/" },
{ name: "Laurent Castillo", url: "http://example.org/",
company: "Gemalto", companyURL: "http://www.gemalto.com/" },
],
// maximum level of table of contents
maxTocLevel: 3,
// name of the WG
wg: "Web Payments Interest Group",
// URI of the public WG page
wgURI: "http://www.w3.org/blog/wpig/",
// name (with the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-webpayments-comments@w3.org",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
wgPatentURI: "http://www.w3.org/2004/01/pp-impl/73816/status",
//preProcess: [ webpayments.preProcess ]
/*,
alternateFormats: [ {uri: "diff-20111214.html", label: "diff to previous version"} ],
*/
};
//respecEvents.sub('start-all', webpayments.preProcess.apply);
</script>
<style type="text/css">
dl {
margin-top: 20px;
margin-bottom: 20px;
}
dt,
dd {
line-height: 1.42857143;
}
dl > dt:first-of-type {
font-weight: bold;
}
@media (min-width: 768px), print {
.dl-horizontal {
margin-bottom: 4em;
}
.dl-horizontal dt {
font-weight: normal;
float: left;
width: 160px;
clear: left;
overflow: hidden;
text-align: right;
text-overflow: ellipsis;
white-space: nowrap;
}
.dl-horizontal dd {
margin-left: 180px;
}
.dl-horizontal dd > ul {
padding-left: 20px;
margin: 0px;
}
}
</style>
</head>
<body>
<section id='abstract'>
<p>
This document is a prioritized list of Web payments use cases.
Guided by these use cases, the W3C Web Payments Interest Group
plans to derive architecture and associated technology
requirements to integrate payments into the Open Web
Platform. That work will form the basis of conversations with W3C
groups and the broader payments industry about what standards
(from W3C or other organizations) will be necessary to fulfill the
use cases and make payments over the Web easier and more secure.
</p>
</section>
<section id='sotd'>
<p>
This document is a work in progress and is being released early and often
using an agile process; it is incomplete.
</p>
<p>
The Web Payments IG has only had the opportunity to review a handful of the
40+ use cases, 120+ requirements, hundreds of pages of
payments research submitted to the group via various other standards group
output such as ISO20022, research documents from X9 and the US Federal Reserve,
documents from the Web Payments Community Group, and input from the
general public. Our desire is to align with the larger payments industry
when it's possible to do so. Expect this document to be rapidly iterated upon
with that desire in mind.
</p>
</section>
<section>
<h2>Introduction</h2>
<p>
ECommerce is thriving and continues to expand. However,
fragmentation of payment systems is limiting the growth potential
as are problems — both real and perceived — such as
fraud and usability.
</p>
<p>
Because the Web is ubiquitous, strengthening support for Web
payments has the potential to create new opportunities for
businesses and customers. Mobile devices are already transforming
the industry by supplanting physical payment cards in proximity
payments, voucher distribution, and identification when people
authenticate to a scanner, point of sale, or access gate. Although
we are seeing innovation in mobile payment systems, the lack of
standards makes it more difficult to adapt to new payment
approaches or integrate new payment providers.
</p>
<p>
The W3C Web Payments Interest Group is developing a roadmap for standards to
improve the interoperability of payments on the Web. This will help achieve
greater interoperability among merchants and their customers,
payment providers, software vendors, mobile operators, and payment networks.
The roadmap will include <a title="payment scheme">payment schemes</a> in use
today (such as electronic cheques, credit cards, direct debit, and
cryptocurrencies) and those of the future. The roadmap will be derived from
the use cases listed below.
</p>
<section>
<h3>Why This Work is Important</h3>
<p>
The Web Payments work is not just about making payments easier, faster,
more secure, and more innovative. There are many people around the world that
today's financial system does not reach. These people are called the world's
unbanked (or underbanked). The unbanked often live pay cheque to pay cheque, do
not have access to savings accounts or low-fee cheque cashing services, lines
of credit, or a way of saving for their future. Being unable to plan for one's
financial future often results in a focus on the short-term, which creates a
vicious cycle of not being able to escape one's situation. Not being able to
participate in the financial system creates unintended inequities that create
waste and result in a net loss for society.
</p>
<p>
However, some of the shortcomings of today's financial system could be
addressed via technological improvements. For example, there is a considerable
overlap between the unbanked and underbanked population and access to advanced
mobile phones and the Web. By providing financial services to people with
mobile phones in a standardized way via the Web, we could see an improvement
in the financial health of these individuals and their families.
</p>
<p>
Extending the current financial system to reach further helps an ever
increasing number of people plan for their future, focus on the long-term, and
thus contributes to a greater net gain for society.
</p>
</section>
<section>
<h3>How this Document is Organized</h3>
<p>
This document is organized as follows:
</p>
<ul>
<li>
Section 2 defines basic payment terms.
</li>
<li>
Section 3 describes a common payment flow at a high
level. The group expects to work on additional
payment flows in future work.
</li>
<li>
Section 4 is a specific narrative, labeled according
to the steps of section 3. Section 7 describes
additional familiar narratives to give a more complete picture
of how the payment phases apply.
</li>
<li>
Section 6 lists the use cases - short scenarios that cover
diverse aspects of each payment step.
</li>
</ul>
<p>
Each use case has:
</p>
<ul>
<li>
A title and short description.
</li>
<li>
Goals. How the use case advances one or more of the
<a href="https://www.w3.org/Payments/IG/wiki/ExecSummary#Goals">goals
for an interoperable Web payments framework</a>.
</li>
<li>
Motivation. This is commentary to help explain why the use
case has been included, including how it relates to similar use cases.
</li>
</ul>
<p>
Each use case may also have notes on:
</p>
<ul>
<li>
Security/Privacy. Security or privacy issues that may arise through this use
case.
</li>
<li>
Exceptions. Considerations in the case of specific exceptions (e.g., if a
user pays with a voucher and the <a>transaction</a> fails, the user's voucher
should be restored).
</li>
<li>
Accessibility. Accessibility considerations (e.g., in multi-factor
authentication, management of biometrics in the case of users with some
disabilities).
</li>
</ul>
<p class="issue">
The group seeks input from security, privacy, and accessibility experts.
Examples of desired groups to perform these reviews are, but are not
limited to: W3C Privacy Interest Group,
W3C Security Interest Group, W3C Web Accessibility Initiative and
Protocols and Formats Working Group, US Federal Reserve Security Panels,
X9 Security subgroups, and ISO security subgroups.
</p>
<p>
The Interest Group (currently) regards some of the use cases as "essential" to
addressing their
<a href="https://www.w3.org/Payments/IG/wiki/ExecSummary#Goals">goals</a> and
others as "non-essential."
</p>
<p class="note">
All character names appearing in this document are fictitious. Any resemblance
to real persons, living or dead, is purely coincidental. Some organizations,
products, and services appearing in this document are real and are included
purely for pedagogic purposes and don't imply endorsement or approval of the
Web Payments work in any way, shape, or form. For all other organizations,
products, or services appearing in this document, any resemblance to real
entities is purely coincidental.
</p>
</section>
</section>
<section>
<h2>Terminology</h2>
<p>
This document attempts to communicate the concepts outlined in the Web
Payments space by using specific terms to discuss particular concepts. This
terminology is included below and linked to throughout the document to aid
the reader:
</p>
<dl>
<dt><dfn>entity</dfn></dt>
<dd>
A person, organization, or software agent that is capable of interacting with
the world.
</dd>
<dt><dfn>payee</dfn></dt>
<dd>
An <a>entity</a> that receives funds as required by a
<a>transaction</a>.
</dd>
<dt><dfn>payer</dfn></dt>
<dd>
An <a>entity</a> that provides a source of funds as required by a
<a>transaction</a>.
</dd>
<dt><dfn>payment instrument</dfn></dt>
<dd>
A mechanism used to transfer value from a <a>payer</a> to a
<a>payee</a>. Examples: Corporate Visa card, personal Visa card, a bitcoin
account, a PayPal account, an Alipay account, etc.
</dd>
<dt><dfn>payment processor</dfn></dt>
<dd>
An <a>entity</a> that submits and processes payments using a particular
<a>payment instrument</a> to a payment network. Examples: Stripe, PayPal,
Authorize.net, Atos, FedACH.
</dd>
<dt><dfn>payment scheme</dfn></dt>
<dd>
Sets of rules and technical standards for the execution of payment
<a title="transaction">transactions</a> that have to be followed by adhering
entities (<a title="payment processor">payment processors</a>,
<a title="payer">payers</a> and <a title="payee">payees</a>). Examples: Visa,
MasterCard, Bitcoin, Ripple, PayPal, Google Pay, Alipay, Yandex money, ACH, SEPA.
</dd>
<dt><dfn>purchase</dfn></dt>
<dd>
Activities surrounding and including a <a>transaction</a> (e.g., discovery of
an offer, negotiation of terms, selection of <a>payment instrument</a>,
delivery, etc.).
</dd>
<dt><dfn>transaction</dfn></dt>
<dd>
An exchange of value (e.g., buying or selling something)
</dd>
</dl>
<p class="note">
There are a number of financial industry standards (such as
ISO20022, ISO12812, various X9 standards, PCI DSS, and others) that
define payment terms. The Web Payments Interest Group has as a goal to
make use of industry-defined terms in its deliverables. At the same time,
the group has as a goal that these use cases may be understood by both
payment industry professionals and the broader Web community. Thus, our
definitions are simplified and few in number here, but the group is
also developing a
<a href="https://www.w3.org/Payments/IG/wiki/GlossaryReference">more complete glossary</a>
with detailed definitions and mappings to industry-defined terms.
</p>
</section>
<section>
<h2>An Overview of the Payment Phases</h2>
<p>There are many types of <a>transaction</a>s in the world of payments,
including person-to-business, business-to-business, business-to-person,
government-to-person, person-to-government, and
person-to-person. In this document we focus on the
interactions between a <a>payer</a> and a <a>payee</a>,
either of which could be a person, business, government, or software
agent), which we organize into four phases:</p>
<p class="issue">
The group would like feedback related to the general structure of the payment
phases from individuals that worked on ISO20022, ISO12812, the
European Payment Commission, and
various X9 documents to ensure that the phases reflect business processes
outlined in financial standardization initiatives. Feedback from the general
public is also requested to see if non-payment professionals can navigate and
understand the document without prior payment industry knowledge.
</p>
<ol>
<li>
Negotiation of Payment Terms
</li>
<li>
Negotiation of Payment Instruments
</li>
<li>
Payment Processing
</li>
<li>
Delivery of Product/Receipt and Reversals
</li>
</ol>
<p>The descriptions below only discuss the interactions between the
payer and the <a>payee</a>. We do not expose the low-level exchanges between
banks, card associations, or other back-end "payment clearing" parties
in a <a>transaction</a>. Those details will be discussed in the Interest
Group's work on architecture and
requirements.</p>
<p>Each phase below consists of a series of steps.
The details of each step vary by <a>payment scheme</a>. Some steps may
not be relevant at certain times (e.g., depending on
<a>payment scheme</a> or <a>transaction</a> specifics).
For example, some <a title="purchase">purchases</a> do not involve a proof of
funds or proof of hold. ACH and SEPA
<a title="payment scheme">payment schemes</a> generally do not support the
verification of available funds, thus in these
<a title="payment scheme">payment schemes</a> the particular proof of funds
step is skipped.
In some cases, steps may happen in a slightly different order than described below.
</p>
<p>
It is also important to note that these phases and steps may be interrupted
at various times (e.g., one party drops out, or exceptions occur like
insufficient funds or a regulatory block). While these phases are an
approximation of the general flow of all payments, they are helpful in
structuring the use cases such that it is easy to figure out to which part of
the payment process a particular use case belongs.
</p>
<p>While these four phases may apply more or less well to a variety
of other payment scenarios such as person-to-person
payments, those topics are not the current focus of the group. We
plan to address them directly in <a href="#future-work">future
work</a>.</p>
<section>
<h3>Negotiation of Payment Terms</h3>
<p>
In the first phase of the payment process, the <a>payer</a> and the
<a>payee</a> negotiate the terms of the payment.
</p>
<ul>
<li>
<strong>Discovery of Offer</strong>. The <a>payer</a> discovers the
<a title="payee">payee's</a> offer (e.g., by browsing a Web page or
from a native application).
</li>
<li>
<strong>Agreement on Terms</strong>. The <a>payer</a> and the
<a>payee</a> agree to what will be purchased, for how much,
in what currency, which <a title="payment scheme">payment schemes</a>
or loyalty programs are acceptable, etc. The <a>payee</a> may require the
<a>payer</a> to authenticate themselves. The <a>payee</a> may generate an
invoice for the <a>payer</a>.
</li>
<li>
<strong>Application of Marketing Elements</strong>. The <a>payer</a>
discovers and applies any loyalty programs, coupons, and other special offers
to the payment terms.
</li>
</ul>
</section>
<section>
<h3>Negotiation of Payment Instruments</h3>
<p>
In the second phase of the payment process, <a>payer</a> and <a>payee</a> determine which <a title="payment instrument">payment instruments</a> the
<a>payer</a> will use to transfer funds to the <a>payee</a>.
</p>
<ul>
<li>
<strong>Discovery of Accepted Schemes</strong>. The <a>payer</a>
discovers the <a title="payment instrument">payment instruments</a> that
are accepted by the <a>payee</a>.
</li>
<li>
<strong>Selection of Payment Instruments</strong>. The <a>payee</a>
selects one or more <a title="payment instrument">payment instruments</a>
that are available to the <a>payer</a> and are accepted by the
<a>payee</a>.
</li>
<li>
<strong>Authentication to Access Instruments</strong>. The
<a title="payer">payer's</a> access to the <a>payment instrument</a>
is authenticated. The <a>payer</a> consents to pay. Note: This authentication
with the <a>payment processor</a> is distinct from any authentication required
by the <a>payee</a> (such as when a merchant requires a customer to
have an account and log in to the merchant's Web site).
</li>
</ul>
</section>
<section>
<h3>Payment Processing</h3>
<p>
The third phase of the payment process is used to initiate the transfer of
funds. Depending on the <a>payment instrument</a>, the transfer of funds
may be verified immediately or only after several days.
</p>
<ul>
<li>
<strong>Initiation of Processing</strong>. Depending on the
<a>payment instrument</a>, the <a>payer</a> (e.g., when using
PayPal or Yandex Money), the <a>payee</a> (e.g., when using a credit card), or other
party (e.g., bank) initiates processing.
</li>
<li>
<strong>Verification of Available Funds</strong>. The <a>payee</a> may
need to provide a proof of funds or a proof of hold to the <a>payer</a>
before finalizing payment and delivery of the product.
</li>
<li>
<strong>Authorization of Transfer</strong>. The <a>payee</a> receives
proof that the transfer of funds has been authorized.
</li>
<li>
<strong>Completion of Transfer</strong>. The <a>payment scheme</a>
determines the details of payment clearing and settlement. Transfer times
may vary from near-realtime to multiple days. The <a>payee</a>,
the <a>payer</a>, and/or third parties (such as regulatory bodies) may be
notified as each stage of the clearing and settlement process is completed.
</li>
</ul>
</section>
<section>
<h3>Delivery of Product/Receipt and Reversals</h3>
<p>
In the fourth phase of the payment process, the <a>transaction</a> is completed by providing the <a>payer</a> with a receipt and/or the
product that was purchased.
</p>
<ul>
<li>
<strong>Delivery of Product</strong>. The <a>payer</a> receives goods or
services immediately, at a later date, automatically on a recurring basis,
etc. depending on the terms of the <a>purchase</a>. A digital proof of
payment may be required to access the product.
</li>
<li>
<strong>Delivery of Receipt</strong>. Depending on the
<a title="payment scheme">payment scheme(s)</a> chosen, there are
various ways and times that a receipt may be delivered (e.g., credit card
receipt, digital proof of <a>purchase</a>, encrypted line-item receipt, etc.).
</li>
<li>
<strong>Reversals</strong>. At time exceptions may occur (e.g., defective
product, application of store return policy, etc.). In this case, the <a>payee</a> initiates payment to the <a>payer</a>. The payment reversal may take different forms, including a refund to the <a>payer's</a> payment instrument, a refund using a different payment scheme, or store credit.
</li>
</ul>
</section>
</section>
<section>
<h2 id="phases-overview">A Simple Example of the Payment Phases</h2>
<p>
The following scenario is provided to aid the reader in understanding how the
phases of the payment process apply to a real world situation. In this scenario,
we follow Jill, who seeks a new outfit for a party. She selects items from
PayToParty, which is a brick-and-mortar store with an online presence.
She chooses how to pay and the items are delivered to her home on the
following day.
</p>
<p>
See the appendix for <a href="#additional-examples">additional examples of
the payment phases</a>.
</p>
<p class="issue">
General feedback is requested as to whether or not this section is helpful in
grounding the payment phases and steps in a real world use case is helpful this
early in the document. An alternative would be removing this section
entirely if the preceding section suffices, or moving this narrative to section 7 with other examples.
</p>
<section>
<h3>Negotiation of Purchase Terms</h3>
<ul>
<li>
<strong>Discovery of Offer</strong>: Jill begins her <a>purchase</a> at
home on her laptop, where she browses the items on the PayToParty Web
site. On the way to work the next morning, she explores the catalog
further from a native app on her smart phone. Jill can't decide
whether the dress displayed online is blue with black stripes or white
with gold stripes, so during her lunch break, she drops into the
PayToParty store near her office. She spots a few more items that
she thinks she'd like to <a>purchase</a>, but decides to wait until later to
make the <a>purchase</a>.
</li>
<li>
<strong>Agreement on Terms</strong>: That same evening at home,
Jill logs into her account on the PayToParty Web site, adding her
preferred items to her shopping cart. The total price appears on the
page.
</li>
<li>
<strong>Application of Marketing Elements</strong>: As Jill prepares to
check out, PayToParty offers her a discount of 10% if she uses the store's
loyalty card to pay.
</li>
<ul>
</section>
<section>
<h3>Negotiation of Payment Instruments</h3>
<ul>
<li>
<strong>Discovery of Accepted Schemes</strong>: Given where Jill lives,
PayToParty offers her payment by credit card, debit card, the PayToParty
loyalty card, and PayPal, but not Jill's favorite cryptocurrency (which she
uses on other sites).
</li>
<li>
<strong>Selection of Payment Instruments</strong>: Jill pushes the "Pay Now to Party!" button and is presented with a number of options to pay, including her
credit card, her PayToParty loyalty card (which is highlighted to remind her
of the discount), and a PayPal account. There is also a gift card from
PayToParty that she received for her birthday, but she chooses not to
use it for this <a>purchase</a>.
</li>
<li>
<strong>Authentication to Access Instruments</strong>: Jill selects
the PayToParty loyalty card, which she enabled with theft-protection,
and is asked to input a code that is sent to her phone before the
<a>purchase</a> can be completed.
</li>
<ul>
</section>
<section>
<h3>Payment Processing</h3>
<ul>
<li>
<strong>Initiation of Processing</strong>. PayToParty receives a
message from Jill's device authorizing the payment. PayToParty
submits the message to their <a>payment processor</a>, requesting a
proof of hold for the funds.
</li>
<li>
<strong>Verification of Available Funds</strong>. PayToParty
receives a proof of hold on Jill's funds for the <a>purchase</a> price of
the goods. The PayToParty night-shift employees begin packing her purchased
items for delivery the next day.
</li>
<li>
<strong>Authorization of Transfer</strong>. Once Jill's package is ready to
go, PayToParty exchanges the proof of hold for a proof of payment by
re-submitting the request to the payment network. They receive a proof of
payment from the <a>payment processor</a>.
</li>
<li>
<strong>Completion of Transfer</strong>. Since Jill's PayToParty loyalty card
operates as a credit card, PayToParty will receive the funds in their normal
end of week settlement.
</li>
<ul>
</section>
<section>
<h3>Delivery of Product/Receipt and Reversals</h3>
<ul>
<li>
<strong>Delivery of Receipt</strong>. Jill's cloud-based wallet
receives a detailed line-item digital receipt for the <a>purchase</a>.
</li>
<li>
<strong>Delivery of Product</strong>. Jill's package goes out by courier the
next morning and is on her doorstep before she leaves for work.
</li>
<ul>
</section>
</section>
<section>
<h2>Assumptions</h2>
<p>
The use cases below rely on a number of assumptions that are not
detailed in the use cases but that will be explored in more detail in
the architecture and requirements documents.
</p>
<ul>
<li>
<strong>Connectivity</strong>. Connectivity requirements vary according to
use case. The types of connections a device may utilize include Internet
connectivity, proxied connections through short-range radio transmissions,
and proximity connections over a technology such as Near-Field Communication
(NFC) or Bluetooth Low Energy (BTLE). Some use cases assume no
connectivity (e.g., user is temporarily unable to connect to a mobile phone
network or a WiFi hotspot).
</li>
<li>
<strong>Registered Payment Instruments</strong>. In order for the
<a>payer</a> to select and utilize
<a title="payment instrument">payment instruments</a>, they must be
registered in some way and discoverable by a browser, native application,
or other software.
</li>
<li>
<strong>Security</strong>. Keys, encryption, and other security technology
must be used to secure sensitive information. It is important that sensitive
information is not transmitted to parties that do not absolutely need to
know the information in order to complete the <a>transaction</a>.</li>
<li>
<strong>Identity</strong>. There will be a consistent, interoperable
identifier used to identify the participants and accounts in a Web Payments
transaction.
</li>
</ul>
</section>
<section>
<h2 id="use-cases">Use Cases</h2>
<p>
This section examines the phases of payment, and the steps involved in each
phase, through a variety of use cases. The purpose of this section is to
elaborate on the variety of scenarios present in each step of the payment
process.
</p>
<p class="issue">
General feedback is requested related to the general structure of the
use case snippets below. Are they focused enough to convey each topic listed?
Is there information that should be added to each use case in general? Would
more elaborate use cases be helpful? Would an attempt to minimize each existing
use further be helpful in scanning the document more quickly?
</p>
<section>
<h3>Negotiation of Payment Terms</h3>
<p>
</p>
<section>
<h4>Discovery of Offer</h4>
<dl class="dl-horizontal">
<dt>Website</dt>
<dd>
Penny uses the HobbyCo website to select a $15 model train for <a>purchase</a>.
</dd>
<dt>Goals</dt>
<dd>
rapid, widespread adoption.
</dd>
<dt>Motivation</dt>
<dd>
This is the most common type of offer on the Web circa 2015 and is included
for the sake of completeness.
</dd>
</dl>
<dl class="dl-horizontal">
<dt>Point of Sale Kiosk</dt>
<dd>
Cory shops for groceries at his local ChowMart, scans all of the items he
wants to <a>purchase</a> at the automated kiosk, and is presented with a
total amount.
</dd>
<dt>Goals</dt>
<dd>
Improved user experience, and rapid, widespread adoption.
</dd>
<dt>Motivation</dt>
<dd>
Unifying POS interaction w/ the Web Payments architecture is vital for the
success of this work.
</dd>
<dt>Privacy</dt>
<dd>Cory should exercise control over how much he wants the merchant
to be able to track his activities. Programs like loyalty cards will likely involve agreement to more data with the merchant.
</dd>
</dl>
<dl class="dl-horizontal">
<dt>Mobile</dt>
<dd>
Daniel takes a taxi from the airport to his hotel. The taxi driver
displays the total with his mobile device and offers a tap-to-pay option.
</dd>
<dt>Goals</dt>
<dd>
Improved user experience, Greater security, Innovation, Automatability, and
rapid, widespread adoption.
</dd>
<dt>Motivation</dt>
<dd>
Unifying the way tap-to-pay offers work with the Web Payments architecture
would help ensure ubiquity.
</dd>
<dt>Exceptions</dt>
<dd>
No mobile phone connectivity (visiting a different country, trip occurs
outside the range of a mobile network, etc.)
</dd>
</dl>
<dl class="dl-horizontal">
<dt>Freemium</dt>
<dd>
Ricki plays his favorite native app game and wants to upgrade his avatar
with a few extra "power-ups." Clicking on a power-up displays the price.
</dd>
<dt>Goals</dt>
<dd>
Improved user experience, Innovation, and Transparency.
</dd>
<dt>Motivation</dt>
<dd>
Many of the very successful games these days run on the freemium model,
but are tied to specific app stores. Providing an app-store agnostic
mechanism to pay for items in freemium games would give players and
developers more choices.
</dd>
</dl>
<section>
<h5>Non-Essential Use Cases</h5>
<dl class="dl-horizontal">
<dt>E-mail</dt>
<dd>
A GroupBuyCo customer receives an offer by email to <a>purchase</a> the deal
of the day.
</dd>
<dt>Goals</dt>
<dd>
Improved user experience, and Automatability.
</dd>
<dt>Motivation</dt>
<dd>
Unifying how people initiate payments from
email, at a Point of Sale, and via a Web site will help ensure the ubiquity of the Web payment technology platform.
</dd>
<dt>Privacy / Security</dt>
<dd>
It is important to recognize that initiating a payment from within an
email application could lead to a wholly new category of phishing/fraud.
</dd>
</dl>
<dl class="dl-horizontal">
<dt>Hold Funds</dt>
<dd>
Renne checks into a hotel and is asked for a deposit for any damages
to the room.
</dd>
<dt>Goals</dt>
<dd>
Improved user experience, Increased user choice, and rapid, widespread adoption.
</dd>
<dt>Motivation</dt>
<dd>
By design, some <a>transactions</a> do not reach completion. Some are
merely there to protect the <a>payee</a> (e.g., in the event of questionable judgment by the <a>payer</a>).
</dd>
<dt>Exceptions</dt>
<dd>
Software acting on the <a title="payer">payer's</a> behalf may keep
track of exactly how much money the <a>payer</a> has and not allow them to
process the offer.
</dd>
</dl>
<dl class="dl-horizontal">
<dt>Pre-authorization</dt>
<dd>
George pulls up to a pump at a petrol station. His in-vehicle application
recognizes the station location and the pump. The pump communicates which
fuels it has and their price in an offer. George's car asks if he wants to
approve a fill up for up to €35.
</dd>
<dt>Goals</dt>
<dd>
Improved user experience, Greater security, Innovation, Transparency,
Automatability, and rapid, widespread adoption.
</dd>
<dt>Motivation</dt>
<dd>
Some offers are not aware of the final price but would rather set limits on
the amount of the <a>purchase</a> before a particular metered good or service is
delivered.
</dd>
<dt>Privacy</dt>
<dd>Due to the sensitivity of location data, individuals
should be able to make small fuel <a title="purchase">purchases</a> in a way that respects their privacy.
</dd>
<dt>Security</dt>
<dd>Automated <a title="purchase">purchases</a> (e.g,. by a vehicle) should involve increased security (e.g., a second factor of authentication).
</dd>
</dl>
<dl class="dl-horizontal">
<dt>Machine Readability</dt>
<dd>
BigBoxCo expresses their entire product catalog online as machine-readable
information so that SearchCo may index their content more easily and direct
more customer traffic to BigBoxCo's website.
</dd>
<dt>Goals</dt>
<dd>
Increased user choice, Improved user experience, Innovation, Lower Costs,
Transparency, Automatability, Portability, Monetization,
and rapid, widespread adoption.
</dd>
<dt>Motivation</dt>
<dd>
Machine-readable offers will have a direct positive impact on store sales
if they are indexed by search engines.
</dd>
</dl>
<dl class="dl-horizontal">
<dt>Live Market Prices</dt>
<dd>
EnergyCo lists barrels of refined oil for sale on their website based on an
algorithm that uses the cost of coal and crude oil as inputs. EnergyCo
guarantees their prices for up to 24 hours from the posting date.
</dd>
<dt>Goals</dt>
<dd>
Increased user choice,
Improved user experience,
Innovation,
Transparency, and
Automatability
</dd>
<dt>Motivation</dt>
<dd>
The ability to express a non-repudiable offer as the basis of a legally
enforceable contract will reduce <a>transaction</a> friction.
</dd>
</dl>
<dl class="dl-horizontal">
<dt>Trial-ware</dt>
<dd>
Amantha downloads the latest version of her favorite game and beats
the first level. The game asks her if she'd like to buy the full game
to play further levels.
</dd>
<dt>Goals</dt>
<dd>
Improved user experience,
Monetization,
and rapid, widespread adoption.
</dd>
<dt>Motivation</dt>
<dd>
There is a fairly large trial-ware industry that could benefit from
a simple way of executing a payment without requiring redirection
to another site to enter account and payment details.
</dd>
</dl>
<dl class="dl-horizontal">
<dt>In-vehicle</dt>
<dd>
Jeff listens to a lot of music on the way to work. The music station serves a digital offer along with the music stream. This enables Jeff to
easily buy music that he really likes.
</dd>
<dt>Goals</dt>
<dd>
Improved user experience,
Innovation,
Monetization,
and rapid, widespread adoption.
</dd>
<dt>Motivation</dt>
<dd>
Car manufacturers and the entertainment industry may be interested in
extending their sales channels into vehicles.
</dd>