Laso Finance agent payments: setup, spending and custody

I would assess this as an agent-payment workflow: an AI agent gets access to a funded account, buys an Apple gift card and returns a code that works. That is useful evidence of a completed purchase, but a gift card and an International Card are different products.

Connect an agent to payment tools

The setup connects an AI agent to a wallet and purchasing services so it can carry out instructions through external tools. The example uses Hermes Cloud Agent running on Haiku; the interface identifies the model as Claude-Haiku-4.5. These details describe this configuration, rather than requirements for every user.

The creator says Claude Code, OpenClaw and other agents can use the same approach. An agent with an existing X402-enabled wallet can, they say, connect and begin purchasing immediately. X402 lets software respond to a request for payment. Here, the new agent needs a wallet first.

I would check the financial product separately from the software connection. A payment card has its own issuer, acceptance network and contractual rules. The demonstration supplies no International Card terms, so its existence, issuer, network, eligibility, verification, fees, limits, custody and reward conditions need verification.

The interface offers these account or wallet options:

The setup uses the managed option. Before choosing one, I would check who can sign transactions and recover funds. A wallet label alone does not answer either question, and those responsibilities matter more than the name. Choosing between these options means understanding which tasks belong to the account holder and which depend on the provider.

Set up and fund the agent

Setup moves between an agent conversation and a browser. The creator says users can start on either side and switch between human-driven and agent-driven setup. A person still chooses the account route, establishes the connection and supplies the money.

To follow this route:

1. Copy the agent setup prompt from the Laso website.
2. Send the prompt to your agent.
3. Choose Lasso Managed Account when the new agent presents the wallet options.
4. Open the setup page in your browser.
5. Create the guest account.
6. Create a wallet for your agent.
7. Pass the generated connection prompt back to the agent.
8. Confirm that Hermes Agent appears as connected.
9. Send USDC from your funding wallet to the deposit destination.
10. Ask the agent what purchases are available.
11. Request an Apple gift card.
12. Redeem the delivered gift-card code through the App Store.

Phantom supplies the USDC deposit in this example. The connection prompt includes an API key, a credential that lets software access a service. I would keep it private: it is not necessarily a wallet's private key, but its permissions may still allow consequential account actions.

Before connecting a wallet, check the website address independently and read what you are authorizing. An agent cannot make an incorrect destination safe. For a crypto transfer, the recipient address and supported network must match the receiving service's instructions.

A connected status confirms the software handshake. The account's transaction record and the eventual purchase provide different checks: whether money arrived and whether the order completed. I would check those records rather than rely on a conversational confirmation alone. The connection is necessary for the agent to use the service, but it is only the first checkpoint in a process that also involves funding and delivery.

What the gift-card purchase establishes

The agent finds an Apple gift-card listing, completes the purchase and returns a redemption code. The App Store accepts it. The funding and redemption sequence displays these amounts:

I consider the accepted redemption stronger evidence than an order message: the delivered code added usable credit. The final App Store balance belongs to that account; it is not the remaining balance in the agent's wallet.

A gift card provides value within its issuer's redemption system. A general payment card authorizes purchases through a payment network. This purchase therefore establishes a working gift-card route, not general card acceptance. Both can turn crypto-funded value into spending power, but the recipient uses that value through different arrangements.

The creator calls this a small example and claims an agent can do everything a human can do on the service. I would keep that broader claim separate from the completed transaction. The successful purchase supports this particular route.

The creator also describes the process as requiring minimal human involvement. The agent handles the search and purchase after setup, while a person provides authority and funding. Someone must still decide whether the requested product suits the intended use. Delegating the search and order does not remove that decision from the account holder.

Understand who controls the funds

The central custody question is who can authorize transfers. A wallet manages the credentials and instructions needed to move crypto. With self-custody, the user controls the private keys that authorize transactions; with custody, a provider controls those credentials on the user's behalf.

I would read the managed-account agreement for recovery rights as well as signing authority. Who can restore access after a lost login? Can the user recover assets independently? Those answers determine what happens when the normal login or spending process fails.

The source of a deposit does not determine custody at its destination. Sending money from a self-custody wallet does not automatically preserve the sender's exclusive control. A service can also let an agent request transactions without handing it a private key. To assess the exposure, the account holder needs to understand both the destination account and the permissions granted to the software.

The risks differ. Losing self-custody recovery information can mean losing access to funds. With custody, users depend on the provider's account controls and ability to honor withdrawals. I would establish who bears those responsibilities before granting spending access.

Revoking an agent's permission is another control. Disconnecting software may stop future instructions without moving the underlying money. For an automated spender, I find a delegated budget the clearest model: grant purchasing authority proportionate to the task, while keeping a way to stop that authority without losing account access.

Calculate the cost of the payment route

I would compare the assets committed with the usable spending value received. The listed purchase price may not be the full cost: network charges, service fees and exchange rates can change the amount paid.

Card charges can apply at different points. An issuing charge covers obtaining a card; a monthly charge covers keeping the account or service active. A top-up charge applies when adding funds. A low price for one action does not settle the overall cost. The relevant schedule is the one covering the actions the account holder intends to take, rather than whichever charge looks most attractive in isolation.

Currency conversion may involve an explicit fee, an exchange-rate spread or both. The spread is the difference between the customer's rate and a reference rate. I would compare the spending value received after those costs, rather than judge the route by a fee label alone.

Cash access needs its own check. An ATM withdrawal can incur both a provider charge and a machine-operator charge. Withdrawal limits may differ from spending limits, so a purchase allowance should not be read as a cash allowance.

Eligibility and identity verification also belong in the pre-funding check. Website access does not establish that residents of a particular country can obtain every product offered there. I would not treat a guest account as evidence that later financial activity avoids verification; requirements can depend on the service used.

Rewards need a separate calculation. Cashback may depend on eligible purchases, caps or a required token position. Staking or a token lock-up adds exposure beyond the purchase itself. Any reward should be assessed after its conditions and costs, rather than treated as guaranteed value.

Give the agent a bounded spending job

During the purchase, the agent briefly thinks it has 0 USDC after the deposit, then recognizes the funded balance. The creator wants webhooks, automatic notifications sent to software, to push updated information to agents.

An agent acts on the information available to it, so a completed transfer can coexist with an outdated response. I would check transaction status before resending money or repeating a purchase instruction because the agent reports an old balance. Otherwise, an information delay can prompt an unnecessary second action.

Asking what is available gives the agent a discovery task. Asking it to buy something grants spending authority. Keep those permissions distinct when the agent can use tools that move value; a request to browse should not become permission to place an order.

I would specify the intended product and acceptable total cost. Where approval controls are available, reviewing the proposed purchase can catch a wrong item or denomination before execution. That is a general safeguard, not a claim that this interface provides such a control. The purpose of the review is to compare the proposed order with the original request while there is still an opportunity to withhold approval.

Product listings and tool responses should supply information, not expand the agent's authority. Software agents can encounter misleading instructions in outside content. A listing should not decide how much access the agent receives over the account.

I would also check whether the API key permits balance reading, order placement or broader account actions. Posting a connection credential in a public conversation or recording can expose those permissions. Restrict access and replace an exposed credential even when the service manages the underlying wallet.

Treat redemption and tax as part of spending

An issued gift-card code needs protection because anyone able to redeem it may capture its value. Keep it out of public support messages, shared screenshots and agent conversations accessible to other people. I would share it only where redemption or necessary support requires it.

Gift cards can have country, currency or account restrictions, and redemption can be difficult to reverse. Match the listing's terms to the intended recipient's account before authorizing the purchase. Acceptance in this account does not establish suitability for a different recipient.

A blockchain transfer, merchant order and gift-card redemption can each have different reversal rules. I would settle product selection before granting purchase authority: stopping future agent instructions does not necessarily cancel an order already completed.

Preserve the order record and funding history. They can help distinguish a transfer problem from a purchase problem and identify which service to contact. Keeping those records does not require exposing the redemption code to people who do not need it.

Spending crypto can count as a taxable sale in many countries. Treatment can depend on the asset's acquisition cost, its disposal value and local rules. I would keep the records needed to assess that disposal even when software submits the purchase instruction.

A stablecoin's intended price stability does not settle its tax treatment. Records of the asset spent and value received can matter even when price movement seems small. Local tax guidance, rather than the agent's transaction description, should determine how those records are used.

Check how interrupted payments are handled

I would define a successful agent payment before funding the account: the task has clear authorization, the order is accepted and the purchase works for its intended recipient. Each checkpoint needs its own evidence. An order response cannot substitute for a usable purchase.

For a repeatable service, failure handling matters too. An expired session may leave the agent disconnected while funds remain in the account. A rejected order or unavailable product tests whether it can stop and report the account state clearly. These are evaluation criteria, not events established by this example. A useful failure report should make the next decision understandable, rather than leave the user guessing whether to wait or issue another instruction.

I would assess any proposed International Card through its own contractual documents. For the agent workflow, the next useful question is more specific: after an interrupted purchase, can the user tell whether the order failed, whether money moved and whether another instruction would duplicate the purchase?