Gravity Forms Mollie - WordPress Plugin

Guide to Setting Up Gravity Forms Mollie for WordPress Payment Forms

Gravity Forms Mollie is not just for adding another payment button to a form. Its main job is to connect your Gravity Forms form, payment field, order amount, payer details, and selected Mollie profile so that after submission, the user can move securely to checkout and the administrator can see a clear payment result in both WordPress and the Mollie dashboard.

In this guide, we will walk through the full working flow: what to check before installation, how to connect your Mollie account, how to build a compatible payment form, how to configure the feed, how to test the payment, where to find the payment status, and what to do if payment methods do not appear or the payment gets stuck in an intermediate status.

This guide is for a site owner, webmaster, or developer who already uses Gravity Forms and wants to accept one-time payments through Mollie without building a full online store. We will not repeat the plugin's marketing copy or discuss buying a license. The focus here is practical setup of a product you already have, result verification, and troubleshooting common errors.

What Problem This Form and Payment Provider Setup Solves

Gravity Forms handles the form itself: fields, conditional logic, entries, notifications, and front-end display. Mollie handles the payment layer: available payment methods, transaction processing, the user's return after checkout, and payment statuses. The add-on sits between those two layers and turns a standard form into a payment workflow.

This approach is most useful when you do not need a full product catalog, shopping cart, or complex product logic. For example, if a site sells a single course, charges for a consultation, collects an event fee, accepts a donation with either a fixed or custom amount, registers a user after successful payment, or sells a small bundle of services.

One important detail: the official Gravity Forms documentation describes the Mollie Add-On as a solution for one-time payments. Subscriptions and recurring payments are not a standard use case for this add-on. So if your project is built around memberships, monthly donations, or recurring invoices, this product may not be the best architectural fit.

When a Form Works Better Than a Store

A payment form works well when the user journey is short: choose a service, fill in contact details, pay, and receive confirmation. It does not require product cards, filters, a cart, coupons, inventory tracking, or complex order statuses. That means fewer moving parts and easier testing.

But a form is a poor substitute for a store if you need inventory control, variable products, shipping, regional taxes, customer accounts, repeat orders, discount rules, and catalog analytics. In that case, it makes more sense to look at WooCommerce with a Mollie payment plugin or another full commerce system.

What Gravity Forms Mollie Actually Sends

When configured correctly, the form does not send Mollie a random collection of fields. It sends structured payment data: the amount, selected payment method, name, address, email address, and related billing fields. Gravity Forms documentation specifically notes that Name, Email, and Address are important for creating an Order with Payment, and that most billing fields are required.

In this setup, the feed acts as the transfer rule. If the form contains the fields but the feed has not been created or completed, the data will not be sent to Mollie for processing. That is why this guide treats setup as three connected layers: account settings, a compatible form, and a feed. If any one of those layers is missing, the admin experience often looks like "the plugin does not work," even though the real issue is usually an incomplete connection.

Who Gravity Forms Mollie Is a Good Fit For, and Who Should Choose Another Path

This add-on is a strong fit for sites where Gravity Forms is already the main form system. If your team already has working forms, conditional logic, notification templates, user registration integrations, or an internal intake workflow, the payment add-on lets you keep that process in place instead of moving everything into a separate store.

Gravity Forms Mollie also makes particular sense for a European audience. Mollie supports popular local payment methods including iDEAL, Bancontact, Sofort, and card payments. In practice, that matters for conversion: people are more likely to complete checkout when they can pay with a familiar method instead of hunting for a credit card or creating an account with another payment service.

There are also cases where this solution may be unnecessary. If the site only accepts PayPal, needs a subscription model, requires complex shipping logic, or already runs on WooCommerce, adding payment directly into a form can make support harder. Do not choose the tool just because it "launches faster" - your payment flow should match the actual sales model.

A quick rule of thumb: if the user needs to fill out a form and pay for one clearly defined outcome, Gravity Forms Mollie is usually a good fit. If the user needs to shop, come back later, compare products, and manage orders, a form becomes a workaround.

What to Check Before Installing and Connecting Mollie

Preparation matters more than it may seem. The payment add-on can be installed correctly and still fail validation if the site is not publicly accessible, SSL is missing, the Gravity Forms currency does not match the payment methods available in Mollie, or the required payment method is not activated in your Mollie account.

The official documentation lists Gravity Forms, an active Mollie Add-On, an SSL certificate, a publicly accessible site, and a Mollie account as required prerequisites. This is especially important during testing: a local site or a locked-down staging environment may not receive proper status updates because the payment system needs to return to your site and send the result back.

Technical Site Readiness

• The site loads over https, and the WordPress Address and Site Address values in WordPress do not conflict with HTTPS.
• The payment page is not blocked by basic authentication, maintenance mode, or a firewall rule that blocks external requests.
• Gravity Forms and the official add-on are updated to supported versions, and PHP and WordPress meet Gravity Forms system requirements.
• The payment page is not using aggressive caching, script combining, or deferred loading without exclusions for the form.
• The administrator configuring the add-on has permission to view Forms settings and add-ons. After a site migration, this sometimes breaks because of role-management plugins.

Mollie Account Readiness

In the Mollie dashboard, check your website profile, active payment methods, and currency in advance. The common "missing payment methods" issue is often not caused by a broken add-on, but by the selected Gravity Forms currency not being supported by the active methods in the specific Mollie Profile. If payment methods are enabled but the form still complains about currency, also check the site locale and the selected Website Profile.

Use test mode for your initial setup. In the official Gravity Forms documentation, Test mode is described as the safe path where the entry is sent to the Mollie test environment and no real charge is created. Switch to Live only after you have verified the form, feed, notifications, and statuses.

Connecting Your Mollie Account in the WordPress Admin Panel

After installing the add-on, the main settings screen is located at Forms -> Settings -> Mollie in the WordPress admin area. This is where you choose the operating mode and start the Mollie connection. Do not confuse this screen with the settings for a specific form: first you connect the account and Website Profile, then you create the feed inside the form.

Test and Live - Two Different Operating Modes

During setup, choose Test. That lets you submit the form, see the test payment in the Mollie Dashboard, and verify whether the Gravity Forms entry updates correctly. If you choose Live right away, a user submission may trigger a real payment. That is normal in production, but risky during debugging.

The switching logic is simple: connect the account, select the profile, save the settings, and run a test submission. Once that succeeds, change the mode to Live, save again, and run a small control payment using your internal process if project rules allow it. Do not treat a successful test result as proof that the live flow definitely works - payment methods, account permissions, and webhooks may differ.

OAuth Connection and Website Profile Selection

When you click Connect with Mollie, WordPress redirects the administrator to Mollie, where you need to sign in and grant access. After returning to WordPress, the settings screen should show the connection status and a Website Profile dropdown. If your Mollie account contains multiple organizations or profiles, select the one that matches the current domain and the payment methods you need.

Do not skip saving after selecting the profile. Visually, the connection may look complete as soon as you return from Mollie, but until you click Update Settings, the selected profile and mode may not become the active configuration for your forms.

What Counts as a Successful Connection

The minimum sign of success is that the Forms -> Settings -> Mollie page shows the account as connected, a mode is selected, and a website profile is available. But that alone is not enough to accept payments. The next level of verification is a form with a Mollie field, pricing fields, and a feed that sends the amount and billing fields.

A Compatible Payment Form: Fields, Amount, and Page Order

A compatible Gravity Forms Mollie form is different from a standard inquiry form because it needs a payment structure. According to the documentation, you need a Pricing field, Mollie field, Name, Email, and Address. These are not decorative requirements: the Mollie field handles payment method selection and card entry when applicable, Pricing fields define the amount, and the contact and address fields are used for billing information.

Minimum Required Field Set

• Pricing field. This can be a Product, Option, Quantity, Shipping, or Total field depending on the scenario. The key requirement is that the form has an amount the feed can send to Mollie.
• Mollie field. Added from the Pricing Fields group, it displays payment method choices as well as card fields when a card payment flow is selected.
• Name field. Needed for payer details and later entry identification.
• Email field. Needed for contacting the payer and sending notifications.
• Address field. Important for billing information. The documentation states that nearly all billing fields are required except Address Line Two and State.

Where to Place the Mollie Field in a Multi-Page Form

If your form is split into pages using Page fields, it is best to place the payment field on the last page. The user first enters their details and chooses the service, then sees the total and moves to payment. That order reduces the risk of the payment field being initialized before the user has completed the required steps.

For a long form, it helps to include a brief review before payment: final amount, selected service, email address, and a short note that the user is about to proceed to payment. But do not overload the last screen: the more distracting fields you place next to the payment field, the higher the risk of errors and abandoned submissions.

If the Site Uses Multiple Payment Providers

Gravity Forms supports setups where multiple payment add-ons exist side by side. In that case, do not mix fields and feeds without conditional logic. If the user chooses Mollie, the Mollie feed should run. If the user chooses PayPal or another provider, the matching feed should run instead. On the Gravity Forms forum, similar issues often come down to conditional logic being applied only to field visibility, not to launching the correct feed.

Result check: after saving the form, open the preview and make sure the amount changes as expected, the Mollie field appears only once, and required fields are not hidden by conditional logic at the time of submission.

The Mollie Feed: The Required Setup That Actually Sends the Payment

The feed is the rule that tells Gravity Forms what exactly to send to Mollie after a successful form submission. The documentation explicitly describes feed creation as the final critical step in the integration: without it, the form may collect data but nothing will be sent for payment processing.

If the form includes a Mollie field and no feed has been created yet, Gravity Forms may automatically create a preconfigured feed. But automatic creation does not mean all fields are mapped correctly. The administrator still needs to open Form Settings -> Mollie, review the feed name, amount, billing mapping, conditional logic, and any additional options.

Basic Feed Settings

In the basic settings, give the feed a clear name. Do not call it "Feed 1" if the site has multiple payment scenarios. A meaningful pattern works better, such as "One-Time Consultation Payment," "Webinar Registration Fee," or "EUR Donation." That makes it much easier to understand later which feed belongs to which form.

The Transaction Type for the official Mollie Add-On is Products and Services, which means one-time payments. If you are looking for a subscription field, that is a signal to stop and reconsider the tool. Trying to imitate recurring billing by resubmitting a form usually creates more problems than it solves.

Products & Services Settings

In this section, choose the amount source. For a simple payment, Total is often enough. For a form with multiple product options, you can send a specific Product field or the final total after the user selects options. The core rule is simple: the amount in the feed must match what the user saw before paying.

Whenever you change the pricing logic, repeat your testing. If you add a discount, shipping option, or custom amount, make sure the Gravity Forms entry, the Mollie payment screen, and the final amount in the Mollie dashboard all show the same result. Even a small mismatch undermines trust in the form.

Billing Information

Billing field mapping is one of the most common error zones. Specify which form fields correspond to the payer's name, address, email, and other details. If some required data is hidden by conditional logic or left empty, Mollie may not be able to create an Order with Payment.

Do not try to replace the address with a single text field such as "Comment." Even if your site does not need an address for shipping, the payment provider may still require structured billing information. If the business does not actually need the physical address, explain to the user why the field is required for payment and avoid collecting more data than necessary.

Conditional Logic for Multiple Scenarios

Conditional Logic in the feed is necessary when one form serves multiple routes. For example, a user may choose "Pay now" or "Submit without payment," choose Mollie or another payment provider, or choose between a free and paid ticket. The condition should control not just field visibility, but whether the feed runs at all.

A simple test: submit the form through each route and check which feed ran. If the free option creates a payment attempt, the condition is too broad. If the paid option does not create a payment, the condition is too narrow or the selection field value does not match what the feed expects.

Payment Methods, Currency, and Localization Without Unnecessary Confusion

The most frustrating part of setting up a payment form is when the administrator can see that Mollie is connected, but the user does not get the expected payment method. From the outside, this looks like a plugin error, but the problem is usually at the boundary between three settings: the Gravity Forms currency, the active methods in the Mollie Profile, and the site locale.

Gravity Forms defines the form currency globally. Mollie, in turn, only shows payment methods that are active in the selected profile and compatible with that currency. If the site accepts payments in euros, but the required method is enabled for a different profile or needs additional verification in Mollie, the add-on cannot display it just because the field exists in the form.

How to Choose Payment Methods Without Overloading the Form

You do not have to show every available payment method to the user. A long list can make decisions harder, especially on a simple service or ticket form. Start with the methods your audience actually needs: for example, iDEAL for the Netherlands, Bancontact for Belgium, cards for international customers, and PayPal if it is enabled in your Mollie account.

If the site has multiple language versions, do not try to solve localization only through form text. Check whether Mollie supports the locale used by WordPress. The Gravity Forms documentation explicitly notes that an unsupported locale can cause issues with localized payment screens or customer facing elements. For a multilingual site, that means you need to test not just the main page, but every language version where the form accepts payment.

A Practical Country and Currency Check

Create a small matrix before launch. In the rows, list the countries or language versions. In the columns, list the currency, active Mollie Profile, payment methods, and test result. That is not bureaucracy - it is a way to catch mistakes before users do. This is especially useful for agencies moving a form from staging to a live domain: the test domain may have used one profile, while production needs another.

• For each language version, open the form as a regular visitor, not from the admin panel.
• Check that the amount is displayed in the expected currency and does not change unexpectedly after option selection.
• Make sure the payment methods match the country and are not showing an extra method because of an old snippet.
• Run a test submission and verify the payment in the Mollie Dashboard.

Short takeaway: if payment methods are not visible, do not start by reinstalling the add-on. First check the Gravity Forms currency, active methods in Mollie, the selected Website Profile, the locale, and any filters that alter the method list.

Use Cases: Services, Tickets, Donations, and Post-Payment Registration

One of Gravity Forms' strongest advantages is that the form does not have to behave like a store. You can tailor the fields, conditional logic, and notifications to a specific process. That is especially helpful with Gravity Forms Mollie: payment becomes part of an application, registration, or request flow instead of a separate checkout screen with extra steps.

Paying for a Service with a Pre-Qualification Form

For a consultation or professional service, the form can first collect the client's request: service type, preferred date, site URL, comments, and contact details. The Pricing field defines the package price, and the Mollie field triggers payment. After a successful transaction, the administrator sees not just the amount, but also the context behind the order.

In this scenario, it is especially important not to send operational notifications before payment if the team treats the email as a signal to begin work. Use payment statuses and delayed dependent actions where your add-on stack supports them. If an action cannot wait for successful payment, make sure the notification clearly includes the current payment status.

Paid Event Registration

For an event, the form can include attendee name, organization, ticket type, extra options, agreement to terms, and payment. If you use the User Registration Add-On, the Mollie feed includes a setting that delays user registration until payment is received. That reduces the risk of granting access before payment is complete.

Test the edge case where the user reaches payment, closes the window, and never returns to the site. In payment workflows, it is important to understand that confirmation may depend on webhooks and payment status, not just on the user's return to the thank you page. Do not build critical access logic solely around the fact that the user saw a confirmation screen.

One-Time Donation

For a one-time donation, you can offer several fixed amounts plus an "Other amount" option if the form is configured correctly. In this case, trust and clarity matter: before the user proceeds to payment, they should see the amount, the purpose of the contribution, and a contact address for questions.

If your organization needs recurring donations, the official Gravity Forms Mollie Add-On may not be enough because its standard flow is designed for one-time payments. In that case, it is better to evaluate alternatives with confirmed support for recurring billing.

Practical Example: A Consultation Payment Form Through Mollie

Imagine an agency website that sells a one-time WordPress setup consultation. The goal is for the client to choose a package, enter contact details, describe the task, pay through Mollie, and receive confirmation. The administrator should be able to see the Gravity Forms entry, amount, and payment status.

Goal and Preparation

The goal is to create a form where the user selects one of two consultation packages and pays the final amount. Before starting, we already have active Gravity Forms, an active Gravity Forms Mollie add-on, SSL on the site, a connected Mollie account in Test mode, a selected Website Profile, and at least one active payment method compatible with the form currency.

Setup Steps

1. Create a new form under Forms -> New Form and give it a clear name, for example "Consultation Payment."
2. Add Name, Email, and Address. Make the fields required if they are needed for billing mapping.
3. Add a Product field with package options: basic consultation and extended consultation. If quantity selection is needed, add Quantity.
4. Add Total so the user can see the final amount before payment.
5. Add the Mollie field from Pricing Fields. In a multi-page form, place it on the last page.
6. Save the form and go to Settings -> Mollie inside that form.
7. Open the existing feed or create a new one. For Payment Amount, choose Total, then map the billing fields to Name, Email, and Address.
8. If the form includes a free option, enable Conditional Logic so the feed only runs when the amount is greater than zero or when a paid package is selected.
9. Save the feed using Update Settings and open the form preview.

Verifying the Result

Fill out the form with test data, choose a paid package, and submit it. The user should see the correct Mollie payment flow or payment method selection, and a Gravity Forms entry should appear in the admin panel. After the test payment is completed, verify that the payment status has updated and that the test payment is visible in the Mollie Dashboard.

If the entry is created but the payment status does not change, check public site accessibility, webhook connectivity, Test versus Live mode, caching on the payment page, and whether the selected Mollie profile is correct. If the payment method does not appear in the form at all, check the currency, active payment methods in Mollie, and the site locale.

A Detail That Often Causes Trouble

After making changes to the form, do not stop at a visual review. Submit the form again as a user. The payment field, pricing fields, and feed are interconnected, and even a small field change can break the mapping. For example, an administrator deletes the Address field and adds a new one with a similar label. The form still looks fine in the interface, but the old feed may still reference the deleted field.

How to Check Payment Results and Statuses After Submission

Result verification should happen on two levels: the Gravity Forms entry and the Mollie Dashboard. In WordPress, you check the entry, selected fields, amount, payment status, and related actions. In Mollie, you check whether the payment was created, which method was used, what status it received, and whether there is a refund or webhook event.

For administrators, it is important not to confuse "the form was submitted" with "the payment is complete." A form can create an entry before the payment has a final result. Some statuses at payment providers are temporary, and some updates arrive later. For post-payment automation, it is safer to rely on a confirmed payment status, not just on the fact that the form was submitted.

What to Check in Gravity Forms

• Whether an entry was created after the form submission.
• Whether the entry amount matches what the user saw in the form.
• Whether the payment status updated after the test payment.
• Whether notifications, registrations, or other actions fired only at the correct stage.
• Whether the Gravity Forms logs show any add-on errors, if logging is enabled.

What to Check in the Mollie Dashboard

In the Mollie Dashboard, look for the test payment, amount, payment method, and status. Mollie documents several payment statuses: created, canceled, pending, authorized, expired, failed, and paid. The practical takeaway for a site owner is this: not every user transition into the payment environment means the payment finished successfully, and a temporary status should not be treated as a paid service.

If you issue a refund through Mollie, keep the official Gravity Forms documentation in mind: the entry may update through a webhook, but there are nuances around refunding the same amount more than once and around card payments without 3D Secure. For disputed refunds, always compare the WordPress entry and the Mollie Dashboard instead of relying on only one screen.

Useful Settings and Safe Customization Without Editing Core Files

Most projects should start with the built-in setup: Test or Live mode, Website Profile, form fields, feed, conditional logic, and status verification. Code is only needed when there is a specific requirement supported by the documentation. Gravity Forms Mollie includes official filters, so small customizations can be implemented safely through Code Snippets, a child theme, or a small custom plugin.

Limit the Available Payment Methods

The official documentation describes the gform_mollie_payment_methods filter, which lets you change the list of payment methods. This can be useful if the business wants to temporarily allow only one payment method in a specific country or hide a method that creates too much manual support work.

The example below leaves only bancontact. Before using it, verify that this method is active in Mollie, supports the form currency, and actually fits your audience. Do not place the snippet directly in the Gravity Forms or Mollie Add-On plugin files.

add_filter( 'gform_mollie_payment_methods', 'cfb_limit_mollie_methods', 10, 1 );

function cfb_limit_mollie_methods( $methods ) {
    // Keep only Bancontact. Get the method ID from the Mollie documentation.
    return array_filter( $methods, function( $method ) {
        return isset( $method['id'] ) && $method['id'] === 'bancontact';
    } );
}

After adding the code, clear the cache for the payment page, open the form in incognito mode, and check the list of payment methods. To roll back the change, disable the snippet and test the form again. If all payment methods disappear after the change, first restore the original list, then check the currency, locale, and active methods in Mollie.

Compatibility with Caching and Script Optimization

Gravity Forms specifically warns that caching and automated script optimization can break dynamic forms, AJAX requests, conditional logic, and payment workflows. For the payment page, it is safer to use a conservative setup: do not cache the page with the form, do not combine payment scripts without testing, and do not defer critical form scripts.

If the site uses Cloudflare, a cache plugin, or a theme optimizer, create an exclusion for the page with the payment form. After every change, submit a test form and confirm that the payment field displays correctly, the amount recalculates, the submission does not hang, and the payment status returns to the entry.

How to Use the Official Mollie Video Without Letting It Replace the Documentation

Gravity Forms has a focused video on this topic called "Accept Payments from Around the World with the Gravity Forms Mollie Add-On." It is useful as a visual supplement during setup, especially if you want to see the overall connection flow and payment form concept. But the video should not replace the documentation: the interface may change, and anything important around feeds, currency, billing fields, and statuses is better verified against the current docs.

Use the video as a quick overview of the working flow: where the add-on lives, what the payment form concept looks like, and why Mollie is a good fit for international and European payment methods. Then return to the checklist in this guide and run a test submission on your own site.

When Gravity Forms Mollie Is the Right Choice

Gravity Forms Mollie is worth using when a site already relies on Gravity Forms workflows and needs a straightforward one-time payment flow through Mollie. The strongest use cases are services, one-time donations, tickets, small digital sales, paid applications, and post-payment registration. In those cases, the form gathers the context and Mollie handles the payment without requiring a full store buildout.

Before launch, run through a short final checklist: HTTPS works, the site is publicly accessible, Test mode passes successfully, the currency matches the active payment methods, the feed is mapped to the amount and billing fields, the payment page is excluded from aggressive caching, and the administrator knows where to check both the entry and the status in Mollie.

If the scenario matches the add-on's capabilities after that review, you can download the installation package and test it on a site copy or in a safe test mode. If the project needs subscriptions, a complex shopping cart, or multiple payment architectures, it is better to choose a tool that supports those requirements natively.