Google Forms payments: what works and what it costs

No. Google's own list of Forms question types covers short answer, paragraph, choices, dropdown, file upload, scales, ratings, grids, date and time. There is nothing that takes a card, and nothing in Settings connects Forms to Stripe, PayPal or Google Pay. Workspace plans change storage and admin controls, not the question list.

So every "Google Forms payment" setup is really two systems: the form records the order, and a payment processor takes the money on a separate page. The questions worth asking are how the respondent gets from one to the other, how you match the two records afterwards, and what each hop costs.

There are four in common use. They differ in setup time, in who takes a cut, and in how much reconciliation they leave you with.

Create a Stripe Payment Link (or a PayPal payment link) for a fixed price, then paste the URL into the form's confirmation message and into the description of the last section. The respondent submits, sees the message, clicks, and pays on Stripe's or PayPal's page. Setup takes about ten minutes, and you pay only the processor's normal fees.

The weakness is that the confirmation message is the same static text for everyone. It cannot show a total based on answers, and paying is optional: the response is already saved before the respondent decides whether to click.

Add-ons attach a payment step to the form and write paid or unpaid status back to your responses. The two we checked take different pricing routes. Payable Forms (Payable Apps) connects Stripe, PayPal, Square and others and charges per transaction instead of a subscription: a flat $0.49 on payments from $5 to $50 and 1% on payments over $50, on top of processor fees. PayQ (by PCI Vault) has a free plan and paid plans at $9.99/month (Individual) or $16.99/month (Enterprise), and its Marketplace listing shows 19,000+ installs.

Before installing any add-on, read the permissions screen. A payment add-on needs to read your form and its responses to do its job, which means a third party sees your respondents' data. That is fine for a bake sale and worth a conversation with whoever owns data protection if you run a clinic or a school.

Google Forms supports an installable "on form submit" trigger in Apps Script. A short script can read the answers, work out the amount, create a Stripe Checkout Session for exactly that amount, and email the respondent a payment link. It is free apart from Stripe's fees and it solves the variable-price problem. The trade-off is maintenance: you own the code, the API key and the failure cases. A copyable version is further down this page.

For a club subscription or a school trip with twenty families, putting bank transfer details or a payment QR code in the last section and ticking payments off weekly is often the fastest thing that works. It stops scaling once you have more than one price or more than a few dozen orders, because every match is done by eye.

On a domestic card payment, Stripe is cheaper: $3.20 against $3.98 when the buyer checks out with a PayPal account. The gap grows with the fixed fee on small orders. On a $10 order, Stripe keeps $0.59 and PayPal Checkout keeps $0.84.

PayPal still earns its place. Some buyers will only pay with a PayPal balance, and for them a PayPal link converts better than a card form. If your audience is mixed, offer both links in the final section and let people pick. For international buyers, both add a surcharge (Stripe 1.5%, PayPal 1.50%), and currency conversion costs extra on both.

Add-ons change the maths more than the processor choice does. A 1% per-payment fee costs nothing noticeable at $20 but $10 on a $1,000 invoice, and a $9.99 subscription is expensive if you take five payments a month and cheap if you take five hundred.

Three things, whichever method you pick.

Payment cannot be a condition of submitting. Forms saves the response the moment the respondent presses Submit. Every method above asks for money afterwards, so you will always collect some orders that never get paid, and you cannot tell a buyer who plans to pay tomorrow from one who changed their mind.

The order and the payment are two records. Even with add-ons that write status back to the sheet, refunds, partial payments and duplicate submissions still need a human to look at both systems. A shared reference (email address, response ID or client_reference_id) makes this bearable; nothing makes it disappear.

Forms cannot calculate. It has no arithmetic on answers, so a total that depends on quantity, size or add-ons must be computed somewhere else: by an add-on, by your script, or by a separate link for every combination. That is where most homegrown setups start charging the wrong amount.

Zunoform has a payment question type, so the charge happens inside the form, before submission. It uses your own Stripe or PayPal keys, Zunoform takes 0% of each payment, and your processor's normal fees still apply. The amount can come from earlier answers (a price mapped to each option of a choice or dropdown question, plus an optional base fee, tax and discount), and it is recomputed on the server so a respondent cannot edit the price. A form with a required payment field is rejected at submission unless a verified payment is attached, which removes the unpaid-order problem above. Currencies are USD, EUR, GBP and INR.

The limits: publishing a payment field needs the Pro plan ($14.99/month or $149.99/year); on Free you can build and preview it but not publish. Free also caps you at 500 responses a month, while Google Forms has no response cap. If you take a handful of fixed-price payments a month, a Stripe Payment Link in a free Google Form is cheaper and perfectly adequate. Zunoform earns its fee when prices vary by answer, when unpaid orders cost you real time, or when you want the order and the payment in one record.