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 machine-native payment flows like x402 and MPP. Cards covers virtual-card spend for traditional merchant rails, drawing from the same Hightop account underneath.

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 starts on Send, with existing payment relationships plus Payment Rules and Create Payment actions.

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 and MPP fit inside this same rules model. They are additional machine-native payment surfaces, not a separate account or policy system.
• 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.

The Send tab keeps one-off and recurring payment cards visible beside the two 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.

Receive turns Payments into a share surface for your username, QR code, copy, and share actions.

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:

• a nickname
• 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.

A one-off payment starts with recipient selection, then moves into nickname, source asset, and amount entry.

When a One-off Payment Clears Instantly vs Waits#

The app uses the account's one-off-payment policy to decide whether the payment should clear now or become a delayed payment commitment. The threshold itself lives in Payment Rules -> One-off Rules.

The practical split is:

• if the payment is below the instant threshold, the CTA stays Swipe to Pay
• if the payment is above the instant threshold, the CTA becomes Create One-off Payment

That second path does not send the funds immediately. It creates a larger one-off payment that sits behind a safety delay so you can review and cancel it before it can clear.

This is the same distinction described in One-Off Payments: small ad hoc payouts can stay fast, while larger ones gain a review window.

Manage Existing One-off Payments#

Existing one-off payments stay visible on the Send side of Payments.

Each card shows the current state and the key terms already fixed for that payment, such as:

• recipient
• amount
• value at creation
• when it becomes available
• when it expires

The main states the app surfaces are:

• Pending
• Ready
• Expired

From those cards, you can:

• Cancel a one-off payment before it is finalized
• Pay it once it becomes ready

There is no separate management area for one-off payments outside this main screen. The Payments send view is the operational dashboard for them.

Existing one-off payments stay on the Send tab with their status, timing, amount, and next action.

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, including:

• activation timing
• cadence and payment frequency
• asset rules
• unit and USD limits
• permissions like pull payments

The app also warns you that new recurring payments take a short time to activate before the first payment can go through.

Recurring setup starts with recipient selection, then shows the nickname, warning, and settings table inline.

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
• limit
• cadence
• activation date when scheduled
• expiry date when applicable

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. It lets you:

• review the current settings
• edit the recurring relationship
• see Live Usage against the active limits
• review the activation window
• pay an active recurring relationship
• remove or cancel the recurring relationship

The detail screen also makes one timing rule explicit: the editable settings for an existing recurring payment do not include the activation-window fields. The screen shows those dates separately under Activation Window, and it tells you to remove and re-add the recurring payment if you need different timing.

Recurring cards summarize the relationship, and the detail screen shows settings, live usage, activation timing, and management actions.

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.

• One-off Rules is where the account defines the instant threshold, review delay, default expiry, creation and payment caps, and allowed assets for ad hoc payouts.
• Recurring Rules is where the account defines the default timing, cooldowns, transaction caps, USD caps, missing-price protection, and vendor-initiated billing switch for repeat vendor relationships.

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

• One-Off Payments
• Recurring Payments

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