forked from w3c/payment-method-credit-transfer
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
356 lines (297 loc) · 16.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
<!DOCTYPE html>
<html>
<head>
<title>SEPA Credit Transfer</title>
<meta charset='utf-8'>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common'
async class='remove'></script>
<script class='remove'>
var respecConfig = {
shortName: "payment-method-basic-ct-dd",
edDraftURI: "https://w3c.github.io/browser-payment-api/basic-ct-dd-payment.html",
specStatus: "ED",
editors: [
{ name: "Cyril Vignet",
company: "BPCE" },
{ name: "Matt Saxon",
company: "Worldpay" }
],
useExperimentalStyles: true,
license: "w3c-software-doc",
//previousMaturity: "FPWD",
//previousPublishDate: "1977-03-15",
wg: "Web Payments Working Group",
wgURI: "https://www.w3.org/Payments/WG/",
wgPublicList: "public-payments-wg",
wgPatentURI: "https://www.w3.org/2004/01/pp-impl/83744/status",
issueBase: "https://github.com/w3c/browser-payment-api/issues/",
localBiblio: {
"PAYMENTARCH": {
title: "Payment Request Architecture"
, href: "architecture.html"
, authors: [
"Adrian Bateman"
, "Zach Koch"
, "Richard Barnes"
]
, status: "ED"
},
"PAYMENTREQUESTAPI": {
title: "Payment Request API"
, href: "paymentrequest.html"
, authors: [
"Adrian Bateman"
, "Zach Koch"
, "Richard Barnes"
]
, status: "ED"
},
"METHODIDENTIFIERS": {
title: "Payment Method Identifiers"
, href: "method-identifiers.html"
, authors: [
"Adrian Bateman"
, "Zach Koch"
, "Richard Barnes"
]
, status: "ED"
},
"WEBIDL": {
title: "WebIDL Level 1"
, href: "http://www.w3.org/TR/WebIDL-1/ "
, authors: [
"Cameron McCormack"
, "Boris Zbarsky"
]
, status: "CR"
}
}
};
</script>
<style>
dt { margin-top: 0.75em; }
table { margin-top: 0.75em; border-collapse:collapse; border-style:hidden hidden none hidden }
table thead { border-bottom:solid }
table tbody th:first-child { border-left:solid }
table td, table th { border-left:solid; border-right:solid; border-bottom:solid thin; vertical-align:top; padding:0.2em }
li { margin-top: 0.5em; margin-bottom: 0.5em;}
</style>
</head>
<body>
<section id='abstract'>
<p>
The SEPA Credit Transfer specification describes the data formats used by the PaymentRequest API [[!PAYMENTREQUESTAPI]] to support payment by SEPA Credit Transfers
</p>
</section>
<section id='sotd'>
<p>
The working group maintains <a href="https://github.com/w3c/browser-payment-api/issues">a
list of all bug reports that the group has not yet addressed</a>.
</p>
</section>
<section class='informative'>
<h2>Introduction</h2>
<p>This specification is a Payment Transaction Message Specification used by the PaymentRequest API [[!PAYMENTREQUESTAPI]] to support SEPA complaint Credit Transfers.</p>
</section>
<section id="dependencies">
<h2>Dependencies</h2>
<p>
This specification relies on several other underlying specifications.
</p>
<dl>
<dt>Payment Request Architecture</dt>
<dd>The terms <dfn data-lt="payment method|payment methods">Payment Method</dfn>,
<dfn data-lt="payment app|payment apps">Payment App</dfn>, and <dfn>Payment Transaction
Message Specification</dfn> are defined by the Payment Request Architecture document
[[!PAYMENTARCH]].</dd>
<dt>Payment Request API</dt>
<dd>The term <dfn>PaymentRequest constructor</dfn> is defined by the PaymentRequest API
specification [[!PAYMENTREQUESTAPI]].</dd>
<dt>Payment Method Identifiers</dt>
<dd>The term <dfn data-lt="payment method identifier|payment method identifiers">Payment
Method Identifier</dfn> is defined by the Payment Method Identifiers specification
[[!METHODIDENTIFIERS]].</dd>
<dt>Web IDL</dt>
<dd>The IDL in this specification is defined by Web IDL [[!WEBIDL]].</dd>
</dl>
</section>
<section id="method-id">
<h2>Payment Method Identifier</h2>
<p>The following payment method identifier strings are described by this specification.</p>
<table>
<tr><th>Identifier String</th><th>Description</th><th>Comment</th></tr>
<tr>
<td>PushSCT</td>
<td>Payment Application Executed SEPA Credit Transfer</td>
<td>This scenario is where the Credit Transfer in initiaited by the Payment Application.</td>
</tr>
<tr>
<td>PullSCT</td>
<td>Payee Merchant Executed SEPA Credit Transfer</td>
<td>This scenario is where the Credit Transfer in initiaited by the Payee or their PSP. TO BE DEFINED, AWAITING PSD2 INTRODUCTION</td>
</tr>
</table>
</section>
<section id="flow">
<h2>Payment Method Flow</h2>
<p>The following represent an overview of the flow for <dfn><code>PushSCT</dfn></code> as it is expected to be used as part of a W3C WebPayment</p>
<section>
<h3>Payer Initiated SEPA Credit Transfer</h3>
<div><a href="http://www.plantuml.com/plantuml/proxy?fmt=svg&src=https://raw.githubusercontent.com/w3c/webpayments-methods-credit-transfer-direct-debit/gh-pages/SCT.pml"><img width="100%" src="http://www.plantuml.com/plantuml/proxy?fmt=svg&src=https://raw.githubusercontent.com/w3c/webpayments-methods-credit-transfer-direct-debit/gh-pages/SCT.pml"/></a></div>
</section>
</section>
<section id="init-data">
<h2>Payment Method Specific Data for the PaymentRequest constructor</h2>
<p>This section describes payment method specific data that is supplied as part of the <code>data</code>
argument to the PaymentRequest constructor.</p>
<section>
<h2>PushSCTRequest</h2>
<p>The <dfn><code>PushSCTRequest</code></dfn> dictionary contains the request from the
PaymentRequest API when a Payee accepts payment via a Payee Initiated SEPA Credit Transfer.</p>
<p>The fields are based upon the Customer to Bank Credit Transfer Initiation (DS-01) specification from <a href="http://www.europeanpaymentscouncil.eu/index.cfm/knowledge-bank/epc-documents/sepa-credit-transfer-rulebook-version-81/">SEPA Credit Transfer Rulebook Version 8.1</a></p>
<p>However the field names are amended to follow with roles defined in the W3C WebPayment specification. Mappings are provided in the field descriptions and are prefixed AT-xx.</p>
<div class="issue" title="Other references useful?">
We have referenced the SEPA Rule Book, however we should define the ISO20022 mappings also to be more specific <a href="https://www.iso20022.org/documents/messages/pain/schemas/pain.001.001.07.zip">CustomerCreditTransferInitiationV07</a> (PAIN001.001.007)
</div>
<pre class="idl">
dictionary PushSCTRequest {
sequence<DOMString> requiredFields;
required DOMString PayeeIBAN;
DOMString PayeeName;
DOMString PayeeIdentificationCode;
required DOMString PayeePaymentIdentification;
DOMString SellerName;
DOMString SellerIdentificationCode;
required DOMString PurposeCode;
DOMString CategoryPurposeCode;
DOMString PreferredProcessingDate;
DOMString NotificationURL;
};
</pre>
</section>
<section>
<h2>Request Fields</h2>
<p>The <dfn><code>PushSCTRequest</code></dfn> dictionaries contains the following fields:</p>
<dl>
<dt><dfn><code>requiredFields</code></dfn></dt>
<dd>The <code>requiredFields</code> field contains the list of fields that the Payment App must attempt to return, if this requirements cannot be met, e.g. the payment instrument must fail as this is a push payment.</dd>
<div class="issue" title="Sub-class modelling required?">
The above field is also required in the BasicCardRequest, does this need modelling in the a superclass or base api?
</div>
<div class="issue" title="Failed payment edge cases?">
The above field is required, but this can result in failed payments after 'Authorise' clicked. Should we have a better modelling (e.g. using subclasses) to allow for a more fine grained matching of apps to requests? Does the PMI specification need to support this?
</div>
<dt><dfn><code>PayeeIBAN</code></dfn></dt>
<dd>AT-20: The IBAN of the account of the Beneficiary</dd>
<dd>The International Bank Account Number used to uniquely identify the account of a customer at a financial institution</dd>
<dd>The ISO standard 13616 applies </dd>
<dt><dfn><code>PayeeName</code></dfn></dt>
<dd>AT-21 The name of the Beneficiary</dd>
<dd>The name of the Beneficiary as supplied by the Originator</dd>
<dt><dfn><code>PayeeIdentificationCode</code></dfn></dt>
<dd>AT-24: The Beneficiary identification code</dd>
<dd>A code supplied by the Originator</dd>
<dt><dfn><code>PayeePaymentIdentification</code></dfn></dt>
<dd>AT-05: The Remittance Information sent by the Originator to the Beneficiary in the Credit Transfer Instruction</dd>
<dd>A maximum of 140 characters for unstructured Remittance Information (see SEPA Rulebook for details for standard structure)</dd>
<dt><dfn><code>SellerName</code></dfn></dt>
<dd>AT-28: The name of the Beneficiary Reference Party</dd>
<dd>The name of a person in relation to whom a Beneficiary receives a payment</dd>
<dd>The Beneficiary Reference Party is a person on behalf of or in connection with whom the Beneficiary
receives a payment.</dd>
<dd>Reference in any payment instruction to a Beneficiary Reference Party does not imply that such party
is a Beneficiary or otherwise a payee, or is contractually obliged or entitled in connection with any
payment obligation</dd>
<dt><dfn><code>SellerIdentificationCode</code></dfn></dt>
<dd>AT-29: The identification code of the Beneficiary Reference Party</dd>
<dd>A code supplied by the Originator and to be delivered unaltered to the Beneficiary</dd>
<dt><dfn><code>PurposeCode</code></dfn></dt>
<dd>AT-44: The purpose of the credit transfer</dd>
<dd>The purpose of the credit transfer is the underlying reason for the credit transfer transaction, i.e.
information on the nature of such transaction.</dd>
<dd>All codes part of the ISO standard are accepted
<a href="https://www.iso20022.org/documents/External_code_lists/ExternalCodeSets_1Q2016_11May2016_v1.xls">ISO20022 External Code Sets</a>
Purpose
</dd>
<dt><dfn><code>CategoryPurposeCode</code></dfn></dt>
<dd>AT-45: The category purpose of the credit transfer</dd>
<dd>The category purpose of the credit transfer is information on the high level nature of the credit transfer
transaction. It can have different goals: allow the Originator Bank to offer a specific processing agreed
with the Originator, or allow the Beneficiary Bank to apply a specific processing
<dd>All codes part of the ISO standard are accepted from
<a href="https://www.iso20022.org/documents/External_code_lists/ExternalCodeSets_1Q2016_11May2016_v1.xls">ISO20022 External Code Sets</a>, defaults to EPAY (ePayment) if excluded
CategoryPurpose
</dd>
<dt><dfn><code>PreferredProcessingDate</code></dfn></dt>
<dd>The merchants preferred processing date, see field SelectedProcessingDate in <dfn><code>PushSCTResponse</code></dfn></dd>
<div class="issue" title="Field date type">
The formatting of the date needs specifying
</div>
<dt><dfn><code>NotificationURL</code></dfn></dt>
<dd>The endpoint (a.k.a. webhook) that will be called by the payment app to update the merchant. This can be used to protect against various failure scenarios.</dd>
<div class="issue" title="Message authentication">
We need to investigate a means for message authentication on the above call-back. If this field is commonyl used, e.g. AliPay also, there is a case for specifying this in a superclass or other spec
</div>
<div class="issue" title="Field lengths">
Are there any further maximum field lengths that need specifying?
</div>
</dl>
</section>
</section>
<section id="response">
<h2>Payment Method Response</h2>
<p>The <dfn><code>PushSCTResponse</code></dfn> dictionary contains the response from the
PaymentRequest API when a payee accepts payment with a Payer Initiated SEPA Credit Transfer.</p>
<p>This section describes payment method specific data that is supplied as part of the response
from PaymentRequest.</p>
<section>
<h2>PushSCTResponse</h2>
<p>The <dfn><code>PushSCTResponse</dfn></code> message means that message has been submitted to the Payee's Bank, not that funds transfer has occured.
The merchant should wait for notification from its Bank that the payment has cleared.</p>
<pre class="idl">
dictionary PushSCTResponse {
required DOMString SelectedProcessingDate;
required DOMString PayerPaymentIdentification;
DOMString PayerIdentificationCode;
DOMString BuyerIdentificationCode;
};
</pre>
</section>
<section>
<h2>Response Fields</h2>
<p>The <dfn><code>PushSCTResponse</code></dfn> dictionaries contains the following fields:</p>
<dl>
<dt><dfn><code>SelectedProcessingDate</code></dfn></dt>
<dd>This date may be different from that requested by the Payee, either because of a business rule (e.g non business day, or a preference from the payee to defer payment</dd>
<dd>AT-07: The Requested Execution Date of the instruction</dd>
<dd>This date corresponds with a date requested by an Originator for commencing the execution of the
Credit Transfer Instruction as described in section 4.2.1.</dd>
<div class="issue" title="Field date type">
The formatting of the date needs specifying
</div>
<dt><dfn><code>PayerPaymentIdentification</code></dfn></dt>
<dd>The reference supplied by the Payer (End to End Identification in ISO20022 definition)</dd>
<dd>AT-41: The Originator’s reference of the Credit Transfer Transaction</dd>
<dd>This reference identifies for a given Originator each Credit Transfer Transaction presented to the
Originator Bank, in a unique way. This number will be transmitted in the entire process of the handling
of the credit transfer transactions from acceptance until the finality of the transaction. It must be
returned in any exception handling process-step by any party involved. The Originator cannot request
for any other referencing information to be returned to him, in order to identify a credit transfer. The
Originator must define the internal structure of this reference; it can only be expected to be meaningful
to the Originator</dd>
<dt><dfn><code>PayerIdentificationCode</code></dfn></dt>
<dd>AT-10: The Originator identification code</dd>
<dd>A code supplied by the Originator and to be delivered unaltered to the Beneficiary</dd>
<dt><dfn><code>BuyerIdentificationCode</code></dfn></dt>
<dd>The buyer reference. The buyer may be a 3rd party to the payer. If the payer is paying on behalf of another party.</dd>
<dd>AT-09: The identification code of the Originator Reference Party</dd>
<dd>A code supplied by the Originator and to be delivered unaltered to the Beneficiary</dd>
<div class="issue" title="Privacy issues?">
The above two fields return information about the payer and buyer, ar there any privacy implications for these?
</div>
</dl>
</section>
</section>
</section>
</body>
</html>