Billing Setup Just Moved Into the Coding Tool

For twenty years you set up billing in a dashboard. You clicked through products, prices, tax settings and dunning rules, and a developer wired the result into the app. On Tuesday Paddle holds a launch event for what it calls its AI Toolkit. The pitch is simple. Set up billing from inside Claude Code, Codex or Cursor, in the same window where you write the code.

The pieces are not new. Paddle shipped its MCP server in 2025 and moved it to a hosted server in May. Its agent skills and Claude Code plugin also arrived in May, alongside a command-line tool that knows when an agent is driving it. The event bundles them under one name. What matters is the direction. Billing setup is leaving the dashboard and moving into the coding tool, and that changes who touches it and who checks it.

What a builder can do now

Three things ship together, and each one removes a trip to the dashboard.

The Paddle MCP server gives a coding agent a live connection to your Paddle account. It exposes three tools: search finds the right API method, execute runs JavaScript that chains Paddle calls, and report_missing_tool tells Paddle what the agent was unable to do. Paddle’s own examples include creating products and prices, previewing a transaction, setting up a customer with custom pricing, handling upgrades and cancellations, and configuring webhook destinations. Sandbox and live run on separate servers.

The agent skills were ten short instruction sets at launch that load when a task matches. They cover catalog setup, checkout, webhooks, subscription sync, localized pricing pages, billing history, the customer portal, cancellation, plan changes and sandbox testing. The Claude Code plugin installs them in one command and wires up the MCP servers at the same time.

The Paddle CLI runs from the terminal and returns JSON when it detects an agent at the keyboard.

Put the three together and a developer can type one sentence into Claude Code: add a $29 monthly plan with a 14-day trial, show localized prices on the pricing page, and sync subscription state to our database. The agent writes the code, creates the catalog, and tests it in sandbox. Nobody opens the Paddle dashboard.

The config file is now the contract

I have argued that the next agents will not be chatbots. They will be documents that act. An invoice that knows its own terms. A policy file an agent reads before every run. Paddle’s toolkit is a clean case of that idea landing in billing.

Look at where the rules live now. The skills are markdown files. The project’s CLAUDE.md tells the agent which environment it is in and what it can touch. The pricing, trial length, tax behavior and dunning rules sit in code and config next to the functions that call them. The agent reads those files, acts on them, and writes the result back as more files.

That is a change in kind, not degree. In the dashboard, the price was a row in Paddle’s database and the code was a separate thing that referenced it. Now the description of the plan and the code that sells the plan live in one place, under version control, and an agent treats both as instructions. The document does the work.

Who reviews a price change that ships in a pull request?

Here is the part that will keep a finance leader up. When pricing lived in the dashboard, finance owned the login. A price change was a finance act. Now a price change is a code change. It arrives as a pull request, written by an agent, reviewed by whichever engineer is on rotation, and merged on a Thursday afternoon.

Paddle knows this. Its MCP documentation is more candid than most. The server does not block destructive operations. It marks them with a warning and notes that agents can ignore it. Paddle recommends starting with a read-only API key, granting write access only for what the agent needs, and turning on a mode where each execute call waits for a person to approve it. It warns that auto mode leaves the agent to decide whether to run a destructive call. The May skills announcement says to review every line an agent writes before you merge or deploy, and it names authentication, webhook secrets and access gating as the places to look hardest.

Those are good defaults. They are also defaults that a developer sets, in a developer’s tool, with a developer’s judgment about what counts as risky. A developer sees a secret leak as a risk. A finance leader sees a 14-day trial changed to 30 days as a risk, and nothing in the toolkit flags that. The stop conditions exist. Finance did not write them.

What to ask for

If your company sells software and your developers use coding agents, assume this is already happening in your repo, with Paddle or with someone else. Four asks, in order of how fast you can get them.

1. A read-only key by default. Any agent key with write access to live billing needs a name on it and a reason.
2. Approval on every live write. Paddle’s ask-permission mode does this. Turn it on and leave it on for live. Sandbox can run free.
3. Finance on the review list. Any pull request that touches prices, trials, tax settings or dunning rules gets a finance reviewer the same way a change to the auth code gets a security reviewer. Most code hosts can do this with a path rule and a team name.
4. A log you can read. Ask whether anything records what the agent ran, where that record lives, and who can see it. If the answer is “in the developer’s terminal,” that is not a log.

None of this slows the developer much. It moves the approval to where the change now happens.

The dashboard was never the control

It felt like one. A separate login, a separate screen, a separate team that owned it. But the dashboard was a place, and controls that depend on a place fail the moment the work moves. The work just moved into the coding tool, and the agent that lives there reads documents and acts.

So write the document. Put the pricing rules, the limits, and the names of the people who approve changes in the same files the agent reads. The config file is the contract. Make sure finance signed it.