The 'payto' URI Scheme for Payments
RFC 8905

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 00
• 01
• 02
• 03
• 04
• 05
• 06
• 07
• 08
• 09
• 10
• 11
• 12
• 13
• 14



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 the