The 'payto' URI Scheme for Payments
RFC 8905
Document | Type |
RFC - Informational
(October 2020; No errata)
Was draft-dold-payto (individual)
|
|
---|---|---|---|
Authors | Florian Dold , Christian Grothoff | ||
Last updated | 2020-10-24 | ||
Stream | ISE | ||
Formats | plain text html xml pdf htmlized bibtex | ||
IETF conflict review | conflict-review-dold-payto | ||
Stream | ISE state | Published RFC | |
Consensus Boilerplate | Unknown | ||
Document shepherd | Adrian Farrel | ||
Shepherd write-up | Show (last changed 2020-01-27) | ||
IESG | IESG state | RFC 8905 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | Adrian Farrel <rfc-ise@rfc-editor.org> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | RFC-Ed-Ack |
Independent Submission F. Dold Request for Comments: 8905 Taler Systems SA Category: Informational C. Grothoff ISSN: 2070-1721 Bern University of Applied Sciences October 2020 The 'payto' URI Scheme for Payments Abstract This document defines the 'payto' Uniform Resource Identifier (URI) scheme for designating targets for payments. A unified URI scheme for all payment target types allows applications to offer user interactions with URIs that represent payment targets, simplifying the introduction of new payment systems and applications. Status of This Memo This document is not an Internet Standards Track specification; it is published for informational purposes. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8905. Copyright Notice Copyright (c) 2020 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction 1.1. Objective 1.2. Requirements Language 2. Syntax of a 'payto' URI 3. Semantics 4. Examples 5. Generic Options 6. Internationalization and Character Encoding 7. Tracking Payment Target Types 7.1. ACH Bank Account 7.2. Business Identifier Code 7.3. International Bank Account Number 7.4. Unified Payments Interface 7.5. Bitcoin Address 7.6. Interledger Protocol Address 7.7. Void Payment Target 8. Security Considerations 9. IANA Considerations 10. Payto Payment Target Types 11. References 11.1. Normative References 11.2. Informative References Authors' Addresses 1. Introduction This document defines the 'payto' Uniform Resource Identifier (URI) [RFC3986] scheme for designating transfer form data for payments. 1.1. Objective A 'payto' URI always identifies the target of a payment. A 'payto' URI consists of a payment target type, a target identifier, and optional parameters such as an amount or a payment reference. The interpretation of the target identifier is defined by the payment target type and typically represents either a bank account or an (unsettled) transaction. A unified URI scheme for all payment target types allows applications to offer user interactions with URIs that represent payment targets, simplifying the introduction of new payment systems and applications. 1.2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Syntax of a 'payto' URI This document uses the Augmented Backus-Naur Form (ABNF) of [RFC5234]. payto-URI = "payto://" authority path-abempty [ "?" opts ] opts = opt *( "&" opt ) opt-name = generic-opt / authority-specific-opt opt-value = *pchar opt = opt-name "=" opt-value generic-opt = "amount" / "receiver-name" / "sender-name" / "message" / "instruction" authority-specific-opt = ALPHA *( ALPHA / DIGIT / "-" / "." ) authority = ALPHA *( ALPHA / DIGIT / "-" / "." ) 'path-abempty' is defined in Section 3.3 of [RFC3986]. 'pchar' is defined in Appendix A of [RFC3986]. 3. Semantics The authority component of a payment URI identifies the payment target type. The payment target types are defined in the "Payto Payment Target Types" registry (see Section 10). The path component of the URI identifies the target for a payment as interpreted by the respective payment target type. The query component of the URI can provide additional parameters for a payment. Every payment target type SHOULD accept the options defined in generic-opt. The default operation of applications that invoke a URI with the 'payto' scheme MUST be to launch an application (if available) associated with theShow full document text