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

# PayID Use Cases

> Compare single-use, reusable fixed-amount, and persistent open-amount PayIDs, pick the right one for your payment flow, and understand how prefixes are reused after deactivation.

A PayID is the address your customer pays to from their banking app. Hello Clever provisions more than one kind, and the one you choose decides how long the address lives, whether it carries an amount, and how many payments it can accept. This page compares the types, matches each to the flows it suits, and explains what happens when you reuse a prefix.

<Info>
  PayID is an **AUD-only** capability, provisioned through the v1 API. See the [AUD PayID payins guide](/developer-reference/api-use-cases/accept-instant-payments-with-aud-payid) for the endpoints and payloads.
</Info>

## Choosing a type

|                       | Single-use                              | Reusable fixed-amount                     | Persistent open-amount              |
| --------------------- | --------------------------------------- | ----------------------------------------- | ----------------------------------- |
| **Address lifetime**  | One payment, then deregistered          | Persistent prefix, registered per payment | Persistent, until you deactivate it |
| **Amount**            | Fixed on the request                    | Fixed on each request                     | Any amount the payer chooses        |
| **Payments accepted** | Exactly one                             | One per registration, repeatable          | Unlimited                           |
| **Expiry**            | `expired_at`, at least 15 minutes ahead | Per request                               | None                                |
| **Tied to**           | A single transaction                    | A customer, reused across requests        | A customer                          |
| **Best for**          | Checkout, invoices                      | Repeat billing to the same payer          | Wallets, top-ups, deposits          |

<Note>
  These names describe what each type does. The v1 API uses its own wording, so if you are reading endpoint reference or response fields, map them like this: a single-use PayID is the `request_payid` on a payment request, a reusable fixed-amount PayID is the deprecated `prefix_static_payid` field, and a persistent open-amount PayID is what the API calls a **Static Open PayID** (`static_payid`).
</Note>

## Single-use PayID

A fresh PayID generated for a single transaction, carrying the exact amount you expect. It deregisters once paid or once `expired_at` passes, so the address cannot be reused or paid twice.

Use it when the payment is a discrete event and you want the amount fixed in advance:

* **Checkout**: the customer pays for one order, then the address is gone.
* **Invoices**: one address per invoice, matched back through `external_id`.
* **Time-limited offers**: set `expired_at` so an unpaid request lapses on its own.

The short life is the fraud control. An address that exists for one payment and one amount gives an attacker nothing to reuse.

<Tip>
  A customer who abandons checkout leaves a `pending` request behind. Call **cancel-a-payid** to deregister it immediately rather than waiting for expiry, so your reporting reflects the abandonment straight away.
</Tip>

## Reusable fixed-amount PayID

The same PayID string, reused across separate payment requests, with a fresh amount and description each time. The address stays recognisable to the payer, so it appears in their banking app's payee list and they can pay you again without retyping anything, but each payment is still a discrete request with its own amount.

This suits a payer you bill repeatedly for varying amounts:

* **Recurring invoices** to a business customer who pays from the same account each month.
* **Account top-ups** where you want the amount fixed per request rather than left open.
* **Instalment payments** against a single customer relationship.

<Warning>
  In the v1 API this pattern is served by the `prefix_static_payid` field on **create-payment-request**, which is **deprecated**. It still works for existing integrations, but omit it for anything new and use a persistent open-amount PayID instead, or a single-use PayID per payment. Confirm the intended replacement with Hello Clever before building a new recurring flow on it.
</Warning>

## Persistent open-amount PayID

A durable address tied to a customer that accepts any amount, any number of times, and stays registered until you deactivate it. Nothing about it is transaction-specific.

Use it when the relationship, not the transaction, is what the address represents:

* **Customer wallets**: a permanent address a customer funds whenever they choose.
* **Deposits and top-ups** with no fixed amount.
* **Marketplace seller floats** where money arrives unpredictably.

Every incoming payment fires your `customer_notification` webhook with the amount, `paid_at`, and sender details, so an open address still gives you a payment-by-payment record.

## Reusing a prefix after deactivation

A static PayID is built from a prefix you choose (3 to 35 characters, lowercase letters, digits, and dots), which becomes an address in the form `prefix@example.com`. Prefixes are not consumed permanently: a prefix that belonged to a deactivated PayID can be used again.

When you recreate a static PayID on a prefix that was used before and then deactivated, **the unique email address validation does not run again**. The email you supply may be one already held against the earlier PayID on that prefix.

<Steps>
  <Step title="Create a static PayID">
    Supply the customer's `name`, `email`, and your chosen `prefix_static_payid`. The email must be unique at this point, so a first-time creation is validated normally.
  </Step>

  <Step title="The customer pays">
    Payments arrive at `prefix@example.com` and fire your webhook as usual.
  </Step>

  <Step title="Deactivate the static PayID">
    The address stops accepting payments and the prefix is released.
  </Step>

  <Step title="Recreate on the same prefix">
    Create a static PayID again with that same prefix. The unique email check is skipped, so the same email address can be used without the request being rejected as a duplicate.
  </Step>
</Steps>

<Note>
  This applies only where the prefix genuinely carried a PayID that has since been deactivated. Creating a static PayID on a prefix that is new to your account, or one whose PayID is still active, follows the normal validation path.
</Note>

<Warning>
  A recreated PayID is a new record, not a restored one. It does not inherit the deactivated PayID's history, and payments made before deactivation stay attached to the earlier record. Keep your own mapping through `external_id` if you need to follow a customer across both.
</Warning>

## Related pages

<CardGroup cols={2}>
  <Card title="AUD PayID payins" icon="code" href="/developer-reference/api-use-cases/accept-instant-payments-with-aud-payid">
    The endpoints, payloads, and webhook handling for each pattern.
  </Card>

  <Card title="PayID for C2B" icon="building-columns" href="/platform-overview/payment-concepts/payid-c2b">
    What consumer-to-business PayID gives your business.
  </Card>
</CardGroup>


## Related topics

- [Accept Instant Payments with AUD PayID](/developer-reference/api-use-cases/accept-instant-payments-with-aud-payid.md)
- [PayID for C2B Payments](/platform-overview/payment-concepts/payid-c2b.md)
- [Industry Use Cases](/getting-started/industry-use-cases.md)