WO2014071311A1 - Plateformes de financement de groupe et techniques associées - Google Patents

Plateformes de financement de groupe et techniques associées Download PDF

Info

Publication number
WO2014071311A1
WO2014071311A1 PCT/US2013/068328 US2013068328W WO2014071311A1 WO 2014071311 A1 WO2014071311 A1 WO 2014071311A1 US 2013068328 W US2013068328 W US 2013068328W WO 2014071311 A1 WO2014071311 A1 WO 2014071311A1
Authority
WO
WIPO (PCT)
Prior art keywords
api
payment
campaign
payments
group funding
Prior art date
Application number
PCT/US2013/068328
Other languages
English (en)
Inventor
Khaled Hussein
James Beshara
Original Assignee
Crowdtilt, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US13/909,626 external-priority patent/US20130325723A1/en
Application filed by Crowdtilt, Inc. filed Critical Crowdtilt, Inc.
Publication of WO2014071311A1 publication Critical patent/WO2014071311A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/06—Asset management; Financial planning or analysis

Definitions

  • a group funding application typically operating in a distributed network context such as the Internet collects money from one or more entities (e.g., individuals or organizations) and then distributes the collected money to one or more entities.
  • entities e.g., individuals or organizations
  • group funding applications include one where people fundraise for a nonprofit organization or a political campaign; fans raise money to pay a struggling musician's medical bills; a group of friends pool their money together to rent a vacation home or planning a bachelor party, and what is commonly known as crowd funding where an entrepreneur tries to fund a startup company; etc.
  • crowd funding where an entrepreneur tries to fund a startup company
  • FIG. 1 is a simplified diagram of a computing environment in which various implementations may be provided.
  • FIG. 2 is a flow diagram illustrating an example of an implementation of a group funding platform.
  • FIG. 3 is a simplified diagram illustrating operation of a particular class of implementations of a group funding platform. DETAILED DESCRIPTION
  • group funding platform refers generally to a set of
  • group funding platform 104 e.g., using any type of client device 108 to set up a "campaign” in which one or more users 106, also referred to as “contributors,” contribute money to reach a goal or target, i.e., a defined amount of money for the campaign.
  • group funding platform 104 also interacts with one or more payment processors 112.
  • payment processors 112. As is well known, there are dozens of online payment processors including, for example, Amazon, PayPal, Stripe, BrainTree, Balanced, WePay, Dwolla, etc.
  • a group funding platform may be designed that works with one or multiple such payment processors. For example, multiple payment processors may be used to allow contributors to contribute to a single campaign in different ways. In another example, a contributor might be enabled to contribute to a campaign using one payment processor, and a beneficiary of the campaign might receive funds via another payment processor or distribution via another entity.
  • a group funding platform may also be designed to work with various forms of payment processing, e.g., credit cards, electronic checks, or other forms of currency, e.g., virtual currency (from gaming environments or online communities, Bitcoins, etc.).
  • Information relating to campaigns, users, and payments employed by group funding platform 104 is stored in one or more data repositories 114.
  • Users 106 make payments via interfaces of platform 104 (e.g., using any type of client device 108) which are mapped to an appropriate one of payment processors 112 (e.g., as described below) for authorization and/or payment.
  • the campaign ends (e.g., when a specified time period expires or when a specified termination trigger is met) the money is released to admin 102 or a beneficiary 118 designated by admin 102.
  • Group funding platform 104 may be implemented using one or more computing devices such as, for examples, one or more servers 110 as illustrated.
  • tilt amount a specified monetary goal or "tilt amount"
  • a tilt amount may be $5,000 for a campaign scheduled to end on March 15 th . Even if the tilt amount is reached on March 1 st , the campaign may continue and additional funds may be contributed beyond the tilt amount.
  • the tilt amount or some target higher than the tilt amount i.e., the goal amount
  • the tilt amount or some target higher than the tilt amount may be specified as what triggers termination of the campaign.
  • a campaign may be set up to accept one or more different types of contributions including fixed amounts, minimum amounts, any amount specified by the contributor, or a dynamic amount as defined by the campaign admin.
  • ⁇ ество may be appropriate for different types of group funding.
  • fixed amounts allow for an admin to enforce specific contribution amounts.
  • Such a capability might be useful, for example, for an event promoter to sell "tickets" (e.g., for a house concert) for one or more specific amounts (as opposed to relying on each contributor to enter an appropriate amount).
  • a minimum amount allows the admin to ensure that anyone contributing to a campaign contributes at least the minimum. This might be useful where, for example, someone is trying to raise funds from a group of friends to purchase a birthday gift for a mutual friend.
  • Contributors might be encouraged to contribute more than the minimum (e.g., with promises of a better gift) but they are at least required to cover some minimum cost if they plan to participate in the group gift. Allowing the contributors to select the amount they would like to contribute provides considerable flexibility. For example, such an approach might be useful in an application where it is important to facilitate participation by the greatest number of contributors, e.g., charitable giving or development. Examples of the use of dynamic pricing are provided below.
  • platform 104 may be a web site, e.g., crowdtilt.com, that provides a platform that enables many unrelated campaigns to be set up and conducted by many unrelated individuals and/or groups.
  • platform 104 can be a standalone application supporting only one or a relatively small number of related campaigns that is/are set up by or associated with a single individual or entity; see, for example, crowdhoster.com (provided by Crowdtilt) which allows anyone to develop and launch his or her own group funding platform.
  • crowdhoster.com providerd by Crowdtilt
  • Another alternative is a third party online portal using a group funding application programming interface (API) as discussed below.
  • API group funding application programming interface
  • a group funding platform implemented as described herein may support use cases having different types of correspondence (e.g., one-to-one, one-to-many, many-to-one and many-to-many) among the various entities involved in campaigns (e.g., admins, applications, campaigns, contributors, communities of contributors, beneficiaries, etc.).
  • campaigns e.g., admins, applications, campaigns, contributors, communities of contributors, beneficiaries, etc.
  • a single application might support many campaigns set up by many different admins.
  • a single admin might create and manage multiple campaigns.
  • a single campaign might be set up to benefit multiple beneficiaries, or multiple campaigns could be set up to benefit a single beneficiary.
  • Many contributors might be enabled to contribute to many different campaigns. Those of skill in the art will appreciate other such examples.
  • FIG. 2 is a flow diagram illustrating some of the functionalities that may be provided in a group funding platform or application as described herein.
  • a user When a user (e.g., an admin or a contributor to a campaign) interacts with the platform or application she or he may, among other things, create or modify a campaign, contribute to an existing campaign, or collect accumulated funds for an existing campaign (e.g., request that the funds be released from an intermediary account after the campaign has "tilted").
  • logging into or creating an account for a group funding platform or application may be optional in that implementations are contemplated in which a user may interact with a platform or application without doing so.
  • a contributor might contribute to a campaign anonymously, or potential contributor might anonymously browse existing campaigns.
  • a user might be allowed to begin creation of a campaign without logging in.
  • a non-user can create a campaign, launch it, and accept commitments from contributors in the form of authorizations.
  • the contributors would be charged only after the tilt amount is reached and the campaign admin creates an account.
  • a beneficiary might receive funds (e.g., into an account specified by an admin) without ever interacting with the platform.
  • a user might not be required to create an account, but may still have to provide some minimal information to address regulatory concerns, e.g., to verify user identity. In such a case, a returning user would be required to re-enter the information.
  • the platform receives or retrieves the user's payment information (208) which might include, for example, credit card information or other suitable payment information (e.g., a PayPal account, a debit account, type of currency, etc.).
  • a first time contributor might be presented with an interface by which the payment information may be entered, while the payment information for a returning contributor might be retrieved from the system's database.
  • the campaign has "tilted" (210), i.e., the campaign's tilt amount has already been reached, payment is both authorized and settled (212) and the user is notified (214). If the campaign has not yet tilted, only payment authorization (e.g., a valid authorization to charge a credit card) is secured (216) and the user may also be notified (214).
  • expiration of a campaign may be triggered by a variety of events. For example, a campaign may expire when a target amount of monetary contributions has been reached. This may be the campaign's tilt amount or may be a goal amount that exceeds the tilt amount. Alternatively, a campaign may expire after a set period of time or at a particular moment in time. As yet another alternative, a campaign may expire after a particular number of contributors have participated. Other suitable alternatives will be apparent to those of skill in the art. As also shown in FIG.
  • a user may also interact with the platform to create a campaign (230-234), or to collect the accumulated funds for her or his campaign (236, 238).
  • Some implementations of group funding platforms or applications employ custom code specifically written for the use cases and functionalities supported by the particular platform or application, e.g., policies for handling payments and refunds, modes of payment, authorization of payments, payment processors supported, etc.
  • custom-built solutions may be suitable for the particular use cases for which they are designed, but may not be easily adapted for other use cases.
  • an application programming interface (API) which may be used to enable a wide variety of group funding or other commerce applications for any merchant online.
  • the API specifies an interface among the software components of such applications that abstracts a number of functionalities in such a way to enable a more efficient approach to implementing and scaling group funding applications and services.
  • APIs implemented as described herein enable the aggregation and queuing of transactions over multiple campaigns, users, and payment processors in a manner that facilitates the scaling of a service or application to encompass new use cases and/or modes of operation.
  • a group funding platform 304 may include a group funding application 307 and an application programming interface (API) 308 that lies between group funding application 307 and the one or more payment processors.
  • API 308 provides a layer of abstraction between application 307 and the payment processors and defines several object classes including, for example, campaign, user, payment (inbound payments, e.g., contributions, and outbound payments, e.g., payments to administrators or beneficiaries), comments, credit cards, and bank accounts.
  • a campaign represents a defined goal that one or more users achieve through payments.
  • Information relating to these various objects employed by application 307 and specified using API 308 is stored in one or more data repositories (e.g., data repository 114 of FIG. 1).
  • the layer of abstraction provided by API 308 allows the developer of a campaign (e.g., an admin) to focus on the goal of the campaign rather than the logistics of how payments and the release of funds will be achieved.
  • the minimum amount of information required to create a user is a valid email address, but considerably more information may be requested, collected, and stored for a given user representing different status and/or permissions.
  • the user's identity may need to be verified to comply with regulatory or legal requirements.
  • user authentication may be advisable therefore requiring some form of login or other suitable authentication credentials.
  • the range of possibilities will be understood by those of skill in the art. It should also be noted that users may interact with a group funding platform as described herein without being a user as defined by the API.
  • an anonymous user may browse campaigns, or even contribute to a campaign without a user being created from the perspective of the API.
  • a beneficiary of the funds raised by a campaign may or may not be a user in the context of the API. The beneficiary may just be the recipient beneficiary of the funds raised.
  • a user might be registered with a third party (e.g., an online merchant) that has an application that connects with the platform. This user may have a unique user identity with the third party, and would be created as a user in the API databases, but the user object would contain a minimal amount of information about that third party's user, e.g., his or her email address, to identify them.
  • APIs implemented as described herein enable management of objects within predefined object classes, e.g., the management of objects within the user class (e.g., a
  • the admin setting up a campaign defines the monetary goals (which may be the tilt amount or the goal amount - which is the amount they would like to reach on the higher end) as well as a variety of other parameters including, for example, any of: the campaign duration/expiration, a target amount beyond the monetary goal at which the campaign expires, the payment processor(s), the currency, the language, the mode of release of the accumulated funds, type of payment, etc.
  • Each user (including the admin or campaign creator) is defined by a set of attributes that sufficiently uniquely identify the user and may specify the specific campaign or campaigns with which that user is associated.
  • the API itself may include some level of permissions capability by which the activities of users are defined and controlled. For example, a user may be given administrator permissions or contributor permissions.
  • an API integrator e.g., an online merchant that provides group funding capacities via the API
  • API 308 has an interface with associated logic (e.g., library 116 of FIG. 1) to enable the API to correctly interface with various payment processors (e.g., payment processors 112 of FIG. 1).
  • Library 116 abstracts the interaction with various payment processors such that group funding applications using the API can interface with the payment processors through one standardized internal-facing contract. Not all payment processors, for example, do holds the same way, or charge cards the same way Additionally, what actually occurs when payment is released to an admin (e.g., admin 102 of FIG. 1) depends on what is allowed and/or required by the payment processor associated with the campaign. Some payment processors allow debiting and deposit of funds directly from and to designated bank accounts. Still others might allow charging a credit card account.
  • API 308 may be PCI compliant, i.e., compliant with the Payment Card Industry Data Security Standard (PCI DSS), an information security standard for organizations that handle cardholder information for the major debit, credit, prepaid, e- purse, ATM, and POS cards, the current version of which is version 2.0 released on October 26, 2010, the entirety of which is incorporated herein by reference for all purposes.
  • PCI DSS Payment Card Industry Data Security Standard
  • code e.g., Java script
  • API 308 may be provided for use with API 308 to enable applications or clients that would otherwise not be PCI compliant to operate in a PCI compliant manner.
  • code e.g., Java script
  • API 308 may be provided for use with API 308 to enable applications or clients that would otherwise not be PCI compliant to operate in a PCI compliant manner.
  • implementations of API 308 are contemplated that are compliant with a variety of information and financial security standards used throughout the world. References to PCI DSS should therefore not be used to limit the scope of the invention.
  • the admin may specify a mode of releasing payment that is not supported by the payment processor being used.
  • the designated payment processor for a particular campaign might be Balanced, while the admin has specified that he'd like the money to be released to his PayPal account.
  • Balanced may not directly support such a payment mode.
  • the API is configured to facilitate release of the funds using a payment mode supported by the designated payment processor to, for example, an intermediate holding account, and then facilitate release of the funds from the intermediate account via the payment mode specified by the admin, e.g., to the admin's PayPal account.
  • such an intermediate holding account may be a third party account (e.g., associated with the payment processor or other financial institution) or may be provided as an option with the group-funding platform or API to provide a total solution to the third party merchant.
  • each admin has a payment processor as one of his defined attributes.
  • the API needs to release funds in connection with a particular campaign, it refers to the user specification for that campaign's admin to identify the payment processor and load the appropriate module (e.g., using a "factory model" approach). This allows the API to support a large number of admin users, each of which may select his own payment processor.
  • an admin may have a holding account provider and/or a payment distributor as defined attributes to further inform a campaign specification.
  • an admin may have multiple associated payment processors each associated with different campaigns.
  • the API then uses the admin and the campaign to identify and load the appropriate payment module. This allows an admin the flexibility of selecting a payment processor that best suits a particular campaign. For example, one payment processor might be more advantageous (e.g., cheaper) for a particular monetary goal, while another might support a level of security or reporting that is necessary to satisfy legal and/or regulatory requirements that may be associated with certain types of campaigns.
  • APIs as described herein may be implemented to work with a variety of modes of payment including, for example, credit cards, Automated Clearinghouse (ACH) payments (e.g., account debiting), online payment (e.g., PayPal, Dwolla, etc.), and various others.
  • ACH Automated Clearinghouse
  • online payment e.g., PayPal, Dwolla, etc.
  • currencies can be conventional national currencies, but may be other types of currencies as well, e.g., virtual currencies (e.g., Bitcoins or currencies associated with a gaming environment or an online community).
  • selection of a payment processor by an admin creating a campaign is guided by payment processor selection logic that allows the admin to select from among a plurality of criteria, and then automatically selects or suggests one or more payment processors that conform to the selected criteria. For example, if you want a payment processor to work within a certain jurisdiction, the logic would select a payment processor that provides that functionality. Another example is where the logic would select a payment processor that operated in desired jurisdictions and offered the cheapest charges for the volume of transactions desired for the campaign.
  • Particular implementations of a group funding API also enable group funding application functionalities relating to collaboration and communication among the users associated with a particular campaign or goal. Additionally, such functionalities may include, for example, sending of invitations to prospective contributors, messaging (e.g., text, email, etc.) among users involved in a campaign, sharing or expressing approval of campaigns using social media (e.g., Facebook, Twitter, etc.), sending of updates to users associated with a campaign, posting of comments on a campaign web page, etc. As will be understood, these are merely examples of the wide range of collaboration and
  • a group funding API implemented as described herein may be employed to enable a vast array of group funding applications.
  • the range of possibilities could include, for example, a Guatemalan coupon site or a Nigerian community action campaign contribution application.
  • Such APIs can enable a wide variety of commercial transactions for existing commerce sites in which a group of users purchase a single item of inventory, e.g., eight people rent a vacation home through VRBO.com; three brothers purchase a single Mother's Day gift on Tiffany.com; etc.
  • a group funding platform might create thousands of admin users and campaigns, millions of contributor users, and thousands of payment types.
  • a group funding application focused on a particular market segment e.g., vacation rentals
  • a group funding application focused on a particular market segment might create only one or a handful of admin users, hundreds or thousands of campaigns, and hundreds of thousands or millions of contributors.
  • Another group funding application might have only one admin, one campaign and 50 contributors. The range of variations will be apparent to those of skill in the art.
  • an admin can create a campaign (e.g., by specifying the various parameters using the specifications and methods described in the Crowdtilt API Specs documentation attached hereto), and then test the campaign in a sandbox environment provided by the group funding platform.
  • an admin may also specify attributes of the payments by each of the contributors to the campaign. For example, the admin could specify a minimum payment amount or a fixed payment amount or both.
  • Various other policies or attributes relating to payments may also be specified.
  • a dynamic pricing policy (represented by optional blocks 242-246 of FIG. 2) may be specified in which the payment amount varies over time or with respect to some other parameter.
  • the dynamic nature means the pricing models offered may include both increasing and decreasing pricing attributes per a defined metric— i.e., the price for something may be configured to go up or down.
  • a party promoter has a fixed amount of tickets to sell. They want to offer 100 tickets for sale, with the starting price of $20 for ticket number 1, and an ending price of $50 for ticket number 100.
  • the party promoter can instruct the platform to linearly increase the price for the tickets so that after each ticket sale, the price for the next ticket increases a fixed amount, i.e., so that there are 99 price increases of a fixed number.
  • Another ability of dynamic pricing is where the price may go down over time.
  • One implementation of this dynamic pricing is where the final amount that is settled for all contributors is equal, and is based upon dividing the goal amount by the total contributors, at which point each contribution must be above a certain amount.
  • the whole group equally shares in the benefits for more contributors joining. However, there may be an implementation where contributors share disproportionately.
  • a group might set up a campaign to raise a target amount to pay for a week-long vacation rental house that sleeps up to 16 people.
  • a payment amount could be set initially that achieves the campaign's goal with fewer than 16, e.g., 10, contributors.
  • Dynamic downward pricing brings authorization and settlement challenges which the API may address. These challenges come into play once the tilt amount is reached.
  • each contributor's contribution is reauthorized for his or her initial authorization amount until the authorization is settled.
  • the reauthorization amount is reduced based upon risk logic.
  • tilt amount is reached and reauthorizations are reduced to the value of the amount that would be allocated at that moment to each contributor should the campaign end, e.g., by dividing the total amount raised by the number of contributors.
  • Other implementations would understood by those of skill in the art.
  • the benefits of such an approach become even more apparent as the size of the funding community increases, e.g., 60 person party bus, 1000 person cruise, etc. As would be understood, the redistribution of cost as the number of contributors increases would be a nuisance in the real world for such applications.
  • payment involves two distinct phases; authorization and charging/debiting.
  • authorization For a campaign in which contributors are not charged unless a tilt amount is reached during the specified duration of the campaign, when a contributor makes a contribution using a credit or debit card, an authorization from the card issuer or bank is obtained (via the associated payment processor(s)) which may have an expiration that is earlier than the end of the campaign. That is, each card issuer or bank authorizes payment for a card for a limited period of time during which the payment is guaranteed.
  • the authorization may last anywhere from minutes to hours to days. Referring again to the example of FIG.
  • the group funding application gets a reauthorization (216) to ensure that the authorization remains "fresh” until the tilting and/or expiration of the campaign (e.g., 218 and/or 224).
  • this reauthorization is obtained within a very short period of time after the time of expiration of the original authorization, e.g., within one or more seconds. Because it is statistically unlikely that the reauthorization will be denied because of other debits or credits posting during that short time period, this approach greatly reduces one of the major issues faced by conventional group funding applications and platforms, i.e., contributors to a campaign reconsidering their contribution. When this happens, the group funding provider is forced to either track down the
  • reauthorization mechanism greatly reduces the incidence of such events.
  • the actual period between authorizations may vary according to the circumstances and risks of the business.
  • the ability to cancel an authorization upon a specified event such as when the tilt amount is not reached and the campaign is expired.
  • the ability to cancel an authorization affords the controls to either cancel an authorization immediately upon the expiration of a non-tilting campaign, or to provide some other time duration to cancel the authorizations.
  • a campaign may be set up with an initial payment amount for which payment is authorized for each contributor. This initial payment amount can be thought of as the maximum that a contributor would be charged if the campaign tilts. Once the target amount of the campaign has been reached (e.g., there are sufficient funds to cover a 1000 person cruise) the campaign can be considered tilted, but the existing authorizations may not be settled at that point. Instead, additional contributions may be received and authorized until the campaign expires or is otherwise terminated. And as these additional contributions are received, the amount that individual contributors will ultimately be charged may be adjusted according to a dynamic pricing model specified by the admin.
  • the dynamic pricing model might specify that all contributors be charged a pro rata share of the campaign's goal amount or a combination of that, but not less than $X.
  • the dynamic pricing model might weight the amounts corresponding to individual contributors according to any of a variety of schemes (e.g., charged contributions might be larger for later contributors). Once the campaign expires, each contributor is charged only her or his adjusted payment amount regardless of the currently authorized payment amount for that contributor.
  • the manner in which payment authorizations are handled to support dynamic pricing may vary for different implementations.
  • the initial payment amount, and therefore the payment amount for which authorization is obtained for each contributor may not change over the duration of the campaign. That is, regardless of whether the campaign's target amount has been reached or exceeded, the same payment amount is authorized for each successive contributor.
  • any necessary payment reauthorizations would be for the same amount, and it is only when the campaign expires that each contributor is charged an adjusted payment amount according to the specified dynamic pricing model.
  • Such an approach would mitigate the risk of contributors pulling out, or payment reauthorizations or settlements failing for some contributors.
  • the requested payment amount, payment authorization amount and/or reauthorization amount may vary over the duration of the campaign, e.g., they might be determined with reference to the adjusted payment amount.
  • payment authorizations for some initial set of contributors would correspond to the initial payment amount until the target amount for the campaign is reached.
  • the requested payment amount and the payment authorization amount for subsequent contributors may be reduced to reflect the adjusted payment amount. This reduction may be done in a granular fashion which reflects the adjusted payment amount in near-real time, or in steps as the adjusted payment amount passes through one or more thresholds.
  • Any necessary payment reauthorizations may be for the original payment authorization amount, or may also be reduced in a similar manner with reference to the adjusted payment amount. Other variations will be understood by those of skill in the art.
  • cloud computing refers to computing models for enabling ubiquitous, convenient, on-demand network access to a shared pool of computing resources (e.g., networks, servers, storage, applications, and services). Cloud-based services are rapidly becoming the primary way in which services are provided to businesses and consumers over the Internet and the World Wide Web. The scope of the invention should therefore not be limited to any particular configuration of computing resources.
  • JSON JavaScript Object Notation
  • this class of implementations is implemented in accordance with at least some of the guiding principles embodied by the REST (REpresentational State Transfer) computing paradigm.
  • REST REpresentational State Transfer
  • the currently evolving notion of a "RESTful” system is based on the doctoral dissertion of Roy Thomas Fielding entitled Architectural Styles and the Design of Network-based Software Architectures, University of California, Irvine (2000), the entirety of which is incorporated herein by reference for all purposes.
  • a RESTful system generally observes a set of principles that define how Web standards such as HTTP and URLs may be used to facilitate heterogeneous application-to-application communication.
  • HTTP HyperText Transfer
  • the API defines a specific set of responses for an application's various software components to the HTTP methods. That is, the API defines a set of rules for how it and the various software components with which it interacts operate on the contents of a query for each of the different methods.
  • a list of HTTP methods for a particular implementation is provided in the attached Crowdtilt API Specs documentation referenced above. Some implementations employ HTTPs (the secure version of HTTP) to obscure important information from potentially malicious third parties.
  • HTTPs the secure version of HTTP
  • authorization in some steps of some system flows may be achieved in accordance with Basic Authentication over SSL which, in the context of an HTTP transaction, is a method for an HTTP user agent to provide a user name and password when making a request.
  • Other forms of authentication e.g., OAuth
  • OAuth OAuth
  • the computer program instructions with which embodiments of the invention may be implemented may correspond to any of a wide variety of programming languages, software tools and data formats, and be stored in any type of volatile or nonvolatile, non-transitory computer-readable storage medium or memory device, and may be executed according to a variety of computing models including, for example, a client/server model, a peer-to-peer model, on a stand-alone computing device, or according to a distributed computing model in which various of the functionalities may be effected or employed at different locations.
  • reference to particular protocols herein are merely by way of example. Suitable alternatives or those later developed known to those of skill in the art may be employed without departing from the scope of the invention.
  • the Crowdtilt API opens up the opportunity for developers to:
  • the API also works with credit cards and ACH debit payments or a combination of these.
  • the API provides collaboration tools such as commenting/updates, nested comments, messaging, notii cations, and tracking of those that have paid and those that haven't.
  • the API defines 3 main objects: campaign, user, and payment.
  • a campaign represents a monetary goal that one or more users try to achieve through payments.
  • the campaign can define multiple payment policies such as fixed payments, e.g, tickets, or variable payments, e.g., donations.
  • the campaign When the campaign is created, it has to have at least one user to act as the owner or the campaign admin. Once the campaign goal is achieved, the money is sent to the campaign admin according to the policies defined when the campaign was created.
  • Crowdtilt is fully PCI compliant and security is of paramount importance to our team. Crowdtilt forces HTTPS for all services, including our public website. All data is stored in a Payment Industry Data Security Standard (PCI DSS) Compliant environment.
  • PCI DSS Payment Industry Data Security Standard
  • Crowdtilt provides a PCI-compliant javascript library, crowdt i l t . j s, which is easy to implement on your website. Sensitive payment information can then be securely collected without ever touching your servers, keeping you completely outside of PCI and regulatory scope. See Tokenizing
  • the Crowdtilt API can be used in a single-project environment (i.e.
  • the first step is to get an APT KEY and APT SECRET.
  • APT KEY and APT SECRET.
  • the sandbox environmeni will be configured with a free Balanced account. If you need support for a different payment processor, please let us know.
  • All resources contain a metadata field for storing key -value pairs of extra data. Store as many of these key- value pairs as y ou wish.
  • This field Some common uses of this field include storing extra user data, such as address fields or profile image urls, or storing extra campaign data, such as a campaign description field or campaign image url.
  • campaigns uri “ /vl /users /USREC5 /campaigns " ,
  • the verification data is as follows:
  • is_verifled on the user object will be set to 1 to reflect this change.
  • campaigns uri “ /vl /users /USREC5 /campaigns " ,
  • total_entries 2 ,
  • campaigns uri “ /vl /users/USREC5 /campaigns”
  • paid campaigns uri “ : " /v1 /users /USREC5 /paid car
  • payments uri “ /vl /users /USR.EC5 /payments " , "metadata” : ⁇ “img” : "http://www.example.com/]
  • this request supports partial PUTs. For example, you can do a request to update a single attribute without having to send the full user
  • campaigns uri “ /vl /users /USREC5 /campaigns " ,
  • This resource returns all the campaigns that the user has created as well as the campaigns that he paid for.
  • This resource returns a specific campaign created by this user.
  • tilt amount 100
  • This resource returns all the campaigns that the user paid for.
  • total_entries 0
  • Card infomiation cannot be updated once it is set. You can however, modify the metadata of a Card. That is the only thing modifiable with this request. Other fields submitted will be ignored.
  • bank_code field is also referred to as a "routing number' the USA
  • Bank information cannot be updated once it is set. You can however, modify the metadata of a bank account. That is the only thing modifiable with this request. Other fields submitted will be ignored.
  • Campaign admins can create campaigns without having to be verified. However, they need to be ver fied in order to set, up their bank account details and then be able to receive the money collected in their campaign.
  • the metadata field is a great place to store references to other campaign assets, such as a campaign image.
  • tilt_amount 100
  • tilt_amount 100
  • this request supports partial PUTs. For example, you can do i request to update a single attribute without having to send the full camp. object.
  • the amount field determines how much money is going to the campaign.
  • the user_fee_amount accepts a value that will be charged to the paying user, on top of the amount, and the
  • campaign : ⁇ “id”: “CMP96B”, "uri” : “/vl/campaigns, "card” : ⁇ “id” : “CCPC41”, "uri” : “ /vl /users /USR521 , "user”: ⁇ “id” : “USR521”, “uri” : “ /vl /users /USR521 “ ,
  • a campaign settlement will show you the campaign, bank, and user that the settlement belongs to. it will also show 7 you the
  • the escrow_amount is how much money from the campaign is going into your escrow account (it represents fees charged to the admin and payers). Possible statuses for a campaign settlement are: needs bank account - this means
  • the bank account can be updated, as specified in the update campa n settlement section, re-sent pending - this means that the settlement previously failed, but the bank account has been updated, and the funds are being
  • a Campaign Settlement can only be updated if the status s needs bank account.
  • a bank object can be sent with the id of a new bank account to re-attempt the settlement with.
  • the only required fields are the user id of the comment author and the body of the comment.
  • the title, parent_id, and score fields are optional.
  • the parent_id is the id of the parent of this comment, i.e., the comment that this comment is a reply to. This only matters if you want to support nested comments. You may provide a parent id of null for top-level comments.
  • the purpose of the score field is to provide support for voting on
  • campaign_id “CMPCCC”,

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Finance (AREA)
  • Accounting & Taxation (AREA)
  • Development Economics (AREA)
  • Operations Research (AREA)
  • Game Theory and Decision Science (AREA)
  • Human Resources & Organizations (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Strategic Management (AREA)
  • Technology Law (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La présente invention concerne une diversité de techniques pour faciliter un financement de groupe dans un environnement informatique de réseau.
PCT/US2013/068328 2012-11-05 2013-11-04 Plateformes de financement de groupe et techniques associées WO2014071311A1 (fr)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US201261722457P 2012-11-05 2012-11-05
US61/722,457 2012-11-05
US201361772630P 2013-03-05 2013-03-05
US61/772,630 2013-03-05
US13/909,626 2013-06-04
US13/909,626 US20130325723A1 (en) 2012-06-04 2013-06-04 Group funding platforms and related techniques

Publications (1)

Publication Number Publication Date
WO2014071311A1 true WO2014071311A1 (fr) 2014-05-08

Family

ID=50628144

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2013/068328 WO2014071311A1 (fr) 2012-11-05 2013-11-04 Plateformes de financement de groupe et techniques associées

Country Status (1)

Country Link
WO (1) WO2014071311A1 (fr)

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2008005018A2 (fr) * 2006-07-06 2008-01-10 Firethorn Holdings, Llc Procédés et systèmes de conduite de transactions financières dans un environnement mobile
US20110082788A1 (en) * 2005-12-14 2011-04-07 Navaho Networks Inc. Electronic Funds Transfer
JP2011222008A (ja) * 2010-04-02 2011-11-04 Intel Corp モバイルデバイスにおける支払い管理
US20120109749A1 (en) * 2010-11-02 2012-05-03 Visa International Service Association Systems and Methods to Provide Recommendations

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20110082788A1 (en) * 2005-12-14 2011-04-07 Navaho Networks Inc. Electronic Funds Transfer
WO2008005018A2 (fr) * 2006-07-06 2008-01-10 Firethorn Holdings, Llc Procédés et systèmes de conduite de transactions financières dans un environnement mobile
JP2011222008A (ja) * 2010-04-02 2011-11-04 Intel Corp モバイルデバイスにおける支払い管理
US20120109749A1 (en) * 2010-11-02 2012-05-03 Visa International Service Association Systems and Methods to Provide Recommendations

Similar Documents

Publication Publication Date Title
US11250493B2 (en) System and method for performing social media cryptocurrency transactions
US11373182B2 (en) System and method for transferring funds
US10185959B2 (en) Shared pools for common transactions
US10497037B2 (en) System and method for managing cryptocurrency payments via the payment request API
EP3405862B1 (fr) Authentification de noeud de réseau
JP6727299B2 (ja) 非金融機関システムでのセキュア取引を促進するシステム及び方法
US20200111139A1 (en) Payment interchange for use with global shopping cart
US10019766B2 (en) Method, medium, and system for enabling gift card transactions
US20140172633A1 (en) Payment interchange for use with global shopping cart
JP2019506075A (ja) ブロックチェーンベースのトークナイゼーションを用いた交換
US20100191622A1 (en) Distributed Transaction layer
EP3189414A2 (fr) Système de vérification pour transmission sécurisée dans un réseau de traitement distribué
US20110106703A1 (en) Computerized deposit account management
US20130151432A1 (en) System, computer-storage medium and methods for allocation of donations between parties
JP6775590B2 (ja) 安全な電子取引を促進するシステム及び方法
BR112013021057A2 (pt) aparelhos, métodos e sistemas de pagamento eletrônico universal
US20160071095A1 (en) Requesting payments for selected items or services using payment tokens
US20130325723A1 (en) Group funding platforms and related techniques
CN103337019A (zh) 对支付交易进行定向于用户的选择性控制的方法和系统
US20240078547A1 (en) System and method for facilitating transferring funds
US20100106663A1 (en) System and method for facilitating charitable donations and goals
WO2014071311A1 (fr) Plateformes de financement de groupe et techniques associées
US20230298005A1 (en) Multi-layer cryptocurrency conversions using available blockchain outputs
Bibodi PodWeb: a decentralized application powered by Ethereum network
Moujaled Cryptocurrency wallet for virtual currencies

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13850603

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13850603

Country of ref document: EP

Kind code of ref document: A1