iDeal for RSForm! Pro - Joomla Extension

Setup Guide for iDeal for RSForm! Pro in Joomla Payment Forms

iDeal for RSForm! Pro is not meant for a basic contact form. It is designed for forms where a visitor selects a service, product, fee, or donation, sees the calculated amount, and then proceeds to pay through a connected payment service. In this guide, we will walk through the practical setup path: preparing the site, installing the extension, configuring gateways, adding payment fields to RSForm! Pro, validating the result, troubleshooting errors, and evaluating similar alternatives.

The main challenge with this type of extension is that payment depends on several layers working together: the core RSForm! Pro component, Payment Package, the iDEAL | Wero system plugin, Mollie, Sisow, or Buckaroo settings, the form fields themselves, and the way the site behaves after submission. If even one layer is missing, the form may look correct, but the payment will never reach the handler, or the user will not see the expected payment method.

This guide is written as a practical working reference for a Joomla site administrator. It does not cover buying, licensing workarounds, or anything similar. It assumes you already have a legitimate installation package, access to the site admin panel, and the credentials for the payment provider you plan to use. All sensitive keys stay with you and are not shared with third-party tools.

What problem this extension solves on a real website

iDeal for RSForm! Pro adds a dedicated iDEAL | Wero payment method to the RSForm! Pro payment system. According to the official RSJoomla documentation, the extension works as an additional payment method for Payment Package and can use the available Mollie, Sisow, and Buckaroo services. That distinction matters: the extension does not replace your form builder and it does not turn Joomla into a full ecommerce store. Its purpose is to accept payments directly from a form when the workflow is simpler than a product catalog with a shopping cart.

Typical use cases include paid event registration, booking a consultation, requesting a service with a fixed or calculated price, collecting donations, taking a deposit for a reservation, or paying for a single selected product. The user fills out the form, selects a payment method, optionally chooses a bank or service, sees the final amount, and submits the form. RSForm! Pro and the payment plugin then build the data for the payment handler.

This approach is especially useful when the full order logic fits inside a single form. There is no need to deploy a separate store, create product listings, or configure a full checkout flow. Instead, you collect the required fields, assign pricing, and define when emails should be sent or integrations should run after the payment is confirmed.

The usage boundary matters too. If you need inventory management, category-based discount rules, customer accounts, repeat orders, advanced shipping, or tax-heavy commerce logic, you are better off using a store component or a dedicated ecommerce system. iDeal for RSForm! Pro is strongest in focused payment forms where the main value is the flexibility of RSForm! Pro fields and a straightforward payment flow.

Who an RSForm! Pro payment form is a good fit for

This extension is a strong fit for webmasters and Joomla site owners who already use RSForm! Pro and want to add payment to a specific form. The advantage is not payment alone. The form remains a form, which means you can still use conditional fields, multi-page layouts, input validation, emails, post-submission messages, saved submissions, and the rest of the core component's features.

iDEAL and Wero have regional specifics. Mollie's documentation describes iDEAL as a widely used payment method in the Netherlands, allowing customers to pay through a familiar bank interface. That makes the extension particularly relevant for sites serving a Dutch or broader European audience and accepting payments within the capabilities of their provider. At the same time, the exact availability of the method, supported currencies, countries, and limits should be verified in your payment provider account, not treated as universal across every site.

When this product is a strong choice

• RSForm! Pro is already installed on the site, and payment needs to be added to a form rather than a product catalog.
• The payment is tied to a single workflow: registration, a fee, a service, a donation, a deposit, or a custom request.
• You need Mollie, Sisow, or Buckaroo, and those services are actually available for your business and region.
• You need to defer emails, data delivery, or internal processing until payment is confirmed through Payment Package.
• You care about the flexibility of a Joomla form: fields, validation, conditions, messages, language strings, and saved submissions.

When a different approach makes more sense

The extension may be unnecessary if the form only collects a request without payment, if your main audience does not use iDEAL | Wero, if the payment provider is not available for your account, or if the business process really requires a full online store. Another risk is trying to force an overly complex order process into a form. Multiple products, different tax rates, promo codes, shipping, and order statuses can quickly turn a simple form into something difficult to maintain.

What to check before installation

Before installing the extension, it is worth doing a short round of prep work. It saves more time than trying to diagnose an empty redirect or a missing payment method after the form goes live.

The Joomla and RSForm! Pro foundation

Make sure RSForm! Pro itself works properly on the current site version, and that the form you plan to add payment to already submits correctly without any payment step. The RSForm! Pro product page lists support for current Joomla branches and technical requirements, but for a separate payment plugin you also need to factor in its changelog. The iDEAL | Wero changelog includes compatibility updates for Joomla, RSForm! Pro, and PHP, so if you are working with an older site, check the requirements of the specific extension version first.

Do not start with the payment gateway if the base form has not been validated yet. First build the form, send a test submission, confirm that it appears in Manage Submissions, make sure emails work, required fields validate correctly, and the post-submit page behaves as expected. Only then should you add the payment layer.

Payment Package as the required foundation

The official documentation explicitly states that Payment Package must be installed before iDEAL | Wero. It is what adds payment fields such as Single Product, Multiple Products, Donation, Quantity, Total, and Choose Payment. Without that foundation, iDeal for RSForm! Pro cannot integrate into the form as a payment method.

Practical check: open the form editor and see whether the payment field group is available. If the pricing, total, and payment selection fields are missing, resolve Payment Package first and only then return to iDEAL | Wero.

Payment provider and keys

For Mollie, you will need the API key from your account settings. Sisow uses a Merchant ID and Merchant Key. For Buckaroo, the RSJoomla documentation lists a Store Key and Secret Key. These values should never be stored in the article, project notes, or shared with developers unless absolutely necessary. Review them only in the provider's secure account area and paste them only into the appropriate Joomla configuration fields.

If the payment service supports test mode, start there. For Sisow and Buckaroo, the RSJoomla documentation lists a Payment Mode parameter with the options Test (Sandbox) and Live. For Mollie, the testing flow depends on the capabilities of your account and API settings, so confirm the process against Mollie's own documentation.

Public site accessibility

Payment confirmations often require the site to be reachable from the outside. The Payment Package documentation specifically notes that deferred email sending and some post-payment actions will not work if the site is blocked by access restrictions. That means a local copy or a password-protected staging domain may be fine for checking the form itself, but not always sufficient for validating the full payment status flow.

Installation and the first verification in the Joomla admin panel

Installation has two parts: upload the extension archive through the Joomla Extension Manager and publish the system plugin. In older interfaces, the path may appear as Extensions - Manager - Install. In newer Joomla versions, the menu structure looks different, but the idea is the same: install the package through the standard extension installer.

1. Create a backup of the site and database before installing the payment extension.
2. Confirm that RSForm! Pro and Payment Package are already installed and updated to compatible versions.
3. Open the Joomla extension installer and upload the iDEAL | Wero ZIP package.
4. Go to the plugin list and find System - RSForm! Pro iDEAL | Wero Plugin.
5. Publish the plugin and save the changes.
6. Open Components - RSForm!Pro - Configuration and verify that the iDEAL | Wero tab appears.

After installation, do not jump straight to the public form. First make sure the settings tab is there and that iDEAL | Wero payment elements are now available in the form. It is a simple but important check: if the tab is missing, the issue is at the installation, plugin publication, or compatibility level, not in the setup of a specific form.

Minimum verification after enabling it

Create a temporary test form or use a copy of an existing one. Do not immediately edit a live form that already handles real submissions unless you have a clear rollback plan. In the form copy, add simple fields: name, email, one product, total, payment selection, and the iDEAL | Wero method itself. That will tell you whether RSForm! Pro can see the new payment method and whether the base price logic is working correctly.

If the test form successfully displays the payment method, you can move the settings into the live workflow. If it does not, do not start adding fields at random. Go back to the plugin list, the RSForm! Pro configuration, and Payment Package. At this stage, the problem is usually not the provider but a missing required form element.

Configuring iDEAL | Wero: providers, amounts, and form behavior

The main configuration lives under Components - RSForm!Pro - Configuration - iDEAL | Wero. The RSJoomla documentation describes three service toggles: Enable Mollie Service, Enable Sisow Service, and Enable Buckaroo Service. Once you save the selected service, additional parameters for that specific provider appear.

Mollie: API key, cancel URL, and method selection

For Mollie, you enter the Mollie API Key. There is also a Cancel URL, which is where the user can return if they cancel the payment. One especially important setting is Show Only iDEAL | Wero Payment Methods. If set to Yes, the selection field will be limited to iDEAL | Wero methods. If set to No, all payment methods available to the account in Mollie may be shown, assuming they are enabled and supported there.

For a form with a clear "pay with iDEAL | Wero" expectation, it usually makes sense to start by limiting the methods. If you are intentionally using Mollie as a broader payment set, check whether the additional payment options might confuse the user. Either way, after saving the settings, open the form as a visitor and confirm that the method list matches the intended workflow.

Sisow: merchant identifiers and test mode

For Sisow, the documentation lists Sisow Merchant Id, Sisow Merchant Key, and Payment Mode. If your version and account support test mode, start with Test (Sandbox). Validate not just the redirect, but also the return to the site, the submission status, and the behavior of emails after payment.

You should also account for the required bank selection element. The RSJoomla documentation states that when using Sisow, the Issuer Bank element is required in the form. This is a common trap: the payment method is added, the amount is there, but the required bank field is missing, and the user flow breaks.

Buckaroo: store keys and the test environment

For Buckaroo, you use Store Key, Secret Key, and Payment Mode. The setup logic is similar: enter the credentials, choose test or live mode, save the configuration, then validate the form from the visitor's perspective. Do not mix test keys with live mode or live keys with test mode. If the payment service rejects the request, first verify that the keys match the selected mode.

Taxes and the final amount

For each service, the documentation references Tax Type and Tax Value. Tax can be percentage-based or fixed, and the transaction amount should include that value. In practice, this means the final amount shown in the form and the amount seen by the payment service must match your expectation.

If you use tax, add a Total field to the form and check how {tax} and {grandtotal} are displayed wherever you need them: in emails, the post-submit message, or the admin-side submission view. Do not overcomplicate tax calculations inside the form if they can be handled more reliably in a separate store or accounting system.

Form fields without which the payment workflow will not come together

The most common mistake in RSForm! Pro payment forms is configuring the provider but forgetting the payment fields. iDeal for RSForm! Pro works inside the Payment Package logic, so the form must include not only regular user fields, but also the elements that define the amount and payment selection.

Pricing: Single Product, Multiple Products, Quantity, Donation, and Total

If the amount is fixed, Single Product is the simplest option: define the label, description, and price. If the user selects one or more options, use Multiple Products. The Payment Package documentation describes the item format as price|label, for example 15|T-shirt. On a Russian-language site, the label can be in Russian, but the internal value structure should still be handled carefully.

The Quantity field multiplies the price of the selected product by the quantity. It is useful for tickets, seats, bundles, or identical services. Donation works for a custom amount entered by the user. Total aggregates the final value and is used alongside product, donation, and quantity fields.

Do not hide the total amount without a good reason. Even if the user is redirected to a payment page, it is helpful to show clearly on the form what they are about to pay for. That reduces abandoned payments and helps you catch calculation issues before the provider step.

Choose Payment and a hidden single method

The iDEAL | Wero documentation explains this point separately: payment data is sent to the handler only if the user selects iDEAL | Wero in the Choose Payment field. This field can be visible when multiple payment methods are available, or hidden when you want to force a single method. To hide it, use the Show in front-end? parameter on the Attributes tab.

If you only use one payment method, you can hide Choose Payment, but do not remove it from the form. Hiding and deleting are not the same thing. When hidden, the selection logic still exists and the user is not distracted by an unnecessary element. When deleted, the form may stop passing the payment method as expected.

Bank fields and provider-specific differences

For Mollie, the current iDEAL | Wero 2.0 logic no longer requires the iDEAL | Wero Mollie Issuer Bank field, according to the RSJoomla documentation. For Sisow, the Issuer Bank element is required. For Buckaroo, the documentation lists the payment element but does not require a separate bank field in quite the same way. That means you cannot safely copy a form between providers without reviewing it first, because the set of required elements is different.

Data storage and statuses

Payment Package notes an important requirement: saving data to the database must be enabled for payment functionality to work correctly. This is configured in the form properties. If data is not saved, it becomes much harder to connect the submission, payment status, and follow-up emails. You can also view the transaction status and ID in submissions if the relevant columns are enabled in the list.

Do not check only the public form page. After a test submission, open Components - RSForm!Pro - Manage Submissions, select the form, and verify whether the payment field values, status, and transaction ID are present. If those columns are not visible, configure the column display in the submissions list.

Practical example: an event registration payment form

Let us walk through a concrete scenario: a Joomla site is accepting registration for an in-person seminar. The form needs to collect the attendee's name, email, number of seats, consent to the terms, calculate the amount, and send the user to payment through iDEAL | Wero. After payment is confirmed, the administrator should receive the submission and the user should receive an email with participation details.

Goal and preparation

The goal is to build a single form without a cart: the visitor selects the number of seats, sees the total, chooses iDEAL | Wero, pays, and returns to the site. Before you begin, RSForm! Pro, Payment Package, and iDeal for RSForm! Pro should already be installed. You also need a configured provider, such as Mollie or Buckaroo, plus a working test form without payment.

Form setup steps

1. Create a copy of the registration form or a new form in RSForm! Pro.
2. Add the standard fields: name, email, phone if needed, and consent to the terms.
3. Add Single Product with the participation label and the base price.
4. Add Quantity and link it to the product if the visitor can select multiple seats.
5. Add Total so the user can see the final amount before submitting.
6. Add Choose Payment and the iDEAL | Wero payment element for the selected provider.
7. If the provider requires bank selection, add the appropriate bank field.
8. In the form properties, enable submission storage in the database.
9. Configure the emails and enable deferred sending until payment confirmation if needed.
10. Save the form and test it on a separate page or a hidden menu item.

Validating the result

Open the form as a regular visitor. Select the number of seats, check the total, submit the form, and make sure you are redirected to the payment service. After returning to the site, review the submission in the admin panel: the amount, payment method, status, and emails should all match the expected state.

Quick takeaway: if the final amount is correct, the selected method appears in the submission, the redirect happens, and the email is sent after payment confirmation, the base workflow is ready to be transferred carefully to the live page.

A common detail that prevents launch

If the user sees the form and the amount but payment never starts, check Choose Payment. In RSForm! Pro payment forms, this element is not just a decorative list. It tells the system which handler should receive the data. With a single method, it can be hidden, but logically it still needs to remain part of the form.

Use cases where a payment form works better than a store

A payment plugin for a form is often chosen not because it is "simpler than a store," but because a form can describe the service more precisely. In a store, the user usually selects a product from a catalog. In RSForm! Pro, they can first answer questions, choose parameters, provide contract details, upload a file, accept terms, and only then pay the calculated amount. iDeal for RSForm! Pro becomes the final step in that workflow.

A good payment form should not feel like a random collection of fields. Before you configure it, it helps to write down a short outline: what the user selects, which fields affect the amount, what should appear in the email, which status counts as successful, and what should happen if payment is canceled. That outline helps keep business logic, form design, and payment handling from getting mixed into one unclear structure.

Event or course registration

For events, a form is useful because it collects more than payment. It can also gather operational details such as the attendee's name, email, phone number, seat count, ticket type, comments, and agreement to the rules. Pricing can be built with Single Product or Multiple Products, while the seat count can be handled through Quantity. If there are multiple participation types, such as in-person and online, it is better to make that difference explicit in the product label than to hide it in the email after payment.

The result check in this case should include three states: successful payment, cancellation, and a repeated attempt. After successful payment, the email can include participation details. If the payment is canceled, the form should not send final confirmation. If the user tries again, the administrator should be able to see that it is a new submission or a separate attempt, not confuse it with an already paid registration.

Paying for a fixed service package

For a consultation, audit, on-site service visit, or time booking, one fixed-price product is often enough. In that case, do not overload the form with too many payment options. A clearer workflow works better: the user fills in their details, sees a single package, accepts the terms, and pays. If you only need iDEAL | Wero, the Choose Payment field can remain hidden, but the payment method logic still needs to be part of the form.

In the admin email, it is useful to include not just the amount, but also the original submission details. That makes it easier to match the payment to the exact service request. If you use {_TRANSACTION_ID:value}, make sure the email is sent after payment confirmation, otherwise the value may be empty or not useful for reconciliation.

Donation or voluntary contribution

For voluntary payments, use Donation and define clear input restrictions if your workflow requires them. The user should be able to see that the amount was entered correctly, and the form should not accept random characters in place of a number. If you want to offer preset amounts, it is often more convenient to use Multiple Products with several options and add a separate field for a custom amount only when necessary.

In these forms, it is especially important not to promise too much. The post-submit message and the emails should clearly explain what happened: the submission was created, payment is pending, payment was confirmed, or the user canceled the payment. The clearer the status, the fewer manual questions the administrator will need to answer.

A small catalog without a full shopping cart

Sometimes a form replaces a mini catalog: the user picks one of several products, adds a quantity, and pays. That works if there are only a few options and no shipping, stock tracking, or complicated discount rules. As soon as the logic becomes "multiple items in a cart, different shipping conditions, coupons, customer account, and order history," a form stops being the right tool.

If you still use a form for several options, pay attention to readability. The price|label format is convenient for setup, but the public-facing label needs to be easy for the user to understand. Do not make them guess what the differences are. Separate fields into logical groups and place the total closer to the submit button.

Limitations, security, and post-launch support

A payment form touches money, personal data, and user expectations. That means once the technical setup is done, you still need to assess the limitations. iDeal for RSForm! Pro does not remove the need to keep Joomla, RSForm! Pro, Payment Package, and your payment providers up to date. The iDEAL | Wero changelog shows that the developer updates compatibility, adds providers, and fixes bugs, so an old installed version should never be treated as permanent.

Updates and a test copy

Before updating the payment extension, make a backup and test the form on a staging copy. Pay special attention to the fields that affect payment: Total, Choose Payment, the payment method, bank selection, and post-payment emails. If an update changes compatibility with PHP, Joomla, or RSForm! Pro, do not install it blindly on a live site during active registration or ordering periods.

After the update, repeat the same workflow you used when launching: successful payment, cancellation, an invalid required field, and reviewing the submission in the admin panel. A repeatable checklist like that is much more reliable than a vague "the form seems to open."

Provider keys and access

API keys, Merchant Keys, Secret Keys, and other secrets should be stored only in the site configuration and the payment provider account. Do not place them in emails, public notes, contractor task descriptions, or screenshots you share without masking them first. If a key is exposed accidentally, it is safer to rotate it in the provider account than to assume no one will misuse it.

Access to the Joomla admin panel for payment configuration should be restricted. A content manager who edits page text does not always need permission to change the payment plugin settings. If multiple administrators work on the site, split responsibilities clearly: who edits the form, who changes payment keys, who reviews submissions, and who handles updates.

Caching, optimization, and custom scripts

Forms with dynamic totals and payment redirects are sensitive to aggressive optimization. If the site uses caching, script merging, or deferred JavaScript loading, test the payment form after every optimization change. Signs of trouble include the total no longer updating, the submit button not responding, required fields validating strangely, or the form submitting without the expected payment step.

Do not begin troubleshooting by disabling everything site-wide. First exclude the form page from the most aggressive cache and minification rules, then test again. If the issue disappears, restore optimization one setting at a time. That is the fastest way to isolate the conflict without giving up performance entirely.

Legal and user expectations

The payment form should clearly tell the user what they are paying for, how much will be charged, what data is being collected, and what happens after successful payment. This is not only a matter of trust but also a practical safeguard against disputed submissions. If refund, cancellation, or participation terms matter, add a link to a separate terms page and require explicit agreement.

Do not try to hide important conditions in the post-payment email. The user should see the material terms before submitting the form. In RSForm! Pro, this can be handled with standard fields, a text block, a consent checkbox, and a clear message next to the total amount.

Emails, statuses, and actions after payment confirmation

A payment form differs from a standard form because form submission and confirmed payment do not always happen at the same moment. The user may submit the form, go to the provider, complete the payment, cancel it, or never return to the site. That means emails and follow-up processing need to account for payment status.

When to send emails

Payment Package supports deferring emails until payment is confirmed: Defer User Email, Defer Admin Email, and Defer Additional Emails. For paid registration or a service order, that is usually more appropriate than sending confirmation immediately after the user clicks the form button. Otherwise, the user could receive a message saying "you are registered" even though the payment was canceled.

There are exceptions. If an email is only meant to confirm that the request was received, not that payment was completed, you can send it immediately, but the wording should stay careful: the request was received, payment is pending. For an email that includes access details, a ticket, a material link, or final confirmation, deferred sending is the safer approach.

Silent Post, mappings, and external integrations

The Payment Package documentation also describes deferred Silent Post and Mappings. This is useful if you need to send data into another system after payment or write it into a separate table. In a payment workflow, it is not safe to perform those actions before payment confirmation if they trigger service delivery, account access, or internal booking of a paid order.

Test these functions on a publicly accessible staging URL. If the site is behind a password, IP restriction, or only available locally, the payment service may not be able to send the confirmation back to the form. In that case, email delivery or the external integration may look broken even though the actual problem is site accessibility.

Status and transaction ID

Payment emails and the admin area can use service values such as {_STATUS:value} and {_TRANSACTION_ID:value}. Do not insert the transaction ID into an email that is sent before payment is confirmed. If the user or administrator needs that value, configure the email so it is sent only after confirmation.

Language labels, bank lists, and careful localization

In payment forms, it is not enough to accept payment technically. The user also needs to understand clearly what they are selecting. The iDEAL | Wero documentation includes a separate example for overriding the bank or service label. This is done through a Joomla language override for a constant such as RSFP_IDEAL_METHOD_ followed by the method value converted into the required format.

For example, if the method value in the dropdown is belfius, the constant becomes RSFP_IDEAL_METHOD_BELFIUS. If the value is inghomepay, the constant becomes RSFP_IDEAL_METHOD_INGHOMEPAY. The point is not to edit extension files, but to use Joomla's standard language override mechanism.

How to change labels safely

1. Open the form on the public side of the site and find the actual payment option value in the HTML or through browser tools.
2. Build the language constant using the documented rule: RSFP_IDEAL_METHOD_ followed by the method value in uppercase Latin characters.
3. Create the language override in the Joomla admin panel without editing extension files.
4. Clear the Joomla and browser cache if caching is in use.
5. Test the form in the target site language and confirm that only the visible label changed, not the method value.

Do not change the internal values of payment methods just to make the text look nicer. The integration logic uses those values, and only the visible label should change for the user. That is safer for updates and much easier to troubleshoot.

A small visual improvement for the form

If the form looks too cramped, you can add a custom CSS class to the form container or wrap the payment block in its own class inside a custom RSForm! Pro layout. Here is a conservative CSS example. It does not depend on the extension's internal classes and is easy to roll back: just remove the class or the CSS from the template.

.ideal-order-form .rsform-payment-summary {
  padding: 16px;
  border: 1px solid #d9e2ef;
  border-radius: 8px;
  background: #f7fafc;
}

.ideal-order-form .rsform-payment-summary strong {
  display: inline-block;
  margin-bottom: 6px;
}

The check is simple: open the form before and after the change, and confirm that only the payment block is highlighted while the bank selection fields, total amount, and submit button remain in place. If the site template already overrides form styles, add the CSS on a test copy first and avoid overly broad selectors.

Validation before publishing the live form

Before publishing the payment form, do one final test pass from three perspectives: editor, administrator, and regular visitor. Each viewpoint has its own goal: the editor checks the text and fields, the administrator checks submissions and statuses, and the visitor checks whether the flow is easy to understand.

Public side of the site

• The form opens without errors and does not require administrator permissions.
• Field labels are clear, especially for the amount, quantity, payment selection, and bank selection.
• The total amount changes as expected when the product or quantity changes.
• The payment method is displayed only where it is needed.
• After submission, the user reaches the payment provider or sees a clear error message.

RSForm! Pro admin panel

• The submission is saved in Manage Submissions.
• The selected method, amount, status, and transaction ID, if available, are visible in the submission.
• Deferred emails are sent only after payment confirmation if that is how you configured the workflow.
• Payment cancellation does not trigger false confirmation of the service.
• Custom language overrides remain in place after clearing the cache.

Payment provider

Check the amount, payment description, status, return flow, and cancellation handling. If Mollie is used as the main provider, remember that the API creates the payment and returns a checkout link, while later status handling depends on the site communicating properly with the payment service. Buckaroo and Sisow differ in details, but the validation logic is similar: keys, mode, amount, status, and return flow.

Do not switch the form to live mode after one successful click. At minimum, test a successful payment, a cancellation, invalid required input, and a repeat submission. That is how you find the points where a real user might get stuck.

Why the payment form does not work and how to diagnose the issue

Troubleshooting works best if you move from the simplest layer to the more complex one: installation, plugin publication, provider configuration, form fields, amount, method selection, statuses, and external site accessibility. Do not change every setting at once. After each fix, repeat the same test scenario so you can see exactly what changed the outcome.

The iDEAL | Wero tab does not appear in settings

Symptom: the archive is installed, but there is no iDEAL | Wero tab under RSForm!Pro - Configuration. Possible causes include an unpublished system plugin, the wrong package being installed, a missing Payment Package, or a version conflict.

What to check: the Joomla plugin list, the presence of System - RSForm! Pro iDEAL | Wero Plugin, its publication status, the RSForm! Pro version, and the presence of Payment Package. If the tab still does not appear after publishing the plugin, clear the admin cache and review the PHP error log.

The payment method does not appear in the form

Symptom: the settings tab is there, but the visitor cannot see iDEAL | Wero in the form. The usual cause is that the iDEAL | Wero payment element, the Choose Payment field, or a required bank element for the selected provider is missing.

How to fix it: open the form editor and add the payment method from the payment elements group. Then add Choose Payment. If there is only one method, do not delete the payment selection field; hide it instead if needed using Show in front-end? - No. For Sisow, verify that the required Issuer Bank field is present.

The amount is zero or does not match what you expect

Symptom: the form submits, but the amount is wrong, tax is missing, or the total does not change when the quantity changes. The cause may be the price|label format, an incorrect Quantity link, a missing Total, or tax settings that do not line up.

What to check: first test one fixed product without quantity, then a product with quantity, then tax. If the simple scenario works, the problem is in the more complex formula or field combination. Do not use custom JavaScript for payment calculations until you have verified the server-side Payment Package logic.

No redirect to the provider

Symptom: the submission is saved, but the user is not sent to payment. Check the selected payment method, provider keys, Test or Live mode, and confirm that the amount is greater than zero. For Mollie, check the API key and whether the selected method is available in the account. For Buckaroo and Sisow, confirm that the keys match the chosen mode.

When to roll back a setting: if the error started after enabling a new provider or changing the mode, restore the previous working mode, clear the cache, and run the test again. That helps separate a credential issue from a form issue.

Emails are sent before payment or never sent after it

Symptom: the user receives confirmation before payment, or the administrator does not receive an email after successful payment. Check Payment Email Settings: Defer User Email, Defer Admin Email, and Defer Additional Emails. Also check whether the site is externally accessible to the payment service.

How to fix it: for confirmation of a paid service, enable deferred sending. For a standard notification that a submission was created, keep the email before payment if needed, but rewrite the text so it does not imply confirmed payment. If the site is password-protected, do not use that URL for a full status test.

The bank label is not translated

Symptom: the bank or payment button appears in the wrong language. Check that you created a Joomla language override for the correct RSFP_IDEAL_METHOD_... constant rather than changing the text in the HTML or the option value. After making the change, clear the cache and test in the correct site language.

When iDeal for RSForm! Pro is worth using

iDeal for RSForm! Pro is a strong choice if you already build forms with RSForm! Pro and want to add an iDEAL | Wero payment flow without deploying a full store. The strength of the solution is not in a long list of storefront features, but in the combination of a flexible Joomla form, Payment Package payment fields, and supported providers such as Mollie, Sisow, and Buckaroo.

Before launch, keep a short readiness checklist in mind: the system plugin is published, the iDEAL | Wero tab is available, the provider is configured, the form includes pricing, total, and payment selection, submissions are saved, statuses are visible, emails are sent at the correct moment, and the user flow is understandable without admin guidance. If all of that has been validated in a test scenario, you can move on to the live form.

When you are ready to test the extension on your own site, you can download the installation file and go through the setup first on a copy or a test page. That approach lowers the risk to real submissions and makes it much easier to see whether this payment form matches your workflow.