FB Pixel
The Kambria DAOs Framework (KDF)

Receiving Revenue: Creating a Payment Request

Estimated reading: 2 minutes 6 views

When a DAO is about to be paid — for a session, a product, a sponsorship — the Order Handler for that order creates a Payment Request. This gives the customer a clean way to pay, and it lets the framework record the revenue correctly from the start.

To create a payment request:

  1. Open Create Payment Request in the KDF app. The DAO is already selected.
  2. Choose the Revenue Category (for example, Service or Product) — see Categorisation & Revenue Split for what these are for.
  3. Enter the Amount in USDT.
  4. Add a short Description — the invoice or order text, so the payment is recognisable later. Add an external reference ID if you have one.
  5. Create the request. The framework produces a payment request page containing:
    • the DAO's Revenue Vault address,
    • the amount and token (USDT on Polygon),
    • a human-readable reference,
    • and a QR code / copy-address option for the customer.

If more than one member worked the order, the Order Handler who created it can add co-handlers — the people who will share that order's Order Handler revenue (see Order Handler Revenue Sharing).

The customer then pays by sending USDT to the vault address shown on the request page.

A payment request moves through clear states, so everyone can see where it is:

Awaiting payment → Detected on-chain → Confirmed → Assigned to cycle

[Image] Screenshot: the "Create Payment Request" form (DAO pre-selected, category, amount, description) and the resulting payment request page with vault address + QR. 

 

Confirming what comes in

When the customer pays, the framework detects the USDT transfer to the vault and creates a draft revenue item. The Order Handler checks the category and reference are right and marks the order completed — and the payment is confirmed against the request.

A few situations need a human eye, and the framework surfaces them rather than guessing: a payment for the wrong amount, a transfer that doesn't match any request, several transfers for one request, or a partial payment. The Order Handler resolves these before marking the order completed.

[Image] Screenshot: the "Incoming Revenue" view with a detected transfer awaiting confirmation.