<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3986 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.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"
     docName="draft-dold-payto-00"
     ipr="trust200902">

  <front>
    <title abbrev="The 'payto' URI scheme">
      The 'payto' URI scheme for payments
    </title>

    <author fullname="Florian Dold" initials="F.D." surname="Dold">
      <organization>INRIA</organization>
      <address>
        <postal>
          <street>&Eacute;quipe TAMIS</street>
          <street>INRIA Rennes Bretagne Atlantique</street>
          <street>263 avenue du G&eacute;n&eacute;ral Leclerc</street>
          <street>Campus Universitaire de Beaulieu</street>
          <city>Rennes</city>
          <region>Bretagne</region>
	  <code>F-35042</code>
          <country>FR</country>
        </postal>
        <email>florian.dold@inria.fr</email>
      </address>
    </author>

    <author fullname="Christian Grothoff" initials="C.G." surname="Grothoff">
      <organization>INRIA</organization>
      <address>
        <postal>
          <street>&Eacute;quipe TAMIS</street>
          <street>INRIA Rennes Bretagne Atlantique</street>
          <street>263 avenue du G&eacute;n&eacute;ral Leclerc</street>
          <street>Campus Universitaire de Beaulieu</street>
          <city>Rennes</city>
          <region>Bretagne</region>
	  <code>F-35042</code>
          <country>FR</country>
        </postal>
        <email>christian@grothoff.org</email>
      </address>
    </author>

    <date day="29" month="March" year="2017" />

    <!-- Meta-data Declarations -->
    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>

    <keyword>payments</keyword>

    <abstract>

      <t>This document defines the 'payto' Uniform Resource Identifier (URI) scheme
      for specifying payments.</t>

    </abstract>

  </front>

  <middle>

<section anchor="introduction" title="Introduction">
<t>
  This document defines the 'payto' Uniform Resource Identifier (URI) <xref target="RFC3986" /> scheme
  for specifying payments.  In its simplest form, a 'payto' URL
  identifies a payment method and optionally an account identifier.  Additional parameters
  for a payment, such as an amount or a payment reference, can be provided.
</t>
</section>

<section anchor="syntax"
  title="Scheme Syntax">
  <t>
  This document uses the Augmented Backus-Naur Form (ABNF) of <xref target="RFC5234" />.
  Certain values are included by reference from <xref target="RFC3986" />:
  </t>
  <figure>
  <artwork type="abnf"><![CDATA[
  payto-URI = "payto" "://" method account [ "?" params ]
  params = param *( "&" param )
  param = (generic-param / method-specific-param) "=" *pchar
  generic-param = "amount" / "recipient-name" / "sender-name" /
               "message" / "instruction"
  method-specific-param = *pchar
  method = <authority, see [RFC3986], Section 3.2>
  account = <path-abempty, see [RFC3986], Section 3.3>
  pchar = <pchar, see [RFC3986], Appendix A.>
  amount = [ currency ":" ] unit [ "." fraction ]
  currency = 1*ALPHA
  unit = 1*(DIGIT / ",")
  fraction = 1*(DIGIT / ",")
]]>
  </artwork>
</figure>
</section>

<section anchor="semantics" title="Scheme Semantics">
<t>
  The authority component of a payment URI identifies the payment method.  The registry
  for payment methods is defined in <xref target="payment-methods" /> of this document.

  The path component of the URI identifies the target account for a payment as interpreted
  by the respective payment method.

  The query component of the URI can provide additional parameters for a payment.
  Every payment method SHOULD accept the options defined in generic-opt.
</t>
</section>

<section anchor="examples" title="Examples">
<figure>
  <artwork><![CDATA[
  payto://sepa/CH9300762011623852957?amount=EUR:200.0&message=hello

  INVALID (authority missing):  payto:sepa/12345
]]>
  </artwork>
</figure>

</section>

<section anchor="payment-methods" title="Payment Methods">

<t>sepa: Single European Payment Area. The path is an IBAN, as defined by <xref target="ISO20022" />.</t>
<t>upi: Unified Payment Interface. The path is an account alias, as defined by <xref target="UPILinking" />.</t>
<t>bitcoin: Bitcoin protocol. The path is a bitcoinaddress, as defined by <xref target="BIP0021" />.</t>
<t>ach: Automated Clearing House.  The path is a bank account number, as defined by <xref target="NACHA" /></t>

</section>

<section anchor="generic-options" title="Generic Options">
<t>
  The following options SHOULD be understood by every payment method.
</t>
<t>

  amount:  The amount to transfer, including currency information if applicable. The format MUST be:
<figure>
  <artwork><![CDATA[
  amount = [ currency ":" ] unit [ "." fraction ]
  currency = 1*ALPHA
  unit = 1*(DIGIT / ",")
  fraction = 1*(DIGIT / ",")
 ]]>
  </artwork>
</figure>
  The fraction MUST be smaller than 10^8.  The unit value MUST be smaller than 2^53.  The use of commas
  is optional for readability and they MUST be ignored.
</t>

<t>
  recepient-name:  Name of the recipient of the payment.
</t>

<t>
  sender-name:  Name of the sender of the payment.
</t>

<t>
  message:  A short message to identify the purpose of the payment, which MAY
  be subject to lossy conversions (for example, due to character set encoding
  limitations).
</t>

<t>
  instruction:  A short message giving instructions to the recipient, which
  MUST NOT be subject to lossy conversions.  Character set limitations allowed
  for instructions depend on the payment method.
</t>
</section>

<section anchor="interoperability" title="Interoperability">
<t>
  This URI scheme subsumes other URI schemes for payments, such as
  "bitcoin" (provisionally registered) and "upi" (unregistered but in use,
  see <xref target="UPILinking" />), providing one unified scheme for payment information.
</t>
</section>

<section anchor="encoding" title="Encoding">
<t>
  The payto URI scheme encoding conforms to the encoding rules established
  for URIs in <xref target="RFC3986" />.

  Various payment systems use restricted character sets.  An
  application that processes 'payto' URIs MUST convert characters that
  are not allowed by the respective payment systems into allowable
  character using either an encoding or a replacement table.  This
  conversion process is typically not lossless.
</t>
</section>

<section anchor="security-considerations" title="Security Considerations">
<t>
  The payto URL contains instructions on how to send money.  Applications
  that support the payto URI scheme MUST ask for confirmation from the
  user in order to confirm a payment.  Applications MUST handle payto
  URLs in conformance with the principle of safe interaction
  (http://www.w3.org/TR/webarch/#safe-interaction).
</t>
</section>


<!-- section anchor="checksums" title="Checksums">
<t>
  (how should fields be sorted?  does order ever matter?  how do we deal with duplicate fields?)
</t>

</section -->

</middle>

<back>

  <references title="Normative References">

    &RFC3986;

    <reference anchor="ISO20022">
      <front>
        <title>ISO 20022 Financial Services - Universal financial industry message scheme</title>
        <author>
          <organization>International Organization for Standardization</organization>
          <address>
            <uri>http://www.iso.ch</uri>
          </address>
        </author>
        <date month="May" year="2013"/>
      </front>
    </reference>

    <reference anchor="NACHA">
      <front>
        <title>NACHA Operating Rules &amp; Guidelines</title>
        <author>
          <organization>NACHA</organization>
          <address>
            <uri>https://www.nacha.org/</uri>
          </address>
        </author>
        <date month="January" year="2017"/>
      </front>
    </reference>

  <reference anchor="RFC5234">
    <front>
      <title abbrev="ABNF for Syntax Specifications">Augmented BNF for Syntax Specifications: ABNF</title>
      <author initials="D." surname="Crocker" fullname="Dave Crocker" role="editor">
        <organization>Brandenburg InternetWorking</organization>
        <address>
          <email>dcrocker@bbiw.net</email>
        </address>
      </author>
      <author initials="P." surname="Overell" fullname="Paul Overell">
        <organization>THUS plc.</organization>
        <address>
          <email>paul.overell@thus.net</email>
        </address>
      </author>
      <date month="January" year="2008"/>
    </front>
    <seriesInfo name="STD" value="68"/>
    <seriesInfo name="RFC" value="5234"/>
  </reference>


  </references>

  <references title="Informational References">

   <reference anchor="BIP0021" target="https://en.bitcoin.it/wiki/BIP_0021">
     <front>
         <title>Bitcoin Improvement Proposal 21</title>
         <author initials="N." surname="Schneider"
                 fullname="Nils Schneider">
         </author>
         <author initials="M." surname="Corallo"
                 fullname="Matt Corallo">
         </author>

         <date month="January" year="2012" />
     </front>
  </reference>

  <reference anchor="UPILinking" target="http://www.npci.org.in/documents/UPILinkingSpecificationsVersion10draft.pdf">
    <front>
      <title>Unified Payment Interface - Common URL Specifications For Deep
      Linking And Proximity Integration</title>
      <author><organization>National Payment Corporation of India</organization>
      </author>
      <date month="May" year="2016" />
    </front>
  </reference>

  </references>

  <!-- Change Log

v01 2017-02-15  CG   References and formatting
v01 2017-02-13  CG   Minimal clarifications
v00 2017-01-17  FD   Initial version
  -->
</back>
</rfc>
