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

# PayTo Agreement Specification

> A field-by-field reference for the PayTo agreement (mandate): what each part means, why it matters, and how it supports automatic reconciliation.

A PayTo agreement is the digital permission a customer gives before you can collect recurring or scheduled payments from their bank account. It is sometimes called a **mandate**. Getting the agreement set up correctly matters, because it defines exactly what you are allowed to charge, how often, and for how long. This page breaks down each part of the agreement so you can configure it correctly for your use case.

<Note>
  For how PayTo works overall and how it compares with older direct debit, start with [PayTo for recurring payments](/platform-overview/payment-concepts/payto-recurring) and [PayTo vs. direct debit](/platform-overview/payment-concepts/payto-vs-direct-debit). This page focuses on the fields inside the agreement itself.
</Note>

## What the agreement is

Unlike an old paper direct debit form that the business keeps, a PayTo agreement lives inside the customer’s own banking app. The customer reviews and approves it there, and can view, pause, or cancel it at any time. Each agreement is a structured record with a set of defined fields.

## The agreement fields

| **Field**                   | **What it means**                                           | **Why it matters to you**                                     | **Why it matters to the customer**                         |
| --------------------------- | ----------------------------------------------------------- | ------------------------------------------------------------- | ---------------------------------------------------------- |
| **Agreement ID**            | A unique reference created for each agreement               | Lets you track and match every payment back to its agreement  | Gives them a clear reference when managing it in their app |
| **Customer details**        | The customer’s full name and optional contact information   | Makes sure payments are tied to the right customer            | Confirms the agreement sits under their own account        |
| **Payer’s bank account**    | The account or PayID that will be debited                   | Confirms where the money will come from for smooth processing | Lets them choose which account or PayID is used            |
| **Payee (merchant) info**   | Your business name and contact details                      | Displays a clear business identity, which builds trust        | Shows them exactly who is collecting the payment           |
| **Payment frequency**       | How often you will collect (for example, weekly or monthly) | Helps you plan predictable revenue                            | Helps them understand their payment schedule               |
| **Start date and end date** | The period the agreement runs for                           | Defines the billing window for a subscription or fixed term   | Makes the length of the commitment clear                   |
| **Payment amount**          | A fixed amount, or a maximum, per payment                   | Supports steady, predictable cash flow                        | Gives them transparency on cost before they approve        |

<Note>
  The **Agreement ID** is the most important field for reconciliation. Hello Clever uses it to match each incoming payment to the agreement it came from, automatically.
</Note>

## Fixed vs. maximum amounts

The payment amount can be set in two ways, depending on your billing model.

<CardGroup cols={2}>
  <Card title="Fixed amount" icon="equals">
    The same amount is collected each time, ideal for a flat subscription or membership fee where the price never changes.
  </Card>

  <Card title="Maximum amount" icon="arrow-up-wide-short">
    You set a ceiling, and each collection can be any amount up to it, ideal for usage-based billing, such as a utility bill that varies month to month.
  </Card>
</CardGroup>

## How an agreement moves through its life

<Steps>
  <Step title="You create the agreement">
    Your system sends a PayTo agreement request through the Hello Clever API, setting the amount, frequency, start date, and end date.
  </Step>

  <Step title="The customer approves it">
    The customer gets a prompt in their banking app, checks the terms and your business name, then approves or declines.
  </Step>

  <Step title="The agreement becomes active">
    Once approved, the agreement is stored in the customer’s banking app, and both you and the customer are notified in real time.
  </Step>

  <Step title="You collect payments against it">
    You initiate each payment through the API on the agreed schedule, within the amount and frequency the customer approved.
  </Step>

  <Step title="Changes stay in sync">
    If the customer pauses, changes, or cancels the agreement in their app, that update flows back to you automatically.
  </Step>
</Steps>

<Tip>
  Set the frequency and amount to match what customers actually expect to see. A clear agreement (accurate business name, sensible amount, and a frequency that matches your billing) reduces the chance a customer declines it or cancels later.
</Tip>


## Related topics

- [Build Recurring Billing with PayTo Agreements](/developer-reference/api-use-cases/build-recurring-billing-with-payto-agreements.md)
- [PayTo for Recurring Payments](/platform-overview/payment-concepts/payto-recurring.md)
- [Amend Payment Agreement](/api/aud-payto/amend-payment-agreement.md)