Payments

A form can charge for what it collects. The price is computed by the form's own rules on the server — never sent by the page — and the money moves through Stripe into your own connected account.

How a price is decided

You do not put an amount in a payment request. A rule on the form carries an amount expression, and the server prices the submitted answers by running the engine over them. When the payment is finally created the amount is derived again and a mismatch is refused.

The request body has no field an amount could even ride in. That is the mechanism behind the guarantee: a modified page, a replayed request or a hand-built API call cannot buy a thousand-pound service for a penny, because the price was never the caller's to state.

Asking for payment later

Not every payment happens at submission. A workflow transition can carry a Request a payment action: it prices the form's existing payment rule at the moment of the move, freezes that figure, and emails the payer a checkout link through a notification template you name — the deposit asked for when a quote is approved, rather than before anyone has agreed to it.

Both the price and the audience are settled at the moment of asking. The amount and the resolved recipient addresses are stored on the payment row as the transition found them, so editing the submission afterwards cannot change what the link asks for, or who it was addressed to.

The link itself is minted a moment later by the same kind of queue everything else here uses, because the mail's entire content is the URL and a URL cannot be templated before it exists. That is why a payment-request email carries only payment_link, payment_amount and payment_currency — see notifications. Checkout links expire after a day by default.

Publishing checks the wiring, as everywhere: a transition that requests a payment on a form with no rule to price it, or names no template, or names one that does not exist, or names nobody to send it to, is refused with that exact reason.

Completion arrives exactly as it does for a payment taken at submission — from Stripe's signed confirmation — and records the same values. A later transition can gate on payment having succeeded without knowing which of the two ways it was collected.

Connecting an account

Payments go into your Stripe account, connected under Settings → Payments. Faldaro never holds your money and no Faldaro API response ever carries a Stripe secret — the publishable key is the only Stripe credential that reaches a browser.

Recipient accounts resolve in the organization that owns the form. This is the deliberate inverse of how integrations resolve: a notification belongs to whoever submits, but the payment belongs to whoever authored the price. A partner submitting against a form you shared with them pays you.

Splits

A payment can be divided between several connected accounts. The split is frozen in whole cents at the moment the payment is created, using largest-remainder rounding so the parts sum to the total exactly. Editing the split configuration later cannot change what an already-charged payment pays out.

Payouts to recipients are queued by Stripe's own confirmation that the charge succeeded — never by the browser returning from checkout. The system this replaced paid recipients from a success callback, which meant a closed tab was a missed payout.

What the submission records

Completion lands on the submission as computed values, so the rest of the platform can act on it without knowing anything about Stripe. The most useful consequence: a workflow transition can require that payment succeeded before a record may move —

`payment_status` = "succeeded"

…and digital delivery uses the same fact to decide whether files are released.

Refunds

Refunds are full-amount and operator-initiated, from the payment record in the app. Running a refund twice is safe: the second attempt lands on Stripe's idempotency cache rather than refunding twice, so a double-click costs nothing.

With a split, the recipients' share comes back first: every split transfer already sent is reversed, each recorded as it lands, and only then is the payer refunded. If a reversal fails — usually because the recipient has already paid that money out of their Stripe account — the refund is refused and the payer is not refunded yet. Refund again once the recipient's balance covers it (transfers already reversed are not repeated), or ask the platform operator to refund the payer from the Stripe dashboard.

Split transfers that had not gone out yet are cancelled with the refund, so a refunded payment is never paid out afterwards.

A refund issued from the Stripe dashboard instead reverses nothing: Stripe does not know about your splits. Faldaro records that fact on the payment — how many sent transfers were left unreversed — and only that fact; running refund from Faldaro afterwards reverses them. Refund from Faldaro when splits are involved.

Payments on public forms

An anonymous submitter can pay: the amount is still priced server-side from their answers, and delivery of anything sold is gated on settlement rather than on the browser reaching a success page. See public forms and digital products.

What is not supported

• Partial refunds — refunds are full-amount only.
• Subscriptions or recurring charges on a form. (Your own Faldaro subscription is separate: see billing.)
• Payment methods Stripe does not offer in your account's country.