How to build a Stripe payment form without writing code

Stripe itself offers three ways to take a payment on the web, and only one of them is truly no-code.

A Payment Link is a Stripe-hosted checkout page you create in the Dashboard in a few minutes. It can sell a product or a subscription, accept a donation where the customer chooses the amount, let customers adjust the quantity, apply promotion codes, collect billing and shipping addresses, phone numbers and a terms-of-service checkbox, and stop accepting payments after a set number of purchases. You can share it as a URL or a QR code, or embed it as a buy button.

The form part is thin. Stripe's API reference says up to three custom fields are supported, and the types are text (up to 255 characters), numbers only, or a dropdown (up to 10 options when created in the Dashboard). Stripe also warns against using custom fields for personal, protected or sensitive data. There is no conditional logic, no file upload, and the price can't change based on a custom field.

Checkout is the same prebuilt payment UI, driven by the Checkout Sessions API: a full page (hosted by Stripe or embedded), an embedded form, or Elements for a fully custom layout. It can do anything a Payment Link does and more, such as computing the line items from your own data. The catch is that your server creates each session, so someone has to write and maintain that code. If you are reading a no-code guide, Checkout is what your developer would use, not you.

Form builders put a payment step inside an ordinary form. You connect your Stripe account (or paste its API keys), add a payment field, and the builder charges the card when the respondent submits. Everything the form can do, such as branching, file uploads, signatures, scheduling and integrations, sits around the payment, and the response and the charge are stored together. The trade-offs are the builder's own plan price and limits, and a checkout that is less polished than Stripe's own page.

The same as any other Stripe payment, because the form builder is just the page that creates the charge. On Stripe's standard US pricing, a domestic card costs 2.9% + 30 cents per successful charge, cards issued outside the US add 1.5%, and currency conversion adds 1%. There are no setup or monthly fees on the standard plan. Recurring billing through Stripe Billing adds 0.7% of billing volume.

Worked example (illustration): a $100 workshop ticket paid with a US card costs $3.20 in Stripe fees, so you receive $96.80. The same ticket paid with a card issued in the UK costs $4.70, or $5.70 if conversion is needed. A builder that took a 5% platform fee would add another $5 on each ticket, which is why the platform-fee column matters more than the plan price once volume grows.

Stripe's rates differ by country; check the pricing page for your Stripe account's country before you quote a number to a client.

Use a form when the payment depends on information you collect first. Three situations come up again and again.

The price depends on the answers. An event with ticket tiers, an optional lunch and a discounted student rate is one form with a computed total, not four Payment Links. The same goes for quote-to-pay services, class bookings with add-ons, and product orders with options.

You need more than three pieces of data. Registrations need names, dietary needs, emergency contacts, consent checkboxes and sometimes a signature or a document upload. Payment Links can't hold that, and splitting it across a form and a separate link means matching two records by hand.

Some people shouldn't pay at all. Conditional logic can skip the payment for members, sponsors or anyone who chose "invoice my company", which a Payment Link can't do.

A form that calculates the total in the browser and sends that number to Stripe can be tricked: anyone who edits the page can submit a $1 total for a $400 order. It is worth asking any builder where the amount is computed.

In Zunoform the payment amount is recomputed on the server from the answers actually submitted, including option prices, logic rules, discount and tax. If the amount paid doesn't match what those answers should cost, or the payment can't be verified with Stripe or PayPal, the response is rejected rather than stored. That also catches the respondent who pays for the cheap option and then switches to the expensive one before submitting.

Zunoform suits one-time payments where the price depends on the answers: orders, registrations, bookings, deposits. It connects to your own Stripe or PayPal account with your keys, charges 0% on top, recomputes the amount server-side, and keeps the response and the payment together. The payment field needs Pro ($14.99/mo, 5,000 responses a month); you can build and preview it on Free.

It is the wrong tool for subscriptions or recurring donations, which it doesn't support; use a Payment Link, Typeform or Fillout for those. It only charges in USD, EUR, GBP or INR. And if you want payments on a free plan, Tally and Fillout offer that, and Jotform does for up to 10 payments a month.