> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tythe.finance/llms.txt
> Use this file to discover all available pages before exploring further.

# Payments

> How value leaves your account and arrives in it: direct payments, agent payments on x402, payment sessions, and the revenue tags that drive capture and underwriting.

Tythe builds no payment rail. You pay on established rails, and your account is what decides whether a payment is allowed before it settles. This page covers paying directly, letting agents pay per call, how payment sessions bound what an agent can spend, and why every inflow is tagged.

## Paying directly

An operator sends USDC from your account to a counterparty. Two rules apply.

* **Allowlists.** Direct payments go to counterparties you have allowlisted, unless you have set the account to permit open counterparties. Denylisted addresses are always refused.
* **Screening.** Sanctions and wallet-risk lists maintained from established providers are enforced regardless of your allowlist.

Where a principal needs regulated fiat rails, those run through a licensed provider. Tythe operates no on-ramp or off-ramp of its own in V1.

## Agents paying on x402

x402 is the agent payment rail: a service returns HTTP 402 with a price, the buyer signs a stablecoin authorisation, and a facilitator settles it on-chain. On Tythe, **your account is the payer**. The agent never holds your funds.

<Steps>
  <Step title="The agent opens a payment session">
    Under a mandate that permits the x402 rail, the agent opens a session with a cap per payment, a number of payments, and an expiry. The account reserves cap times count against the agent's budget and assigns a range of one-time payment identifiers.
  </Step>

  <Step title="The agent hits a paid resource">
    The service returns 402 with its price and address. The agent builds a payment authorisation from your account for that amount, to that address, using the next identifier in its range.
  </Step>

  <Step title="Your account validates">
    The account checks the payment against the session: within the cap, inside the identifier range, before the expiry, to a permitted counterparty, under a live mandate. Only then is the authorisation valid.
  </Step>

  <Step title="The facilitator settles">
    The facilitator broadcasts the payment. It cannot change the amount or the destination, because those are fixed in what your account signed. USDC enforces that each identifier is used once.
  </Step>

  <Step title="The session closes">
    At expiry or when the range is used up, the session closes and any unspent reservation is released.
  </Step>
</Steps>

### Why sessions exist

A payment on x402 is settled by the facilitator calling the stablecoin contract directly, so your account is not in the transaction to check it at that moment. The session is how the check happens in advance: the agent asks once for a bounded envelope, your account grants exactly that, and every individual payment must fit inside it. The result is that an agent making a hundred small payments needs one on-chain action, not a hundred, and its total possible spend is capped at exactly what was reserved.

### What a session cannot do

* Spend more than cap times count, in total.
* Pay a counterparty the mandate does not permit.
* Outlive its expiry, or the mandate that authorised it.
* Survive revocation. Revoking the mandate closes the session and releases the reservation.
* Reuse a payment identifier. The stablecoin contract itself prevents it.

## Receiving

Anyone can send USDC to your account address. What matters is how the inflow is tagged, because tags drive capture and underwriting.

| Tag                      | What it means                                                    | Capturable          |
| ------------------------ | ---------------------------------------------------------------- | ------------------- |
| Revenue, x402            | A settled x402 payment to an endpoint you or your agent operate  | Yes                 |
| Revenue, venue yield     | A withdrawal of yield from a venue position                      | Yes                 |
| Revenue, tagged transfer | An inbound transfer the Intelligence Layer classifies as revenue | Yes, and disputable |
| Operator deposit         | Funding from a wallet you have bound                             | No                  |
| Loan disbursement        | Proceeds of a Loan you drew                                      | No                  |
| Internal                 | Movement between your own positions                              | No                  |

x402 receipts and venue yield are tagged from on-chain facts and are never guessed. Plain inbound transfers are classified, and you can dispute a classification from the console; a disputed inflow is excluded from capture until it resolves.

### Selling through your agents

An agent can operate a paid endpoint of its own, with your account as the recipient. Payments for it settle to your account tagged as revenue, which services any open Loan through capture and strengthens your Credit Rating.

## Gas

Your agents' actions are sponsored by Tythe's paymaster within a per-account allowance, metered into your account fee. Beyond the allowance, your account pays its own gas from idle balance. Gas for settling an x402 payment is the facilitator's, never yours.

## Costs

Tythe charges nothing on a payment. Facilitator and rail costs are passed through at cost. See [Fee model](/get-started/resources/fee-model).

<CardGroup cols={2}>
  <Card title="Delegate" icon="robot" href="/principals/account/delegate">
    The mandate fields that govern what an agent may pay, to whom, and how often.
  </Card>

  <Card title="Borrow" icon="scale-balanced" href="/principals/account/borrow">
    How revenue-tagged inflows service a Loan through capture.
  </Card>
</CardGroup>