Stripe payments in FormNode forms

Add a Payment field when a form should collect a fixed-amount payment before downstream automation runs. FormNode creates a server-side Stripe Checkout Session, redirects the respondent to Stripe, and updates the submission after Stripe sends a signed webhook.

How the flow works

1. A workspace admin connects that workspace's Stripe account in Settings.
2. A form builder adds a Payment field with a fixed amount and currency.
3. The respondent fills out the form and submits it in FormNode.
4. FormNode stores the form submission with payment status checkout_pending.
5. FormNode creates a Stripe Checkout Session using the workspace's encrypted Stripe secret key.
6. The browser redirects to Stripe Checkout so the respondent can pay.
7. Stripe sends a signed webhook to FormNode after payment completes.
8. FormNode verifies the webhook signature and workspace metadata, records the Stripe event for idempotency, marks the submission paid, and then sends the normal form webhook to n8n or the configured endpoint.

What FormNode stores

FormNode stores only operational payment metadata needed to connect a payment back to the correct workspace, form, organization, and submission.

Connect Stripe

1. Open Settings → Integrations.
2. Enter the Stripe publishable key, secret key, and webhook signing secret for the current workspace.
3. Copy the displayed FormNode webhook URL into Stripe as an endpoint.
4. Subscribe the Stripe endpoint to Checkout completion events.
5. Save the connection in FormNode.

Stripe credentials are workspace-scoped. A form in one workspace cannot use another workspace's Stripe connection.

Add a Payment field

1. Open a form in the builder.
2. Add Payment from the Input field group.
3. Set the amount, currency, item name, and Stripe description.
4. Publish the form.

The first version is fixed-amount Checkout. Do not use respondent-entered text or number fields as payment amounts unless a future release adds an explicit server-side pricing model for that use case.

Webhook behavior

Payment-required forms delay fulfillment-style webhooks until payment is confirmed. That means your n8n workflow receives the normal form.submitted payload after Stripe confirms payment, with apayment object that includes provider, status, amount, currency, and Checkout Session ID.

{
  "eventType": "form.submitted",
  "formId": "form_123",
  "organizationId": "org_123",
  "submissionId": "sub_123",
  "payment": {
    "provider": "stripe",
    "status": "paid",
    "checkoutSessionId": "cs_live_...",
    "amountCents": 5000,
    "currency": "usd"
  },
  "data": {
    "customer_name": "Acme Co"
  }
}

Security model

• Stripe secret keys and webhook secrets are encrypted at rest.
• Checkout Sessions are created server-side, never from browser-supplied Stripe credentials.
• Payment metadata includes workspace, form, organization, and submission IDs.
• Stripe webhooks must pass signature verification before FormNode trusts the event.
• Stripe event IDs are recorded so retries do not duplicate downstream fulfillment webhooks.
• FormNode revalidates that the submitted Stripe metadata matches a submission inside the same workspace before updating payment status.
• Hidden or conditionally hidden Payment fields do not create Checkout Sessions.

Operational implications

• Refunds, disputes, failed payments, tax settings, receipts, and Stripe account reviews are handled in Stripe.
• FormNode records payment status for workflow and support visibility, but Stripe remains the payment source of truth.
• Use Stripe test keys and a test webhook endpoint before enabling payment forms for real customers.
• Keep webhook endpoints configured for the same FormNode environment that creates the Checkout Session.
• Use a clear item name and description so respondents understand what they are paying for on Stripe Checkout.

Related docs

• Form builder & field types
• Webhook payload
• n8n webhook forms
• Team, API keys & billing