Snaplii's agent-to-merchant payment layer: prepaid credits, a CLI, and an MCP server

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

The README opens with a blunt claim: payments are broken for AI agents. It then lists what agents already do well, which is deciding what to buy, comparing options, and navigating merchant platforms. The missing piece it names is payment, because payment carries trust, compliance, and risk control that the project argues agents were not designed to handle. The stated alternative, handing an agent a card, is described as a risk rather than a solution. That framing is the whole pitch, and it is a narrower one than it first appears. Snaplii is not trying to give an agent a bank account or a general card. It is giving the agent a spending allowance against a catalog of merchant gift cards and bill-pay payees, where each transaction is, in the README's words, pre-funded, isolated, and non-reusable. The audience is therefore specific: developers wiring an autonomous or semi-autonomous agent into consumer commerce, where the purchase is a known denomination from a known brand or a recurring bill, and where the operator wants a ceiling that does not depend on the agent's own restraint. If your agent needs to buy an arbitrary item from an arbitrary merchant at an arbitrary price, this is not the shape of the product.

The funding path: user to agent to Snaplii to merchant

The architecture the README describes is a four-hop flow: user, agent, Snaplii, merchant. The user funds Snaplii Cash from the mobile app by binding a payment method and loading a balance. The agent never holds credentials for the underlying payment method. Instead it holds an API key with a permission scope and a hard spending limit, both set in the app under More, Payment Methods, AI Payment Management. The key format is snp_sk_live_ and, per the README, it is shown only once. Two properties follow from this design. First, the spend ceiling lives on Snaplii's side, not in the agent's prompt or in your orchestration code, so a misbehaving agent cannot talk its way past it. Second, each purchase is drawn from a prepaid balance, which means the agent cannot create debt. The README also states that the API key is used only to obtain a session token and is never stored on disk, and that the agent ID is auto-derived from the key. That is a meaningful detail for anyone who has had to scrub secrets out of an agent's working directory. What the README does not describe is the token lifetime, the refresh behaviour, or what happens when a session expires mid-purchase. Treat that as an open question to test against the API rather than something the documentation answers.

Four integration surfaces, one HTTP endpoint underneath

The README lists four ways in. The REST API is the base layer, with paths under aipayment.snaplii.com/v2/*, and it is presented as language- and framework-agnostic. The Python CLI is distributed as snaplii-cli and installed from the cloned repository. The MCP server speaks Model Context Protocol over stdio and is aimed at Claude Desktop, OpenClaw, Cursor, and VS Code. The OpenClaw skill installs with clawhub install snaplii-a2m-payment. The project describes itself as model-agnostic and names Claude, ChatGPT, GPT-4, Gemini, LLaMA, Mistral, and OpenClaw, which is a fair claim given that the lowest common denominator is an HTTP call. The practical difference between the surfaces is where the tool schema lives. With MCP, the agent discovers the operations as tools. With the CLI, the agent shells out and parses text. With raw REST, you write the tool definitions yourself. There is no TypeScript or Go client mentioned, so non-Python stacks are expected to call HTTP directly. That is a deliberate simplification, and it also means the CLI and MCP server are conveniences rather than the contract.

Getting it running: pipx, an API key from the app, and snaplii init

The install path in the README assumes Python 3.10 or newer for the MCP server, with the note that the CLI alone works on 3.9. On macOS the sequence is brew install pipx, pipx ensurepath, then pipx install -e ./snaplii-cli from inside the cloned repository. Linux uses python3 -m pip install --user pipx and the same ensurepath step. Windows offers Scoop or pip, and the README flags that a Microsoft Store Python install should be invoked as python3 rather than py. After ensurepath you must open a new terminal, then confirm with snaplii --help. Authentication is a single interactive command, snaplii init, which prompts for the key with hidden input. The everyday commands are browse, balance, quote, giftcard list, and purchase. Item IDs take the form {cardBrandId}-{cardTemplateId}, and both halves come from snaplii browse brand. The README notes that the catalog is scoped to the account's country, fixed at login and enforced server-side, so there is no region flag to pass, and that balance takes a --country argument where CA means CAD and US means USD. Denomination bounds are enforced before purchase: quote and purchase reject an out-of-range price up front, with the README's example being a ten-dollar request against a twenty-dollar minimum card. That pre-flight check is a small thing that saves a class of support tickets.

Bill pay runs on a different state machine than gift cards

Gift cards are a browse-and-buy flow. Bill pay is a six-step sequence the README spells out explicitly: payees, detail, save, quote, pay, result. You find the biller with snaplii billpay payees, check the account rules with snaplii billpay detail --payee-code PE01015, then register the account with snaplii billpay save, passing first name, last name, amount, and account number. That save step returns a pay code, which is the handle for the rest of the flow. From there, snaplii billpay quote --pay-code PC... previews the price, snaplii billpay pay executes against the Snaplii Cash balance, and snaplii billpay result --payment-no PSP... checks status. The existence of a result command is the tell that bill payment is asynchronous: the payment is submitted and settled later, so an agent that calls pay and immediately reports success is reporting the wrong thing. The README states that bill pay draws from the same prepaid balance and carries the same cashback and vouchers as gift cards, which keeps the mental model consistent. It does not state settlement latency, retry semantics, or what a failed bill payment does to the reserved amount. Anyone integrating bill pay should read the result command as the source of truth rather than the pay command's return.

The savings claim is the weakest documented part

Snaplii's differentiator, stated twice in the README, is that it is the only one that actually saves you money, up to 10% per transaction, stacking with existing merchant deals and promotions. The mechanism is visible in the CLI surface: quote returns a price with voucher and cashback applied, and browse brand shows denominations and cashback per brand. So the savings are real in the sense that they are computed and shown before you commit, which is the right place for them. What is not documented is the distribution. Up to 10% is a ceiling, and the README gives no per-brand table, no worked example, and no statement of which categories reach the ceiling and which do not. The welcome offer, ten dollars off a first thirty-dollar transaction, is a one-time acquisition incentive and should not be read as a steady-state rate. For an engineering decision, the honest position is that the quote endpoint is the number that matters, and you should sample it across the brands you actually intend to buy before you build a business case on the headline figure. The same caution applies to the 500+ brands claim, which is a catalog size, not a measure of anything about the software.

What the repository does not settle: licence, releases, and failure modes

The licence is listed as unknown in the repository metadata, and the README has a License section in its table of contents without a corresponding text in the material available here. That is not a detail to wave away. Until the licence is published, you cannot know whether redistribution, commercial embedding, or modification of the CLI is permitted, and the safe assumption is that no permission has been granted. The material also shows no releases, which means the install path is a clone-and-install-from-source rather than a pinned version, and pipx install -e ./snaplii-cli is an editable install pointed at a working copy. That is fine for evaluation and awkward for production, because you have no version number to pin and no changelog to read before upgrading. On failure modes, the README is thin. It does not describe what happens when the balance is insufficient at the moment of purchase, when a session token expires between quote and purchase, when a bill payment is rejected by the biller after submission, or when the same item is purchased twice because an agent retried. The non-reusable, pre-funded design limits the blast radius of a compromised key, but it does not by itself prevent duplicate purchases. Rate limits are also unstated. These are the questions to put to the API before depending on it.

Where this sits against Stripe's agent toolkit and virtual card issuers

The obvious comparison is Stripe, which publishes an agent toolkit and an MCP server of its own, and issuers that mint single-use virtual cards. The difference is where the money comes from and what the agent can buy. Stripe's model is built on the merchant's existing card acceptance: the agent presents a payment credential, and the merchant processes it as a card transaction. Snaplii inverts that. The agent spends a prepaid balance against Snaplii's own catalog of gift cards and bill-pay payees, and Snaplii fulfills the purchase on the merchant side. The consequence is a much tighter boundary, since the agent can only buy what is in the catalog and only within the denomination range of each brand, and a much narrower reach, since a merchant outside that catalog is simply not addressable. Single-use virtual cards sit between the two: broader acceptance than a gift card catalog, but the ceiling is usually set by the issuer's controls rather than by a prepaid balance, and the card number itself is still a credential that can leak. Snaplii's non-reusable transaction claim is the direct answer to that leak concern. Which model is right depends entirely on whether the purchases you care about are inside the catalog. For utilities, telecom, and the brands Snaplii lists, the catalog model is the simpler integration. For anything else, it is a dead end.

Editorial conclusion

Adopt this if you are building an agent that buys gift cards or pays utility and telecom bills in Canada or the US, and you want the spend ceiling enforced outside your own code. Do not adopt it if you need a general-purpose card rail, if you cannot accept that the API key must be minted in the Snaplii mobile app, or if an unknown licence is a blocker for your legal review. Verify two things before writing integration code: that the licence is actually published in the repository, and that the savings figure holds for the specific brands you intend to buy, because the README asserts up to 10% without showing a per-brand breakdown.

Official sources

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