Payment request form

A payment request form tells a customer or a colleague what they owe and gives them one place to say how they intend to pay. The amount stays a number field so there is no ambiguity, payment method is a dropdown so you know what to expect, and the invoice reference stays visible so reconciliation is automatic. Use it for client invoices, reimbursement requests or internal billing.

The form beside this text is live. Fill it in and submit it — it validates exactly as it would for a real respondent, and saves nothing.

Amount fields validate before they submit

Amount is a number field, not free text, so "fifty dollars" or a blank value never reaches your records. Validation runs in the browser before the request is sent.

Send each request onward as it arrives

Point the form at a webhook and every request is delivered to your own system the moment it is placed, in addition to being stored in your dashboard. Every request is also in the CSV export, regardless.

No card required.

Payment Request

Live preview

How to build this form

5 steps in the editor. Nothing here needs a paid plan.

  1. Add text and email fields for the payer, so you know who this request is for.
  2. Add a number field for the amount owed, so the value is always numeric.
  3. Add a text field for the invoice or reference number, so a later payment can be matched back to this request.
  4. Add a select for payment method — bank transfer, check, other — so the payer states how they will pay.
  5. In Settings, add a webhook, Slack or Discord destination so each request reaches your system as it is placed.

Fields in this form

6 fields, using 5 of the 19 field types available.

QuestionField typeRequired
Payer nameShort textYes
EmailEmailYes
Amount owedNumberYes
Invoice or reference numberShort textYes
Preferred payment methodSelectYes
NotesLong textOptional

What goes wrong with this form

Specific to a payment request form, not general advice about forms.

Leaving the amount as free text

Use a number field. It is validated in the browser, so "fifty", "50 dollars" and a blank never reach your records — free text produces disputes over whether 50 meant dollars or was simply forgotten.

Not including a reference number

Without an invoice or reference field, matching a form submission to your own accounting record becomes guesswork. One short text field for the reference makes reconciliation automatic instead.

Assuming everyone pays the same way

Offering only one payment method in the form loses requests from people who prefer another. A select listing the methods you actually accept avoids that friction entirely.

Questions about this form

How do I collect a payment request through a form?

Ask for the amount as a number field, an invoice or reference number, and the payer's preferred method — bank transfer, check or other. You then process the actual payment yourself using the method they chose; the form only collects the request.

Can this form charge a card directly?

No. This collects the payment request — amount, invoice reference and preferred method — and hands it to you to invoice or collect manually. If you need to charge a card at the point of request, a dedicated checkout or payment processor is the right tool; this form is for requesting and tracking the payment itself.

How do I match an incoming payment to the right request?

Include an invoice or reference number field on the form and reuse the same reference in your own accounting record. Every request also carries a submission timestamp, which the CSV export preserves for reconciliation.