Mollie

View saved version →

---
name: mollie-agent-toolkit
description: >
  Activate this skill when a developer wants to build an AI agent that uses Mollie —
  giving an LLM function-calling access to Mollie via @mollie/agent-toolkit. This
  includes: OpenAI Agents SDK, LangChain, or Vercel AI SDK integrations with Mollie;
  letting an agent list/create payments, issue refunds, manage customers or
  subscriptions, or read balances/settlements; tool allowlisting for an LLM agent;
  and safety controls for agents that can move money. This is distinct from
  `mollie-payments`, which is about integrating Mollie into a regular application,
  not building an agent around it.
---

# Mollie Agent Toolkit

Building "an AI agent that uses Mollie" is a different task from "integrating Mollie
into my app." The agent's behavior is driven by a model's output, not your own
application logic — treat every write-capable tool as something an LLM, not your
code, decides to call.

## ⚠️ This toolkit can move money

`create_payment` and `create_refund` are real financial operations. Once an LLM can
call them, anything that reaches the prompt — a customer's email, a payment
description, any untrusted text — can influence what the agent does. Two rules
follow, and they are not optional:

1. **Default to read-only.** Always pass an explicit `tools` allowlist. Never omit
   it — omitting `tools` exposes every tool, including the money-moving ones.
2. **Confirm write operations.** Put a human-in-the-loop, or your own server-side
   authorization check, in front of anything that creates a payment or refund. Do
   not let a model trigger these unattended.

These follow the same principle as `<mollie-payments:references/operations/write-action-safety.md>`
— apply that file's rules here too, with "confirm before executing" now meaning a
human approves the *specific agent-proposed action*, not just that a human wrote the
code path.

---

## Step 1 — Which framework?

> Which agent framework are you using — Vercel AI SDK, OpenAI Agents SDK, or
> LangChain?

The toolkit is framework-agnostic; only the adapter import changes:

| Framework | Adapter |
|---|---|
| Vercel AI SDK | `toVercelAITools` from `@mollie/agent-toolkit/vercel-ai` |
| OpenAI Agents SDK | `toOpenAITools` / `executeOpenAIToolCall` from `@mollie/agent-toolkit/openai` (or map `toolkit.getTools()` directly to `tool()`) |
| LangChain | `toLangChainTools` from `@mollie/agent-toolkit/langchain` |

```typescript
// Vercel AI SDK — read-only agent, safe to run first
import { MollieAgentToolkit } from "@mollie/agent-toolkit";
import { toVercelAITools } from "@mollie/agent-toolkit/vercel-ai";
import { generateText } from "ai";

// Injected from your secret manager / deployment config (a test_… key to start)
declare const mollieApiKey: string;

const toolkit = new MollieAgentToolkit({
  apiKey: mollieApiKey,
  tools: ["list_payments", "get_payment", "list_balances", "get_balance"],
});

const { text } = await generateText({
  model: /* your chosen model provider */,
  tools: toVercelAITools(toolkit),
  prompt: "List my last 5 payments",
});
```

```typescript
// OpenAI Agents SDK — read-only agent, safe to run first
import OpenAI from "openai";
import { MollieAgentToolkit } from "@mollie/agent-toolkit";
import { toOpenAITools, executeOpenAIToolCall } from "@mollie/agent-toolkit/openai";

const openai = new OpenAI();
const toolkit = new MollieAgentToolkit({
  apiKey: mollieApiKey,
  tools: ["list_payments", "get_payment", "list_balances", "get_balance"],
});

const tools = toOpenAITools(toolkit);
const messages = [{ role: "user", content: "List my last 5 payments" }];

const response = await openai.chat.completions.create({ model: "gpt-5.5", tools, messages });
const toolCalls = response.choices[0].message.tool_calls ?? [];

// The raw OpenAI API doesn't drive the tool-use loop for you (unlike the Vercel
// AI SDK example above) — feed each result back as a "tool" message, keyed by
// tool_call_id, and call the API again so the mo

Preview of the first 4,000 characters. Read full instructions →

View saved version →

---
name: mollie-payments
description: >
  Activate this skill when a developer is working with Mollie: integrating payments,
  setting up Mollie Connect for a platform/marketplace, building recurring payments or
  subscriptions, issuing refunds or captures, investigating chargebacks or settlements,
  or troubleshooting a Mollie integration. This includes: hosted checkout, custom
  checkout, Mollie Components (card fields), payment links, webhooks and payment
  status handling, Next.js / React / Vue / Node.js / PHP / Python integrations, 3D
  Secure, PCI compliance, payment methods (iDEAL, credit card, SEPA, Klarna, Apple
  Pay, Google Pay, Bancontact), OAuth onboarding, submerchants, application fees,
  customers and mandates, subscriptions, reconciliation, sales invoices and B2B
  invoicing, stuck or pending payments, missing webhooks, and 401/403 errors.
---

# Mollie Payments

Use `<references/product-selection/routing-guide.md>` for the full decision tree if
a request spans more than one dimension below (e.g. "recurring payments for my
marketplace clients"). The steps here cover the common single-dimension case.

## Step 1 — Is this new integration work, or something else?

**Ask this first, before anything else:**

> Are you setting up something new, fixing a problem with an existing integration,
> upgrading/migrating an existing one, or building an AI agent that uses Mollie?

- **Something isn't working** (stuck payment, missing webhook, auth error, wrong
  credentials) → go straight to `<references/troubleshooting/>`. Do not generate new
  integration code before ruling out a known issue.
- **Upgrading an SDK version or migrating from an older API** → this is the
  `mollie-upgrade` skill, not this one.
- **Building an agent that calls Mollie autonomously** (via `@mollie/agent-toolkit`,
  or exposing Mollie as LLM tools) → this is the `mollie-agent-toolkit` skill.
- **Refunding, capturing, or investigating existing payments/chargebacks/settlements**
  → `<references/operations/>`.
- **Invoicing a customer to be paid later** (B2B billing, payment terms, VAT line
  items — not a real-time checkout) → this is Sales Invoices (Revenue Collection),
  a distinct product from the Payments API. Go straight to
  `<references/payments/sales-invoices.md>` — skip Steps 2–6 below, they don't apply.
- **New integration** → continue to Step 2.

---

## Step 2 — Direct merchant or platform?

> Are you building this for your own business (accepting payments directly as a
> merchant), or are you building a platform or marketplace that processes payments
> on behalf of other businesses?

**If they are a platform or marketplace** → this needs Mollie Connect, not a
standard integration. Route to `<references/connect/oauth-and-onboarding.md>` and
work through the Connect reference set — it covers OAuth, onboarding, application
fees, permissions/tokens, and testing/offboarding. Everything in Steps 3–5 below
still applies once Connect is set up (a platform can still need recurring payments
or hosted checkout — just executed via a client's access token).

**If they are a direct merchant** → continue to Step 3.

---

## Step 3 — One-time or recurring?

> Is this a single checkout, or does the customer get charged again later without
> re-entering their payment details (subscription, saved card, usage billing)?

**Recurring** → route to `<references/recurring/customers-and-mandates.md>` — this
is a distinct flow (Customers API → first payment → mandate → subscription or
on-demand charge), not a variant of one-time checkout. Webhook handling still
applies (`<references/payments/webhooks.md>`), but skip Step 4 below.

**One-time** → continue to Step 4.

---

## Step 4 — Understand their checkout preference

> How much control do you want over the payment experience?
>
> **A) Mollie-hosted checkout** — Mollie handles the entire payment page. Simplest to
> integrate; no frontend work required. Customers are redirected to Mollie to
> complete payment.

Preview of the first 4,000 characters. Read full instructions →

Referenced files: 22 — file references are metadata, not package contents.

View saved version →

---
name: mollie-upgrade
description: >
  Activate this skill when a developer wants to upgrade their Mollie SDK to a newer
  version, or migrate an existing integration from a deprecated Mollie API to its
  replacement — most commonly migrating from the Orders API to the Payments API.
  This includes: updating @mollie/api-client, mollie-api-php, mollie-api-python, or
  mollie-api-typescript to a newer major version, resolving breaking changes after an
  upgrade, and moving off the Orders API (orderNumber, order lines, Shipments API,
  order cancellation) onto the Payments API (captures, release-authorization,
  unified refunds).
---

# Mollie Upgrade

This is a distinct workflow from `mollie-payments` — that skill builds new
integrations; this one changes existing, working code. Confirm current behavior
with tests before changing anything, and re-verify after.

## Step 1 — Identify the type of upgrade

> Are you updating your Mollie SDK to a newer version, or moving off the Orders API
> to the Payments API?

These require different playbooks — ask before proceeding.

---

## Step 2A — SDK version upgrade

1. **Detect the current version.**
   ```bash
   # Node.js
   npm list @mollie/api-client
   # TypeScript
   npm list mollie-api-typescript
   # PHP
   composer show mollie/mollie-api-php
   # Python
   pip show mollie-api-python
   ```
2. **Find the latest supported version and read its changelog** before touching
   code — do not upgrade blind. Check for a major version bump specifically; minor/
   patch upgrades rarely have breaking changes, major ones usually do.
3. **Identify breaking changes** relevant to this codebase — grep the existing
   integration for methods/fields the changelog flags as renamed or removed, rather
   than assuming nothing broke.
4. **Apply the version bump and required code changes** together, not separately —
   an upgraded dependency with unmigrated call sites will fail at runtime, not at
   install time, for a dynamically-typed language.
5. **Run the existing test suite.** If there isn't one covering the Mollie
   integration, say so explicitly before declaring the upgrade done — this skill
   should not report success on the basis of "the code compiles."
6. **Verify webhooks and payment flows manually in test mode** — create a test
   payment, complete it, confirm the webhook still fires and fulfilment still
   triggers, before recommending a live-mode deploy.

---

## Step 2B — Migrating from Orders API to Payments API

Mollie no longer recommends the Orders API. Payments API is simpler and gets new
features the Orders API doesn't. This is not a drop-in rename — several concepts
don't map 1:1.

### Field and endpoint changes

| Orders API | Payments API | Note |
|---|---|---|
| `orderNumber` | `description` | No dedicated order-number field |
| `lines[].name` | `lines[].description` | |
| Negative amounts on `physical`/`digital`/`shipping_fee`/`surcharge` lines | Not supported | Redesign any discount-via-negative-line logic |
| `consumerDateOfBirth` | Removed | No replacement field |
| `expiresAt` controlling authorization expiry | Removed | Authorization expiry is no longer configurable this way |

### Authorize-then-capture behavior changed

Orders auto-produced an `authorized` status for Klarna/Billie/Riverty. Payments
capture immediately by default — **you must explicitly set `captureMode: 'manual'`**
to keep a hold-then-capture flow. Without this, funds are taken immediately where
the old integration expected a hold. See `<mollie-payments:references/operations/captures.md>`
for the Payments-API capture flow.

### Fulfilment: Shipments API → Captures API

- The Shipments API doesn't exist for standalone Payments — use the Captures API
  instead.
- Captures only work on `authorized`-state payments, are amount-based (not
  line-based), and are asynchronous (status via webhook, not immediate).
- **You cannot use the Captures API on a payment that is still part of an Order** —
  fully migra

Preview of the first 4,000 characters. Read full instructions →