Overview
The Frisbii developer toolkit gives AI coding assistants, such as Claude Code, Cursor and Codex, expert knowledge of Frisbii Billing and Frisbii Pay. Your developers keep working in their own editor and ask their assistant for help in plain language; the assistant uses the toolkit's skills to write integration code that follows Frisbii's recommended patterns and avoids the mistakes we most often see in support.
A skill is a packaged set of instructions, reference material and small scripts on one topic, such as checkout or webhooks. Your developers don't need to name a skill: the assistant picks the right one automatically from what they ask.
Note
The developer toolkit is for developers building an integration with Frisbii Billing & Pay. It is different from the Frisbii MCP Connector and the skills in the MCP prompt guide, which help support, finance and operations teams work with live account data in a chat assistant.
Before you begin
Your developers use an AI coding assistant that supports skills, such as Claude Code, Cursor or Codex.
You have a Frisbii test account to build and test against. Live keys should never be used while developing. If you don’t have a test account, you can create one here - https://frisbii.com/signup/
Install the toolkit
Claude Code: run these two commands inside Claude Code:
/plugin marketplace add frisbii-com/frisbii-developer-toolkit
/plugin install frisbii@frisbii-developer-toolkitThis installs all six skills and also connects the Frisbii MCP server, so the assistant can look up and set up data in your test account while it codes. The skills work without the MCP connection. See Connect MCP to your AI assistant for how the connection signs in with your API key.
Note
MCP usage is billed per token.
Cursor, Codex and other assistants: run this in your project folder and choose the skills you want:
npx skills add frisbii-com/frisbii-developer-toolkitOther assistants get the skills only. To use the MCP server as well, add https://mcp.frisbii.com/mcp in that assistant's own MCP settings.
The skills
Each skill below lists its purpose and example prompts your developers can use. The prompts are only examples: any request on the same topic will use the skill.
Frisbii best practices
Purpose: the starting point for any Frisbii integration. It helps the assistant choose the right Frisbii product and API for what you want to build, and applies the fundamentals every integration needs: authentication, test versus live accounts, handles, safe retries without double charges, error handling, and a list of the integration mistakes we see most often in support. It hands over to the more specific skills below when needed.
Example prompts:
"We want to sell monthly memberships on our website. Which Frisbii products and APIs should we use, and how should we structure the integration?"
"Set up a Frisbii API client for our Node.js backend with authentication, timeouts and error handling."
"How do I make sure retrying a failed request can never charge a customer twice?"
"Review our Frisbii code against the common integration mistakes and tell me what to fix."
Frisbii checkout
Purpose: building payment collection with Frisbii Checkout: one-off payments, saving a card or wallet for future payments, and checkout for subscription sign-ups. It covers choosing between the hosted, embedded and modal checkout, which payment methods to offer in each market (cards, MobilePay, Vipps, Swish, SEPA, Apple Pay, Google Pay, Klarna, PayPal and others), 3-D Secure and SCA, confirming payments safely on your server, and settling and refunding.
Example prompts:
"Add a Frisbii checkout to our order page so customers can pay by card, MobilePay or Apple Pay."
"We sell physical goods. Reserve the payment at checkout and charge it only when the order ships."
"Which payment methods should we offer customers in Denmark, Norway, Sweden and Germany?"
"Apple Pay isn't showing in our embedded checkout. What are we missing?"
"Save the customer's card during sign-up so we can charge it for future orders."
Frisbii subscriptions
Purpose: building recurring billing on Frisbii Billing. It covers designing plans and pricing, creating and changing subscriptions, add-ons, discounts and coupons, trials, upgrades and downgrades with proration, usage-based (metered) billing, contract and notice periods, pausing and cancelling, the customer portal, and handling failed renewals and dunning.
Example prompts:
"Create Basic, Pro and Enterprise plans with monthly and yearly billing and a 14-day free trial."
"Let customers upgrade from Basic to Pro mid-month and pay only the difference."
"We bill per API call. Set up usage-based billing and report usage from our app each day."
"What should our app do when a renewal payment fails, and when should we remove access?"
"Add a link to the Frisbii customer portal so customers can update their card or cancel."
Frisbii webhooks
Purpose: receiving Frisbii webhooks reliably and securely. It covers verifying each webhook's signature (with ready-made code for Python, Node.js, PHP, Java, C# and Go), choosing which events to handle, responding quickly, coping with retries, duplicates and events that arrive out of order, and testing webhooks locally.
Example prompts:
"Build a webhook endpoint in our Express app that verifies Frisbii signatures and marks orders as paid."
"Which Frisbii webhook events do we need for a subscription business?"
"Our webhook handler sometimes processes the same event twice. Make it safe to run more than once."
"Send a test webhook to my local server so I can check the signature verification works."
Frisbii migrate from Stripe
Purpose: moving an existing Stripe integration and its billing data to Frisbii. It maps Stripe objects and webhook events to their Frisbii equivalents, guides the code changes, and plans the data side: exporting cards from Stripe, importing SEPA and PayPal customers, and running Stripe and Frisbii side by side during the switch.
Example prompts:
"We use Stripe Checkout and Stripe Subscriptions today. Plan our migration to Frisbii."
"Replace our Stripe PaymentIntent code with the Frisbii equivalent."
"Map our Stripe webhook handlers to Frisbii events."
"How do we move our customers' saved cards from Stripe to Frisbii without asking them to re-enter them?"
Frisbii go-live review
Purpose: checking that an integration is ready before you switch from your test account to your live account. The assistant scans your code for common problems (such as API keys written into the code, or payments confirmed only from the browser redirect), works through a checklist covering keys, payments, webhooks, subscriptions, error handling and test evidence, and gives you a verdict (ready, ready with fixes or not ready) with the file and line behind each finding. It reports first and only changes code if you ask it to.
Example prompts:
"Is our Frisbii integration ready to go live?"
"Do a security review of our payment code before launch."
"We're switching from the Frisbii test account to live next week. What do we need to check?"
Tips for getting the best results
Say what you're building and in which language or framework, for example "a Django shop selling physical goods in Denmark".
Build against your test account. Keep API keys in configuration or a secret store, never in the code you share with the assistant.
Run the go-live review before launch, even if you built the integration without the toolkit.
The Frisbii API reference remains the source of truth. The skills point your assistant to it at docs.frisbii.com for full details.