Payment

Use Payment when the form should collect or authorize a payment

Use Payment when the form itself is responsible for taking payment. If the project already has a full checkout flow, it may be better to keep payment there and link the form to that process.

Take a Test Payment

Start with a form containing a Payment field and connect a provider using its setup page below. Configure the amount and currency, then use the provider’s test environment to complete the form. Inspect both the saved submission and the provider’s transaction before using live credentials. Also test a declined or cancelled payment; the confirmation shown to the visitor must match the actual payment outcome.

For a multi-page form, place every enabled Payment field on the final page shown to the visitor. Payment runs when the form is completed. A visible Payment field on an earlier page prevents completion, so test each path when page or field conditions change what visitors see.

Key Settings

• Payment integration - Choose the provider used by this field.
• Amount and currency - Configure the amount to charge or authorize.
• Billing details - Map form fields into the payment provider’s expected customer or billing data.
• Provider behavior - Configure provider-specific settings such as hosted UI, tokenization or redirects.
• Submission behavior - Account for any Ajax or workflow requirements surfaced by the provider.

Submitted Value

Payment stores payment-related submission data rather than normal text input. The exact value and records depend on the configured provider and whether the payment is authorized, captured, redirected or reconciled later.

When querying or saving submissions through GraphQL, payment behaviour depends on the provider and submission workflow. Query the form’s formFields and include inputTypeName when building a custom front end.

Payment Providers

Payment providers are configured in two places:

1. Create and configure a payment integration in Formie → Settings → Payments.
2. Edit the Payment field, then choose the provider for Payment Integration.

Provider setup is documented on the payment integration pages:

• BPOINT
• eWAY
• GoCardless
• Mollie
• Moneris
• Opayo
• Paddle
• PayPal
• PayWay
• Square
• Stripe

Payment behaviour depends on the selected provider. Some providers use hosted payment UI, some tokenize card details in the browser, and some complete payment through redirects or webhook updates. If you are building a custom provider, see Payment Integration.

Theme Config

The Payment field can be targeted with the payment theme config key.

{{ craft.formie.renderForm('contactForm', {
    themeConfig: {
        payment: {
            field: {
                attributes: {
                    class: 'my-payment-field',
                },
            },
            stripePlaceholder: {
                attributes: {
                    class: 'my-stripe-placeholder',
                },
            },
        },
    },
}) }}

Use theme config for surrounding markup and attributes. Be careful with template overrides because payment providers may require specific elements or scripts.

For full Tailwind, Bootstrap and other framework examples, see Formie theme configs (opens new window).

Front-End Reference

Payment fields often depend on provider JavaScript, Ajax submission, redirects or webhook reconciliation. If you customise rendering, keep the provider’s required front-end assets and submission flow intact.

• Payment (opens new window)

Related Fields

• Use Products or Variants when the form should select Commerce elements.
• Use Calculations when the payment amount is derived from other field values.

Recover Unresolved Payments

If a visitor sees an unresolved payment after a timeout, check the gateway before asking them to pay again. Your developer can use the payment recovery commands to inspect the saved attempt, verify its outcome and resume a successful submission.