Skip to main content
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.
PayID is an AUD-only capability, provisioned through the v1 API. See the AUD PayID payins guide for the endpoints and payloads.

​
Choosing a type

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).

​
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.
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.

​
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.
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.

​
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.
1

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.
2

The customer pays

Payments arrive at prefix@example.com and fire your webhook as usual.
3

Deactivate the static PayID

The address stops accepting payments and the prefix is released.
4

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.
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.
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.

AUD PayID payins

The endpoints, payloads, and webhook handling for each pattern.

PayID for C2B

What consumer-to-business PayID gives your business.