A consultant finishes a strategy session, opens Stripe to send a €750 payment link, and hits a wall: Stripe wants a product first. Name, image, description, price — and only *then* a link. The whole point was to skip the bookkeeping. So the consultant creates a fake product called "Consulting" with a placeholder image, generates the link, and now the Stripe dashboard has 47 single-use products with names like "May invoice client X." This is the most common Stripe payment-link complaint we hear.
Stripe Payment Links were built around fixed-price catalogues — a SaaS plan, a course, a physical SKU. That model breaks the moment you sell anything custom: consulting hours, agency retainers, deposits, donations, variable-amount invoices. The good news is there *are* product-free options inside Stripe. The bad news is they come with limits — a hard cap, no recurring billing, single line items only, and a dashboard that fills up fast.
This guide covers every way to create a Stripe payment link without a product, when each one works, where each one breaks, and the upgrade path once your invoicing volume outgrows them. It pairs with our free payment-link guide — same problem, different angle.
Key Takeaways
- Stripe does let you create a payment link without a product, but only via the "Customers choose what to pay" option (Dashboard) or inline `price_data` (API)
- The Dashboard option caps payments at $10,000 by default, supports a single line item only, and doesn't support recurring billing
- The API approach is more flexible but requires writing code — not realistic for non-technical users
- Both Stripe options still create a hidden product behind the scenes — your dashboard fills with one-off entries
- PayRequest skips products entirely: enter an amount, click create, send. No fake SKUs, no $10K cap, no API needed
- The same product-free PayRequest link accepts cards (via Stripe), iDEAL, Bancontact, SEPA, and PayPal on one checkout — without spinning up a product per provider
Can You Create a Stripe Payment Link Without a Product?
Yes — Stripe offers two product-free workflows: the "Customers choose what to pay" option in the Dashboard, and inline `price_data` through the API. Both let you generate a checkout link without pre-creating a Stripe Product. Both come with constraints — a $10,000 default cap, a single line item, and no recurring billing — that make them unsuitable for most invoicing or subscription use cases beyond donations and tips.
For full control over amounts, currencies, payment methods, and recurring billing without products, a hosted payment-link platform on top of Stripe is usually the faster route. We'll get to that. First, the two native Stripe options.
Method 1: Stripe's "Customers Choose What to Pay" (Dashboard)
This is Stripe's official workaround for product-free payment links. It's built into the Dashboard, takes about 60 seconds, and doesn't require code. The trade-off is that it's designed for donations, tips, and pay-what-you-want flows — not for invoicing.
The flow is straightforward in the Stripe Dashboard:
- Open Payment Links in the Stripe Dashboard
- Click + New (or the plus icon → Payment link)
- Under "Select a product or service," pick "Customers choose what to pay"
- Add a title, description, and optional image — this is what the customer sees on the checkout page
- Optionally set a minimum and maximum amount (defaults to a $10,000 USD ceiling)
- Choose your currency and accepted payment methods
- Click Create link — copy the URL and share it
The customer lands on a Stripe-hosted checkout page, types in any amount within your range, and pays. No product was created in your Stripe Products list.
The "Customers choose what to pay" option is genuinely useful for a narrow set of cases. It shines when the amount is truly the customer's choice — a tip jar, a "buy me a coffee" page, a charity donation form, a freelancer's pay-what-you-can rate. It's also fine for one-off custom quotes if your client is the one entering the agreed amount.
For these use cases the workflow is faster than building a product, and the Stripe checkout page handles the heavy lifting (PCI compliance, card validation, receipt emails). For donations and tips specifically, this is probably the cleanest option Stripe offers.
The limits show up the moment you try to use this for actual B2B invoicing. The $10,000 USD default cap blocks anything bigger — agency retainers, enterprise deposits, real-estate commissions, custom-build projects. You can request a higher cap from Stripe support, but it's not automatic and not guaranteed.
The bigger issue is the single-line-item restriction. With "Customers choose what to pay" selected, you cannot add other line items, taxes, fees, or shipping on the same link. Quantity is locked to 1. So a payment link that's "session fee + travel reimbursement + VAT" can't be built this way. You'd have to either bundle everything into a single amount the customer types in (no breakdown on the receipt) or fall back to creating a product.
And recurring billing is not supported — this option only handles one-time payments. If you need a subscription, you're back to the standard product-based flow.
Method 2: Stripe API with Inline `price_data`
For developers, the API gives you a cleaner escape hatch. Instead of pre-creating a product in your Stripe dashboard, you pass the product details inline when creating the payment link. Stripe creates the product behind the scenes, but you don't see it cluttering your Products list (technically it's still there — it's just generated automatically).
When you call the Payment Links API, you can use `line_items[].price_data` to define everything in one shot:
``` POST /v1/payment_links line_items[0][price_data][currency]=eur line_items[0][price_data][unit_amount]=75000 line_items[0][price_data][product_data][name]=May Consulting Retainer line_items[0][quantity]=1 ```
That single API call creates a one-off payment link for €750 with a custom product name. No need to build the product first via the Products API. You can repeat the call with different amounts and names per invoice, and each generates its own link.
This is the right answer for technical teams that already have Stripe deeply integrated and want to programmatically generate links from their own billing UI — say, an internal admin tool that sends a payment link the moment a quote is approved. It's also the route taken by most no-code automation platforms (Zapier, Make.com) that "create Stripe payment link" actions internally.
The flexibility is significantly better than the Dashboard option: you can include multiple line items, taxes, shipping, and recurring prices. Effectively any Stripe Checkout feature is available.
The API requires code. For an agency owner, a freelancer, or a hosting reseller — most of the people Googling "Stripe payment link without product" — writing API calls isn't a practical answer. Even with Postman or Zapier, the setup eats more time than just creating a fake product in the dashboard. And every API-generated link still produces an underlying Stripe Product object behind the scenes, so the database fills up either way.
This is the gap a hosted payment-link platform fills: the API flexibility without the API.
Why Stripe Forces Products in the First Place
Understanding *why* Stripe is product-centric helps frame what's missing. Stripe's Payment Links product was built around the assumption that businesses sell a relatively small number of fixed-price items repeatedly — a SaaS subscription, a digital course, an e-commerce SKU. The product object is meant to be the canonical record: it powers analytics ("how much revenue did Product X generate this quarter?"), it ties into Stripe Tax, and it's the building block for subscriptions and Connect.
That model fits SaaS and DTC e-commerce really well. It fits service businesses, agencies, consultants, and anyone billing a custom amount per invoice poorly. For those workflows, the "product" is just a bookkeeping artefact — a workaround for Stripe's data model. That mismatch is why "create Stripe payment link without product" is a high-volume search query year after year.
A Faster Path: PayRequest Payment Links Without Products
PayRequest treats every payment as amount-first. There is no product object in the workflow at all. You log in, click "New payment link," type the amount and a short description (e.g., "May retainer — Acme Corp"), and the link is ready in about 8 seconds. No SKU, no fake product, no $10,000 cap to navigate, no API call.
The flow is the same regardless of whether you're billing €50 or €50,000:
- Connect Stripe (and/or Mollie, and/or PayPal) to PayRequest via OAuth — about 3 minutes, no API keys
- In PayRequest, click New payment link and type the amount, currency, and a description
- Optionally attach a customer (so the link is tracked against their record) or leave it generic
- Send the link via email, SMS, WhatsApp, or copy/paste — it's just a URL
- The customer lands on a hosted checkout page that shows cards (powered by Stripe), iDEAL, Bancontact, SEPA, and PayPal on one screen
- Once paid, the funds settle in your Stripe (or Mollie / PayPal) account exactly as if the customer paid Stripe directly
PayRequest takes 0% of the transaction. You only pay your provider's standard processing fee — Stripe's normal 1.5% + €0.25 in the EU, or whatever rate applies in your region.
This is the bigger unlock. With Stripe alone, every payment method that isn't a card needs its own setup — and if you also want PayPal or iDEAL specifically, you typically need separate links. With PayRequest, a single product-free link offers all the methods on one checkout. The customer picks the one they want; the funds route to the matching provider account automatically.
That changes conversion meaningfully: a Dutch customer sees iDEAL, a Belgian customer sees Bancontact, a German customer sees SEPA, an American customer sees cards or Apple Pay. No "please use Stripe instead" emails when a client wants to pay via PayPal. See the full breakdown in the Stripe vs PayPal vs Mollie comparison.
Because there's no product object holding the link together, PayRequest can attach metadata directly to each link — customer, channel sent through, opened/clicked status, payment timestamps. That powers the automatic dunning system: an unpaid link gets a reminder at 2, 5, and 14 days without you lifting a finger. Stripe alone doesn't track payment-link reminders this way; you'd build it yourself or chase manually.
Stripe vs PayRequest for Product-Free Payment Links
A side-by-side of the two product-free Stripe options against PayRequest:
| Feature | Stripe Dashboard | Stripe API | PayRequest |
|---|---|---|---|
| Product required | No (uses "Customers choose what to pay") | No (inline price_data) | No — amount-first by design |
| Setup time per link | ~60 seconds | API call | ~8 seconds |
| Code required | No | Yes | No |
| Maximum amount | $10K default cap | None (provider limits apply) | None (provider limits apply) |
| Multiple line items | No | Yes | Yes |
| Recurring billing | No | Yes | Yes |
| Multi-method (Stripe + PayPal + iDEAL on one link) | No | Build yourself | Yes, native |
| Tracking per link | Basic | Build yourself | Yes, native |
| Automatic reminders | No | Build yourself | Yes, native |
| Customer portal | No | Build yourself | Yes, native |
Stripe alone is a great answer when the constraint is "I just need one tip jar." PayRequest is the better answer when the constraint is "I send 5+ payment links a week and don't want to manage a fake-product graveyard."
Real-World Use Cases for Product-Free Payment Links
The use cases that don't fit Stripe's product model are exactly the ones where this whole question comes up. A few patterns we see weekly:
A strategy consultant invoices €1,500 for a half-day workshop. The amount is unique to that engagement; there's no reusable product. With Stripe, you'd either create "Workshop — Acme" as a one-time product (cluttering your dashboard) or use "Customers choose what to pay" (and trust the client to type the right number). PayRequest handles this in one screen with the exact amount pre-filled. See more on the payment links for freelancers guide.
An agency bills €4,200 in May, €3,800 in June, €5,100 in July. Same client, different amounts each month. Stripe's recurring billing fits a *fixed* monthly amount; variable retainers don't fit cleanly. A product-free payment link per month is the natural pattern — and PayRequest's tracked, reminder-enabled links eliminate the manual chase.
Rental deposits, event pre-payments, holding fees on a custom build — all amount-driven, customer-specific, and not really "products." Stripe payment links don't natively handle authorisation holds (where you reserve a card without charging it); for that, see our security deposit guide. PayRequest does handle holds via Mollie integration.
This is the one case where Stripe's "Customers choose what to pay" works really well. Use it. If your needs grow into recurring donations or supporter tiers, then a memberships platform becomes the better answer.
Anything where the price varies per customer or per project — translation work billed per word, freight quotes, custom orders, photography packages priced per session length — fits product-free links naturally. The product model just adds friction.
Frequently Asked Questions
The questions below come from real PayRequest support tickets and "People Also Ask" search data on Stripe payment-link topics.
Skip the Fake Products
Stripe's "Customers choose what to pay" option is a real workaround for donations and tips, and the API handles flexible cases for technical teams. For everyone else — agencies, consultants, hosts, anyone sending custom-amount invoices regularly — the product-free PayRequest workflow is faster, cheaper than building it yourself, and adds the customer portal, automatic reminders, and multi-method checkout that Stripe alone doesn't ship.
Try it free at PayRequest — connect Stripe (or Mollie or PayPal) in 3 minutes and send your first product-free payment link before lunch. For the broader payment-link comparison, see our complete payment-links guide.
