Set up Stripe properly, let Claude Code do the wiring and the dashboard work for you, and turn a PageMotor site into one that actually takes money. The full three-part path, test mode first, real card last.
Download it as a prompt file, paste it into Claude, ChatGPT, Gemini or any LLM, and it will walk you through every step interactively.
↓ Download as LLM promptSign up at stripe.com; the dashboard lives at dashboard.stripe.com. You give an email, a name and a password, then confirm the email.
During sign-up you set the country your business is legally registered in. This is a load-bearing choice: it sets your currency and payout rules, and it is effectively fixed to your legal entity, so you cannot freely switch country later. Stripe availability depends on where your business is established, not where your customers are. Ireland and the United Kingdom are both fully supported; check stripe.com/global for any other country before you promise anything, since the list is updated often.
A fresh account can use test mode right away. Stripe now uses isolated sandboxes and an account or environment picker at the top of the dashboard, rather than a single “View test data” switch. You can manage them from the Sandboxes page at dashboard.stripe.com/sandboxes. Stay in a sandbox while you build. No bank details are needed yet.
You cannot accept real payments or receive payouts until the account is activated. Activation means completing the checklist and passing verification. Stripe checks four things: your business identity and address, your bank account, what you sell, and your overall risk level. Concretely you provide:
You can see what is still outstanding under View account status in the dashboard, or at dashboard.stripe.com/account/onboarding. The exact on-screen sequence varies by country and entity type, so treat the list above as the categories of information required, not a fixed wizard.
In the dashboard, go to the Developers area, then API keys. Test keys are at dashboard.stripe.com/test/apikeys; live keys at dashboard.stripe.com/apikeys when you are in live mode. You will see three things: a publishable key, a secret key, and a section to create restricted keys.
pk_. Safe to expose in the browser: it is how Stripe.js and Checkout identify your account client-side. Test is pk_test_, live is pk_live_.sk_. Server-side only, with unrestricted access to your whole account. Test is sk_test_, live is sk_live_. Live secret and restricted keys are shown only once at creation, then masked, so copy them into your secrets store immediately.Test keys and live keys are separate sets. Test keys move no money and operate only on simulated data; live keys operate on real customers and real money. The prefix tells you instantly which environment a key belongs to, which is how you catch a test key accidentally shipped to production, or a live key dropped into a test script.
A restricted key (prefix rk_, so rk_test_ or rk_live_) carries only the permissions you grant it, per resource, with everything else blocked. Stripe explicitly recommends restricted keys over unrestricted secret keys, following the principle of least privilege. This is the key type to hand to any third-party tool, automation or agent: scope it to exactly what it needs, so a leak is contained rather than handing over the whole account. Restricted keys are recommended, not mandatory, and secret keys are not deprecated; Stripe now recommends against secret keys for new use cases and points you to scoped restricted keys instead. This matters in step 3, where you hand a key to Claude Code.
This is the step that wires it up. Stripe hosts an official remote MCP server at https://mcp.stripe.com, and Claude Code connects to it over HTTP. Add it with one line:
$ claude mcp add --transport http stripe https://mcp.stripe.com/
Then, inside Claude Code, complete authentication:
> /mcp
There are two ways to authenticate, and the first is recommended on your own machine:
rk_...), never your full secret key, in the Authorization header. Admins can enable or disable MCP access per environment at dashboard.stripe.com/settings/mcp.Instead of the hosted endpoint, you can run the MCP server as a local process and add it to Claude Code as a stdio server:
$ claude mcp add stripe -- npx -y @stripe/mcp@latest --api-key=rk_test_xxx
This package is part of the Stripe Agent Toolkit (the stripe/agent-toolkit repository), so if you search that name you will find it. The only accepted arguments are --api-key and --stripe-account. You can set STRIPE_SECRET_KEY as an environment variable instead of passing the key inline. The package validates the key and warns you to use a restricted rk_ key rather than a full sk_ secret key.
@stripe/mcp package no longer uses a --tools flag at all. Which tools are available is controlled entirely by the permissions on the restricted key you pass, not by a flag. Anything online still showing --tools is from an older version.pk_test_ and sk_test_ (or rk_test_) pair, and keep the MCP environment toggle on sandbox, so nothing it does can move real money while you learn.Try a read-only request first, so you can see real data come back and confirm the connection is live:
> List my Stripe products and prices.
Then a small, reversible create:
> Create a test product called Sample Download, price £5, then show me how to delete it.
Through the hosted server, the agent can work across the core payment lifecycle in plain English: customers, products, prices, payment links, invoices, subscriptions, coupons, refunds, disputes and your balance, plus searching Stripe’s documentation. It reaches most of this through generic tools that wrap the Stripe API, so “create a product and a price, give me a payment link, list this week’s payments, what is my balance” are all in scope.
Claude will tell you what it is about to do before it touches anything. Read the plan, then approve. Keep that human-in-the-loop confirmation on for write actions; it is your safety net while you learn what the connection can reach.
This is the payoff. On the PageMotor site, two plugins must be active: EP Ecommerce (the store engine) and EP Ecommerce Stripe (the payment provider that extends it). Install each through Manage Plugins, then open Settings → EP Ecommerce Stripe.
The settings page is grouped. In the Stripe group, tick Enable Stripe Payments and set Mode to Test. In the Test API Keys group, paste your pk_test_ Publishable Key and your sk_test_ Secret Key. The plugin selects the active key by mode at runtime, so test keys are used while Mode is Test, and your Live API Keys stay unused until you switch.
The Webhook group shows the exact endpoint URL to register, built from your own site address. It takes this shape:
https://your-site.com/?ep_ecommerce_stripe_webhook=1
In the Stripe dashboard, go to Developers → Webhooks, add an endpoint, paste that URL, and select the events the plugin listens for:
payment_intent.succeededpayment_intent.payment_failedcheckout.session.completedStripe then generates a webhook signing secret (prefix whsec_). Paste it into Webhook → Webhook Signing Secret in the plugin settings. The plugin uses it to verify each event’s signature, so only genuine Stripe calls are trusted.
Create a product in EP Ecommerce with a name, a unique slug, a price, a currency that matches your Stripe account, and status set to active so it appears on the site. Then place the checkout shortcode on a page, pointing at the product slug:
[ep-checkout product="my-product-slug"]
Open the page and pay with a Stripe test card: 4242 4242 4242 4242, any future expiry date, any three-digit CVC. Card details are entered in Stripe’s own element and confirmed with Stripe.js, so no card data touches your server.
Worth understanding, so you know which part is doing what when something needs a nudge.
The payment processor and dashboard. It holds your products, prices, customers and payouts, and it is where you create keys and register webhook endpoints.
Operates Stripe for you from the terminal, through Stripe’s MCP server. It turns “knows about Stripe” into “can run your Stripe account”: create products and prices, manage webhooks, list charges, all by you asking.
The EP Ecommerce Stripe plugin renders the checkout, verifies the webhook signature, and records the order against the site. This is the part that takes the money on your pages.
Everything so far has been in test mode. Going live is a deliberate, separate switch, not a flag you flip by accident.
Test mode simulates payments, customers and charges with no real money and only test card numbers. Live mode processes real cards and real money, and is only usable once the account is activated. The keys carry the environment in their prefix, so the safest mental model is: test for building, live only when you mean it.
| Thing | Test mode | Live mode |
|---|---|---|
| Keys | pk_test_ / sk_test_ / rk_test_ | pk_live_ / sk_live_ / rk_live_ |
| Cards | Stripe test cards only (e.g. 4242…) | Real customer cards |
| Webhooks | A test-mode endpoint and its whsec_ | A separate live-mode endpoint and its own whsec_ |
| Payouts | None; no money moves | Real payouts, after activation |
To go live in PageMotor: paste your pk_live_ and sk_live_ keys into the Live API Keys group, create a fresh webhook endpoint in live mode (the same URL, but a new endpoint produces a new whsec_), paste that live signing secret in, then set Mode to Live. Complete Stripe’s account activation first, or live charges will not clear.
The webhook is what makes a payment real on your site, not just in the browser.
When a payment succeeds, Stripe notifies your site server-to-server, rather than the site trusting a message from the customer’s browser. That is why the webhook matters: it is the authoritative confirmation. The EP Ecommerce Stripe plugin listens for three events: payment_intent.succeeded (which fulfils the order), payment_intent.payment_failed (which marks it failed), and checkout.session.completed. Each event’s signature is verified against your webhook signing secret before it is acted on.
While developing locally, the Stripe CLI lets you replay events at your machine. It is only needed for local development; the hosted MCP server and dashboard-registered webhook handle everything for a live site. Install it (for example brew install stripe), sign in with stripe login, then forward and fire test events:
$ stripe listen --forward-to "localhost:8080/?ep_ecommerce_stripe_webhook=1" # prints a whsec_ for local use $ stripe trigger payment_intent.succeeded
whsec_) has its own. Paste the one that matches the endpoint and mode you are actually using, or signature verification will fail and orders will not complete.You are handing keys to live money to a terminal agent and a website. A few habits keep that safe.
test keys and a sandbox until the whole loop works end to end.rk_ key scoped to exactly what they need, not your full secret key.Four proofs that the whole chain is real, not just configured.
4242 test payment completes Checkout on the live PageMotor page.The handful of things that actually go wrong, and the fix for each.
Check that your rk_test_ key is set (as the --api-key argument or the STRIPE_SECRET_KEY environment variable), then remove and re-add the server. For the hosted server, complete the OAuth sign-in in your browser when prompted, or confirm MCP access is enabled for your environment at dashboard.stripe.com/settings/mcp.
This is almost always the webhook. Confirm the endpoint URL in Stripe matches the one shown in the plugin’s Webhook group exactly, that the signing secret pasted into Webhook Signing Secret is the one for that endpoint, and that test-versus-live lines up on both sides. A live endpoint’s secret will not verify a test payment, and vice versa.
Confirm which mode you are in from the prefix on the keys in use (test versus live) and the dashboard environment picker. If a real charge happened, refund it from the Stripe dashboard, then roll the key that should have been a test key: delete it on the API keys page and create a fresh one. Set the plugin Mode back to Test while you investigate.
You are most likely using a real card in test mode, or a wrong number. In test mode, use Stripe’s published test cards: 4242 4242 4242 4242 for a straightforward success, with any future expiry and any three-digit CVC. The full set of test cards (declines, authentication, specific brands) is in Stripe’s testing docs, linked below.
Three usual causes: the account is not fully activated (so live charges cannot clear), the live webhook endpoint was never created (test and live endpoints are separate), or the live keys were not swapped into the Live API Keys group and Mode left on Test. Work through all three.
If Claude Code can read but not create (or the reverse), the restricted key probably lacks the permission for that resource. Edit the key at dashboard.stripe.com/apikeys to grant exactly the resources the task needs, or create a new scoped key. Scoping is now done entirely on the key, so the key’s permissions are what decide what the agent can do.