The purpose of PaySwarm is to build payment into the core architecture of the Web. This document details a mechanism called payment intents that can enable decentralized crowd-funding for projects and innovative initiatives.

Introduction

General introduction to crowd-funding and parameterized transactions.

The Payment Intent Process

A payment intent is the agreement to execute a transaction once a pre-defined set of external parameters have been met. The most direct example of this is when a group of funders promises to fund a project if the project can raise a minimum amount of capital by a certain date.

Payment Intent Terms

The following terminology is used to describe concepts used when processing payment intents.

promisor
A participant that has created a parameterized listing that will result in a payment intent if transacted.
promisee
A participant that is making a promise to enter into a contract if the terms of the parameterized listing are met before a certain date and time.

The Payment Intent Algorithm

The following algorithm describes the payment intent process, which consists of three distinct phases. The first phase is the publication of the parameterized listing by the promisor. The second phase is the submission of payment intents from promisees. The third phase is the finalization of transaction intents into contracts.

This section still needs a ton of work: specify the [[!JSON-LD]] messages that are transmitted in detail, examples, and cover error conditions and exceptions.

  1. The promisor creates an asset describing the asset provided if the parameters in the parameterized listing are met. The promisor also creates a parameterized listing containing at least the following two fields:
    ps:constraint
    A set of parameters that must be met in order to complete the transaction.
    com:minimumAmount
    The minimum amount necessary, in aggregate, to finalize all payment intents before the deadline.
    com:currency
    The currency associated with the minimum amount field.
  2. When an authority processes the parameterized listing, per The Purchase Algorithm, a ps:Contract and ps:Receipt are generated as specified in the algorithm, but funds MUST NOT be disbursed at that time. Instead of the ps:Receipt's ps:contract's property being of @type ps:Contract, it MUST instead be of type ps:PaymentIntent. All other fields must remain the same both in the short-form contract and the long-form contract. The promisor's publishing agent is notified of the intent in the same way as it would be notified of a purchase except that the resulting receipt will be the modified object as described in this step.
  3. The promisee's authority then notifies the promisor's authority of the payment intent by retrieving the transaction service IRI from the configuration service. The ps:PaymentIntent is sent to the promisor's authority via an HTTPS POST.
  4. The promisor's authority keeps track of all ps:PaymentIntent's for the parameterized listing until the end of the ps:validUntil date in the listing or until the com:minimumAmount in the ps:constraint property in the listing has been met in aggregate.
  5. If the authority detects that the com:minimumAmount in the ps:constraint property in the listing has been met in aggregate, it submits all ps:PaymentIntents for the parameterized listing to each promisee's authority. That is, for every com:source financial account intended to transfer money to the com:destination in each ps:PaymentIntents, the source financial accounts authority is contacted.
  6. The promisor's authority MUST determine if all promisee's can meet their obligation. It does so by contacting each promisee's authority and performing an HTTP POST of all ps:PaymentIntents intended for the authority to the transaction service with an additional query parameter where the key is mode and the value is query. Each promisee's authority responds with a total amount of funds that are available to be committed.
  7. If the previous step is successful and there are enough funds to meet the com:minimumAmount constraint, then the promisor's authority MUST then place all amounts listed in all ps:PaymentIntent on hold. It does this by contacting each promisee's authority by performing an HTTP POST of all ps:PaymentIntent's intended for the authority to the transaction service with an additional query parameter where the key is mode and the value is hold. Each promisee's authority responds with a total amount of funds placed on hold.
  8. If the previous step is successful and enough funds were placed on hold to meet the com:minimumAmount constraint, then the promisor's authority MUST then retrieve all amounts listed in all ps:PaymentIntents. It does this by contacting each promisee's authority by performing an HTTP POST of all ps:PaymentIntent's intended for the authority to the transaction service with an additional query parameter where the key is mode and the value is finalize. Each promisee's authority responds with a finalized contract for each ps:PaymentIntent and disburses the funds according to the Decentralized Settlement Algorithm.
  9. The promisor's authority marks the parameterized listing as being fulfilled and any further ps:PaymentIntents submitted before the ps:validUntil date are automatically processed according to the previous step.