Web Payments HTTP API 1.0

├── CODE_OF_CONDUCT.md ├── CONTRIBUTING.md ├── LICENSE.md ├── README.md ├── WD ├── 2016-07-12 │ ├── flow-purchase.svg │ ├── index.html │ └── spec.css └── 2016-09-15 │ ├── flow-purchase.svg │ ├── index.html │ └── spec.css ├── flow-purchase.svg ├── index.html ├── spec.css ├── utils.js └── w3c.json /CODE_OF_CONDUCT.md: -------------------------------------------------------------------------------- 1 | # Code of Conduct 2 | 3 | All documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/). 4 | -------------------------------------------------------------------------------- /CONTRIBUTING.md: -------------------------------------------------------------------------------- 1 | # Web Payments Working Group 2 | 3 | Contributions to this repository are intended to become part of Recommendation-track documents governed by the 4 | [W3C Patent Policy](http://www.w3.org/Consortium/Patent-Policy-20040205/) and 5 | [Software and Document License](http://www.w3.org/Consortium/Legal/copyright-software). To make substantive contributions to specifications, you must either participate 6 | in the relevant W3C Working Group or make a non-member patent licensing commitment. 7 | 8 | If you are not the sole contributor to a contribution (pull request), please identify all 9 | contributors in the pull request comment. 10 | 11 | To add a contributor (other than yourself, that's automatic), mark them one per line as follows: 12 | 13 | ``` 14 | +@github_username 15 | ``` 16 | 17 | If you added a contributor by mistake, you can remove them in a comment with: 18 | 19 | ``` 20 | -@github_username 21 | ``` 22 | 23 | If you are making a pull request on behalf of someone else but you had no part in designing the 24 | feature, you can remove yourself with the above syntax. 25 | -------------------------------------------------------------------------------- /LICENSE.md: -------------------------------------------------------------------------------- 1 | All documents in this Repository are licensed by contributors under the [W3C Software and Document License](http://www.w3.org/Consortium/Legal/copyright-software). 2 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Web Payments HTTP API 1.0 2 | 3 | This document outlines how to register payment apps, request payments, 4 | and acknowledge payment requests using a standard HTTP API. 5 | 6 | The live version of this specification can be found here: 7 | 8 | http://w3c.github.io/webpayments-http-api/ 9 | -------------------------------------------------------------------------------- /WD/2016-07-12/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 108 | 156 | 267 | 409 | Web Payments HTTP API 1.0 410 | 411 | 416 | 417 | 418 | 419 | 420 | 425 | 426 | 427 | 483 | 484 | 485 | 486 | 538 | 539 |

540 |

Abstract

541 |

542 | This document outlines how to register payment applications, create payment requests, and reply with payment responses using a standard HTTP API. 543 |

544 |

545 | 546 |

547 |

Status of This Document

548 |

549 | This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/. 550 |

551 | 552 | 553 |

554 | The most effective way to report issues and request features is to engage the working group via the Github 555 | issue tracker for the Working Group. Submitting issues as well as pull requests for changes to the specification are encouraged. 556 |

557 | 558 | 559 |

560 | This document was published by the Web Payments Working Group as a First Public Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to 561 | public-webpayments-comments@w3.org (subscribe, 562 | archives). All comments are welcome. 563 |

564 |

565 | Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. 566 |

567 |

568 | This document was produced by a group operating under the 569 | 5 February 2004 W3C Patent 570 | Policy. 571 | W3C maintains a public list of any patent 572 | disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains 573 | Essential 574 | Claim(s) must disclose the information in accordance with 575 | section 576 | 6 of the W3C Patent Policy. 577 |

578 |

This document is governed by the 1 September 2015 W3C Process Document. 579 |

580 | 581 |

582 | 604 | 605 | 606 | 607 | 608 |

609 | 610 |

1. Introduction

611 |

This section is non-normative.

612 | 613 |

614 | This HTTP API enables a web application to initiate payment for a product or service by responding with an HTTP 402 Payment Required response and enough data to initiate and complete a payment flow. The implementation of this feature is expected to be implemented by any HTTP server and client that is interested in executing payments. 615 |

616 | 617 |

618 |

1.1 How to Read this Document

619 |

This section is non-normative.

620 | 621 |

This document is a detailed specification for a HyperText Transfer Protocol application programming interface (HTTP API) for executing payments via an HTTP client and server. The document is primarily intended for the following audiences: 622 |

623 | 624 |

Software developers who want to understand the design decisions and algorithms behind the API.
Software developers who want to implement the API.

628 |

629 | 630 |

631 |

1.2 Terminology

632 | 633 |

634 |

635 | 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: 636 |

637 | 638 |

payee

An entity that receives funds as required by a transaction.

payer

An entity that provides a source of funds as required by a transaction. 702 |

payment

[ECB] in a strict sense, a payment is a transfer of funds which discharges an obligation on the part of a payer vis-a-vis a payee. However, in a technical or statistical sense, it is often used as a synonym for transfer order

payment app

A payment app is a component able to process a payment 711 | request and return a payment response.

payment mediator

[EXPERIMENTAL] The payment mediator fulfills a number of roles: 728 | 729 |

731 | It helps determine which payer payment apps can be used to fulfill the payment request given the payee's accepted payment methods. 732 |
734 | It helps the payer choose a payment app (typically with explicit interaction or prior consent). 735 |
737 | It passes payment request data to the payer's selected payment app. 738 |

740 | 741 | A payment mediator thus co-ordinates the flow of messages between the payee, payer, and selected payment app. 742 |

payment method

[EXPERIMENTAL] A way of paying. A system and set of rules for payments. A payment app may support one or more payment methods. For example, Visa, Mastercard, American Express, bobspay.com are payment methods.

payment method data

[EXPERIMENTAL] The data describing an instance of a payment method. For example, for the Visa payment method this might be the card primary account number (PAN), expiry date, and CVV.

753 | payment method identifier

A string that uniquely identifies a payment method that a user can use to complete a transaction.

payment request

A request from a payee to be paid. It contains the details of what to pay and how the payment can be made. How the payment can be made is specified as a list of payment method 776 | identifiers. The payment request MUST contain all of the 777 | payment method data required for each payment method identified in it's set of supported payment methods.

payment response

A response to a payment request (normally the result of processing by a payment app). The content of a payment response will be dependant on how the payment is being processed. 794 |

848 |

849 | 850 |

851 | 852 |

853 | 854 |

855 | 856 |

2. Payment Flow Overview

857 | 858 |

859 | The diagram below outlines a basic HTTP client payment flow with no errors. The basic flow starts out with the payer optionally accessing a protected resource and being notified that payment is required. The payee provides a URL where a payment request for the resource can be fetched. The payer fetches the payment request, selects a payment app, and sends the request on to the appropriate 860 | payment app for processing. The payment app initiates the payment and sends a payment response back to the payer. The payer then forwards the payment response back to the payee. If there are no errors, the payee then grants access to the resource that was purchased. 861 |

862 | 863 |

Basic tokenized card payment flow — Fig. 1 866 | - A basic tokenized card payment flow. 867 |

869 | 870 |

871 |

Issue 1

872 |

873 | The flow above reflects a pull-based tokenized card payment scenario. There are other flows, like push-based flows, that we may want to demonstrate in this specification as well. Is a tokenized pull-based flow the best exemplary flow to use when introducing the reader to the HTTP API? 874 |

875 |

876 | 877 |

878 | 879 |

880 | 881 |

3. Detailed Payment Flow

882 | 883 |

884 |

Issue 2

885 |

886 | It may be a good idea to return the payment request with the 402 response. The concern is that this would be a misrepresentation of the resource. The counter-argument is that a client shouldn't interpret a 402 response as the resource, and since 402 has not been formally defined yet, we could define it to always come with a payment request response. 887 |

888 |

889 | 890 |

892 | The payee's web page requests payment by responding with a 402 Payment Required response code and a URL encoded in the Location header to fetch the request from. 893 |
895 | The payment mediator fetches the request from the URL specified in the Location header in the previous step. 896 |
898 | The payment mediator scans the list of previously registered payment apps and finds matches against paymentTerms in the payment request. 899 |
901 | A payment app is selected by the payment mediator or the payer. The process MAY consist of one or more of the following steps: 902 | 903 |
904 |
Issue 3
905 |
906 | This payment app selection process should probably be moved out into a separate 907 | payment mediator specification and referenced from this specification. 908 |
909 |
910 | 911 |
1. 913 | If there is only one app that matches, that is automatically set to the selected payment app. 914 |
2. 916 | If there is a pre-existing preference set by the payer that narrows the selection of the payment app to one match, the match is set to the 917 | selected payment app. 918 |
3. 920 | If there is more than one potential match, the payer is asked which app they would like to use and the selection is set to the 921 | selected payment app 922 |
4. 924 | If there are no matches, the payer is notified and may be taken to an alternate flow where a matching payment app is acquired. 925 |
927 |
929 | If the payment app does not require the payment flow to switch to a 3rd party payment processor (e.g., cryptocurrency), then the payment response is generated locally and the payee's software is notified. 930 | 931 |
932 |
Issue 4
933 |
934 | Steps 5, 6, and 7 are intended to provide for various flows envisioned by the Web Payments ecosystem. This algorithm is merely a starting point, is very much a work in progress, and is not asserted to be correct at present: 935 | 936 |
1. 938 | Let "selectedApp" be the payment app selected by the payment mediator. 939 |
2. 941 | Let "selectedMethod" be the payment method provided by the payee and selected by the payer. 942 |
3. 944 | If selectedMethod.paymentRequestService exists, re-direct the user there (payee-based PSP). 945 |
4. 947 | If selectedApp.paymentRequestService exists, re-direct the user there (payer-based PSP). 948 |
5. 950 | Otherwise, the payment response can be generated locally (local PSP - Bitcoin and others). 951 |
953 | 954 |
955 |
956 |
958 | If the app requires the payment flow to switch to a 3rd party payer payment processor (e.g., push-payment like a PayPal/Google Wallet-like app, ACH, ISO20022 style app): 959 |
1. 961 | The payment mediator forwards the request, via an HTTP POST to the 962 | paymentRequestService in the payment app for approval. 963 |
965 |
967 | If the app requires the payment flow to switch to a 3rd party payee payment processor (e.g., pull-payment like non-EMV magstripe credit card with embossed PAN and CVV2, or tokenized credit card): 968 |
1. 970 | The payment mediator forwards the request on via an HTTP POST to the paymentRequestService in the 971 | paymentTerms (note that the payee sets this, not the payment app). 972 |
974 |
976 | The payment flow is then transferred to the entity that is going to generate the payment acknowledgment (locally installed payment app, payee's payment service provider, or payer's payment service provider). 977 |
979 | Once the entity in control of the payment flow finalizes the 980 | payment response, even if the message is to acknowledge that the payment failed, the payment response is generated and the payer's payment mediator is notified via an HTTP 200 success code. 981 | 982 |
983 |
Issue 5
984 |
985 | Returning an HTTP status code of 200 when a payment fails is controversial. The current thinking seems to be that 200 is the right thing to do as the message was processed successfully (that's what the 200 is referring to). The result of processing the message, however, has nuance that may be dependent on the payment method used. As a thought experiment, what should the HTTP response code be in the following cases: 986 | 987 |
1. 989 | Funds transfer was initiated and completed. Clearly 200, right? 990 |
2. 992 | Funds transfer was initiated, but network delay may cause it to fail at a later point in time (ACH, etc.). 102 or 202? 993 |
3. 995 | Request for subscription was noted and is setup, but no funds were moved. 200? 996 |
4. 998 | Payment submitted to network, but network didn't respond with an auth code. 504? 999 |
5. 1001 | Cryptocurrency payment was submitted to network but a fork has been detected and it is unclear if we're on the winning or losing fork. 102 or 202? 1002 |
1005 | 1006 | There are not enough HTTP status codes to try and enumerate the nuanced potential outcomes so the best we can do at present (it seems) is to just report on whether or not the payment request was processed successfully or not and let the payee determine if the outcome of the transaction was valid from their viewpoint. In many nuanced cases, it's up to the payer to decide if it was "successful" or not (like waiting on a certain number of acknowledgments from a blockchain, for example). 1007 |
1008 |
1009 |

1011 |

1012 |

Issue 6

1013 |

1014 | Melvin Carvalho has also raised an issue noting that we may not want to use 402 and the Location header, but rather an additional HTTP header called 1015 | Payment that is compatible with multiple 4xx error conditions. 1016 |

1017 |

1018 |

1019 | 1020 |

1021 | 1022 |

4. Web Payment Operations

1023 | 1024 |

1025 |

4.1 Payment app Registration

1026 |

1028 | The payer's HTTP client navigates to a payment service provider website and authenticates itself to fetch a payment app to register: 1029 |

1030 |

Example 1: Authenticated GET of payment app

GET /apps/visa HTTP/1.1
1031 | Host: mybank.example.org
1032 | Date: Tue, 07 Jun 2017 20:51:35 GMT
1033 | Accept: application/json
1034 | Authorization: Digest username="jdoe", realm="jane@mybank.example.org", ...

1035 |

1036 |

Issue 7

1037 |

1038 | While digest authentication is used above, more advanced authentication schemes may also be employed. For example, the mechanism below uses HTTP Signatures and public/private key cryptography to authenticate the client with the server: 1039 |

1040 |

Example 2: Authenticated GET of payment app using HTTP Signatures

GET /apps/visa HTTP/1.1
1041 | Host: mybank.example.org
1042 | Date: Tue, 07 Jun 2017 20:51:35 GMT
1043 | Accept: application/json
1044 | Authorization: Signature keyId="https://mybank.example.org/people/jane/keys/42",
1045 |    algorithm="rsa-sha256",headers="(request-target) host date",
1046 |    signature="jgSqYK0yKclIHfF9zdApVEbDp5eqj8C4i4X76pE+XHoxugXv7qnVrGR+30bmB
1047 |               gtpR39I4utq17s9ghz/2QFVxlnToYAvbSVZJ9ulLd1HQBugO0jOyn9sXOtcN7
1048 |               uNHBjqNCqUsnt0sw/cJA6B6nJZpyNqNyAXKdxZZItOuhIs78w="

1049 |

1050 |

1051 |

1053 | The payment service provider MUST respond with the payment app or an HTTP error code. If successful, something like the following will be returned: 1054 |

1055 |

Example 3: Successful retrieval of payment app

HTTP/1.1 200 OK
1056 | Date: Tue, 07 Jun 2017 20:51:36 GMT
1057 | Content-Type: application/json
1058 | Content-Length: 412
1059 | 
1060 | {
1061 |   "type": "PaymentApp",
1062 |   "paymentMethod": "https://payments.example.org/payment-schemes#Visa",
1063 |   "label": "ExampleBank Visa Card",
1064 |   "paymentRequestService": "https://mybank.example.org/services/cards/2745023475"
1065 | }

1066 |

1068 |

1069 | 1070 |

1071 |

4.2 Initiating a Payment Request

1072 |

1074 | The payer's HTTP client accesses a resource that requires payment: 1075 |
1076 |
Example 4: Payer requests a resource that requires a payment
```
GET /movies/dr-strangelove HTTP/1.1
1077 | Host: videos.example.com
1078 | Date: Tue, 07 Jun 2017 21:31:35 GMT
```
1079 |
1081 | The payee's HTTP server responds with a 402 Payment Required response and the URL where the payment request may be fetched via the 1082 | Location header: 1083 |
1084 |
Example 5: Payee responds with 402 Payment Required
```
HTTP/1.1 402 Payment Required
1085 | Date: Tue, 07 Jun 2017 21:31:36 GMT
1086 | Location: https://videos.example.com/payment-requests/dr-strangelove
```
1087 | 1088 |
1089 |
Issue 8
1090 |
1091 | It's currently not clear if having an extra round-trip (steps 2 and 3) is beneficial. The alternative is to respond with an HTTP 402 and the payment request (step 4) when the GET for the initial resource is performed. This removes the need to do an extra GET at the expense of providing a little more flexibility wrt. the location of the payment request service. For example, having the Location header enables software developers to split media servers from payment processing servers. That said, there are techniques to do this today without the extra layer of indirection. 1092 |
1093 |
1094 |
1095 |
Issue 9
1096 |
1097 | The model described here does not yet take into account "push" payments. While there is nothing in this design that precludes payments pushed from a payer to a payee, explicit support and an example that illustrates this need to be included in the document. 1098 |
1099 |
1100 |
1102 | The payer's HTTP client accesses the payment request resource: 1103 |
1104 |
Example 6: Payer requests a payment request
```
GET /payment-requests/dr-strangelove HTTP/1.1
1105 | Host: videos.example.com
1106 | Date: Tue, 07 Jun 2017 21:31:37 GMT
```
1107 |

1109 | The payee server provides the payment request. 1110 |

1111 |

Example 7: Payee provides the payment request

HTTP/1.1 200 OK
1112 | Date: Tue, 07 Jun 2017 21:31:38 GMT
1113 | Content-Type: application/json
1114 | Content-Length: 873
1115 | 
1116 | {
1117 |   "type": "PaymentRequest",
1118 |   "description": "Payment for Dr. Strangelove",
1119 |   "paymentTerms": {
1120 |     "paymentMethod": "https://payments.example.org/payment-schemes#Visa",
1121 |     "paymentAmount": {
1122 |       "amount": "2.99",
1123 |       "currency": "USD"
1124 |     }
1125 |   },
1126 |   "paymentCompleteService": "https://videos.example.com/services/paymentComplete?transaction=923847298"
1127 | }

1128 |

1130 |

1131 | 1132 |

1133 |

4.3 Generating a Payment Response

1134 |

1136 | A payment app is selected by the payment mediator to process the payment request generated in the previous section. 1137 |

1139 | The paymentRequestService URL, provided in the payment app or the payment request, is used as the HTTP POST endpoint. The payment service provider that is providing the payment app interface receives the payment request, authenticates the payer, and proceeds with the payment: 1140 |

1141 |

Example 8: The payment request is POSTed by the payment mediator for processing at the payment app

POST /services/cards/2745023475 HTTP/1.1
1142 | Host: mybank.example.org
1143 | Date: Tue, 07 Jun 2017 20:51:35 GMT
1144 | Accept: application/json
1145 | 
1146 | {
1147 |   "type": "PaymentRequest",
1148 |   "description": "Payment for Dr. Strangelove",
1149 |   "paymentTerms": {
1150 |     "paymentMethod": "https://payments.example.org/payment-schemes#Visa",
1151 |     "paymentAmount": {
1152 |       "amount": "2.99",
1153 |       "currency": "USD"
1154 |     }
1155 |   },
1156 |   "paymentCompleteService": "https://videos.example.com/services/paymentComplete?transaction=923847298"
1157 | }

1158 |

1160 | The payment service provider generates a payment response message that contains enough information to verify that the transaction has completed in success or failure: 1161 |

1162 |

Example 9: The payment response is provided back to the payment mediator from the payment app

HTTP/1.1 200 OK
1163 | Date: Tue, 07 Jun 2017 20:51:36 GMT
1164 | Content-Type: application/json
1165 | Content-Length: 623
1166 | 
1167 | {
1168 |   "type": "PaymentResponse",
1169 |   "description": "Payment to ExampleMerch for widgets",
1170 |   "paymentTerms": {
1171 |     "paymentMethod": "https://payments.example.org/payment-schemes#Visa",
1172 |     "status": "authorized",
1173 |     "token": "10025AB",
1174 |     "paymentAmount": {
1175 |       "amount": "2.99",
1176 |       "currency": "USD"
1177 |     }
1178 |   }
1179 | }

1180 |

1182 | The payment response is then relayed back to the payee by the 1183 | payment mediator using the paymentCompleteService URL provided in the initial payment request: 1184 |

1185 |

Example 10: The payment response is relayed back to the payee by the payment mediator

POST /services/paymentComplete?transaction=923847298 HTTP/1.1
1186 | Host: videos.example.com
1187 | Date: Tue, 07 Jun 2017 20:51:35 GMT
1188 | Content-Type: application/json
1189 | 
1190 | {
1191 |   "type": "PaymentResponse",
1192 |   "description": "Payment to ExampleMerch for widgets",
1193 |   "paymentTerms": {
1194 |     "paymentMethod": "https://payments.example.org/payment-schemes#Visa",
1195 |     "status": "authorized",
1196 |     "token": "10025AB",
1197 |     "paymentAmount": {
1198 |       "amount": "2.99",
1199 |       "currency": "USD"
1200 |     }
1201 |   }
1202 | }

1203 |

1205 | The payee validates the payment response, sets the appropriate access control for the resource, and re-directs the payer to the resource: 1206 |
1207 |
Example 11: The payee grants access to the initially requested resource
```
HTTP/1.1 302 Found
1208 | Date: Tue, 07 Jun 2017 20:51:36 GMT
1209 | Cookie: movieToken=2983fhfa92h3iuhf908723nkjcsdh923; Expires=Tue, 08 Jun 2017 20:51:40 GMT
1210 | Location: /movies/dr-strangelove
```
1211 |

1213 |

1214 | 1215 |

1216 |

4.4 Security and Privacy Considerations

1217 | 1218 |

1219 |

Issue 10

1220 |

1221 | The Working Group is currently in the early stages of the analysis of the security and privacy implications of this specification. The ongoing analysis can be accessed via the 1222 | 1223 | Web Payments Working Group Security and Privacy Considerations wiki 1224 | . 1225 |

1226 |

1227 |

1228 | 1229 |

1230 | 1231 |

1232 | 1233 |

A. Acknowledgements

1234 |

This section is non-normative.

1235 | 1236 |

1237 | The editor would like to thank members of the Web Payments Community Group, Web Payments Interest Group, and Web Payments Working Group for the ideas and discussion that culminated in this specification. In addition, thank you to the to the following individuals, in order of their first name, for their input on this specification: LIST_TBD 1238 |

1239 | 1240 |

1241 | 1242 | 1243 | 1244 | 1245 | 1246 | 1247 | -------------------------------------------------------------------------------- /WD/2016-07-12/spec.css: -------------------------------------------------------------------------------- 1 | ol.algorithm { counter-reset:numsection; list-style-type: none; } 2 | ol.algorithm li { margin: 0.5em 0; } 3 | ol.algorithm li:before { font-weight: bold; counter-increment: numsection; content: counters(numsection, ".") ") "; } 4 | 5 | ol.clear-algorithm { list-style-type: decimal; border-left: 0px;} 6 | ol.clear-algorithm li { margin: 0.5em 0; } 7 | ol.clear-algorithm li:before { font-weight: normal; counter-increment: nonsection; content: none; } 8 | -------------------------------------------------------------------------------- /WD/2016-09-15/index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | 6 | 7 | 108 | 156 | 267 | 413 | Web Payments HTTP API 1.0 414 | 415 | 420 | 421 | 422 | 423 | 424 | 429 | 430 | 431 | 432 | 505 | 506 | 507 | 508 | 560 | 561 |

562 |

Abstract

563 |

564 | This document outlines how to register payment applications, create payment requests, and reply with payment responses using a standard HTTP API. 565 |

566 |

567 | 568 |

569 |

Status of This Document

570 |

571 | This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/. 572 |

573 | 574 | 575 |

576 | The most effective way to report issues and request features is to engage the working group via the Github 577 | issue tracker for the Working Group. Submitting issues as well as pull requests for changes to the specification are encouraged. 578 |

579 | 580 | 581 |

582 | This document was published by the Web Payments Working Group as a First Public Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to 583 | public-webpayments-comments@w3.org (subscribe, 584 | archives). All comments are welcome. 585 |

586 |

587 | Publication as a First Public Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress. 588 |

589 |

590 | This document was produced by a group operating under the 591 | 5 February 2004 W3C Patent 592 | Policy. 593 | W3C maintains a public list of any patent 594 | disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains 595 | Essential 596 | Claim(s) must disclose the information in accordance with 597 | section 598 | 6 of the W3C Patent Policy. 599 |

600 |

This document is governed by the 1 September 2015 W3C Process Document. 601 |

602 | 603 |

604 | 631 | 632 | 633 | 634 | 635 |

636 | 637 |

1. Introduction

638 |

This section is non-normative.

639 | 640 |

641 | This HTTP API enables a web application to initiate payment for a product or service by responding with an HTTP 402 Payment Required response and enough data to initiate and complete a payment flow. The implementation of this feature is expected to be implemented by any HTTP server and client that is interested in executing payments. 642 |

643 | 644 |

645 |

1.1 How to Read this Document

646 |

This section is non-normative.

647 | 648 |

650 | 651 |

Software developers who want to understand the design decisions and algorithms behind the API.
Software developers who want to implement the API.

655 | 656 |

657 |

Note

658 |

659 | There are a number of Web Payments messages that are referenced and used in examples in this specification. The normative definition of these messages, as well as how to express them in a variety of syntaxes, is specified in [ 660 | WEBPAYMENTS-HTTP-MESSAGES]. 661 |

662 |

663 |

664 | 665 |

666 |

1.2 Terminology

667 | 668 |

669 |

Issue 3: HTTP API terminology needs to be refined

670 |

671 | The current terminology that is pulled into the HTTP API specification needs some simplification and alignment. 672 |

673 |

674 | 675 |

676 |

677 | 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: 678 |

679 | 680 |

payee

An entity that receives funds as required by a transaction.

payer

An entity that provides a source of funds as required by a transaction. 744 |

payment

payment app

A payment app is a component able to process a payment 753 | request and return a payment response.

payment mediator

[EXPERIMENTAL] The payment mediator fulfills a number of roles: 770 | 771 |

773 | It helps determine which payer payment apps can be used to fulfill the payment request given the payee's accepted payment methods. 774 |
776 | It helps the payer choose a payment app (typically with explicit interaction or prior consent). 777 |
779 | It passes payment request data to the payer's selected payment app. 780 |

782 | 783 | A payment mediator thus co-ordinates the flow of messages between the payee, payer, and selected payment app. 784 |

payment method

payment method data

[EXPERIMENTAL] The data describing an instance of a payment method. For example, for the Visa payment method this might be the card primary account number (PAN), expiry date, and CVV.

795 | payment method identifier

A string that uniquely identifies a payment method that a user can use to complete a transaction.

payment request

A request from a payee to be paid. It contains the details of what to pay and how the payment can be made. How the payment can be made is specified as a list of payment method 818 | identifiers. The payment request MUST contain all of the 819 | payment method data required for each payment method identified in it's set of supported payment methods.

payment response

A response to a payment request (normally the result of processing by a payment app). The content of a payment response will be dependant on how the payment is being processed. 836 |

890 |

891 | 892 |

893 | 894 |

895 | 896 |

897 | 898 |

2. Payment Flow Overview

899 | 900 |

901 | The diagram below outlines a basic HTTP client payment flow with no errors. The basic flow starts out with the payer optionally accessing a protected resource and being notified that payment is required. The payee provides a URL where a payment request for the resource can be fetched. The payer fetches the payment request, selects a payment app, and sends the request on to the appropriate 902 | payment app for processing. The payment app initiates the payment and sends a payment response back to the payer. The payer then forwards the payment response back to the payee. If there are no errors, the payee then grants access to the resource that was purchased. 903 |

904 | 905 |

911 | 912 |

913 |

Issue 4: Overview diagram may be misleading

914 |

915 | The flow above reflects a pull-based tokenized card payment scenario. There are other flows, like push-based flows, that we may want to demonstrate in this specification as well. Is a tokenized pull-based flow the best exemplary flow to use when introducing the reader to the HTTP API? 916 |

917 |

918 | 919 |

920 | 921 |

922 | 923 |

3. Detailed Payment Flow

924 | 925 |

926 |

Issue 5: Should PaymentRequest be returned via HTTP 402 response code?

927 |

928 | It may be a good idea to return the payment request with the 402 response. The concern is that this would be a misrepresentation of the resource. The counter-argument is that a client shouldn't interpret a 402 response as the resource, and since 402 has not been formally defined yet, we could define it to always come with a payment request response. 929 |

930 |

931 | 932 |

934 | The payee's web page requests payment by responding with a 402 Payment Required response code and a URL encoded in the Location header to fetch the request from. 935 |
937 | The payment mediator fetches the request from the URL specified in the Location header in the previous step. 938 |
940 | The payment mediator scans the list of previously registered payment apps and finds matches against paymentTerms in the payment request. 941 |
943 | A payment app is selected by the payment mediator or the payer. The process MAY consist of one or more of the following steps: 944 | 945 |
946 |
Issue 6: Payment App selection process should be in Payment App spec
947 |
948 | This payment app selection process should probably be moved out into a separate 949 | payment mediator specification and referenced from this specification. 950 |
951 |
952 | 953 |
1. 955 | If there is only one app that matches, that is automatically set to the selected payment app. 956 |
2. 958 | If there is a pre-existing preference set by the payer that narrows the selection of the payment app to one match, the match is set to the 959 | selected payment app. 960 |
3. 962 | If there is more than one potential match, the payer is asked which app they would like to use and the selection is set to the 963 | selected payment app 964 |
4. 966 | If there are no matches, the payer is notified and may be taken to an alternate flow where a matching payment app is acquired. 967 |
969 |
971 | If the payment app does not require the payment flow to switch to a 3rd party payment processor (e.g., cryptocurrency), then the payment response is generated locally and the payee's software is notified. 972 | 973 |
974 |
Issue 7: Further clarify the branching options for the payment flow
975 |
976 | Steps 5, 6, and 7 are intended to provide for various flows envisioned by the Web Payments ecosystem. This algorithm is merely a starting point, is very much a work in progress, and is not asserted to be correct at present: 977 | 978 |
1. 980 | Let "selectedApp" be the payment app selected by the payment mediator. 981 |
2. 983 | Let "selectedMethod" be the payment method provided by the payee and selected by the payer. 984 |
3. 986 | If selectedMethod.paymentRequestService exists, re-direct the user there (payee-based PSP). 987 |
4. 989 | If selectedApp.paymentRequestService exists, re-direct the user there (payer-based PSP). 990 |
5. 992 | Otherwise, the payment response can be generated locally (local PSP - Bitcoin and others). 993 |
995 | 996 |
997 |
998 |
1000 | If the app requires the payment flow to switch to a 3rd party payer payment processor (e.g., push-payment like a PayPal/Google Wallet-like app, ACH, ISO20022 style app): 1001 |
1. 1003 | The payment mediator forwards the request, via an HTTP POST to the 1004 | paymentRequestService in the payment app for approval. 1005 |
1007 |
1009 | If the app requires the payment flow to switch to a 3rd party payee payment processor (e.g., pull-payment like non-EMV magstripe credit card with embossed PAN and CVV2, or tokenized credit card): 1010 |
1. 1012 | The payment mediator forwards the request on via an HTTP POST to the paymentRequestService in the 1013 | paymentTerms (note that the payee sets this, not the payment app). 1014 |
1016 |
1018 | The payment flow is then transferred to the entity that is going to generate the payment acknowledgment (locally installed payment app, payee's payment service provider, or payer's payment service provider). 1019 |
1021 | Once the entity in control of the payment flow finalizes the 1022 | payment response, even if the message is to acknowledge that the payment failed, the payment response is generated and the payer's payment mediator is notified via an HTTP 200 success code. 1023 | 1024 |
1025 |
Issue 8: What is the appropriate HTTP response code for a failed payment?
1026 |
1027 | Returning an HTTP status code of 200 when a payment fails is controversial. The current thinking seems to be that 200 is the right thing to do as the message was processed successfully (that's what the 200 is referring to). The result of processing the message, however, has nuance that may be dependent on the payment method used. As a thought experiment, what should the HTTP response code be in the following cases: 1028 | 1029 |
1. 1031 | Funds transfer was initiated and completed. Clearly 200, right? 1032 |
2. 1034 | Funds transfer was initiated, but network delay may cause it to fail at a later point in time (ACH, etc.). 102 or 202? 1035 |
3. 1037 | Request for subscription was noted and is setup, but no funds were moved. 200? 1038 |
4. 1040 | Payment submitted to network, but network didn't respond with an auth code. 504? 1041 |
5. 1043 | Cryptocurrency payment was submitted to network but a fork has been detected and it is unclear if we're on the winning or losing fork. 102 or 202? 1044 |
1047 | 1048 | There are not enough HTTP status codes to try and enumerate the nuanced potential outcomes so the best we can do at present (it seems) is to just report on whether or not the payment request was processed successfully or not and let the payee determine if the outcome of the transaction was valid from their viewpoint. In many nuanced cases, it's up to the payer to decide if it was "successful" or not (like waiting on a certain number of acknowledgments from a blockchain, for example). 1049 |
1050 |
1051 |

1053 |

1054 |

Issue 9: Prefer new 'Payment' header instead of 402 response code?

1055 |

1056 | Melvin Carvalho has also raised an issue noting that we may not want to use 402 and the Location header, but rather an additional HTTP header called 1057 | Payment that is compatible with multiple 4xx error conditions. 1058 |

1059 |

1060 |

1061 | 1062 |

1063 | 1064 |

4. Web Payment Operations

1065 | 1066 |

1067 |

4.1 Payment app Registration

1068 |

1070 | The payer's HTTP client navigates to a payment service provider website and authenticates itself to fetch a payment app to register: 1071 |

1072 |

Example 1: Authenticated GET of payment app

GET /apps/visa HTTP/1.1
1073 | Host: mybank.example.org
1074 | Date: Tue, 07 Jun 2017 20:51:35 GMT
1075 | Accept: application/json
1076 | Authorization: Digest username="jdoe", realm="jane@mybank.example.org", ...

1077 |

1078 |

Issue 10: What other authentication schemes should be supported for Payment App registration?

1079 |

1080 | While digest authentication is used above, more advanced authentication schemes may also be employed. For example, the mechanism below uses HTTP Signatures and public/private key cryptography to authenticate the client with the server: 1081 |

1082 |

Example 2: Authenticated GET of payment app using HTTP Signatures

GET /apps/visa HTTP/1.1
1083 | Host: mybank.example.org
1084 | Date: Tue, 07 Jun 2017 20:51:35 GMT
1085 | Accept: application/json
1086 | Authorization: Signature keyId="https://mybank.example.org/people/jane/keys/42",
1087 |    algorithm="rsa-sha256",headers="(request-target) host date",
1088 |    signature="jgSqYK0yKclIHfF9zdApVEbDp5eqj8C4i4X76pE+XHoxugXv7qnVrGR+30bmB
1089 |               gtpR39I4utq17s9ghz/2QFVxlnToYAvbSVZJ9ulLd1HQBugO0jOyn9sXOtcN7
1090 |               uNHBjqNCqUsnt0sw/cJA6B6nJZpyNqNyAXKdxZZItOuhIs78w="

1091 |

1092 |

1093 |

1095 | The payment service provider MUST respond with the payment app or an HTTP error code. If successful, something like the following will be returned: 1096 |

1097 |

Example 3: Successful retrieval of payment app

HTTP/1.1 200 OK
1098 | Date: Tue, 07 Jun 2017 20:51:36 GMT
1099 | Content-Type: application/json
1100 | Content-Length: 412
1101 | 
1102 | {
1103 |   "type": "PaymentApp",
1104 |   "paymentMethod": "https://payments.example.org/payment-schemes#Visa",
1105 |   "label": "ExampleBank Visa Card",
1106 |   "paymentRequestService": "https://mybank.example.org/services/cards/2745023475"
1107 | }

1108 |

1110 |

1111 | 1112 |

1113 |

4.2 Initiating a Payment Request

1114 |

1116 | The payer's HTTP client accesses a resource that requires payment: 1117 |
1118 |
Example 4: Payer requests a resource that requires a payment
```
GET /movies/dr-strangelove HTTP/1.1
1119 | Host: videos.example.com
1120 | Date: Tue, 07 Jun 2017 21:31:35 GMT
```
1121 |
1123 | The payee's HTTP server responds with a 402 Payment Required response and the URL where the payment request may be fetched via the 1124 | Location header: 1125 |
1126 |
Example 5: Payee responds with 402 Payment Required
```
HTTP/1.1 402 Payment Required
1127 | Date: Tue, 07 Jun 2017 21:31:36 GMT
1128 | Location: https://videos.example.com/payment-requests/dr-strangelove
```
1129 | 1130 |
1131 |
Issue 11: Should getting a PaymentRequest result in an extra round trip?
1132 |
1133 | It's currently not clear if having an extra round-trip (steps 2 and 3) is beneficial. The alternative is to respond with an HTTP 402 and the payment request (step 4) when the GET for the initial resource is performed. This removes the need to do an extra GET at the expense of providing a little more flexibility wrt. the location of the payment request service. For example, having the Location header enables software developers to split media servers from payment processing servers. That said, there are techniques to do this today without the extra layer of indirection. 1134 |
1135 |
1136 |
1137 |
Issue 12: Push-based payments should be documented in the HTTP API
1138 |
1139 | The model described here does not explicitly mention "push" payments even though they are supported. While there is nothing in this design that precludes payments pushed from a payer to a payee, it may be helpful to point out explicit support for the scenario as well as an example that illustrates this feature. 1140 |
1141 |
1142 |
1144 | The payer's HTTP client accesses the payment request resource: 1145 |
1146 |
Example 6: Payer requests a payment request
```
GET /payment-requests/dr-strangelove HTTP/1.1
1147 | Host: videos.example.com
1148 | Date: Tue, 07 Jun 2017 21:31:37 GMT
```
1149 |

1151 | The payee server provides the payment request. 1152 |

1153 |

Example 7: Payee provides the payment request

HTTP/1.1 200 OK
1154 | Date: Tue, 07 Jun 2017 21:31:38 GMT
1155 | Content-Type: application/json
1156 | Content-Length: 873
1157 | 
1158 | {
1159 |   "type": "PaymentRequest",
1160 |   "description": "Payment for Dr. Strangelove",
1161 |   "paymentTerms": {
1162 |     "paymentMethod": "https://payments.example.org/payment-schemes#Visa",
1163 |     "paymentAmount": {
1164 |       "amount": "2.99",
1165 |       "currency": "USD"
1166 |     }
1167 |   },
1168 |   "paymentCompleteService": "https://videos.example.com/services/paymentComplete?transaction=923847298"
1169 | }

1170 |

1172 |

1173 | 1174 |

1175 |

4.3 Generating a Payment Response

1176 |

1178 | A payment app is selected by the payment mediator to process the payment request generated in the previous section. 1179 |

1181 | The paymentRequestService URL, provided in the payment app or the payment request, is used as the HTTP POST endpoint. The payment service provider that is providing the payment app interface receives the payment request, authenticates the payer, and proceeds with the payment: 1182 |

1183 |

Example 8: The payment request is POSTed by the payment mediator for processing at the payment app

POST /services/cards/2745023475 HTTP/1.1
1184 | Host: mybank.example.org
1185 | Date: Tue, 07 Jun 2017 20:51:35 GMT
1186 | Accept: application/json
1187 | 
1188 | {
1189 |   "type": "PaymentRequest",
1190 |   "description": "Payment for Dr. Strangelove",
1191 |   "paymentTerms": {
1192 |     "paymentMethod": "https://payments.example.org/payment-schemes#Visa",
1193 |     "paymentAmount": {
1194 |       "amount": "2.99",
1195 |       "currency": "USD"
1196 |     }
1197 |   },
1198 |   "paymentCompleteService": "https://videos.example.com/services/paymentComplete?transaction=923847298"
1199 | }

1200 |

1202 | The payment service provider generates a payment response message that contains enough information to verify that the transaction has completed in success or failure: 1203 |

1204 |

Example 9: The payment response is provided back to the payment mediator from the payment app

HTTP/1.1 200 OK
1205 | Date: Tue, 07 Jun 2017 20:51:36 GMT
1206 | Content-Type: application/json
1207 | Content-Length: 623
1208 | 
1209 | {
1210 |   "type": "PaymentResponse",
1211 |   "description": "Payment to ExampleMerch for widgets",
1212 |   "paymentTerms": {
1213 |     "paymentMethod": "https://payments.example.org/payment-schemes#Visa",
1214 |     "status": "authorized",
1215 |     "token": "10025AB",
1216 |     "paymentAmount": {
1217 |       "amount": "2.99",
1218 |       "currency": "USD"
1219 |     }
1220 |   }
1221 | }

1222 |

1224 | The payment response is then relayed back to the payee by the 1225 | payment mediator using the paymentCompleteService URL provided in the initial payment request: 1226 |

1227 |

Example 10: The payment response is relayed back to the payee by the payment mediator

POST /services/paymentComplete?transaction=923847298 HTTP/1.1
1228 | Host: videos.example.com
1229 | Date: Tue, 07 Jun 2017 20:51:35 GMT
1230 | Content-Type: application/json
1231 | 
1232 | {
1233 |   "type": "PaymentResponse",
1234 |   "description": "Payment to ExampleMerch for widgets",
1235 |   "paymentTerms": {
1236 |     "paymentMethod": "https://payments.example.org/payment-schemes#Visa",
1237 |     "status": "authorized",
1238 |     "token": "10025AB",
1239 |     "paymentAmount": {
1240 |       "amount": "2.99",
1241 |       "currency": "USD"
1242 |     }
1243 |   }
1244 | }

1245 |

1247 | The payee validates the payment response, sets the appropriate access control for the resource, and re-directs the payer to the resource: 1248 |
1249 |
Example 11: The payee grants access to the initially requested resource
```
HTTP/1.1 302 Found
1250 | Date: Tue, 07 Jun 2017 20:51:36 GMT
1251 | Cookie: movieToken=2983fhfa92h3iuhf908723nkjcsdh923; Expires=Tue, 08 Jun 2017 20:51:40 GMT
1252 | Location: /movies/dr-strangelove
```
1253 |

1255 |

1256 | 1257 |

1258 |

4.4 Security and Privacy Considerations

1259 | 1260 |

1261 |

Issue 13: What are the security and privacy implications of the HTTP API?

1262 |

1263 | The Working Group is currently in the early stages of the analysis of the security and privacy implications of this specification. The ongoing analysis can be accessed via the 1264 | 1265 | Web Payments Working Group Security and Privacy Considerations wiki 1266 | . 1267 |

1268 |

1269 |

1270 | 1271 |

1272 | 1273 |

1274 | 1275 |

A. Acknowledgements

1276 |

This section is non-normative.

1277 | 1278 |

1279 | The editor would like to thank members of the Web Payments Community Group, Web Payments Interest Group, and Web Payments Working Group for the ideas and discussion that culminated in this specification. In addition, thank you to the to the following individuals, in order of their first name, for their input on this specification: LIST_TBD 1280 |

1281 | 1282 |

1283 | 1284 | 1285 | 1286 |

1287 | 1288 |

B. References

1289 | 1290 |

1291 |

B.1 Normative references

1292 |

[WEBPAYMENTS-HTTP-MESSAGES]: Manu Sporny; Dave Longley; Shane McCarron. W3C. Web Payments HTTP Messages 1.0. W3C First Public Working Draft. URL: https://www.w3.org/TR/webpayments-http-messages/ 1294 |

1296 |

1297 |

1298 | 1299 | 1300 | 1301 | -------------------------------------------------------------------------------- /WD/2016-09-15/spec.css: -------------------------------------------------------------------------------- 1 | ol.algorithm { counter-reset:numsection; list-style-type: none; } 2 | ol.algorithm li { margin: 0.5em 0; } 3 | ol.algorithm li:before { font-weight: bold; counter-increment: numsection; content: counters(numsection, ".") ") "; } 4 | 5 | ol.clear-algorithm { list-style-type: decimal; border-left: 0px;} 6 | ol.clear-algorithm li { margin: 0.5em 0; } 7 | ol.clear-algorithm li:before { font-weight: normal; counter-increment: nonsection; content: none; } 8 | -------------------------------------------------------------------------------- /index.html: -------------------------------------------------------------------------------- 1 | 2 | 3 | 4 | 5 | Web Payments HTTP API 1.0 6 | 7 | 12 | 13 | 15 | 16 | 17 | 114 | 119 | 120 | 121 |

122 |

123 | This document outlines how to register payment applications, create 124 | payment requests, and reply with payment responses using a standard 125 | HTTP API. 126 |

127 |

128 |

129 |

130 | This section describes the status of this document at the time of 131 | its publication. Other documents may supersede this document. A list of 132 | current W3C publications and the latest revision of this technical 133 | report can be found in the W3C technical reports index at 134 | http://www.w3.org/TR/. 135 |

136 |

137 | The Web Payments 138 | Working Group has discontinued work on this document, although 139 | other groups may take up this work in the future. The specification 140 | should not be referenced in this form or implemented as-is. 141 |

142 |

143 |

144 | Looking for the Specification? 145 |

146 |

147 | Please see the 15 149 | September 2016 draft of this specification for the full content 150 | at the time that the Working Group discontinued its work. 151 |

152 |

153 |

154 |

155 | Background to Publication as a Note 156 |

157 |

158 | The Web Payments Working Group first published this document as a 159 | Working 161 | Draft in September 2016. At the time, the Working Group had 162 | already focused on in-browser payments for a year and projected that 163 | its browser focus would continue through the bulk of its (initial) 165 | charter. The Working Group made a decision to publish this 166 | document (along with Web Payments HTTP 168 | Messages 1.0) to socialize it more visibly, and potentially to 169 | align it with Payment Request API as 171 | it matured. 172 |

173 |

174 | As the Working Group neared the end of its initial charter, the group 175 | discussed whether to continue to list out-of-browser payments as in 176 | scope in its second charter. Participants at the Working Group's 177 | face-to-face 179 | meeting in November 2017 expressed consensus to publish this 180 | document as a group Note rather than advance it to Recommendation, 181 | but to maintain discussion of message structure in charter scope. 182 |

183 |

184 | This document was published by the Web Payments Working Group as a 186 | Working Group Note. If you wish to make comments regarding this 187 | document, please send them to public-webpayments-comments@w3.org (archive). 189 | All comments are welcome. 190 |

191 |

192 |

193 |

194 | Additional Information 195 |

196 |

197 | Publication as a Working Group Note does not imply endorsement by the 198 | W3C Membership. This is a draft document and may be updated, replaced 199 | or obsoleted by other documents at any time. It is inappropriate to 200 | cite this document as other than work in progress. 201 |

202 |

203 | This document was produced by a group operating under the W3C Patent Policy. 205 | W3C maintains a public list of any 207 | patent disclosures made in connection with the deliverables of 208 | the group; that page also includes instructions for disclosing a 209 | patent. An individual who has actual knowledge of a patent which the 210 | individual believes contains Essential 212 | Claim(s) must disclose the information in accordance with 213 | 214 | section 6 of the W3C Patent Policy. 215 |

216 |

217 | This document is governed by the 1 March 2017 W3C Process 219 | Document. 220 |

221 |

222 |

223 | 224 | 225 | -------------------------------------------------------------------------------- /spec.css: -------------------------------------------------------------------------------- 1 | ol.algorithm { counter-reset:numsection; list-style-type: none; } 2 | ol.algorithm li { margin: 0.5em 0; } 3 | ol.algorithm li:before { font-weight: bold; counter-increment: numsection; content: counters(numsection, ".") ") "; } 4 | 5 | ol.clear-algorithm { list-style-type: decimal; border-left: 0px;} 6 | ol.clear-algorithm li { margin: 0.5em 0; } 7 | ol.clear-algorithm li:before { font-weight: normal; counter-increment: nonsection; content: none; } 8 | -------------------------------------------------------------------------------- /utils.js: -------------------------------------------------------------------------------- 1 | // We should be able to remove terms that are not actually 2 | // referenced from the common definitions 3 | // 4 | // the termlist is in a block of class "termlist", so make sure that 5 | // has an ID and put that ID into the termLists array so we can 6 | // interrogate all of the included termlists later. 7 | var termNames = [] ; 8 | var termLists = [] ; 9 | var termsReferencedByTerms = [] ; 10 | 11 | function restrictReferences(utils, content) { 12 | var base = document.createElement("div"); 13 | base.innerHTML = content; 14 | 15 | // New new logic: 16 | // 17 | // 1. build a list of all term-internal references 18 | // 2. When ready to process, for each reference INTO the terms, 19 | // remove any terms they reference from the termNames array too. 20 | $.each(base.querySelectorAll("dfn"), function(i, item) { 21 | var $t = $(item) ; 22 | var titles = $t.getDfnTitles(); 23 | var n = $t.makeID("dfn", titles[0]); 24 | if (n) { 25 | termNames[n] = $t.parent() ; 26 | } 27 | }); 28 | 29 | var $container = $(".termlist",base) ; 30 | var containerID = $container.makeID("", "terms") ; 31 | termLists.push(containerID) ; 32 | 33 | // add a handler to come in after all the definitions are resolved 34 | // 35 | // New logic: If the reference is within a 'dl' element of 36 | // class 'termlist', and if the target of that reference is 37 | // also within a 'dl' element of class 'termlist', then 38 | // consider it an internal reference and ignore it. 39 | 40 | return (base.innerHTML); 41 | } 42 | 43 | require(["core/pubsubhub"], function(respecEvents) { 44 | "use strict"; 45 | respecEvents.sub('end', function(message) { 46 | if (message == 'core/link-to-dfn') { 47 | // all definitions are linked; find any internal references 48 | $(".termlist a.internalDFN").each(function() { 49 | var $r = $(this); 50 | var id = $r.attr('href'); 51 | var idref = id.replace(/^#/,"") ; 52 | if (termNames[idref]) { 53 | // this is a reference to another term 54 | // what is the idref of THIS term? 55 | var $def = $r.closest('dd') ; 56 | if ($def.length) { 57 | var $p = $def.prev('dt').find('dfn') ; 58 | var tid = $p.attr('id') ; 59 | if (tid) { 60 | if (termsReferencedByTerms[tid]) { 61 | termsReferencedByTerms[tid].push(idref); 62 | } else { 63 | termsReferencedByTerms[tid] = [] ; 64 | termsReferencedByTerms[tid].push(idref); 65 | } 66 | } 67 | } 68 | } 69 | }) ; 70 | 71 | // clearRefs is recursive. Walk down the tree of 72 | // references to ensure that all references are resolved. 73 | var clearRefs = function(theTerm) { 74 | if ( termsReferencedByTerms[theTerm] ) { 75 | $.each(termsReferencedByTerms[theTerm], function(i, item) { 76 | if (termNames[item]) { 77 | delete termNames[item]; 78 | clearRefs(item); 79 | } 80 | }); 81 | } 82 | // make sure this term doesn't get removed 83 | if (termNames[theTerm]) { 84 | delete termNames[theTerm]; 85 | } 86 | }; 87 | 88 | // now termsReferencedByTerms has ALL terms that 89 | // reference other terms, and a list of the 90 | // terms that they reference 91 | $("a.internalDFN").each(function () { 92 | var $item = $(this) ; 93 | var t = $item.attr('href'); 94 | var r = t.replace(/^#/,"") ; 95 | // if the item is outside the term list 96 | if ( ! $item.closest('dl.termlist').length ) { 97 | clearRefs(r); 98 | } 99 | }); 100 | 101 | // delete any terms that were not referenced. 102 | Object.keys(termNames).forEach(function(term) { 103 | var $p = $("#"+term) ; 104 | if ($p) { 105 | var tList = $p.getDfnTitles(); 106 | $p.parent().next().remove(); 107 | $p.remove() ; 108 | tList.forEach(function( item ) { 109 | if (respecConfig.definitionMap[item]) { 110 | delete respecConfig.definitionMap[item]; 111 | } 112 | }); 113 | } 114 | }); 115 | } 116 | }); 117 | }); 118 | -------------------------------------------------------------------------------- /w3c.json: -------------------------------------------------------------------------------- 1 | { 2 | "group": 83744 3 | , "contacts": "ianbjacobs" 4 | , "repo-type": "note" 5 | , "exposed": false 6 | } 7 | --------------------------------------------------------------------------------

Web Payments HTTP API 1.0

W3C First Public Working Draft 12 July 2016

Abstract

Status of This Document

1. Introduction

1.1 How to Read this Document

1.2 Terminology

2. Payment Flow Overview

3. Detailed Payment Flow

4. Web Payment Operations

4.1 Payment app Registration

4.2 Initiating a Payment Request

4.3 Generating a Payment Response

4.4 Security and Privacy Considerations

A. Acknowledgements

Web Payments HTTP API 1.0

W3C First Public Working Draft 15 September 2016

Abstract

Status of This Document

1. Introduction

1.1 How to Read this Document

1.2 Terminology

2. Payment Flow Overview

3. Detailed Payment Flow

4. Web Payment Operations

4.1 Payment app Registration

4.2 Initiating a Payment Request

4.3 Generating a Payment Response

4.4 Security and Privacy Considerations

A. Acknowledgements

B. References

B.1 Normative references

144 | Looking for the Specification? 145 |

155 | Background to Publication as a Note 156 |

194 | Additional Information 195 |