People and roles

Who created the agreement is not automatically who pays.

A person may hold one role or several, but SecurePay never assumes two roles are the same thing.

A practical example: buying cement

  1. 1MaryProposes the agreement
  2. 2JamesFunds it
  3. 3Kamau HardwareSupplies the cement
  4. 4The site supervisorProvides delivery evidence
  5. 5MaryConfirms the delivery condition
  6. 6Kamau HardwareReceives the eligible settlement

Every role SecurePay recognises

  • Creator or proposer

    The person or organization who prepared and proposed this agreement version.

    It does not mean they fund the agreement, perform the work or approve a release.

    Common actions

    • Prepare the agreement
    • Invite participants
    • Propose a new version

    Acceptance. The creator still accepts their own responsibilities like any other participant.

  • Payer

    The participant who connects money to the agreement.

    It does not mean they decide alone that a condition is satisfied.

    Common actions

    • Fund the agreement
    • Review evidence
    • Request a review

    Acceptance. Acceptance of the version is required before funding is requested.

  • Recipient

    The participant who receives an eligible amount when the conditions are satisfied.

    It does not mean money is available on request.

    Common actions

    • Accept the version
    • Confirm settlement destination
    • Track eligibility

    Acceptance. Yes. A recipient must accept before an amount becomes eligible for them.

  • Performer

    The participant who carries out a responsibility.

    Performing work does not automatically confirm the condition attached to it.

    Common actions

    • Begin the responsibility
    • Submit evidence
    • Report a blocker

    Acceptance. Yes, for the responsibility they are named in.

  • Evidence provider

    The participant who supplies a record supporting what happened.

    Providing evidence is not confirming a condition.

    Common actions

    • Upload a delivery note
    • Record a location
    • Add a testing record

    Acceptance. Acceptance of the evidence responsibility is required where it is named.

  • Condition confirmer

    The identified participant permitted to record a response about a specific condition.

    It does not mean they own the money or can move it directly.

    Common actions

    • Confirm delivery
    • Record that something is not satisfied
    • Ask for clarification

    Acceptance. Yes. The confirmer must accept the condition they are responsible for.

  • Approver

    A person with recorded authority who accepts a specific proposal, stage or decision.

    It does not mean they performed or witnessed the work.

    Common actions

    • Approve a stage
    • Decline with a reason
    • Approve a material change

    Acceptance. Yes, and their authority must be recorded before it applies.

  • Organizer

    A named participant responsible for a group purpose and its recorded governance.

    An organizer does not personally own contributed money.

    Common actions

    • Propose a governance decision
    • Publish updates
    • Invite other organizers

    Acceptance. Yes. An organizer must join and accept the responsibility.

  • Treasurer

    An organizer role focused on the money position and its records.

    It does not create authority to release money alone.

    Common actions

    • Track contributions
    • Explain the money position
    • Support reconciliation

    Acceptance. Yes, and the governance rule still decides what approval is required.

  • Contributor

    A person contributing towards a group purpose.

    Contributing does not grant organizer authority over the purpose.

    Common actions

    • Contribute
    • Choose how their name appears
    • Read updates

    Acceptance. A contributor accepts the published purpose and governance before contributing.

  • Reviewer or review participant

    Someone permitted to raise or take part in an Agreement Review.

    Raising a question does not decide the outcome.

    Common actions

    • Raise a question
    • Respond
    • Provide evidence

    Acceptance. Not separately, but only permitted participants may take part.

  • Authorized representative

    A person acting for a business or organization KSNumber under recorded authority.

    It does not merge their personal KSNumber with the organization's.

    Common actions

    • Act within a recorded permission
    • Accept on behalf of the organization

    Acceptance. Yes. Authority must be recorded and accepted before it can be used.

  • Developer application owner

    The party responsible for an application that uses SecurePay as its agreement engine.

    It does not make the application an agreement participant.

    Common actions

    • Manage keys
    • Handle webhooks
    • Request production access

    Acceptance. Yes, through the developer terms and production access process.

About the examples on this page

Every example, record and status here is demonstration content and is labelled mock. Sandbox records behave realistically but move no money. Live records come from real activity. These pages are not live customer cases.