This repository has been archived by the owner on Mar 19, 2018. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 14
/
index.html
782 lines (700 loc) · 26.3 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
<!DOCTYPE html>
<html>
<head>
<title>Web Payments Browser API 1.0</title>
<meta http-equiv='Content-Type' content='text/html;charset=utf-8'/>
<!--
=== NOTA BENE ===
For the three scripts below, if your spec resides on dev.w3 you can check them
out in the same tree and use relative links so that they'll work offline,
-->
<link rel="stylesheet" href="spec.css">
<script src='//www.w3.org/Tools/respec/respec-w3c-common' async class='remove'></script>
<script src='utils.js' async class='remove'></script>
<script type="text/javascript" class="remove">
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "CG-DRAFT",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName: "web-payments-browser-api",
// 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: "WD",
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "https://web-payments.org/specs/source/web-payments-browser-api/",
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// 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/" },
],
// 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: "Manu Sporny", url: "https://manu.sporny.org/",
company: "Digital Bazaar, Inc.", companyURL: "http://digitalbazaar.com/" },
{ name: "Dave Longley", url: "https://github.com/dlongley",
company: "Digital Bazaar, Inc.", companyURL: "http://digitalbazaar.com/" },
],
// extend the bibliography entries
//localBiblio: {},
// name of the WG
wg: "W3C Web Payments Community Group",
// URI of the public WG page
wgURI: "http://www.w3.org/community/webpayments/",
// name (with the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-webpayments@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: "",
maxTocLevel: 4,
preProcess: [ ] /*,
alternateFormats: [ {uri: "diff-20111214.html", label: "diff to previous version"} ],
*/
};
</script>
<style>
.sequence-diagram {
margin: auto;
}
</style>
</head>
<body>
<section id="abstract">
<p>
This document outlines how to register <a>payment instrument</a>s, request payments,
and acknowledge payment requests using a polyfill-able browser API.
</p>
</section>
<section id="sotd">
<p>There are a number of ways that one may participate in the development of
this specification:</p>
<ul>
<li>Ad-hoc technical discussion primarily occurs on the public community mailing list:
<a href="http://lists.w3.org/Archives/Public/public-webpayments/">public-webpayments@w3.org</a></li>
<li><a href="http://payswarm/minutes/">Public Web Payments Community Group teleconferences</a>
are held on Wednesdays at 1600UTC every other week.</li>
<li>Specification bugs and issues should be reported in the
<a href="https://github.com/web-payments/web-payments.org/issues">issue tracker</a>
if you do not want to send an e-mail to the public-webpayments mailing
list.</li>
<li><a href="https://github.com/web-payments/web-payments.org/tree/master/">Source code</a>
for the specification can be found on Github.</li>
</ul>
</section>
<section class="informative">
<h1>Introduction</h1>
<p>
This API enables a web application to initiate payment for a product or
service by calling a <code>navigator.payment.request()</code> method. The
implementation of this feature is expected to be provided by a JavaScript
polyfill at first, and if deployment is successful, native browser
implementations will surface to enhance usability and transaction
security.
</p>
<section class="informative">
<h2>About this Document</h2>
<p>This document is a detailed specification for an application programming
interface (API) for initiating payments from within a browser
environment. The document is primarily intended for the following
audiences:</p>
<ul>
<li>Software developers who want to understand the design decisions and
algorithms behind the API.</li>
<li>Software developers who want to implement the API.</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 terminology
used throughout this document.
</li>
<li>
<a href="#a-basic-purchase-flow">Section 3: A Basic Purchase Flow</a> describes
the basic payment flow at a high-level.
</li>
<li>
<a href="#detailed-flows">Section 4: Detailed Flows</a> describes each
flow provided by the browser API in detail.
</li>
<li>
<a href="#the-application-programming-interface">Section 5:
The Application Programming Interface</a> defines the browser API for
registering, initiating, and acknowledging payments.
</li>
</ul>
</section>
</section>
<section class="normative">
<h2>Terminology</h2>
<div data-include="//w3c.github.io/webpayments-ig/latest/common/terms.html"
data-oninclude="restrictReferences">
</div>
</section>
</section>
<section>
<h2>A Basic Purchase Flow</h2>
<p>
The diagram below outlines a basic payment flow with no errors. The basic
flow starts out with the <a>payee</a> offering the <a>payer</a> a
payment request. The payer then selects an appropriate
<a>payment instrument</a> using their user agent and either 1) processes
the payment request locally if a local application is capable of processing
the request, or 2) sends the payment request to a 3rd party for
processing. The flow ends with the payment acknowledgement being returned
to the payee for processing, and if no errors occured, the delivery of the
good or service to the payer.
</p>
<script type='text/jumly+sequence'>
@found "Payee server (merchant)", ->
@message "display offer", "Payer browser (customer)", ->
@message "click 'Pay'", "Payee server (merchant)", ->
@reply "payment request", "Payer browser (customer)"
@found "Payer browser (customer)", ->
@message "select payment instrument"
@alt
"3rd party NOT required": ->
@message "generate payment acknowledgement"
"3rd party required": ->
@message "payment request + selected instrument", "Payer payment processor (wallet)", ->
@message "process request", ->
@reply "payment acknowledgement", "Payer browser (customer)"
@found "Payer browser (customer)", ->
@message "payment acknowledgement", "Payee server (merchant)", ->
@message "process acknowledgement", ->
@reply "deliver good/service", "Payer browser (customer)"
</script>
<ol class="algorithm">
<li>
The <a>payee</a>'s web page calls <code>navigator.payment.request(request)</code>.
</li>
<li>
The payment agent scans the list of previously registered <a>payment instrument</a>s
and finds matches against <code>acceptedSchemes</code> in
<code>request</code>.
</li>
<li>
A <a>payment instrument</a> is selected by the payment agent or the <a>payer</a>. The
process MAY consist of one or more of the following steps:
<ol class="algorithm">
<li>
If there is only one instrument that matches, that is automatically set
to the <em>selected <a>payment instrument</a></em>.
</li>
<li>
If there is a pre-existing preference set by the <a>payer</a> that narrows the
selection of the <a>payment instrument</a> to one match, the match is set to the
<em>selected <a>payment instrument</a></em>.
</li>
<li>
If there is more than one potential match, the <a>payer</a> is asked which
instrument they would like to use and the selection is set to the
<em>selected <a>payment instrument</a></em>
</li>
<li>
If there are no matches, the <a>payer</a> is notified and may be taken to an
alternate flow where a matching <a>payment instrument</a> is acquired.
</li>
</ol>
</li>
<li>
If the <a>payment instrument</a> does not require the payment flow to switch
to a 3rd party <a>payment processor</a> (e.g. cryptocurrency),
then the payment acknowledgement is generated locally and the web
application that called <code>navigator.payment.request()</code> is
sent the acknowledgement via <code>navigator.payment.acknowledge()</code>.
</li>
<li>
If the instrument requires the payment flow to switch to a 3rd party
payer <a>payment processor</a> (e.g. push-payment like a PayPal/Google Wallet-like instrument, ACH, ISO20022 style instrument):
<ol class="algorithm">
<li>
The payment agent forwards the <code>request</code>, and
<em>selected <a>payment instrument</a></em> via <code>postMessage</code> to the
<code>paymentRequestService</code> in the <a>payment instrument</a> for approval.
</li>
</ol>
</li>
<li>
If the instrument requires the payment flow to switch to a 3rd party
payee <a>payment processor</a> (e.g. pull-payment like non-EMV magstripe credit
card with embossed PAN and CVV2, or tokenized credit card):
<ol class="algorithm">
<li>
The payment agent forwards the request on via <code>postMessage()</code>
to the <code>paymentRequestService</code> in the
<code>acceptedScheme</code> (note that the <a>payee</a>
sets this, not the <a>payment instrument</a>).
</li>
</ol>
</li>
<li>
The payment flow is then transferred to the entity that is going to
generate the <em>payment acknowledgment</em> (locally installed
payment instrument, <a>payee</a>'s <a>payment service provider</a>, or <a>payer</a>'s
payment service provider).
</li>
<li>
Once the entity in control of the payment flow finalizes the
<em>payment acknowledgement</em>, even if the message is to
acknowledge that the payment failed, the <em>payment acknowledgement</em>
is generated and <code>navigator.payment.acknowledge(acknowledgement)</code>
is called.
</ol>
</section>
<section>
<h2>Detailed Flows</h2>
<p class="issue">
Describe the payment flow in detail here using Adrian's flow diagram and Ian's
steps.
</p>
<section>
<h3>Payment Instrument Registration</h3>
<ol>
<li>
The <a>payer</a> navigates to a payment instrument provider website
(like their bank) to sign up.</li>
</li>
<li>
During sign-up, the <code>navigator.payment.register()</code> call is made
to register a <a>payment instrument</a>:
<pre class="example" title="Example of a credit card registration">
var card = {
'@context': 'https://w3id.org/web-payments/v1',
type: 'PaymentInstrument',
scheme: 'https://w3id.org/payment-schemes#Visa',
label: 'ExampleBank Visa Card',
cardNumber: '4444444444444444'
};
// register the <a>payment instrument</a> - at this point, the interface asks the
// person for approval to store the new <a>payment instrument</a>
var promise = navigator.payment.register(card);
// this happens when the registration completes with success or a failure
promise.then(function(result) {
// card has been registered, do something
}).catch(function(err) {
// card has not been registered, do something
});
</pre>
</li>
</ol>
<p class="issue">
Clearly, registering a card number in the clear is a bad idea, so perhaps
a tokenized card would be a better example. There are much more secure flows
that we could demonstrate, but showing that this API works with 90%+ of the
card-not-present transactions online today is important.
</p>
</section>
<section>
<h3>Processing a Payment Request</h3>
<ol>
<li>
The <a>payer</a> navigates to a <a>payee</a>'s website.</li>
<li>
The <a>payer</a> finds an item to payment and initiates the payment flow
(by clicking a button, swiping, speaking a voice command, etc.).
</li>
<li>
The <a>payee</a> application generates a signed payment request, which is a
[[!JSON-LD]] object that contains enough information to process the
payment:
<pre class="example" title="Example of a payment request">
var req = {
'@context': 'https://w3id.org/web-payments/v1',
type: 'PaymentRequest',
description: 'Payment to ExampleMerch for widgets',
acceptedScheme: {
scheme: 'https://w3id.org/payment-schemes#Visa',
transfer: {
amount: '4.35',
currency: 'USD'
},
paymentRequestService: 'https://merchant-psp.example.com/services/getPaymentInfo'
},
signature: {
type: 'LinkedDataSignature2015',
creator: 'https://payee.example.com/keys/23',
created: '2015-09-23T20:21:34Z',
nonce: '239807882930744354',
signatureValue: '4NTIyOGQzNGVkMzVmZTkZ...3Q3ODgoYzI4IyOWM32NjI='
}
};
// request payment and get a promise that is resolved on payment
var promise = navigator.payment.request(req);
// resolve the promise
promise.then(function(result) {
// payment was processed by the payment processor
}).catch(function(err) {
// payment failed to be processed by the payment processor
});
</pre>
</li>
</ol>
</section>
<section>
<h3>Processing a Payment Acknowledgement</h3>
<ol>
<li>
The <a>payee</a>'s <a>payment service provider</a> receives a payment request,
authenticates the payer's card information, and gets approval to proceed with
the payment from the <a>payer</a>.
</li>
<li>
Once approval has been provided by the <a>payer</a>, the payment is processed.
</li>
<li>
The payment service processor generates a signed payment acknowledgement
message, which is a [[!JSON-LD]] object that contains enough information to
verify that the transaction has completed successfully (or has failed):
<pre class="example" title="Example of a payment acknowledgement">
var acknowledgement = {
'@context': 'https://w3id.org/web-payments/v1',
type: 'PaymentAcknowledgement',
description: 'Payment to ExampleMerch for widgets',
selectedScheme: {
scheme: 'https://w3id.org/payment-schemes#Visa',
status: 'authorized',
approvalCode: '10025AB',
transfer: {
amount: '4.35',
currency: 'USD'
}
},
signature: {
type: 'LinkedDataSignature2015',
creator: 'https://payment-service-provider.example.com/keys/12',
created: '2015-09-23T20:23:15Z',
nonce: '239807882930744352',
signatureValue: 'm4NTIyZTOGQzNGVkMzVkZ...OWM32NjIgoYzI43Q3ODIy='
}
};
// acknowledge that the payment was processed
navigator.payment.acknowledge(acknowledgement);
</pre>
</li>
</ol>
</section>
</section>
<section>
<h2>The Application Programming Interface</h2>
<p class="issue">
This browser-based API is provided for convenience purposes only. The
existence of the API is absolutely not a requirement for the basic operation
of the Web Payments protocol. No browser API is necessary in order for a
Web application to initiate payment and receive an acknowledgement of the
result of the payment.
</p>
<p>This API provides a clean mechanism that enables developers to
initiate payments in a User Agent.
A conformant payment agent MUST implement the entirety of the
following API.</p>
<section>
<h3>NavigatorPayment</h3>
<p>Navigator Payment is the name of the high-level programming
interface that Web developers use to initiate payments. If MUST be
made available via the <code>navigator.payment</code> object.</p>
<dl title="interface NavigatorPayment" class="idl">
<dt>Promise register()</dt>
<dd>
<p>
Typically called by a payment processor to register a <a>payment instrument</a> for
later use during a payment request.
</p>
<dl class="parameters">
<dt>object instrument</dt>
<dd>
A [[!JSON-LD]] encoded <a>payment instrument</a>.
</dd>
<dt>object options</dt>
<dd>
A set of options to use when registering the payment instrument.
</dd>
</dl>
</dd>
<dt>Promise request()</dt>
<dd>
<p>
Typically called by a <a>payee</a> to initiate a payment. The instrument is
encoded in [[!JSON-LD]] format.
</p>
<dl class="parameters">
<dt>object request</dt>
<dd>
Typically called by a <a>payee</a> to request a payment. The request is
encoded in [[!JSON-LD]] format.
</dd>
<dt>object options</dt>
<dd>
A set of options to use when requesting payment.
</dd>
</dl>
</dd>
<dt>void acknowledge()</dt>
<dd>
<p>
Typically called by a payment processor to acknowledge that a payment request
has been processed. The acknowledgement is encoded in [[!JSON-LD]] format.
</p>
<dl class="parameters">
<dt>object acknowledgement</dt>
<dd>
A [[!JSON-LD]] encoded payment acknowledgement describing the result of a
payment request.
</dd>
<dt>object options</dt>
<dd>
A set of options to use when processing the payment acknowledgement.
</dd>
</dl>
</dd>
</dl>
</section> <!-- end of NavigatorPayment -->
</section>
<section class="appendix informative">
<h2>Messages Addendum</h2>
<p>
Multiple types of <a>payment instrument</a>s may be supported using this approach:
</p>
<pre class="example" title="Example of Bitcoin registration">
var bitcoin = {
'@context': 'https://w3id.org/web-payments/v1',
type: 'PaymentInstrument',
scheme: 'https://w3id.org/payment-schemes#Bitcoin',
id: 'bitcoin:19Cgacam5sVryog9QQKjFo1GApy34Qat83',
label: 'BitExample Bitcoin Account',
privateKeyBitcoin: '5JSjcscTvQcCb2h7LxFGwEzVqHM6HqC6xanxwZtymRZg5Z1yWot',
paymentRequestService: 'https://bitcoin.example.com/services/bitcoin'
};
// register the <a>payment instrument</a> - at this point, the interface asks the
// person for approval to store the new <a>payment instrument</a>
var promise = navigator.payment.register(bitcoin);
// this happens when the registration completes with success or a failure
promise.then(function(result) {
// bitcoin instrument has been registered, do something
}).catch(function(err) {
// bitcoin instrument has not been registered, do something
});
</pre>
<p>
Multiple payment requests may be collected into a single request.
</p>
<pre class="example" title="Example of a complex payment request">
var req = {
'@context': 'https://w3id.org/web-payments/v1',
type: 'PaymentRequest'
description: 'Payment to ExampleMerch for Widget 1'
acceptedScheme: [{
scheme: [
'https://w3id.org/payment-schemes#Visa',
'https://w3id.org/payment-schemes#Mastercard',
'https://w3id.org/payment-schemes#Discover'
],
transfer: {
amount: '4.35',
currency: 'USD'
},
destination: '20389472398'
}, {
scheme: 'https://w3id.org/payment-schemes#Bitcoin',
transfer: {
amount: '0.0177',
currency: 'BTC'
},
destination: '3QJmV3qfvL9SuYo34YihAf3sRCW3qSinyC'
},
signature: {
type: 'LinkedDataSignature2015',
creator: 'https://payee.example.com/keys/23',
created: '2015-09-23T20:21:34Z',
nonce: '239847230947223423',
signatureValue: 'OGQzNGVkMzVm4NTIyZTkZ...goYzI43Q3ODIyOWM32NjI='
}
};
// request payment and get a promise that is resolved on payment acknowledgement
var promise = navigator.payment.request(req);
// resolve the promise (performed in the next section)
promise.then(function(acknowledgement) {
// payment was processed by the payment processor
// acknowledgement may contain scheme-specific information
}).catch(function(err) {
// payment failed to be processed by the payment processor
});
</pre>
<p>
Additional information may be requested along with the payment request, like
a proof of age credential or optional shipping address, loyalty card, or
government assistance credentials.
</p>
<pre class="example" title="Example of a payment request with additional information">
var req = {
'@context': 'https://w3id.org/web-payments/v1',
type: 'PaymentRequest',
description: 'Payment to ExampleGrocer for groceries.',
acceptedScheme: {
scheme: 'https://w3id.org/payment-schemes#Visa',
transfer: {
amount: '4.35',
currency: 'USD'
},
destination: '20389472398',
},
requiredCredential: [{
type: 'ProofOfAgeCredential'
}],
optionalCredential: [{
type: 'ShippingAddressCredential'
}, {
type: 'ShopGoodLoyaltyCardCredential'
}, {
type: 'SnapCardCredential'
}],
signature: {
type: 'LinkedDataSignature2015',
creator: 'https://payee.example.com/keys/23',
created: '2015-09-23T20:21:34Z',
nonce: '239807882930744352',
signatureValue: 'OGQzNGVkMzVm4NTIyZTkZ...goYzI43Q3ODIyOWM32NjI='
}
};
// request payment and get a promise that is resolved on payment
var promise = navigator.payment.request(req);
// resolve the promise
promise.then(function(result) {
// payment was processed by the payment processor
}).catch(function(err) {
// payment failed to be processed by the payment processor
});
</pre>
<p class="issue">
There is a strong argument to simplify this interface by ensuring that
credentials are provided in a step prior to the payment request. The downside
of this approach is that there would be two UI prompts to the customer to
1) provide the appropriate credentials, and 2) provide the appropriate
payment instrument. The upside is that keeping these things separate will
enable each to improve independently of one another.
</p>
</section>
<section class="appendix informative">
<h2>Flows Addendum</h2>
<section>
<h3>Traditional Unencrypted Credit Card Flow</h3>
<p>
The diagram below outlines a traditional unencrypted credit card flow
where the user agent stores credit card details and forwards them on
to a merchant for processing.
</p>
<script type='text/jumly+sequence'>
@found "Payee payment processor"
@found "Payee server (merchant)", ->
@message "display offer", "Payer browser (customer)", ->
@message "click 'Pay'", "Payee server (merchant)", ->
@reply "payment request", "Payer browser (customer)"
@found "Payer browser (customer)", ->
@message "select payment instrument", ->
@message "payment instrument details (PAN, CVV2, address)", "Payee server (merchant)"
@found "Payee server (merchant)", ->
@message "process payment", "Payee payment processor", ->
@message "funds captured", "Payee server (merchant)", ->
@message "deliver good/service", "Payer browser (customer)"
</script>
</section>
<section>
<h3>Tokenized Credit Card Flow</h3>
<p>
The diagram below outlines a tokenized credit card flow where the token is
generated via a local mobile wallet application available to the payer.
</p>
<script type='text/jumly+sequence'>
@found "Payee payment processor"
@found "Payee server (merchant)", ->
@message "display offer", "Payer browser (customer)", ->
@message "click 'Pay'", "Payee server (merchant)", ->
@reply "payment request", "Payer browser (customer)"
@found "Payer browser (customer)", ->
@message "select payment instrument", ->
@message "payment request + selected instrument", "Payer Mobile Wallet", ->
@message "process request", ->
@reply "payment token", "Payer browser (customer)"
@found "Payer browser (customer)", ->
@message "payment token", "Payee server (merchant)", ->
@message "use token", "Payee payment processor", ->
@message "funds captured", "Payee server (merchant)", ->
@message "deliver good/service", "Payer browser (customer)"
</script>
</section>
<section>
<h3>Push Payment</h3>
<p>
The diagram below outlines a traditional push-payment (e.g. PayPal).
</p>
<script type='text/jumly+sequence'>
@found "Payee server (merchant)", ->
@message "display offer", "Payer browser (customer)", ->
@message "click 'Pay'", "Payee server (merchant)", ->
@reply "payment request", "Payer browser (customer)"
@found "Payer browser (customer)", ->
@message "select payment instrument", ->
@message "payment request + selected instrument", "Payment Service Provider", ->
@message "process request", ->
@reply "payment acknowledgement", "Payer browser (customer)"
@found "Payer browser (customer)", ->
@message "payment acknowledgement", "Payee server (merchant)", ->
@message "verification", ->
@reply "deliver good/service", "Payer browser (customer)"
</script>
</section>
<section>
<h3>Crypto-currency Payment</h3>
<p>
The diagram below outlines a cryptographic currency payment where the
cryptocurrency application is available on the same system as the user
agent.
</p>
<script type='text/jumly+sequence'>
@found "Payee server (merchant)", ->
@message "display offer", "Payer browser (customer)", ->
@message "click 'Pay'", "Payee server (merchant)", ->
@reply "payment request", "Payer browser (customer)"
@found "Payer browser (customer)", ->
@message "select payment instrument", ->
@message "payment request", "Cryptocurrency Application", ->
@message "process request", ->
@reply "payment proof", "Payer browser (customer)"
@found "Payer browser (customer)", ->
@message "payment proof", "Payee server (merchant)", ->
@message "cryptographic verification", ->
@reply "deliver good/service", "Payer browser (customer)"
</script>
</section>
</section>
<section class="appendix informative">
<h2>Acknowledgements</h2>
<p>
The editor would like to thank the Web Payments Community Group, the
Web Payments Interest Group, Andreas Gal, Fernando Jiménez, Mike Hanson,
and Kumar McMillan for their work on the MozPay API.
</p>
<p>
Thanks to the following individuals, in order of their first name, for
their input on the specification: ...
</p>
</section>
<script src='//code.jquery.com/jquery-2.1.3.min.js' class='remove'></script>
<script src='//coffeescript.org/extras/coffee-script.js' class='remove'></script>
<script src='//jumly.tmtk.net/public/jumly.min.js' class='remove'></script>
</body>
</html>