Drop these into Cursor, Claude Code, v0, Aider, or any other agent. Each prompt is self-contained — no docs fetch needed; the agent has everything it needs to act in one paste.
Settle is built so an AI agent can wire it up end-to-end without a human clicking through docs. The catalogue below mirrors what surfaces on the dashboard overview — copy any prompt, drop it into your agent, replace the placeholder tokens (<PASTE>, <DESCRIBE-YOUR-PRODUCT>, etc.), and let it run.
Adding a prompt: open apps/web/lib/prompts.ts and append to the PROMPTS array. It surfaces here, on the dashboard, and on the onboarding done step automatically.
Connect Settle.
One-liner. Drop into any AI agent — Cursor, Claude Code, v0, Aider — and Settle is wired into your project.
Set up Settle in this project. MCP: https://mcp.settle.xxx, my key: <PASTE>. Mint a $1 test invoice and show me the checkout link.
Replace <PASTE>.
Wire up Settle webhooks.
Register a webhook endpoint via the MCP, scaffold the receiver in your codebase, verify the signature scheme. End-to-end, no dashboard clicks.
Wire up Settle webhooks for this project. Settle has NO REST API and NO dashboard form for webhook registration — everything goes through the MCP at https://mcp.settle.xxx/mcp via JSON-RPC `tools/call`.
Steps:
1. Register the endpoint:
- Tool: register_webhook
- Auth: Authorization: Bearer <PASTE>
- Args: { url: "<YOUR_APP_URL>/api/webhooks/settle", events: ["invoice.paid"] }
- Returns: { id, url, events, signing_secret, ... } — the signing_secret is shown ONCE. Save it as SETTLE_WEBHOOK_SECRET in env immediately.
2. Scaffold the receiver at <YOUR_APP_URL>/api/webhooks/settle. Verify the signature on every request:
- Header: X-Settle-Signature: t=<unix_ts>,v1=<hex>
- Compute: HMAC_SHA256(SETTLE_WEBHOOK_SECRET, "<unix_ts>.<raw_request_body>")
- Compare hex to v1 with constant-time equality (e.g. crypto.timingSafeEqual). Reject on mismatch with 401.
- Optionally reject if |now - t| > 5 minutes for replay defense.
- On verified invoice.paid: mark the corresponding order paid in your DB. The event payload carries data.invoice.id, data.invoice.amount_usd, data.invoice.payment_tx, and data.invoice.metadata (whatever you stamped at create_invoice time — order_id, sku, etc.).
3. Test it: the MCP exposes simulate_payment(invoice_id) on test-mode invoices. Mint a test invoice, call simulate_payment, and watch a real signed delivery hit your receiver.
Subscribe to invoice.paid as the minimum. Add invoice.expired and invoice.voided only if you need to display those state changes to the buyer or revert a held inventory hold. Don't subscribe to ["*"] — too chatty.
I'm using <FRAMEWORK> on the backend. My app URL is <YOUR_APP_URL>. My Settle test key: <PASTE>.
Replace <PASTE>, <YOUR_APP_URL>, <FRAMEWORK>.
Build a checkout side-card.
The same slide-in panel we use on settle.xxx/store — cart, paid + form, saved-order, all in one card. Self-contained prompt OR fork the public reference at github.com/settle-xxx/cookbook.
Build a storefront with a slide-in checkout side-card in Next.js 15 App Router. The card morphs through THREE states without ever navigating the buyer away from the product page:
1. CART — product image, quantity selector, "Pay with USDC" button
2. PAID — receipt + post-pay collection form (e.g. shipping address)
3. SAVED — confirmation icon + order number + ship-by ETA
Implementation pattern:
- Use Next.js parallel routes + intercepting routes for state #1. App
layout has a {modal} slot. The intercepting route at
app/store/@modal/(.)checkout/[sku]/page.tsx renders the card body
inside the modal slot when the user navigates client-side. The X
button uses closeHref="/store" so back-button + backdrop click +
manual close all work.
- The full-page route at app/store/checkout/[sku]/page.tsx redirects
to /store (it only fires on direct visits / hard refreshes — those
shouldn't see the panel).
- @modal/default.tsx returns null so the slot renders nothing when no
modal is active.
- For state #2 + #3, mount the SAME panel chrome inline on the
storefront page based on URL searchParams. After the hosted checkout
redirects back with ?paid=<inv_id>, the storefront detects it and
renders <CheckoutPanel><PaidOrderContent /></CheckoutPanel> over the
product. Same component as state #1, different body. The route stays
/store; no second intercept.
- After the post-pay form submits, redirect with ?paid=<id>&order=<num>
so the same panel branches into the saved-order view.
Server actions:
- startStorePurchaseQuick(formData): mints an invoice via your payment
provider's API (for Settle: POST tools/call create_invoice to
https://mcp.settle.xxx/mcp), HMAC-signs an inv_<id> cookie binding
the buyer to that invoice, redirect to the hosted checkout URL.
- savePostPayDetails(formData): verifies the signed cookie matches the
form-submitted invoice id (refuses if not — blocks scrape-and-race
attacks where someone POSTs shipping for an invoice they didn't pay).
Idempotent: re-submitting from a stale tab returns the existing
order number instead of creating a duplicate row.
Why intercepting routes instead of React state:
- Back button works (panel is a route, not a boolean)
- Shareable URL (buyer can paste /?paid=inv_xxx and resume)
- Server components in the body (DB lookups at render time, no
loading spinners)
A working reference is at https://github.com/settle-xxx/cookbook/tree/main/cart
— you can clone that and adapt instead of building from scratch.
I'm using Settle for stablecoin checkout. MCP key: <PASTE>. MCP
endpoint: https://mcp.settle.xxx. Use create_invoice for state #1 and
the public /api/invoice/<id> read endpoint for state #2's invoice
lookup. My product is <DESCRIBE-YOUR-PRODUCT>; what I collect post-pay
is <DESCRIBE-YOUR-COLLECTION-STEP-OR-SAY-NONE>.
Stripe’s integration story is a docs site you read top to bottom, a dashboard you click through, and SDK boilerplate you paste from a snippet library. Settle’s is — ideally — one paste. These prompts are how we close the gap between “here’s the MCP” and “your agent built it.”
We treat each prompt the same way Stripe treats its quickstart: a first-class artifact, kept honest, updated when the underlying surface moves. If a prompt no longer reflects what the agent should build, fix it in lib/prompts.ts in the same commit as the underlying change.