Single-use virtual cards: how Ottr pays without exposing your card
Every Ottr purchase gets its own virtual card, locked to the amount and retailer you approved. How single-use cards work and why your own card stays private.
On this page
When you buy something online, you usually hand over the same long card number you use everywhere else. That number then sits with the retailer, its payment processor and sometimes other parties, for as long as they choose to keep it. If any of them suffers a breach, your card may need replacing, and you are the one who has to update every subscription that depended on it.
An AI shopping assistant raises the stakes. If an agent is going to check out on your behalf, the obvious approach would be to give it your card details. We think that is the wrong approach, and this article explains what Ottr does instead.
The idea in one sentence
For every purchase you approve, Ottr creates a new virtual card that can only be used once, for that amount, at that retailer, for a short time. Your own card is never shown to the retailer, the messaging app or the AI.
What a virtual card is
A virtual card is a real card number, with an expiry date and security code, that exists only digitally. It works like any other card at a checkout, but it is issued for a specific purpose and can carry controls that a plastic card in your wallet cannot.
Businesses have used virtual cards for years to control spending: one card per supplier, with a fixed limit. The same idea works well for individual purchases made by an assistant.
The controls on every Ottr card
Each card Ottr issues is created with hard limits, set from the exact terms you approved:
- Amount ceiling. The card cannot be charged more than the approved total.
- Currency. The card only accepts the currency of the approved price.
- Merchant lock. The card is tied to the retailer you approved. A charge from anywhere else is declined.
- Single use. Once one payment has been authorised, the card cannot be used again.
- Short life. The card expires shortly after it is created, so an unused card does not linger.
These checks are made by the card issuer at the moment a payment is attempted. They do not rely on the retailer, or on Ottr's AI, behaving correctly. If someone obtained the card details and tried to use them elsewhere, or tried to charge a second time, the attempt would simply be declined.
Where your own card fits in
You still need a way to pay, and that is your own card. The difference is where it lives and who sees it.
When you add a card to OTTR, it is captured and tokenised by our payment provider. Stripe is our acquirer of choice for card payments. OTTR holds a token that represents your card, not the number itself. When you approve a purchase, your card is charged for the approved amount and the matching virtual card is issued to complete the checkout with the retailer.
Because funding happens while you are on the approval page, your bank can run its own checks, such as 3-D Secure, as part of Strong Customer Authentication. We cover that in more detail in Why a 'yes' in a chat should never be enough to buy something.
What never happens to card numbers
We treat card numbers as something that should touch as few systems as possible. In Ottr's design:
- Your card number is never seen by Ottr's AI. The model works with products, prices and order references, never with card details.
- Card numbers never appear in a message. Not in Telegram, not on WhatsApp, not in web chat.
- Virtual card details are held only in memory, from the moment the card is issued until the checkout uses it. They are not written to logs or to the database. If a checkout has to be resumed after an interruption, the old card is closed and a fresh one is issued.
- The parts of the system that agents can reach have no route to the card issuer. This separation is checked by automated tests, so a future change cannot quietly break it.
What happens with refunds
If you return an item, the retailer refunds the virtual card it was paid with, and OTTR then refunds your own card. Every purchase has its own entries in a double-entry ledger, so each one can be traced from your payment, through the virtual card, to the retailer, and back again if there is a refund.
Why one card per purchase is safer
The benefit of this approach is containment. If something goes wrong at a single retailer, the damage is limited to a card that has already been used, or has already expired, and was never good for anything else.
Compare that with the alternatives:
| Approach | If the retailer is breached |
|---|---|
| Your own card, saved at every shop | Your card may need replacing everywhere |
| One virtual card reused across shops | Every shop using that card is exposed |
| One single-use card per purchase | The exposed card is already spent or expired |
There is also a quieter benefit: an assistant that pays with your real card would make that card a target. Removing it from the agent's world entirely is simpler and stronger than trying to guard it there.
Where this stands today
We want to be precise about status. OTTR is in development. Card issuing currently runs on a sandbox issuer and card network that we built to enforce exactly the controls described above, against a test merchant. The cards it creates use a test range and cannot be used anywhere real.
Going live requires a licensed card issuing partner and programme, an approved arrangement for funding purchases, and the related regulatory and card scheme work. We will not describe any of that as live until it is.
The takeaway
An AI assistant should be able to pay for things without ever knowing your card number. Single-use virtual cards make that possible: each purchase gets a card that works once, for the amount and retailer you approved, and then becomes useless. Your own card stays with our payment provider, and your approval stays with you.
To see how the approval step works alongside this, read Why a 'yes' in a chat should never be enough. If you are new to Ottr, start with What is an AI shopping agent?, or try it in sandbox.
- #virtual cards
- #payments
- #security
- #card issuing
Keep reading
All articlesWhy a 'yes' in a chat should never be enough to buy something
A chat reply is easy to send, mistype or fake. Why Ottr asks you to approve every purchase on a secure page bound to the exact item, price and address.
5 min read
How to brief an AI shopping assistant for better results
A few well-chosen details turn a vague request into a shortlist you can act on. Practical tips for briefing Ottr, or any AI shopping assistant, effectively.
5 min read
Agent-to-agent commerce: when your AI asks another AI to buy for you
Your assistant may soon ask another agent to buy things for you. How Ottr supports REST, MCP and A2A while keeping the final approval with the customer.
5 min read