Your wallet balance is not an agent’s allowance
Why shared funds and individual spending limits are two different things.
Available means available now
An agent’s available spending is capped by its remaining monthly allowance and the current wallet balance. Its per-purchase limit still applies to each request. If another agent spends from the wallet, the first agent’s ability to spend can decrease even though its own monthly usage has not changed.
Keep the language precise
A spending limit is permission, not a deposit. Keeping these concepts separate makes budgets easier to reason about and avoids the impression that every card has a separately funded balance. Frozen cards have no spending availability until they are unfrozen.
Follow the numbers across two agents
Suppose Agent A and Agent B each have €150 of remaining monthly allowance, and the shared wallet contains €200. Agent A completes a simulated €80 purchase. The wallet now has €120, while Agent A has €70 of monthly allowance remaining. Agent B still has €150 of allowance, but it cannot use more than the €120 left in the shared wallet. A separate per-purchase cap may reduce the amount it can request in one attempt. Writing out these numbers is an easy way to spot the difference between an individual budget and the funds available to the whole workspace.
Understand month boundaries
Transfer measures monthly limits using UTC calendar months. The relevant monthly usage belongs to the card, while wallet funds belong to the owner’s shared simulation account. A new month changes the allowance calculation; it is not a new deposit into the wallet. If the wallet has no funds, a fresh monthly allowance still does not make a purchase possible. This matters when reviewing activity around the end of a month or comparing local time with UTC. Treat the wallet balance and monthly usage as separate values, each with its own meaning and its own reason for changing.
Design a clearer balance display
When building an interface on top of the API, label these values separately. Show the shared wallet balance as shared money, then explain an agent’s remaining monthly limit and per-purchase cap near its card. Avoid adding individual allowances together and calling the result available funds. That number would describe overlapping permissions rather than a spendable balance. It is also useful to make the simulation status visible beside amounts, so readers know that these are test funds. A clear display helps people predict an outcome without needing to learn the underlying database or request flow.
Understand simultaneous spending
Shared funds mean that multiple agents can affect the same balance. A wallet read is a snapshot, not a reservation of the amount returned. An agent might inspect €100 of test funds, then encounter a smaller balance when it attempts a purchase because another agent has spent in the meantime.
The purchase must be evaluated against the state at processing time. Transfer’s simulation uses database transactions to prevent concurrent purchases from overspending the shared account. An integration should still be prepared for a request to be declined after an earlier balance check looked sufficient. Do not tell the user that checking the wallet guarantees a later purchase will succeed. Use the final purchase outcome to describe what happened, and refresh the displayed balance when you need the current state. This distinction becomes easier to notice when you test more than one agent against the same wallet.
Keep amounts and currency together
The API represents monetary amounts in integer EUR cents. An application displaying an amount needs to convert it for presentation without confusing cents with euros. For example, a value of 1250 cents represents €12.50, not €1,250. The currency belongs beside the amount, even when the current product supports only one currency.
When testing a dashboard or agent explanation, include values with cents so that formatting mistakes are visible. Compare the displayed number with the underlying response before assuming a budget is larger or smaller than expected. Keep the shared balance separate from the remaining allowance in both variable names and screen labels. Precise representation does not change the spending rules, but it makes those rules much easier for owners and developers to interpret correctly. A well-labeled amount is part of the product’s control surface.
Frequently asked questions
Do card allowances reserve wallet funds?
No. Allowances overlap and do not reserve separate funds. Every agent uses the same shared wallet, so activity by one agent can reduce what another agent can spend even if its own monthly limit has not changed.
Does a new month refill the wallet?
No. Monthly allowance calculations and wallet funding are separate. A fresh monthly allowance does not add funds to the shared simulation balance. A purchase still needs sufficient wallet funds.
Why is available spending lower than my monthly limit?
Current availability is capped by the remaining monthly allowance and shared wallet funds, and is zero for a frozen card. Each purchase must also fit the per-purchase cap, which can further constrain a single attempt.
Can two agents both rely on an earlier balance check?
An earlier balance is a snapshot, not a reservation. Another agent may spend before the next request is processed. Use the final purchase outcome to determine whether that request succeeded.
What units does the API use for wallet amounts?
Amounts are integer EUR cents. For example, 1250 cents represents €12.50. Convert values for display while preserving their currency and keeping the shared balance separate from card allowances.
Does creating another agent increase the wallet balance?
No. A new agent receives its own spending rules, not new funds. Test money is added to the shared wallet through funding, independently of agent creation and monthly limits.
Ready to start with Transfer?
Start with test money. Every purchase is a simulation.