-
Notifications
You must be signed in to change notification settings - Fork 22
/
payments.html
2975 lines (2758 loc) · 107 KB
/
payments.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 1.0</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<script src="../common/biblio.js" class="remove"></script>
<script src='../respec-w3c-common.js' class='remove'></script>
<script src='../respec-webpayments.js' class='remove'></script>
<script src="../common/script/resolveReferences.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: "2015-07-15",
// 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", 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: "Cyril Vignet", url: "https://www.linkedin.com/pub/cyril-vignet/bb/704/423",
company: "Groupe BPCE", companyURL: "http://www.bpce.fr/" },
{ name: "David Ezell", url: "http://example.org/",
company: "NACS", companyURL: "http://www.nacsonline.com/" },
{ name: "David Jackson", url: "https://www.linkedin.com/in/davidjjackson",
company: "Oracle", companyURL: "http://www.oracle.com/" }
],
otherLinks: [{
key: "Version control",
data: [{
value: "Github Repository",
href: "https://github.com/w3c/webpayments-ig"
}, {
value: "Issues",
href: "http://www.w3.org/Payments/IG/track/products/2"
}]
}],
// maximum level of table of contents
maxTocLevel: 3,
// name of the WG
wg: "Web Payments Interest Group",
// This is an IG so will become a Note
noRecTrack: true,
// URI of the public WG page
wgURI: "http://www.w3.org/Payments/IG/",
// name of the public mailing to which comments are due
wgPublicList: "public-webpayments-comments",
// 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-20150416.html", label: "diff to previous version"} ],
};
//respecEvents.sub('start-all', webpayments.preProcess.apply);
</script>
<style type="text/css">
body {
line-height: 1.4em;
}
h4 {
color: #005A9C;
}
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>
<p>
The following changes have been made since the last version of this document:
</p>
<ul>
<li>
Reorganization of use cases by phases approved by the Web Payments IG.
</li>
<li>
Removal of the "Goals" for each use case as they were repetitive and did not
greatly aid understanding of the use case.
</li>
<li>
Addition of Regulatory concerns to a number of the use cases.
</li>
<li>
Addition of two more scenarios related to Direct Debit and Credit Transfer.
</li>
<li>
Addition of "Relationship to Other Documents" section.
</li>
<li>
Integration of a unified Web Payments Activity glossary.
</li>
<li>
Addition of Escrow, Biometric, Know Your Customer (KYC), and
Anti-Money Laundering (AML) use cases.
</li>
<li>
Integration of feedback from the public, Web Payments Community Group, and
Web Payments Interest Group.
</li>
</ul>
</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 using Web technologies for both
online and brick-and-mortar (offline) scenarios. This will help achieve
greater interoperability among merchants and their customers,
payment providers, software vendors, mobile operators, native mobile
apps, and payment networks. The roadmap will include
<a title="payment scheme">payment schemes</a> in use
today (such as electronic checks, 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 paycheck to paycheck, do
not have access to savings accounts or low-fee check 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 id="relationships">
<h2>Relationship to Other Documents</h2>
<p>
This document is one part of a greater body of work around Web Payments that
the <a href="https://www.w3.org/Payments/IG/">Web Payments Interest Group</a>
at W3C is producing. These other documents include:
</p>
<ul>
<li>
<a href="https://www.w3.org/Payments/IG/Vision">A Vision for Web Payments</a>
describes the desirable properties of a Web Payments architecture.
</li>
<li>
<a href="http://www.w3.org/TR/web-payments-use-cases/">Web Payments Use Cases
1.0</a> (this document) is a prioritized list of all Web Payments scenarios
that the Web Payments Interest Group expects the architecture to address
in time.
</li>
<li>
<a href="https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/capabilities/index.html">
Web Payments Capabilities 1.0</a>
derives a set of capabilities from the use cases that, if standardized, will
improve payments on the Web.
</li>
<li>
<a href="https://www.w3.org/Payments/IG/Roadmap">Web Payments Roadmap 1.0</a>
proposes an implementation and deployment plan that will result in
enhancements to the Open Web Platform that will achieve the scenarios outlined
in the Use Cases document and the capabilities listed in the Capabilities
document.
</li>
</ul>
</section>
<section>
<h3>How this Document is Organized</h3>
<p>
This document is organized as follows:
</p>
<ul>
<li>
<a href="#terminology">Section 2: Terminology</a> defines basic payment
terminology.
</li>
<li>
<a href="#an-overview-of-the-payment-phases">Section 3: An Overview of the
Payment Phases</a> describes a common payment flow at a high level. The group
expects to work on additional payment flows in future work.
</li>
<li>
<a href="#a-simple-example-of-the-payment-phases">Section 4: A Simple
Example of the Payment Phases</a> is a specific
narrative, labeled according to the steps of section 3.
<a href="#additional-examples-of-the-payment-phases">Section 7:
Additional Examples of the Payment Phases</a> describes additional familiar
narratives to give a more complete picture of how the payment phases apply.
</li>
<li>
<a href="#assumptions">Section 5: Assumptions</a> highlights general
assumptions that have been made about the use cases.
</li>
<li>
<a href="#use-cases-1">Section 6: Use Cases</a> 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>
A <em>Roadmap phase</em> which specifies the intended phase of the
<a href="https://www.w3.org/Payments/IG/Roadmap">Web Payments Roadmap</a> that
will enable the use case.
</li>
<li>
A short <em>Motivation</em> statement 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>
Accessibility. Accessibility considerations (e.g., in multi-factor
authentication, management of biometrics in the case of users with some
disabilities).
</li>
<li>
Regulatory. Regulatory considerations (e.g., anti-money laundering
clearing, suspicious activity reporting, tax collection, trade compliance).
</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>
</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 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>
<div data-include="../common/terms.html"
data-oninclude="restrictReferences">
</div>
</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 Refunds
</li>
</ol>
<p>The descriptions below only discuss the interactions between the
<a>payer</a> 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>payer</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>payer</a> may
need to provide a proof of funds or a proof of hold to the <a>payee</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 Refunds</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>, or encrypted line-item receipt).
</li>
<li>
<strong>Refunds</strong>. At times exceptions may occur (e.g., defective
product or application of store return policy). In this case, the
<a>payee</a> initiates payment to the <a>payer</a>. The refund may
take different forms, including a refund to the <a title="payer">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 on whether this section is helpful. We are
attempting to ground the payment phases and steps in a real world use case.
An alternative would be removing this section entirely if the preceding
section suffices, or moving this narrative to section 7 with the 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
<a href="https://en.wikipedia.org/wiki/The_dress_(viral_phenomenon)">
blue with black stripes or white with gold stripes</a>,
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
chosen 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 notifies her of a discount for 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 accepts 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, the use of which is protected by two-factor
authentication, 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 Refunds</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 use 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 an 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 id="uc-website" class="dl-horizontal">
<dt>Website</dt>
<dd>
Penny uses the HobbyCo website to select a $15 model train for <a>purchase</a>.
</dd>
<dt>Roadmap phase</dt>
<dd>1</dd>
<dt>Motivation</dt>
<dd>
A human being seeing a visual offer of sale on a website is the most common
way offers are discovered on the Web today (2015).
</dd>
</dl>
<dl id="uc-pos-kiosk" class="dl-horizontal">
<dt>Point of Sale Kiosk</dt>
<dd>
Cory shops for groceries at his local ChowMart, scans his loyalty card and
all of the items he wants to <a>purchase</a> at the automated kiosk, requests
a cash back amount, and is presented with a total amount.
</dd>
<dt>Roadmap phase</dt>
<dd>Uncategorized</dd>
<dt>Motivation</dt>
<dd>
Unifying point of sale interaction w/ the Web Payments architecture is
vital for the success of this work.
</dd>
<dt>Accessibility</dt>
<dd>
At present kiosks are rarely accessible to blind people, people with low
vision, people who use wheelchairs, or people with restricted mobility that
makes touch interaction difficult or impossible. They don’t tend to offer
speech output, any ability to zoom or customise colours, may be difficult to
reach from a wheelchair/sitting position, and do not accept voice commands.
Enabling as much of the payment interaction to move to a customer-held device
with accessibility features would help alleviate a number of barriers that
exist today.
</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.<br/>
Making kiosks that are used for financial transactions accessible introduces
several challenges. Speech output may be overheard by people nearby, increased
text size and/or visibility of content may make it easier for other people
to read, and voice commands may also be overheard.
</dd>
</dl>
<dl id="uc-mobile" class="dl-horizontal">
<dt>Mobile</dt>
<dd>
A mobile device can be used to discover an offer in a variety of ways:
<ul>
<li>
Hani takes a taxi from the airport to his hotel. The taxi driver
displays the total with his mobile device. Hani and the taxi driver
touch their mobile devices to each other. The total appears on Hani's mobile
device.
</li>
<li>
There is a Quick Response Code (QR Code) printed on the bottom of a cup that
Donna wants to buy. Donna uses her mobile phone app to capture the QR Code,
view the price of the item, and add it to the list of items that she is buying
from the store.
</li>
</ul>
</dd>
<dt>Roadmap phase</dt>
<dd>Uncategorized</dd>
<dt>Motivation</dt>
<dd>
Unifying the way proximity mobile offers work with the Web Payments
architecture would help ensure ubiquity.
</dd>
<dt>Accessibility</dt>
<dd>
An auditory cue notifying people that have low vision or are blind
that a payment offer/invoice is awaiting their response as well as providing
guidance on how close their payment device is to the payment terminal would
be helpful.
</dd>
<dt>Exceptions</dt>
<dd>
No mobile phone connectivity (e.g. visiting a different country or trip occurs
outside the range of a mobile network).
</dd>
</dl>
<dl id="uc-freemium" class="dl-horizontal">
<dt>Freemium</dt>
<dd>
Chaoxiang 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>Roadmap phase</dt>
<dd>Uncategorized</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>
<dl id="uc-email" class="dl-horizontal">
<dt>Email</dt>
<dd>
A GroupBuyCo customer receives an offer by email to <a>purchase</a> the deal
of the day.
</dd>
<dt>Roadmap phase</dt>
<dd>Uncategorized</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 id="uc-hold-funds" 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>Roadmap phase</dt>
<dd>Uncategorized</dd>
<dt>Motivation</dt>
<dd>
Some <a title="transaction">transactions</a>, such as a hold of funds,
do not always reach completion and are primarily used
to protect the <a>payee</a> from negligence on the part of the
<a>payer</a> (e.g., such as a <a>payer</a> damaging a hotel room).
</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 available and
not allow them to process the offer.
</dd>
</dl>
<dl id="uc-preauth" class="dl-horizontal">
<dt>Pre-authorization</dt>
<dd>
Krishna 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. Krishna's car asks if he wants to
approve a fill up for up to €35.
</dd>
<dt>Roadmap phase</dt>
<dd>Uncategorized</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) may involve
increased logging and security (e.g., a second factor of authentication).
</dd>
<dt>Regulatory</dt>
<dd>
If a pre-authorization is initiated by a software agent (such as a vehicle)
due to a <a title="payer">payer's</a> negligence, the regulatory environment
may assert that the software manufacturer is liable if the proper consent
notifications were not displayed when the pre-authorization rule was activated.
</dd>
</dl>