Why we’re starting with simulated spending

Learn the shape of the workflow

A spending product includes much more than a successful purchase. People need to connect an agent, fund a balance, choose limits, understand declines, and review activity. Simulation creates a place to explore those interactions with test money.

Make the boundary explicit

Every purchase in Transfer is currently simulated. Test balances are not deposits, and display card identifiers are not usable payment credentials. Adding test money does not fund a bank account, and a successful simulation does not mean a merchant has been paid.

Build from what works

Real payments require provider integration and operational work beyond these controls. We describe the capabilities available today separately from future work. For now, simulation is a useful way to evaluate how an agent behaves when spending has concrete constraints.

Build a useful simulation plan

A good simulation includes more than a successful purchase. Try a request within the rules, one above the per-purchase cap, one after freezing the card, and one when shared funds are insufficient. Write down the expected result for each case. Then compare the tool response and transaction history with that expectation. This gives you a more useful picture of the integration than a single happy-path demonstration. You can also observe whether the agent explains the result accurately or invents a merchant interaction that never occurred. The language used after a simulation matters as much as the request itself.

Avoid assuming production equivalence

A simulated purchase is not evidence that real card issuance, merchant acceptance, settlement, refunds, or a funding programme are ready. Those are separate operational and provider concerns. Transfer’s current test cards use display identifiers rather than usable payment credentials, and test top-ups do not create real funds. Keep that distinction in demos, internal screenshots, and any application built around the tools. A realistic-looking interface can otherwise encourage assumptions that the underlying system does not support. Describe the result as a simulation even when the user’s intended task involves something they would eventually buy.

Use findings to improve the workflow

Simulation can reveal confusing labels, poor default limits, and missing context in error handling. An owner might expect an allowance to reserve wallet funds, or an agent might interpret a decline as a temporary outage. These are useful findings because they can be addressed in the product and instructions before real funds are involved. Record the scenario, the observed result, and the expectation that was not met. Improve one part of the workflow and repeat the exercise. The goal is to make the system easier to understand, not to present test results as guarantees about future live-payment behavior.

Keep a record of expected outcomes

For each test, write down the starting wallet balance, relevant limits, requested amount, and expected outcome. After the request, compare the result with that record. This is especially helpful when several people review a demo or when you return to an experiment later and no longer remember the original setup.

A simple record also helps distinguish a product issue from a mistaken assumption. If the test expected a purchase above the per-purchase cap to succeed, the expectation was wrong. If a declined request reduced wallet funds, that would deserve investigation. Describing the setup precisely makes feedback actionable without requiring anyone to infer the conditions from a screenshot. Keep private keys out of this record, and identify the test as a simulation so it cannot be mistaken for a real financial transaction.

Evaluate the human experience too

A test environment should help owners understand the system, not just prove that an endpoint returns a response. Watch for moments when someone confuses an agent allowance with reserved funds, or assumes the displayed card can be used outside the product. These misunderstandings are valuable design feedback.

Try asking another person to explain a result using only the information visible in the workflow. Can they tell which agent acted, whether funds changed, and whether the attempt was paid in simulation or declined? If they cannot, the next improvement may be a label, an explanation, or a clearer display rather than another backend feature. Simulation is useful because these interactions can be improved while the money remains test money. It gives the product a place to become understandable before broader capabilities are introduced.