Skip to main content
Glama
PaddleHQ

Paddle MCP Server

Official
by PaddleHQ

create_transaction

Create new transactions in Paddle for automated checkout payments or manual invoicing workflows, handling customer billing and subscription setup.

Instructions

This tool will create a new transaction in Paddle.

Don't use this tool without checking with the user first. Avoid using before gaining explicit approval.

The collectionMode against a transaction determines how Paddle tries to collect for payment:

  • Manually-collected transactions are for sales-assisted billing. Paddle sends an invoice to the customer when a transaction is billed. Payment is often by wire transfer. Requires billingDetails, and an address which has country, postalCode, region, city, and firstLine.

  • Automatically-collected transactions are for payments collected automatically using a self-serve checkout where payment is collected using a checkout. Pass the transaction to a checkout or use the returned checkout.url to collect for payment. checkout.url is a unique Paddle payment link composed of the URL passed as checkout.url, or the default payment URL on the account, with ?_ptxn= and the Paddle ID for this transaction appended to the URL.

Transactions have a status. Set the status or omit it to have Paddle set it. It's only recommended to set the status manually if working with manually-collected transactions as part of an invoicing workflow. Options are:

  • billed: Marks as finalized and can't be updated, only canceled. This is essentially issuing an invoice. At this point, it becomes a legal record so it can't be changed. Paddle automatically assigns an invoice number, creates a related subscription, and sends it to the customer.

  • canceled: Canceled transactions are no longer due. This is only for record purposes on creation.

When status is omitted, transactions are initially created with the status of draft or ready:

  • Draft transactions have items against them, but don't have all of the required fields for billing. Paddle creates draft transactions automatically when a checkout is opened.

  • Paddle automatically marks transactions as ready when all of the required fields are present for billing. This includes customerId and addressId for automatically-collected transactions, and billingDetails for manually-collected transactions.

When a transaction has items which are recurring, and the transaction has a status of billed when manually-collected or completed when automatically-collected, Paddle automatically creates a related subscription for the items on the transaction. Use the returned subscriptionId to get the subscription entity.

Use the include parameter to include related entities in the response:

  • address: An object for the address entity related to this transaction. Only returned if an address is set against the transaction with addressId.

  • available_payment_methods: An array of payment methods that are available to use for this transaction.

  • business: An object for the business entity related to this transaction. Only returned if a business is set against the transaction with businessId.

  • customer: An object for the customer entity related to this transaction. Only returned if a customer is set against the transaction with customerId.

  • discount: An object for the discount entity related to this transaction. Only returned if a discount is set against the transaction with discount or discountId.

Ensure you have all the information needed before making the call. Don't fabricate, imagine, or infer details and parameter values unless explicitly asked to. If anything is ambiguous, unknown, or unclear, ask the user for clarification or details before you proceed.

Consider using the preview_transaction_create tool to preview and confirm the transaction before creating it.

If successful, the response includes a copy of the new transaction entity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
statusNoStatus of this transaction. Either set a transaction to `billed` or `canceled` when creating, or omit to let Paddle set the status. Transactions are created as `ready` if they have an `addressId`, `customerId`, and `items`, otherwise they are created as `draft`. Marking as `billed` when creating is typically used when working with manually-collected transactions as part of an invoicing workflow. Billed transactions cannot be updated, only canceled.
customerIdNoPaddle ID of the customer that this transaction is for, prefixed with `ctm_`. If omitted, transaction status is `draft`.
addressIdNoPaddle ID of the address that this transaction is for, prefixed with `add_`. Requires `customerId`. If omitted, transaction status is `draft`.
businessIdNoPaddle ID of the business that this transaction is for, prefixed with `biz_`. Requires `customerId`.
customDataNoAny structured custom key-value data needed outside of Paddle's standard fields. Occasionally used by third-parties.
currencyCodeNoSupported three-letter ISO 4217 currency code. Must be `USD`, `EUR`, or `GBP` if `collectionMode` is `manual`.
collectionModeNoHow payment is collected for this transaction. `automatic` for checkout, `manual` for invoices. If omitted, defaults to `automatic`.
discountIdNoPaddle ID of the discount applied to this transaction, prefixed with `dsc_`.
billingDetailsNoDetails for invoicing. Required if `collectionMode` is `manual`.
billingPeriodNoTime period that this transaction is for. Set automatically by Paddle for subscription renewals to describe the period that charges are for.
itemsYesList of items to charge for. Charge for items that have been added to the catalog by passing the Paddle ID of an existing price entity, or charge for non-catalog items by passing a price object. Non-catalog items can be for existing products, or pass a product object as part of the price to charge for a non-catalog product.
checkoutNoPaddle Checkout details for this transaction. Used for automatically-collected transactions, or when creating or updating a manually-collected transaction where `billingDetails.enableCheckout` is `true`.
includeNoInclude related entities in the response. Use a comma-separated list to specify multiple entities.

Implementation Reference

  • The main handler function that implements the logic for creating a transaction using the Paddle SDK by calling paddle.transactions.create(params).
    export const createTransaction = async (
      paddle: Paddle,
      params: z.infer<typeof Parameters.createTransactionParameters>,
    ) => {
      try {
        const transaction = await paddle.transactions.create(params);
        return transaction;
      } catch (error) {
        return error;
      }
    };
  • Tool schema definition specifying the method name, description from prompts, input parameters Zod schema, and required actions (write/create on transactions).
      method: "create_transaction",
      name: "Create a transaction",
      description: prompts.createTransactionPrompt,
      parameters: params.createTransactionParameters,
      actions: {
        transactions: {
          write: true,
          create: true,
        },
      },
    },
  • src/api.ts:19-19 (registration)
    Maps the CREATE_TRANSACTION tool method to the createTransaction handler function in the API's toolMap.
    [TOOL_METHODS.CREATE_TRANSACTION]: funcs.createTransaction,
  • Constant exporting the string identifier for the create_transaction tool method.
    CREATE_TRANSACTION: "create_transaction",
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds significant behavioral context beyond annotations. It explains collection modes (manual vs. automatic), status implications (billed transactions become legal records), subscription creation for recurring items, and response inclusion options. Annotations only indicate it's not read-only or destructive, so the description provides essential operational details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is excessively long (over 600 words) and poorly structured. It mixes usage warnings, parameter explanations, and behavioral details without clear organization. While informative, it lacks front-loading and contains repetitive elements, making it difficult for an agent to quickly extract key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (13 parameters, nested objects, no output schema), the description provides substantial context about behavior, usage scenarios, and implications. It covers collection modes, status handling, subscription creation, and response inclusions. However, it could better summarize the tool's overall workflow and error conditions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds some semantic context for parameters like 'collectionMode', 'status', and 'include', explaining their effects and usage scenarios, but doesn't provide extensive additional parameter details beyond what the schema already documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'create a new transaction in Paddle.' It specifies the verb ('create') and resource ('transaction'), and distinguishes it from sibling tools like 'preview_transaction_create' and 'get_transaction' by emphasizing the creation action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool: 'Don't use this tool without checking with the user first' and 'Consider using the preview_transaction_create tool to preview and confirm the transaction before creating it.' It also mentions alternatives like using checkouts for automatically-collected transactions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/PaddleHQ/paddle-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server