Test environment. Payments settle on Base Sepolia with test funds, and every order and receipt here is marked as a test. The live site is coinslot.nuanu.ai.
An agent is a program that was given a task and a budget. To finish the task it finds the goods itself, pays for them itself and takes delivery itself. Coinslot puts your catalogue where those agents buy and carries the payment. The money goes from the buyer's wallet straight to yours — it never passes through our accounts.
await coinslot.catalog.publish({
merchant_item_id: 'access-monthly',
title: 'One month of access to the service',
description:
'Access for 30 days from delivery, renewal not included',
price: '5.00 USD',
result: { access_url: 'string', expires_at: 'string' },
})That is a whole card: what you sell, at what price, and what the buyer gets. The product card reference prints the same product with nothing written short, and every field a card can add to it.
A card is what the agent sees in the catalogue and buys: title, description, price and the list of what has to be given at purchase. Send us a link to your site or your documentation and we write the cards from it; you approve them, because it is your product at your price and the card is the whole of what an agent reads. If you would rather keep the card in your own code, your engineer publishes it with the call above.
The agent does not look at pictures and does not read reviews — it decides on the text of the card. If your price is worked out on the fly, we ask your side for it at the moment of purchase. The payment is checked, signature and funds both, before the order reaches you.
The order arrives in your code, the same way you already deliver to people. The same order can arrive twice — a connection dropped, a reply never landed — so it carries a key by which your side hands back the first result instead of delivering again. The goods go to the agent, the money to you.
The payment travels from the buyer's wallet to yours. We check it and we execute it, but we never hold it, so there is no payout schedule here and no balance to withdraw. Every sale is its own incoming transfer: a hundred sales are a hundred transfers, and an accounting department used to one line per period will see as many lines as there were sales.
The transfer is final. There is no mechanism in these payments for a buyer to reverse one the way a charge on a bank card is reversed, so the familiar case where money is pulled back a month after the sale and you argue that the goods went out does not happen. Whatever you give back, you give back yourself and by your own decision.
Finality does not mean nothing can go wrong for you, and the case where it does is worth knowing before you start. For goods that are paid for after you deliver, we check the payment, hand you the order, receive the goods from you and only then execute the payment — and in the gap between the check and the execution the buyer's funds can leave for something else. You would have delivered and not been paid. What it can cost you is the price of that one sale, we tell you when it happens rather than leaving you to reconcile transfers by hand, and you close the case for any given product by choosing to be paid before you deliver instead. That choice is yours, product by product.
We take no percentage of the payments, and there is nowhere for one to come from: the money goes past us. We earn on the tools and on a subscription — on what you use, not on what you sold.
A stablecoin is money whose rate is pegged to the dollar, so the sum the buyer saw at purchase and the sum that lands in your wallet do not differ by an exchange rate applied in between. Which one we use and which transfer network carries it is not chosen yet; it is in the list below.
An engineer with access to your API. The tools they would use are written for Node today, and if your side is not Node, the protocol underneath them is something we will have documented by the pilot rather than something you can build against now. If you have no engineer of your own, or they are busy with something else, we write the handler and run it ourselves — then all we need is access to your API and your sign-off on the cards.
If you sell through an online shop instead of an API, your side has nothing to write at all: paid orders show up in the shop as ordinary ones, and we set up and run that link ourselves.