rfc8905xml2.original.xml   rfc8905.xml 
<?xml version="1.0" encoding="US-ASCII"?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3986.xml">
<!ENTITY RFC3629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3629.xml">
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.5234.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC8126 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8126.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="info" <rfc xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-dold-payto-14"
docName="draft-dold-payto-14" number="8905" ipr="trust200902" obsoletes="" updates=""
ipr="trust200902"> submissionType="independent" category="info" xml:lang="en"
tocInclude="true" symRefs="true" sortRefs="true" version="3">
<front> <front>
<title abbrev="The 'payto' URI scheme"> <title abbrev="The 'payto' URI Scheme">
The 'payto' URI scheme for payments The 'payto' URI Scheme for Payments
</title> </title>
<seriesInfo name="RFC" value="8905"/>
<author fullname="Florian Dold" initials="F.D." surname="Dold"> <author fullname="Florian Dold" initials="F." surname="Dold">
<organization>Taler Systems SA</organization> <organization>Taler Systems SA</organization>
<address> <address>
<postal> <postal>
<street>7, rue de Mondorf</street> <street>7, rue de Mondorf</street>
<city>Erpeldange</city> <city>Erpeldange</city>
<code>L-5421</code> <code>5421</code>
<country>LU</country> <country>Luxembourg</country>
</postal> </postal>
<email>dold@taler.net</email> <email>dold@taler.net</email>
</address> </address>
</author> </author>
<author fullname="Christian Grothoff" initials="C." surname="Grothoff">
<author fullname="Christian Grothoff" initials="C.G." surname="Grothoff"> <organization>Bern University of Applied Sciences</organization>
<organization>BFH</organization>
<address> <address>
<postal> <postal>
<street>H&ouml;heweg 80</street> <street>Quellgasse 21</street>
<street></street> <street/>
<city>Biel/Bienne</city> <city>Biel/Bienne</city>
<code>CH-2501</code> <code>2501</code>
<country>CH</country> <country>Switzerland</country>
</postal> </postal>
<email>christian.grothoff@bfh.ch</email> <email>christian.grothoff@bfh.ch</email>
</address> </address>
</author> </author>
<date month="October" year="2020"/>
<date day="01" month="May" year="2020" />
<!-- Meta-data Declarations -->
<area>General</area> <area>General</area>
<workgroup>Independent Stream</workgroup> <workgroup>Independent Stream</workgroup>
<keyword>payments</keyword> <keyword>payments</keyword>
<abstract> <abstract>
<t>This document defines the 'payto' Uniform Resource Identifier (URI)
<t> scheme for designating targets for payments.</t>
This document defines the 'payto' Uniform Resource Identifier (URI) sche <t>A unified URI scheme for all payment target types allows applications
me to offer user interactions with URIs that represent payment targets,
for designating targets for payments. simplifying the introduction of new payment systems and
</t> applications.</t>
<t>
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.
</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction" title="Introduction"> <name>Introduction</name>
<t> <t>This document defines the 'payto' Uniform Resource Identifier (URI)
This document defines the 'payto' Uniform Resource Identifier (URI) <xref targ <xref target="RFC3986" format="default"/> scheme for designating
et="RFC3986" /> scheme transfer form data for payments.</t>
for designating transfer form data for payments. <section numbered="true" toc="default">
</t> <name>Objective</name>
<t>A 'payto' URI always identifies the target of a payment. A 'payto'
<section title="Objective"> URI
<t> consists of a payment target type, a target identifier, and optional
A 'payto' URI always identifies the target of a payment. parameters such as an amount or a payment reference.</t>
A 'payto' URI consists of a payment target type, a target identifier and optio <t>The interpretation of the target identifier is defined by the
nal parameters payment target type and typically represents either a bank account or
such as an amount or a payment reference. an (unsettled) transaction.</t>
</t> <t>A unified URI scheme for all payment target types allows
<t> applications to offer user interactions with URIs that represent
The interpretation of the target identifier is defined by the payment target t payment targets, simplifying the introduction of new payment systems
ype, and typically and applications.</t>
represents either a bank account or an (unsettled) transaction. </section>
</t> <section numbered="true" toc="default">
<t> <name>Requirements Language</name>
A unified URI scheme for all payment target types <t>
allows applications to offer user interactions with URIs that represent paymen The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
t targets, "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
simplifying the introduction of new payment systems and applications. NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
</t> "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
</section> "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
<section title="Requirements Language"> to be interpreted as
<t> described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", when, and only when, they appear in all capitals, as shown here.
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and </t>
"OPTIONAL" in this document are to be interpreted as described in BCP 14 </section>
<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, </section>
they appear in all capitals, as shown here. <section anchor="syntax" numbered="true" toc="default">
</t> <name>Syntax of a 'payto' URI</name>
</section> <t>This document uses the Augmented Backus-Naur Form (ABNF) of <xref
target="RFC5234" format="default"/>.</t>
</section> <sourcecode type="abnf" ><![CDATA[
<section anchor="syntax"
title="Syntax of a 'payto' URI">
<t>
This document uses the Augmented Backus-Naur Form (ABNF) of <xref target="RFC5
234"/>.
</t>
<figure>
<artwork type="abnf"><![CDATA[
payto-URI = "payto://" authority path-abempty [ "?" opts ] payto-URI = "payto://" authority path-abempty [ "?" opts ]
opts = opt *( "&" opt ) opts = opt *( "&" opt )
opt-name = generic-opt / authority-specific-opt opt-name = generic-opt / authority-specific-opt
opt-value = *pchar opt-value = *pchar
opt = opt-name "=" opt-value opt = opt-name "=" opt-value
generic-opt = "amount" / "receiver-name" / "sender-name" / generic-opt = "amount" / "receiver-name" / "sender-name" /
"message" / "instruction" "message" / "instruction"
authority-specific-opt = ALPHA *( ALPHA / DIGIT / "-" / "." ) authority-specific-opt = ALPHA *( ALPHA / DIGIT / "-" / "." )
authority = ALPHA *( ALPHA / DIGIT / "-" / "." ) authority = ALPHA *( ALPHA / DIGIT / "-" / "." )
]]> ]]></sourcecode>
</artwork> <t>
</figure> 'path-abempty' is defined in <xref target="RFC3986" sectionFormat="of"
<t> section="3.3"/>.
'path-abempty' is defined in <xref target="RFC3986" /> in Section 3.3. 'pchar' is defined in <xref target="RFC3986" sectionFormat="of"
'pchar' is defined in <xref target="RFC3986" />, Appendix A. section="A"/>.
</t> </t>
</section> </section>
<section anchor="semantics" numbered="true" toc="default">
<section anchor="semantics" title="Semantics"> <name>Semantics</name>
<t> <t>The authority component of a payment URI identifies the payment
The authority component of a payment URI identifies the payment target type. target type. The payment target types are defined in the "Payto Payment
The Target Types" registry (see <xref target="payto-registry"
payment target types are defined in the "Payment Target Types" sub-registry, s format="default"/>). The path component of the URI identifies the target
ee <xref for a payment as interpreted by the respective payment target type. The
target="payto-registry" />. query component of the URI can provide additional parameters for a
payment. Every payment target type <bcp14>SHOULD</bcp14> accept the
The path component of the URI identifies the target for a payment as interpret options defined in generic-opt. The default operation of applications
ed that invoke a URI with the 'payto' scheme <bcp14>MUST</bcp14> be to
by the respective payment target type. launch
an application (if available) associated with the payment target type
The query component of the URI can provide additional parameters for a payment that can initiate 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 payment
target type that can initiate a payment. If multiple handlers are registered
for the same
payment target type, the user SHOULD be able to choose which application to la
unch.
This allows users with multiple bank accounts (each accessed the respective ba
nk's
banking application) to choose which account to pay with.
An application SHOULD allow dereferencing a payto URI even
if the payment target type of that URI is not registered in the "Payment Targe
t Types" sub-registry.
Details of the payment MUST be taken
from the path and options given in the URI. The user SHOULD be allowed to
modify these details before confirming a payment.
</t>
</section>
<section anchor="examples" title="Examples">
<figure>
<artwork><![CDATA[
payto://iban/DE75512108001245126199?amount=EUR:200.0&message=hello
INVALID (authority missing): payto:iban/12345 If multiple handlers are registered for the
]]> same payment target type, the user <bcp14>SHOULD</bcp14> be able to
</artwork> choose which application to launch. This allows users with multiple bank
</figure> accounts (each accessed via the respective bank's banking application)
to
choose which account to pay with. An application <bcp14>SHOULD</bcp14>
allow dereferencing a 'payto' URI even if the payment target type of
that
URI is not registered in the "Payto Payment Target Types"
registry. Details
of the payment <bcp14>MUST</bcp14> be taken from the path and options
given in the URI. The user <bcp14>SHOULD</bcp14> be allowed to modify
these details before confirming a payment.</t>
</section>
<section anchor="examples" numbered="true" toc="default">
<name>Examples</name>
</section> <t>Valid Example:</t>
<sourcecode><![CDATA[
payto://iban/DE75512108001245126199?amount=EUR:200.0&message=hello
]]></sourcecode>
<t>Invalid Example (authority missing):</t>
<sourcecode><![CDATA[
payto:iban/12345
]]></sourcecode>
</section>
<section anchor="generic-options" numbered="true" toc="default">
<name>Generic Options</name>
<t>Applications <bcp14>MUST</bcp14> accept URIs with options in any
order. The "amount" option <bcp14>MUST NOT</bcp14> occur more than
once. Other options <bcp14>MAY</bcp14> be allowed multiple times, with
further restrictions depending on the payment target type. The following
options <bcp14>SHOULD</bcp14> be understood by every payment target
type.</t>
<section anchor="generic-options" title="Generic Options"> <dl newline="false" spacing="normal">
<t> <dt>amount:</dt>
Applications MUST accept URIs with options in any order. The <dd><t>The amount to transfer. The format <bcp14>MUST</bcp14> be:</t>
"amount" option MUST NOT occur more than once. Other options MAY be
allowed multiple times, with further restrictions depending on the
payment target type.
The following options SHOULD be understood by every payment target type. <sourcecode type="abnf"><![CDATA[
</t>
<t>
amount: The amount to transfer. The format MUST be:
<figure>
<artwork><![CDATA[
amount = currency ":" unit [ "." fraction ] amount = currency ":" unit [ "." fraction ]
currency = 1*ALPHA currency = 1*ALPHA
unit = 1*(DIGIT / ",") unit = 1*(DIGIT / ",")
fraction = 1*(DIGIT / ",") fraction = 1*(DIGIT / ",")
]]> ]]></sourcecode>
</artwork> <t>If a 3-letter 'currency' is used, it <bcp14>MUST</bcp14> be an <xref
</figure> target="ISO4217" format="default"/> alphabetic code. A payment target
If a 3-letter 'currency' is used, it MUST be an type <bcp14>MAY</bcp14> define semantics beyond ISO 4217 for currency
<xref target="ISO4217" /> codes that are not 3 characters. The 'unit' value <bcp14>MUST</bcp14> be
alphabetic code. A payment target type MAY define semantics beyond ISO 4217 smaller than 2^53. If present, the 'fraction' <bcp14>MUST</bcp14>
for currency codes that are not 3 characters. The 'unit' value MUST be smaller consist of no more than 8 decimal digits. The use of commas is optional
than 2^53. If present, the 'fraction' MUST consist of no more than 8 decimal for readability, and they <bcp14>MUST</bcp14> be ignored.</t> </dd>
digits.
The use of commas is optional for readability and they MUST be ignored.
</t>
<t>
receiver-name: Name of the entity that receives the payment (creditor).
The value of this option MAY
be subject to lossy conversion, modification and truncation (for example, due
to
line wrapping or character set conversion).
</t>
<t>
sender-name: Name of the entity that makes the payment (debtor).
The value of this option MAY
be subject to lossy conversion, modification and truncation (for example, due
to
line wrapping or character set conversion).
</t>
<t>
message: A short message to identify the purpose of the payment.
The value of this option MAY
be subject to lossy conversion, modification and truncation (for example, due
to
line wrapping or character set conversion).
</t>
<t>
instruction: A short message giving payment reconciliation instructions to
the recipient.
An instruction that follows the character set and length limitation defined by
the
respective payment target type SHOULD NOT be subject to lossy conversion.
</t>
</section>
<section anchor="encoding" title="Internationalization and Character Encoding"> <dt>receiver-name:</dt>
<t> <dd>Name of the entity that receives the payment (creditor). The value of
this option <bcp14>MAY</bcp14> be subject to lossy conversion, modification,
and truncation (for example, due to line wrapping or character set
conversion).</dd>
<dt>sender-name:</dt>
<dd>Name of the entity that makes the payment (debtor). The value of this
option <bcp14>MAY</bcp14> be subject to lossy conversion, modification, and
truncation (for example, due to line wrapping or character set
conversion).</dd>
<dt>message:</dt>
<dd>A short message to identify the purpose of the payment. The value of
this option <bcp14>MAY</bcp14> be subject to lossy conversion, modification,
and truncation (for example, due to line wrapping or character set
conversion).</dd>
<dt>instruction:</dt>
<dd>A short message giving payment reconciliation instructions to the
recipient. An instruction that follows the character set and length
limitation defined by the respective payment target type <bcp14>SHOULD
NOT</bcp14> be subject to lossy conversion.</dd>
</dl>
</section>
<section anchor="encoding" numbered="true" toc="default">
<name>Internationalization and Character Encoding</name>
<t>
Various payment systems use restricted character sets. Various payment systems use restricted character sets.
An application that processes 'payto' URIs MUST convert An application that processes 'payto' URIs <bcp14>MUST</bcp14> convert
characters that are not allowed by the respective payment systems characters that are not allowed by the respective payment systems
into allowable character using either an encoding or a replacement table. into allowable characters using either an encoding or a replacement table.
This conversion process MAY be lossy, except for the instruction field. This conversion process <bcp14>MAY</bcp14> be lossy, except for the
instruction field.
If the value of the instruction field would be subject to lossy conversion, If the value of the instruction field would be subject to lossy conversion,
modification or truncation, modification, or truncation,
the application SHOULD refuse further processing of the payment until a the application <bcp14>SHOULD</bcp14> refuse further processing of the
payment until a
different value for the instruction is provided. different value for the instruction is provided.
</t> </t>
<t> <t>To avoid special encoding rules for the payment target identifier,
To avoid special encoding rules for the payment target identifier, the userinf the userinfo component <xref target="RFC3986" format="default"/> is
o component disallowed in 'payto' URIs. Instead, the payment target identifier is
<xref target="RFC3986" /> is disallowed in payto URIs. Instead, the payment t given as an option, where encoding rules are uniform for all
arget identifier is options.</t>
given as an option, where encoding rules are uniform for all options. <t>
</t> Defining a generic way of tagging the language of option fields containing
<t> natural
Defining a generic way of tagging the language of option fields containing nat language text (such as "receiver-name", "sender-name", and "message)
ural is out of the scope of this document, as internationalization must
language text (such as "receiver-name", "sender-name" and "message) accommodate the restrictions
is out of the scope of this document, as internationalization must accomodate and requirements of the underlying banking system of the payment target
the restrictions type.
and requirements of the underlying banking system of the payment target type.
The internationalization concerns SHOULD be individually defined by each payme
nt target type.
</t>
</section>
<section anchor="tracking" title="Tracking Payment Target Types">
<t>
A registry of Payment Target Types is described in <xref target="payto-regis
try" />.
The registration policy for this registry is "First Come First Served",
as described in <xref target="RFC8126" />.
When requesting new entries, careful consideration of the following criteria is
strongly advised:
<list style="numbers">
<t>The description clearly defines the syntax and semantics of the payment tar
get and optional parameters if applicable.</t>
<t>Relevant references are provided if they are available.</t>
<t>The chosen name is appropriate for the payment target type, does not confli
ct
with well-known payment systems, and avoids potential to confuse users.</t>
<t>The payment system underlying the payment target type is not fundamentally
incompatible with the general options (such as positive decimal amounts) in
this specification.</t>
<t>The payment target type is not a vendor-specific version of a payment targe
t type that
could be described more generally by a vendor-neutral payment target type.</
t>
<t>The specification of the new payment target type remains within the scope o
f payment transfer form data.
In particular specifying complete invoices is not in scope. Neither are pro
cessing instructions to the
payment processor or bank beyond a simple payment.</t>
<t>The payment target and the options do not contain the payment sender's acco
unt details.</t>
</list>
</t>
<t>
Documents that support requests for new registry entries should
provide the following information for each entry:
<list style="symbols">
<t>Name: The name of the payment target type (case insensitive ASCII string, res
tricted to alphanumeric characters,
dots and dashes)</t>
<t>Description: A description of the payment target type, including
the semantics of the path in the URI if applicable.</t>
<t>Example: At least one example URI to illustrate the payment target type.</t>
<t>Contact: The contact information of a person to contact for further informati
on</t>
<t>References: Optionally, references describing the payment target type (such a
s an RFC) and target-specific options,
or references describing the payment system underlying the payment target type
.</t>
</list>
</t>
<t>
This document populates the registry with six entries as follows (see
also <xref target="payto-registry" />).
</t>
<section anchor="registry-entry-ach" title="ACH Bank Account"> The internationalization concerns <bcp14>SHOULD</bcp14> be individually
<t> defined by each payment target type.
<list style="symbols"> </t>
<t>Name: ach</t> </section>
<t>Description: Automated Clearing House. The path consist of two components, t <section anchor="tracking" numbered="true" toc="default">
he routing number and the account number. <name>Tracking Payment Target Types</name>
Limitations on the length and character set of option values are defined by th <t> A registry of "Payto Payment Target Types" is described in <xref
e implementation target="payto-registry" format="default"/>. The registration policy for
of the handler. this registry is "First Come First Served", as described in <xref
Language tagging and internationalization of options is not supported. target="RFC8126" format="default"/>. When requesting new entries,
</t> careful consideration of the following criteria is strongly advised:</t>
<t>Example: payto://ach/122000661/1234</t> <ol spacing="normal" type="1">
<t>Contact: N/A</t> <li>The description clearly defines the syntax and semantics of the
<t>References: <xref target="NACHA" />, [this.I-D]</t> payment target and optional parameters if applicable.</li>
</list> <li>Relevant references are provided if they are available.</li>
</t> <li>The chosen name is appropriate for the payment target type, does
</section> not conflict with well-known payment systems, and avoids potential to
confuse users.</li>
<li>The payment system underlying the payment target type is not
fundamentally incompatible with the general options (such as positive
decimal amounts) in this specification.</li>
<li>The payment target type is not a vendor-specific version of a
payment target type that could be described more generally by a
vendor-neutral payment target type.</li>
<li>The specification of the new payment target type remains within
the scope of payment transfer form data. In particular, specifying
complete invoices is not in scope. Neither are processing
instructions to the payment processor or bank beyond a simple
payment.</li>
<li>The payment target and the options do not contain the payment
sender's account details.</li>
</ol>
<t>Documents that support requests for new registry entries should
provide the following information for each entry:</t>
<dl newline="false" spacing="normal">
<dt>Name:</dt>
<dd>The name of the payment target type (case-insensitive ASCII
string, restricted to alphanumeric characters, dots, and dashes).</dd>
<dt>Description:</dt>
<dd>A description of the payment target type, including the semantics
of the path in the URI if applicable.</dd>
<dt>Example:</dt>
<dd>At least one example URI to illustrate the payment target
type.</dd>
<dt>Contact:</dt>
<dd>The contact information of a person to contact for further
information.</dd>
<dt>References:</dt>
<dd>Optionally, references describing the payment target type (such as
an RFC) and target-specific options or references describing the
payment system underlying the payment target type.</dd>
</dl>
<t>This document populates the registry with seven entries as follows
(see
also <xref target="payto-registry" format="default"/>).</t>
<section anchor="registry-entry-ach" numbered="true" toc="default">
<name>ACH Bank Account</name>
<dl newline="false" spacing="normal">
<dt>Name:</dt>
<dd>ach</dd>
<dt>Description:</dt>
<dd>Automated Clearing House (ACH). The path consists of two
components:
the routing number and the account number. Limitations on the
length
and character set of option values are defined by the
implementation
of the handler. Language tagging and internationalization of
options
are not supported.</dd>
<dt>Example:</dt>
<dd>
<sourcecode><![CDATA[
payto://ach/122000661/1234
]]></sourcecode>
</dd>
<dt>Contact:</dt>
<dd>N/A</dd>
<dt>References:</dt>
<dd><xref target="NACHA" format="default"/>, RFC 8905</dd>
</dl>
</section>
<section anchor="registry-entry-bic" numbered="true" toc="default">
<name>Business Identifier Code</name>
<dl newline="false" spacing="normal">
<dt>Name:</dt>
<dd>bic</dd>
<dt>Description:</dt>
<section anchor="registry-entry-bic" title="Business Identifier Code"> <dd>Business Identifier Code (BIC). The path consists of just
<t> a BIC. This is used for wire transfers between banks. The registry
<list style="symbols"> for BICs is provided by the Society for Worldwide Interbank
<t>Name: bic</t> Financial Telecommunication (SWIFT). The path does not allow
<t>Description: Business Identifier Code. The path consist of just a BIC. This i specifying a
s used for wire transfers between banks. The registry for BICs is provided by SW bank account number. Limitations on the length and character set of
IFT. The path does not allow specifying a bank account number. option values are defined by the implementation of the
Limitations on the length and character set of option values are defined by th handler. Language tagging and internationalization of options
e implementation are not
of the handler. supported.</dd>
Language tagging and internationalization of options is not supported. <dt>Example:</dt>
</t> <dd>
<t>Example: payto://bic/SOGEDEFFXXX</t> <sourcecode><![CDATA[
<t>Contact: N/A</t> payto://bic/SOGEDEFFXXX
<t>References: <xref target="BIC" />, [this.I-D]</t> ]]></sourcecode>
</list> </dd>
</t> <dt>Contact:</dt>
</section> <dd>N/A</dd>
<dt>References:</dt>
<dd><xref target="BIC" format="default"/>, RFC 8905</dd>
</dl>
</section>
<section anchor="registry-entry-iban" numbered="true" toc="default">
<name>International Bank Account Number</name>
<dl newline="false" spacing="normal">
<dt>Name:</dt>
<dd>iban</dd>
<dt>Description:</dt>
<section anchor="registry-entry-iban" title="International Bank Account Number"> <dd>International Bank Account Number (IBAN). Generally, the IBAN
<t> allows to unambiguously derive the associated Business
<list style="symbols"> Identifier Code (BIC) using a lookup in the respective
<t>Name: iban</t> proprietary translation table. However, some legacy applications
<t>Description: International Bank Account Number (IBAN). Generally the IBAN al process
lows to unambiguously derive payments to the same IBAN differently based on the specified BIC.
the the associated Business Identifier Code (BIC). However, some legacy appli Thus, the path can consist of either a single component (the IBAN)
cations process payments to the same IBAN differently based on the or
specified BIC. Thus the path can either consist of a single component (the IB two components (BIC followed by IBAN). The "message" option of
AN) or two components the
(BIC followed by IBAN). The "message" option of the payto URI corresponds to 'payto' URI corresponds to the "unstructured remittance
the "unstructured remittance information" information"
of SEPA credit transfers and is thus limited to 140 characters with character of Single Euro Payments Area (SEPA) credit transfers and is
set limitations that thus
differ according to the countries of banks and payment processors involved in limited to 140 characters with
the payment. character set limitations that differ according to the
The "instruction" option of the payto URI corresponds to the "end to end ident countries of
ifier" of SEPA credit transfers the banks and payment processors involved in the
and is thus limited to at most 35 characters that can be alphanumeric or from payment. The
the allowed set "instruction" option of the 'payto' URI corresponds to
of special characters "+?/-:().,'". the "end-to-end
Language tagging and internationalization of options is not supported. identifier" of SEPA credit transfers and is thus
</t> limited to, at most,
<t>Example: 35 characters, which can be alphanumeric or from
the allowed set of
special characters, i.e., "+?/-:().,'". Language
tagging and
internationalization of options are not
supported.</dd>
<dt>Examples:</dt>
<dd>
<sourcecode><![CDATA[
payto://iban/DE75512108001245126199
payto://iban/SOGEDEFFXXX/DE75512108001245126199
]]></sourcecode>
</dd>
<dt>Contact:</dt>
<dd>N/A</dd>
<dt>References:</dt>
<dd><xref target="ISO20022" format="default"/>, RFC 8905</dd>
</dl>
</section>
<section anchor="registry-entry-upi" numbered="true" toc="default">
<name>Unified Payments Interface</name>
<dl newline="false" spacing="normal">
<dt>Name:</dt>
<dd>upi</dd>
<dt>Description:</dt>
<dd>Unified Payment Interface (UPI). The path is an account
alias. The
amount and receiver-name options are mandatory for this payment
target. Limitations on the length and character set of option
values
are defined by the implementation of the handler. Language
tags and
internationalization of options are not supported.</dd>
<dt>Example:</dt>
<dd>
<sourcecode><![CDATA[
payto://upi/alice@example.com?receiver-name=Alice&amount=INR:200
]]></sourcecode>
payto://iban/DE75512108001245126199 </dd>
<dt>Contact:</dt>
<dd>N/A</dd>
<dt>References:</dt>
<dd><xref target="UPILinking" format="default"/>, RFC 8905</dd>
</dl>
</section>
<section anchor="registry-entry-bitcoin" numbered="true" toc="default">
<name>Bitcoin Address</name>
<dl newline="false" spacing="normal">
<dt>Name:</dt>
<dd>bitcoin</dd>
<dt>Description:</dt>
<dd>Bitcoin protocol. The path is a "bitcoinaddress", as per <xref
target="BIP0021" format="default"/>. Limitations on the length
and
character set of option values are defined by the implementation
of
the handler. Language tags and internationalization of options
are
not supported.</dd>
<dt>Example:</dt>
<dd>
<sourcecode><![CDATA[
payto://bitcoin/12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu
]]></sourcecode>
</dd>
<dt>Contact:</dt>
<dd>N/A</dd>
<dt>References:</dt>
<dd><xref target="BIP0021" format="default"/>, RFC 8905</dd>
</dl>
</section>
<section anchor="registry-entry-ilp" numbered="true" toc="default">
<name>Interledger Protocol Address</name>
<dl newline="false" spacing="normal">
<dt>Name:</dt>
<dd>ilp</dd>
<dt>Description:</dt>
<dd>Interledger protocol (ILP). The path is an ILP address, as per
<xref
target="ILP-ADDR" format="default"/>. Limitations on the
length and
character set of option values are defined by the implementation
of
the handler. Language tagging and internationalization of
options
are not supported.</dd>
<dt>Example:</dt>
<dd>payto://ilp/g.acme.bob
</dd>
<dt>Contact: </dt>
<dd>N/A</dd>
<dt>References:</dt>
<dd><xref target="ILP-ADDR" format="default"/>, RFC 8905</dd>
</dl>
</section>
<section anchor="registry-entry-void" numbered="true" toc="default">
<name>Void Payment Target</name>
<dl newline="false" spacing="normal">
<dt>Name:</dt>
<dd>void</dd>
<dt>Description:</dt>
<dd>The "void" payment target type allows specifying the
parameters
of an out-of-band payment (such as cash or other types of
in-person
transactions). The path is optional and interpreted as a
comment. Limitations on the length and character set of
option
values are defined by the implementation of the
handler. Language
tags and internationalization of options are not
supported.</dd>
<dt>Example:</dt>
<dd>
<sourcecode><![CDATA[
payto://void/?amount=EUR:10.5
]]></sourcecode>
</dd>
<dt>Contact:</dt>
<dd>N/A</dd>
<dt>References:</dt>
<dd>RFC 8905</dd>
</dl>
</section>
</section>
payto://iban/SOGEDEFFXXX/DE75512108001245126199 <section anchor="security" numbered="true" toc="default">
</t> <name>Security Considerations</name>
<t>Contact: N/A</t> <t>Interactive applications handling the 'payto' URI scheme <bcp14>MUST
<t>References: <xref target="ISO20022" />, [this.I-D]</t> NOT</bcp14> initiate any financial transactions without prior review and
</list> confirmation from the user and <bcp14>MUST</bcp14> take measures to
</t> prevent clickjacking <xref target="HMW12" format="default"/>.</t>
<t>Unless a 'payto' URI is received over a trusted, authenticated
channel,
a user might not be able to identify the target of a payment. In
particular, due to homographs <xref target="unicode-tr36"
format="default"/>, a payment target type <bcp14>SHOULD NOT</bcp14> use
human-readable names in combination with unicode in the target account
specification, as it could give the user the illusion of being able to
identify the target account from the URI.</t>
<t>The authentication/authorization mechanisms and transport security
services used to process a payment encoded in a 'payto' URI are handled
by
the application and are not in scope of this document.</t>
<t>To avoid unnecessary data collection, payment target types
<bcp14>SHOULD NOT</bcp14> include personally identifying information
about the sender of a payment that is not essential for an application
to conduct a payment.</t>
</section> </section>
<section anchor="iana" numbered="true" toc="default">
<section anchor="registry-entry-upi" title="Unified Payments Interface"> <name>IANA Considerations</name>
<t> <t>
<list style="symbols"> IANA maintains the "Uniform Resource Identifier (URI) Schemes" registry,
<t>Name: upi</t> which contains an entry for the 'payto' URI scheme as follows. IANA has updat
<t>Description: Unified Payment Interface. The path is an account alias. The am ed that
ount and receiver-name entry to reference this document.</t>
options are mandatory for this payment target.
Limitations on the length and character set of option values are defined by th
e implementation
of the handler.
Language tags and internationalization of options are not supported.
</t>
<t>Example: payto://upi/alice@example.com?receiver-name=Alice&amp;amount=INR:200
</t>
<t>Contact: N/A</t>
<t>References: <xref target="UPILinking" />, [this.I-D]</t>
</list>
</t>
</section>
<section anchor="registry-entry-bitcoin" title="Bitcoin Address"> <dl>
<t> <dt>Scheme name:</dt><dd> payto</dd>
<list style="symbols">
<t>Name: bitcoin</t>
<t>Description: Bitcoin protocol. The path is a "bitcoinaddress" as per <xref ta
rget="BIP0021" />.
Limitations on the length and character set of option values are defined by the
implementation
of the handler.
Language tags and internationalization of options are not supported.
</t>
<t>Example: payto://bitcoin/12A1MyfXbW6RhdRAZEqofac5jCQQjwEPBu</t>
<t>Contact: N/A</t>
<t>References: <xref target="BIP0021" />, [this.I-D]</t>
</list>
</t>
</section>
<section anchor="registry-entry-ilp" title="Interledger Protocol Address"> <dt>Status:</dt><dd> provisional</dd>
<t>
<list style="symbols">
<t>Name: ilp</t>
<t>Description: Interledger protocol. The path is an ILP address as per <xref ta
rget="ILP-ADDR" />.
Limitations on the length and character set of option values are defined by the
implementation
of the handler.
Language tagging and internationalization of options is not supported.
</t>
<t>Example: payto://ilp/g.acme.bob</t>
<t>Contact: N/A</t>
<t>References: <xref target="ILP-ADDR" />, [this.I-D]</t>
</list>
</t>
</section>
<section anchor="registry-entry-void" title="Void Payment Target"> <dt>URI scheme syntax:</dt><dd>See <xref target="syntax"/> of RFC 8905.</dd>
<t>
<list style="symbols">
<t>Name: void</t>
<t>
Description: The "void" payment target type allows specifying the parameters
of an out-of-band payment (such as cash or other types of in-person
transactions). The path is optional and interpreted as a comment.
Limitations on the length and character set of option values are defined by th
e implementation
of the handler.
Language tags and internationalization of options are not supported.
</t>
<t>Example: payto://void/?amount=EUR:10.5</t>
<t>Contact: N/A</t>
<t>References: [this.I-D]</t>
</list>
</t>
</section>
</section><!-- tracking --> <dt>URI scheme semantics:</dt><dd>See <xref target="semantics"/> of RFC
8905.
</dd>
<section anchor="security" title="Security Considerations"> <dt>Applications/protocols that use this scheme name:</dt><dd> payto URIs are
<t> mainly used by financial software.</dd>
Interactive applications handling the payto URI scheme MUST NOT initiate any
financial transactions without prior review and confirmation from the user,
and MUST take measures to prevent clickjacking <xref target="HMW12"/>.
</t>
<t>
Unless a payto URI is received over a trusted, authenticated channel,
a user might not be able to identify the target of a payment. In particular
due to homographs <xref target="unicode-tr36" />, a payment target type SHOULD N
OT
use human-readable names in combination with unicode in the target
account specification, as it could give the user the illusion of being able
to identify the target account from the URI.
</t>
<t>
The authentication/authorization mechanisms and transport security services
used to process a payment encoded in a payto URI
are handled by the application and are not in scope of this document.
</t>
<t>
To avoid unnecessary data collection, payment target types SHOULD NOT
include personally identifying information about the sender of a payment that is
not
essential for an application to conduct a payment.
</t>
</section>
<section anchor="iana" title="IANA Considerations"> <dt>Contact:</dt><dd><t><contact fullname="Christian Grothoff"/> &lt;grothoff@ gnu.org&gt;</t></dd>
<t> <dt>Change controller:</dt><dd><t><contact fullname="Christian Grothoff"/> &lt
IANA maintains a registry called the "Uniform Resource Identifier ;grothoff@gnu.org&gt;</t></dd>
(URI) Schemes" registry.
</t>
<section anchor="payto-uri" title="URI Scheme Registration"> <dt>References:</dt><dd> See <xref target="refs"/> of RFC 8905.</dd>
<t> </dl>
IANA maintains the "Uniform Resource Identifier (URI) Schemes"
registry that contains an entry for the 'payto' URI scheme. IANA is
requested to update that entry to reference this document when
published as an RFC.
</t>
</section>
</section>
<section anchor="payto-registry" title="Payment Target Types"> </section>
<t>
This document specifies a list of Payment Target Types. It is <section anchor="payto-registry" numbered="true" toc="default">
<name>Payto Payment Target Types</name>
<t>
This document specifies a list of payment target types. It is
possible that future work will need to specify additional payment possible that future work will need to specify additional payment
target types. The GNUnet Assigned Numbers Authority (GANA) <xref target="GAN target types. The GNUnet Assigned Numbers Authority (GANA) <xref
A" /> target="GANA" format="default"/>
operates the "payto-payment-target-types" registry to track operates the "Payto Payment Target Types" registry to track
the following information for each payment target type: the following information for each payment target type:
<list style="symbols"> </t>
<t>Name: The name of the payment target type (case insensitive ASCII string, re <dl newline="false" spacing="normal">
stricted to alphanumeric characters, <dt>Name:</dt>
dots and dashes)</t> <dd>The name of the payment target type (case-insensitive ASCII
<t>Contact: The contact information of a person to contact for further informati string, restricted to alphanumeric characters, dots, and dashes)</dd>
on</t> <dt>Contact:</dt>
<t>References: Optionally, references describing the payment target type (such a <dd>The contact information of a person to contact for further
s an RFC) and target-specific options, information</dd>
or references describing the payment system underlying the payment target type <dt>References:</dt>
.</t> <dd>Optionally, references describing the payment target type (such as
</list> an RFC) and target-specific options or references describing the
</t> payment system underlying the payment target type</dd>
<t> </dl>
The entries that have been made for the "payto-payment-target-types" <t>
The entries in the "Payto Payment Target Types" registry
defined in this document are as follows: defined in this document are as follows:
</t> </t>
<figure> <table>
<artwork> <thead>
Name | Contact | Reference <tr>
----------+-------------------------+------------ <th>Name</th>
ach | N/A | [This.I-D] <th>Contact</th>
bic | N/A | [This.I-D] <th>Reference</th>
iban | N/A | [This.I-D] </tr>
upi | N/A | [This.I-D] </thead>
bitcoin | N/A | [This.I-D] <tbody>
ilp | N/A | [This.I-D] <tr>
void | N/A | [This.I-D] <td>ach</td>
</artwork> <td>N/A</td>
</figure> <td>RFC 8905</td>
</tr>
</section><!-- payto-registry --> <tr>
<td>bic</td>
</middle> <td>N/A</td>
<td>RFC 8905</td>
<back> </tr>
<tr>
<references title="Normative References"> <td>iban</td>
<td>N/A</td>
&RFC2119; <td>RFC 8905</td>
</tr>
&RFC3986; <tr>
<td>upi</td>
&RFC5234; <td>N/A</td>
<td>RFC 8905</td>
&RFC8126; </tr>
<tr>
&RFC8174; <td>bitcoin</td>
<td>N/A</td>
<reference anchor="ISO4217"> <td>RFC 8905</td>
<front> </tr>
<title>ISO 4217 Currency Codes</title> <tr>
<author> <td>ilp</td>
<organization>International Organization for Standardization</organiza <td>N/A</td>
tion> <td>RFC 8905</td>
<address> </tr>
<uri>http://www.iso.ch</uri> <tr>
</address> <td>void</td>
</author> <td>N/A</td>
<date month="August" year="2018"/> <td>RFC 8905</td>
</front> </tr>
</reference> </tbody>
</table>
<reference anchor="ISO20022"> </section>
<front>
<title>ISO 20022 Financial Services - Universal financial industry messa
ge scheme</title>
<author>
<organization>International Organization for Standardization</organiza
tion>
<address>
<uri>http://www.iso.ch</uri>
</address>
</author>
<date month="May" year="2013"/>
</front>
</reference>
<reference anchor="NACHA"> </middle>
<front> <back>
<title>NACHA Operating Rules &amp; Guidelines</title> <references anchor="refs">
<author> <name>References</name>
<organization>NACHA</organization> <references>
<address> <name>Normative References</name>
<uri>https://www.nacha.org/</uri> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
</address> .2119.xml"/>
</author> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
<date month="January" year="2017"/> .3986.xml"/>
</front> <xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
</reference> .5234.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.8126.xml"/>
<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/reference.RFC
.8174.xml"/>
<reference anchor="unicode-tr36"> <reference anchor="ISO4217" target="https://www.iso.org">
<front> <front>
<title abbrev="Unicode Security Considerations">Unicode Technical Report # <title>Codes for the representation of currencies</title>
36: Unicode Security Considerations</title> <author>
<author initials="M." surname="Davis" fullname="Mark Davis" role="editor"> <organization>International Organization for
<address> Standardization</organization>
<email>markdavis@google.com</email> </author>
</address> <date month="August" year="2015"/>
</author> </front>
<author initials="M." surname="Suignard" fullname="Michael Suignard"> <seriesInfo name="ISO" value="4217"/>
<address> </reference>
<email>michel@suignard.com</email>
</address>
</author>
<date month="September" year="2014"/>
</front>
</reference>
</references> <reference anchor="ISO20022" target="https://www.iso.org">
<front>
<title>Financial Services - Universal financial industry message
scheme</title>
<author>
<organization>International Organization for
Standardization</organization>
</author>
<date month="May" year="2013"/>
</front>
<seriesInfo name="ISO" value="20022"/>
</reference>
<references title="Informational References"> <reference anchor="NACHA">
<front>
<title>2020 Nacha Operating Rules &amp; Guidelines</title>
<author>
<organization>Nacha</organization>
<address>
<uri>https://www.nacha.org/</uri>
</address>
</author>
<date year="2019"/>
</front>
</reference>
<reference anchor="BIP0021" target="https://en.bitcoin.it/wiki/BIP_0021"> <reference anchor="unicode-tr36">
<front> <front>
<title>Bitcoin Improvement Proposal 21</title> <title abbrev="Unicode Security Considerations">Unicode Technical
<author initials="N." surname="Schneider" Report #36: Unicode Security Considerations</title>
fullname="Nils Schneider"> <author initials="M." surname="Davis" fullname="Mark Davis"
</author> role="editor">
<author initials="M." surname="Corallo" <address>
fullname="Matt Corallo"> <email>markdavis@google.com</email>
</author> </address>
</author>
<author initials="M." surname="Suignard" fullname="Michael Suignard"
role="editor">
<address>
<email>michel@suignard.com</email>
</address>
</author>
<date month="September" year="2014"/>
</front>
</reference>
</references>
<date month="January" year="2012" /> <references>
</front> <name>Informative References</name>
</reference>
<reference anchor="HMW12" target="https://www.usenix.org/system/files/confere <reference anchor="BIP0021"
nce/usenixsecurity12/sec12-final39.pdf"> target="https://en.bitcoin.it/w/index.php?title=BIP_0021&amp;o
<front> ldid=66778">
<title>Clickjacking: Attacks and Defenses</title> <front>
<author initials="L.S." surname="Huang" <title>Bitcoin Improvement Proposal 21</title>
fullname="Lin-Shung Huang"> <author initials="N." surname="Schneider" fullname="Nils
</author> Schneider">
<author initials="A." surname="Moshchuk" </author>
fullname="Alexander, Moshchuk"> <author initials="M." surname="Corallo" fullname="Matt Corallo">
</author> </author>
<author initials="H.J." surname="Wang" <date month="September" year="2019"/>
fullname="Helen J. Wang"> </front>
</author> </reference>
<author initials="S." surname="Schecter"
fullname="Stuart Schecter">
</author>
<author initials="C." surname="Jackson"
fullname="Collin Jackson">
</author>
<date month="January" year="2012" /> <reference anchor="HMW12"
</front> target="https://www.usenix.org/system/files/conference/usenixs
</reference> ecurity12/sec12-final39.pdf">
<front>
<title>Clickjacking: Attacks and Defenses</title>
<author initials="L." surname="Huang" fullname="Lin-Shung Huang">
</author>
<author initials="A." surname="Moshchuk" fullname="Alexander
Moshchuk">
</author>
<author initials="H." surname="Wang" fullname="Helen J. Wang">
</author>
<author initials="S." surname="Schecter" fullname="Stuart
Schecter">
</author>
<author initials="C." surname="Jackson" fullname="Collin Jackson">
</author>
<date year="2012"/>
</front>
</reference>
<reference anchor="UPILinking" target="https://www.npci.org.in/sites/default/f <reference anchor="UPILinking"
iles/UPI%20Linking%20Specs_ver%201.6.pdf"> target="https://www.npci.org.in/sites/default/files/UPI%20Link
<front> ing%20Specs_ver%201.6.pdf">
<title>Unified Payment Interface - Common URL Specifications For Deep <front>
<title>Unified Payment Interface - Common URL Specifications For
Deep
Linking And Proximity Integration</title> Linking And Proximity Integration</title>
<author><organization>National Payment Corporation of India</organization> <author>
</author> <organization>National Payments Corporation of
<date month="November" year="2017" /> India</organization>
</front> </author>
</reference> <date month="November" year="2017"/>
</front>
<reference anchor="ILP-ADDR" target="https://interledger.org/rfcs/0015-ilp-addr </reference>
esses/">
<front>
<title>ILP Addresses - v2.0.0</title>
<author><organization>Interledger Team</organization>
</author>
<date month="September" year="2018" />
</front>
</reference>
<reference anchor="BIC" target="https://www.iso.org/standard/60390.html"> <reference anchor="ILP-ADDR"
<front> target="https://interledger.org/rfcs/0015-ilp-addresses/">
<title>ISO 9362:2014 Business Identifier Code (BIC)</title> <front>
<author><organization>International Organization for Standardization</orga <title>ILP Addresses - v2.0.0</title>
nization> <author>
</author> <organization>Interledger</organization>
<date month="March" year="2019" /> </author>
</front> </front>
</reference> </reference>
<reference anchor="GANA" target="https://gana.gnunet.org/"> <reference anchor="BIC" target="https://www.iso.org">
<front> <front>
<title>GNUnet Assigned Numbers Authority (GANA)</title> <title>Banking -- Banking telecommunication messages -- Business
<author><organization>GNUnet e.V.</organization> identifier code (BIC)</title>
</author> <author>
<date month="April" year="2020" /> <organization>International Organization for
</front> Standardization</organization>
</reference> </author>
<date month="December" year="2014"/>
</front>
<seriesInfo name="ISO" value="9362"/>
</reference>
</references> <reference anchor="GANA" target="https://gana.gnunet.org/">
<front>
<title>GNUnet Assigned Numbers Authority (GANA)</title>
<author>
<organization>GNUnet e.V.</organization>
</author>
<date month="April" year="2020"/>
</front>
</reference>
</references>
</references>
<!-- Change Log
v11 2020-03-23 CG Workaround IESG/IAB/IANA/ISE discussion on who gets to crea
te IANA registries as suggested by Adrian Farrel
v10 2019-11-14 CG Address comments from Adrian Farrel
v09 2019-11-04 CG Reference ISO 4217 for currency codes, clean up ENBF syntax
and language (based on feedback from Matthias Heckmann)
v08 2019-09-27 CG Clarify use of sub-registry as per draft-ise-iana-policy
v05 2019-05-20 CG Addressing coments, preparing for independent stream submis
sion, adding BIC
v01 2017-02-15 CG References and formatting
v01 2017-02-13 CG Minimal clarifications
v00 2017-01-17 FD Initial version
-->
</back> </back>
</rfc> </rfc>
 End of changes. 59 change blocks. 
673 lines changed or deleted 706 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/