Snaplii agent-to-merchant-payments: a tokenized payment layer for AI agents

The gap Snaplii is aiming at: agents that can decide but cannot pay

The README opens with a blunt claim: AI agents can decide what to buy, compare options and navigate merchant platforms, but they still cannot safely pay. Its argument is that payments need trust, compliance and risk control, and that handing an agent a card number is not a solution but a risk.

That framing is the whole product thesis. Snaplii is not a shopping agent and not a merchant checkout. It is a payment rail that sits between a user's funded balance and a merchant, and it is aimed at people building agents that need to complete a purchase without being trusted with credentials. The README describes the flow as User → Agent → Snaplii → Merchant, with each transaction pre-funded, isolated and non-reusable. No shared credentials, no persistent risk.

The audience is therefore narrow and specific: developers wiring an LLM agent to a terminal or an MCP-capable client, who want a spend boundary they can set in a mobile app rather than in a system prompt. If your agent only needs to read prices, you do not need this.

How the tokenized payment layer actually works

The architecture is a hosted service with three client surfaces. The core is a REST API at `aipayment.snaplii.com/v2/*`. On top of that sit a Python CLI installed as `snaplii-cli`, and an MCP server that speaks stdio for Claude Desktop, OpenClaw, Cursor and VS Code. The repository also ships an OpenClaw skill installed with `clawhub install snaplii-a2m-payment`.

Authentication is deliberately indirect. You generate an API key in the Snaplii mobile app under More → Payment Methods → AI Payment Management, with a name, a permission scope (the README gives Read-only and Purchase as examples) and a hard spending limit. The key format is `snp_sk_live_...` and is shown once. Running `snaplii init` prompts for it via hidden input, uses it only to obtain a session token, and never stores the key on disk. The agent ID is derived from the key.

The spending limit and scope living in the app, not in the agent, is the part worth noting. A prompt injection that convinces your agent to buy something still has to pass a server-side limit you set by hand. That is a real design decision, and it is the reason the README can claim non-reusable transactions.

The catalog is scoped to your account's country, fixed at login and enforced server-side, so there is no region or province flag to pass. Gift card identifiers are formatted as `{cardBrandId}-{cardTemplateId}`, both obtained from `snaplii browse brand`. Prices must fall inside the brand's denomination range; the README states that `quote` and `purchase` reject an out-of-range price up front, so you never pay for a card that cannot be issued.

Installing the Snaplii CLI and making a first purchase

The README recommends `pipx` so the `snaplii` executable lands on your PATH in its own isolated environment. On macOS that is a Homebrew install followed by `ensurepath`; on Linux it is a user-level pip install. After either, restart the terminal, because `ensurepath` only takes effect in a new shell.

brew install pipx
pipx ensurepath

Clone the repository and install the CLI from the local path. The README uses an editable install pointed at the `snaplii-cli` subdirectory, not a bare `pip install snaplii-cli`.

git clone https://github.com/Snaplii-Inc/agent-to-merchant-payments.git
cd agent-to-merchant-payments
pipx install -e ./snaplii-cli
snaplii --help

If `snaplii --help` prints the command list, the executable is on PATH. If you get `command not found`, the README points at its Troubleshooting section. Next, authenticate. The key comes from the Snaplii mobile app, and the prompt is hidden input.

snaplii init

Now a real sequence. Browse categories, then a brand to get its IDs and denominations, then check your balance, then preview the price before committing.

snaplii browse tags
snaplii browse brand --id CB...
snaplii balance --country CA
snaplii quote --item-id CB...-CT... --price 50
snaplii purchase --item-id CB...-CT... --price 50

`--country` takes CA or US, mapping to CAD and USD. The `quote` step is the one to run first: it shows the price with voucher and cashback applied, which is where the advertised savings show up. `purchase` then buys the card. Bill pay follows the same shape with a longer chain the README spells out as payees → detail → save (returns payCode) → quote → pay → result.

snaplii billpay payees
snaplii billpay detail --payee-code PE01015
snaplii billpay save --payee-code PE01015 --first-name Alex --last-name Chen --amount 75.25 --account 1234567890
snaplii billpay quote --pay-code PC... --price 75.25
snaplii billpay pay --pay-code PC... --price 75.25
snaplii billpay result --payment-no PSP...

The `save` call returns the `payCode` that the following `quote` and `pay` calls consume, and `result` takes a separate payment number to check status.

Where this breaks: coverage, refunds and the missing licence

The first limitation is coverage. Snaplii's payment layer is built on merchant gift cards and bill pay, so an agent can only pay a merchant whose brand is in the catalog. The README advertises 500+ brands, but 500 brands is not the long tail of the web. If your agent needs to buy from a merchant outside that set, this project cannot help, and no amount of prompt engineering changes that.

The second is the funding model. Every transaction draws from a prepaid Snaplii Cash balance that you load in the mobile app by binding a payment method. That is what makes the isolation claim work, and it is also a hard operational constraint: an agent cannot spend money that has not been loaded, and topping up is a manual step in an app, not an API call the README documents.

The third is refunds. The README describes purchase, quote, balance and bill pay status. It does not describe a refund or reversal command, and it does not document what happens to a gift card that fails to issue after a successful `purchase`. Treat that as an open question to raise with the vendor before you put an agent in front of real money.

The fourth is legal, and it is the one most likely to stall adoption. The repository's licence field is unknown, and the README's own table of contents lists a License section but the text is not present in what is available. Do not assume an open source licence. Check the repository's LICENSE file before you ship anything built on this code.

Snaplii versus card-issuing agent payment stacks

The obvious alternative is a card-issuing layer for agents, the kind of thing Visa Intelligent Commerce Connect and Mastercard Agent Pay are building toward. The difference in approach is structural, not cosmetic. A card-issuing stack gives the agent a credential that resolves to a card network transaction, which means the merchant sees a normal card payment and coverage is as wide as the network. Snaplii instead issues a pre-funded, non-reusable token that resolves to a gift card or a bill payment at a specific brand.

That trade buys safety and costs reach. A card number in an agent's context is a persistent credential; a Snaplii token is scoped to one brand, one price and one use, and the limit is enforced server-side. But the merchant must be in Snaplii's catalog, and the value has to be pre-loaded. If your agent's job is to buy from a fixed list of well-known brands, the narrower model is easier to defend to a risk team. If your agent must pay an arbitrary supplier invoice, it is the wrong tool.

The README also claims Snaplii is the only one that saves you money, up to 10% per transaction on top of existing deals. That claim is the vendor's, not a measured result, and the actual saving depends on the brand and the vouchers on your account. The `quote` command is how you find out for a given purchase.

Editorial conclusion

Adopt it if your agent needs to buy gift cards or pay bills at brands Snaplii already covers and you want a spending limit set in the mobile app rather than a card number in a prompt. Do not adopt it if your agent must pay arbitrary merchants, handle refunds, or run against a card-issuing stack you already control; nothing in the README describes those paths. Before writing code, run `snaplii browse tags` and `snaplii billpay payees` against your own account to see whether your target merchants are actually in the catalog, because the catalog is scoped to the country fixed at login and enforced server-side.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Snaplii-Inc/agent-to-merchant-payments on GitHub