Collect payments right on a form using a Product field, a price field, or a calculated total, then charge the visitor through a connected processor — Stripe, PayPal, Square or Razorpay. Checkout completes on the provider’s secure page, so raw card data never touches your site, and the outcome is written straight back onto the submission.
Where: per-form setup lives in the Form Builder under Settings → Payment. Provider keys are entered once under Tiger Forms → Settings → Payments.
Supported providers
Four gateways ship built in, each with its own credential set:
- Stripe — publishable key, secret key and webhook signing secret.
- PayPal — client ID, client secret and webhook ID.
- Square — access token and location, with its own application credentials.
- Razorpay — key ID, key secret and webhook secret.
Every provider stores separate Sandbox and Live credential pairs behind a single mode switch, so you can keep test and production keys side by side and flip between them without re-typing anything. Secret keys are encrypted at rest and are only ever decrypted server-side to authenticate against the gateway.
Connect a provider
- Open Tiger Forms → Settings → Payments and pick the provider.
- Set the mode to Sandbox and paste in your test keys.
- Use Test connection — a read-only ping that confirms the keys authenticate before you rely on them.
- Save. The same keys are now available to every form on the site.
Take a payment — step by step
- In the Form Builder, add the field that produces the charge: a Product field (fixed price, quantity or selectable options), a dedicated price field, or a Calculation field that outputs the total.
- Open Settings → Payment and enable it.
- Choose the amount source — a fixed amount, or a field / calculation / product reference so the total follows what the visitor enters.
- Set the currency (any valid three-letter ISO-4217 code; defaults to USD) and a description shown at checkout.
- Publish. Submitting the form now opens the provider’s checkout, and the returning result is recorded on the entry.
Amounts are resolved and validated server-side in cents, so a visitor cannot tamper with the price in the browser.
Testing and going live
Always run a real submission in Sandbox first using the provider’s published test card, confirm the entry shows paid with the gateway reference attached, then switch the provider’s mode to Live. Payment forms should be served over HTTPS, and each provider’s webhook should point at your site so asynchronous confirmations (and refunds) update the entry reliably.
Reading the result
Open the submission under Tiger Forms → Submissions. The detail view shows the paid / failed status, the amount and currency charged, and the provider’s transaction reference, so the entry is the single record of both the lead and its payment.
Troubleshooting
Checkout opens but the entry never shows paid.
The confirmation arrives by webhook. Make sure the provider’s webhook endpoint and signing secret are configured for the same mode you are testing in — a Live webhook secret will not verify a Sandbox event, and vice versa.
“Test connection” fails.
The keys are for the wrong environment, or a stray space was pasted in. Re-copy the key for the currently selected mode and test again — the button reports the gateway’s own error so you can see exactly what was rejected.
The charged amount is wrong.
Check the amount source. In field or calculation mode the total is read from that field’s server-side value, so make sure the referenced Field ID is correct and produces a positive number.