Payments#

Money does not just move in and out of Hightop. It also moves around inside the account: to vendors you already trust, to new recipients you need to pay once, and back toward your own payment identity so other people can pay you.

Payments is the workflow surface for that. It combines Send and Receive in one screen, then branches into Recurring Payments for approved repeat relationships and One-off Payments for new or occasional recipients.

In practice, Hightop has two payment surfaces. Payments covers the stablecoin-native side — recurring vendors, one-off payouts, trusted destinations, and current machine-native payment flows like x402. Cards covers virtual-card spend for traditional merchant rails, drawing from the same Hightop account underneath. Hightop is tracking MPP as an emerging machine-payment direction, but it is not a live Agent API endpoint.

This page covers the in-app workflow. For the deeper control model behind Recurring Payments, One-Off Payments, and Trusted Transfers, use those Control Agents pages directly.

Payments Send shows a recipient picker preview, a Payment Rules action, and a Create Payment action

The Mental Model#

Payments lives inside the same Hightop account as your wallet balances, Earn positions, borrowing, and agents.
Most programmable payments in Hightop settle in stablecoins, especially USDC.
Receive is the identity side of the flow. It lets you share your Hightop payment identity through your username or QR code.
Send is the outgoing side of the flow. It lets you create One-off Payments for ad hoc payouts and Recurring Payments for approved repeat relationships.
x402 fits inside this same rules model as a machine-native payment surface. MPP is an emerging protocol direction, not a current Hightop payment endpoint.
One-off Payments are for new or occasional recipients. Smaller payments can clear immediately. Larger payments can wait behind a safety delay before they can be paid or claimed.
Recurring Payments are for recipients you expect to pay again. You set the relationship once, then pay inside that approved relationship.
Payment Rules is the account-wide entry point for the two payment paths. Those rules set the broader boundary. Individual recurring relationships and one-off payments can only narrow them.
Cards is the traditional card-rail payment surface. It is separate from this screen, but it still draws from the same Hightop balance and control model.
Your own highest-trust destinations still belong to Withdraw, not to the normal payments flow.

Open Payments#

When you open Payments, the screen starts on Send, with a toggle at the top for Send and Receive.

On the Send side, the screen can show:

existing One-off Payments
existing Recurring Payments
a Payment Rules button
a Create Payment button

Create Payment opens a simple chooser:

One-off Payment
Recurring Payment

Payment Rules opens a parallel chooser:

One-off Rules
Recurring Rules

This is an important Hightop pattern. The app groups both payment types into one operational surface, but it still keeps the two rule systems distinct underneath.

Payments Send lists recurring and one-off payment cards with amounts, cadence, next or first payment dates, agent labels, and setup actions

Receive Money#

Switching to Receive turns the screen into a share surface instead of a payout surface.

The app shows:

your Hightop QR code
your username, when one exists
a copy action
a share action

The point of this screen is simple: let someone else pay your Hightop account without making you hand over a raw wallet address every time.

If your username exists, the app emphasizes that identity and lets you copy it directly. If it does not, the app falls back to your account address.

Payments Receive displays a Hightop QR code, username, copy control, and share button

Start a One-off Payment#

Choose Create Payment, then One-off Payment.

The first screen is a recipient picker. It lets you choose a recipient through:

username search
QR scan
recent recurring-payment contacts
recent one-off-payment contacts
a direct Base wallet address

After you choose the recipient, the app opens the One-off Payment screen. This is the actual send flow. It asks for:

an optional memo
the source asset
the amount

If the recipient is genuinely new or occasional, this is the right path. The recipient picker blocks addresses that are already treated as trusted destinations. If a trusted destination sneaks through as an existing contact, the payment screen itself blocks submission and tells you to use Withdraw in Settings instead.

One-off payment flow searches for a recipient, then shows amount entry, source asset, optional memo, recipient, and send control

Review One-off Timing and States#

After you enter a one-off payment, the app reflects your account's one-off-payment policy. Some payments can clear immediately; others become delayed commitments first. The Payments screen keeps those commitments visible until they are ready, cancelled, paid, or expired.

Existing one-off cards show the recipient, amount, timing, current state, and next available action. The full timing, cancellation, claim, and expiry model lives in One-Off Payments.

One-off payment cards show pending and ready states with recipient, amount, availability, expiry, and cancel or pay actions

Start a Recurring Payment#

Choose Create Payment, then Recurring Payment.

The first step is another recipient picker. After you choose the recipient, the app opens a Recurring Payment setup screen with:

a nickname
the selected recipient
the full settings table for the new recurring relationship

The recurring-payment settings are shown up front as part of the flow, not tucked behind an Advanced sheet.

That settings screen is where you shape the relationship up front: timing, cadence, asset rules, limits, and whether the vendor can initiate pulls. The app also warns you when a new recurring relationship must wait before the first payment can go through.

Recurring setup searches for a recipient, then shows nickname, activation window, payment controls, asset rules, and create action

Manage Existing Recurring Payments#

Existing recurring relationships also live on the Send side of Payments.

Each recurring-payment card shows the current relationship at a glance, including:

status
amount
cadence
next or first payment date
assigned agent

From the main card, the app can offer:

Pay for an active recurring payment
Remove when the relationship should be dismissed instead

Tapping the card opens the recurring-payment detail screen. That is the full management surface for an existing recurring relationship: review settings, edit the relationship, see Live Usage, pay an active relationship, and remove or cancel it. The full recurring-payment rule model lives in Recurring Payments.

Recurring payment cards summarize amount, cadence, next payment, and agent, while the detail screen shows limit, period usage, expiry, current rules, and asset rules

Open Payment Rules#

The Payment Rules button on the main Payments screen is the account-wide entry point for both payment paths.

From there, the app splits into two dedicated rule screens:

One-off Payments -> Account-wide Rules
Recurring Payments -> Account-wide Rules

These screens are part of the operational workflow because they are how you reach the rules from the app surface.

Payment Rules shows account-wide one-off payment settings and a chooser for one-off or recurring rules

This page is not the place to restate every parameter or every edge case. The deeper rule semantics already live here:

The important workflow truth is simply:

the Payments screen gives you one entry point
Hightop still keeps the two rule systems separate underneath
account-wide rules set the broader boundary for each path

What to Expect After You Submit#

A small one-off payment can clear immediately from the source asset you selected.
A larger one-off payment can enter a delayed state first, then appear on the Payments screen until it is ready, cancelled, or expired.
A new recurring payment does not necessarily become usable immediately. It can appear as Scheduled or Pending before it becomes Active.
Existing recurring relationships update in place on the Payments screen and in their detail screens, including usage against their configured limits.
Completed payments appear as transfer-style activity entries, showing the source asset and the recipient or destination label rather than a separate payment-specific settled title.
Protected setup and management actions such as Creating One-off Payment, Adding Recurring Payment, Updating Recurring Payment, Cancelling One-off Payment, and Removing Recurring Payment go through Hightop's protected authentication flow before the account owner's action is signed and submitted.
None of these flows move money into a separate product silo. The funds are still operating inside the same Hightop account your agents use.

Where to Go Next#

Fund and Withdraw for money entering or leaving the account entirely
One-Off Payments for the deeper delay, expiry, cancellation, and claim model
Recurring Payments for the deeper recurring-payment control model
Trusted Transfers for your own highest-trust destinations and withdrawals
Agents for the in-app agent workflows that operate inside these payment paths