Revolut Checkout for VirtueMart - Joomla Extension

How to Set Up Revolut Checkout for VirtueMart in a Joomla Store

Revolut Checkout for VirtueMart does more than add one more payment option to your checkout. This payment extension connects a Joomla and VirtueMart store to Revolut Merchant, displays the payment widget to the customer, passes the order to the payment side, and after a successful transaction updates the order status in the store according to the rules you choose.

In this guide, we will walk through the practical path: what to check before installation, where to enable the plugin in Joomla, how to create a payment method in VirtueMart, which fields to configure first, how to run a test order, where to look when something fails, and when a different payment setup may be the better choice. This article is written for a store owner, Joomla administrator, or developer who already has site access and wants to enable card payments through Revolut safely.

This guide does not replace the developer's documentation or Revolut Business documentation, but it helps connect them to the real VirtueMart workflow: currencies, order statuses, payment method visibility, test mode, customer return after payment, store emails, and troubleshooting. If a specific feature depends on your extension version or your Revolut Merchant settings, verify it in your account and documentation instead of copying settings blindly from another site.

What This Payment Extension Actually Solves

In a typical VirtueMart store, an order moves through several stages: the customer selects products, enters their details, chooses shipping and payment, confirms the purchase, and the administrator receives the order with a specific status. If payment happens off-site or manually, a gap appears between order creation and the actual receipt of funds, and someone has to monitor that gap by hand. Revolut Checkout for VirtueMart is designed to close that gap: the customer selects Revolut as the payment method, enters card details in the payment system widget, and the store receives the transaction result and updates the order status.

According to Ignis.Dev, the extension is aimed at VirtueMart store owners who have Revolut Business with Revolut Merchant enabled. It supports card payments, including Visa and MasterCard, uses the Revolut Checkout widget, and does not store customer payment data in the Joomla database. That is a major difference from custom-built payment forms: the site administrator configures the connection and statuses, but the website does not become a place where card credentials are stored.

It is important to understand the boundary of responsibility. The extension adds a payment method to VirtueMart and helps send the order to Revolut. It does not fix broken tax rules, configure shipping, replace currency checks, make the store automatically compatible with every checkout template, or remove the need for a test order. A good setup starts before installation: make sure the site already processes regular orders reliably, calculates totals correctly, and does not break the cart because of cache or a conflicting template.

What the Customer Gets

For the customer, the flow should be short and clear: choose the payment method, see a clear payment widget, confirm the transaction, and return to the order. On the Ignis.Dev product page, the process is described as straightforward: at the end of checkout on the site, the Revolut widget opens, and the customer enters card details there. If the payment requires 3D Secure or another strong authentication step, the confirmation happens within the payment flow.

This flow is especially useful for stores where it is important not to send users through a long external payment path. The widget does not cancel out the need for a clean checkout experience: if the cart page itself is overloaded, the mobile layout breaks, or customer fields behave inconsistently, the payment method will not save your conversion rate. That is why this guide includes a separate verification step on the public storefront.

What the Store Administrator Gets

The administrator gets a controlled configuration point inside VirtueMart: the payment method can be published, given a clear name, limited by shopper groups, countries, categories, amount ranges, or shipping methods if those parameters are available in the standard payment method form. The plugin itself adds its own configuration fields: environment, keys, capture mode, customer creation in Revolut, debug mode, and statuses for different payment outcomes.

The most common implementation mistake is enabling the method as a button and never checking the business logic behind the statuses. In VirtueMart, statuses control emails, invoices, inventory movement, and later order processing. That means a successful payment should move the order into a status your team actually works with, for example a confirmed status or another internal status already used by your warehouse and email flow.

Who Revolut Checkout for VirtueMart Fits, and When Another Path Makes More Sense

This extension makes the most sense for Joomla store owners already using VirtueMart who want to accept online payments through Revolut Merchant without building their own integration with the Merchant API. It is especially appropriate if the store sells regular products or services, handles orders inside VirtueMart, and needs order statuses to update automatically after payment confirmation.

A good candidate for this setup is a store where products, shipping, taxes, currencies, emails, and checkout are already working properly. In that situation, Revolut Checkout for VirtueMart adds the missing payment layer instead of becoming an attempt to repair the entire checkout process. If the cart is unstable, customer fields change from template to template, or order statuses have not been thought through, it is better to clean up the VirtueMart foundation first.

When the Extension Is Especially Useful

• The store already runs on Joomla and VirtueMart, and the team does not want to move the catalog to another platform just to add payments.
• You need card payments through Revolut Merchant with 3D Secure and SCA, and card data must not be stored in the site database.
• The administrator needs to choose statuses for pending, successful, and canceled payments inside VirtueMart.
• You need a test environment before launch so you can verify the order flow without exposing real customers to risk.
• The store uses currencies supported both by the extension and by your Revolut Merchant account.

When You Should Pause and Check Alternatives

If you do not have Revolut Business and an active Merchant account, the extension will not solve the problem on its own. If the store sells in a currency that is not included in the supported list on the product page, the payment method may not appear in the required scenario or the order may not go through correctly. If the business needs a local payment system with bank transfers, BLIK, installments, or regional methods, Tpay, Przelewy24, or another provider with a VirtueMart plugin may be a better fit.

You should also evaluate the checkout architecture itself. Revolut officially offers several payment solutions: embedded Revolut Checkout, separate card flows, a Hosted Checkout Page, no-code plugins for popular platforms, and direct Merchant API integration. Ignis.Dev covers the specific combination of Joomla + VirtueMart + Revolut Checkout. If you need deep customization of the payment route, preauthorization, separate server-side operations, or unusual booking logic, you may need a developer and a direct review of the Revolut Merchant API.

What to Check Before Installing It in Joomla and VirtueMart

Preparation matters for more than formality. A payment plugin sits at the intersection of the CMS, the store, the payment system, HTTPS, currencies, statuses, the checkout template, and PHP server extensions. If any one of those pieces is not ready, the failure often shows up only after the customer selects payment and expects to complete the order.

Ignis.Dev documentation lists the baseline requirements: a PHP version no lower than the one specified in the developer guide, the curl, mbstring, and json extensions, HTTPS enabled, and Joomla and VirtueMart versions that meet the stated minimums. The product page also lists compatibility with Joomla 3.x, Joomla 4.x, Joomla 5.x, VirtueMart 3.x, and VirtueMart 4.x. You should compare that information against your actual installation, because an older checkout template or a third-party one-page checkout may behave differently from the standard cart.

Technical Checklist Before Installation

You should not start with live payments. Even for a small store, enable the test environment first, run one or two test orders, verify statuses and emails, and only then switch to live keys. Switching environments without re-testing is one of the highest-risk mistakes: the site may look ready while actually running with the wrong key or the wrong status setup.

What to Prepare in Revolut Merchant

The extension requires access to Revolut Merchant. In Revolut documentation, a Merchant account is described as a sub-account of Revolut Business that unlocks tools for accepting payments, managing orders, viewing reports, and handling integrations. For direct API use or some plugins, keys are used: a public key for the client side and a secret key for server-side calls. In the Ignis.Dev guide for this extension, the fields are listed specifically as Sandbox Merchant API key and Production Merchant API key.

The practical order is simple: prepare test access in the sandbox, make sure the Merchant account is active, do not share the secret key in messages, notes, or with third-party contractors unless absolutely necessary, and in Joomla enter it only in the configuration field of the payment method. If the plugin reports an environment mismatch after you enter the key, do not try to "guess" the right option - go back to Revolut Business or the sandbox and verify exactly which key you copied.

Installing the Extension and Enabling the Plugin for the First Time

Installation works like any standard Joomla extension, but there is an important second step in VirtueMart. It is not enough to upload the ZIP file in the admin panel: the payment plugin must be enabled in Joomla, and then a payment method based on it must be created in the VirtueMart list. The customer sees the payment method, not just the plugin.

According to the Ignis.Dev instructions, the path starts in the Joomla admin panel: Extensions -> Manage -> Install, then the Upload Package File tab, and then upload the extension archive. After installation, go to Extensions -> Plugins, find Ignisdev Revolut Checkout for Virtuemart, and enable it. Only then will the plugin become available in VirtueMart settings.

A Low-Risk Setup Sequence

1. Create a backup of files and the database before installation, especially if your checkout has already been customized.
2. Install the ZIP through the standard Joomla installer without manually extracting the archive into the site folders.
3. Enable the plugin in the Joomla plugin list and make sure it is not left disabled.
4. Open VirtueMart -> Shop -> Payment Methods and create a new payment method.
5. In the Payment Method field, select the Ignisdev Revolut Checkout option and save the record so the configuration parameters load.
6. Configure the keys, environment, statuses, and visibility, then publish the payment method.

Quick check after installation: if the Ignisdev Revolut Checkout option does not appear in the VirtueMart payment methods list, first verify that the Joomla plugin is enabled. Do not create a second payment method or reinstall the archive until you have checked the plugin status.

If you are installing this on a live store, do it during a low-traffic window. You can create the payment method in unpublished mode, configure it, save it, then test it in the sandbox or temporarily restrict it to a test shopper group. That approach reduces the chance that a real customer will see a half-configured payment method.

Configuring the Payment Method After Installation

The main configuration area is inside the VirtueMart payment method record. The standard VirtueMart section controls the name, publication status, description, display order, shopper groups, countries, categories, amounts, and shipping assignment. The plugin configuration section controls the Revolut connection: environment, keys, capture mode, customer creation, debug mode, and order statuses.

Do not try to configure every field in one pass. First, get a minimal working test order: a published method, test environment, sandbox key, correct currency, and clear statuses. Only after that should you add restrictions by country, category, group, or shipping.

Basic VirtueMart Fields: How to Name the Payment Method and Where to Show It

The payment method name should be clear to the customer. The internal name can be technical, but the visible name should be short, for example, Pay by card via Revolut. In the description, you can mention that payment is processed through the Revolut payment widget and card details are not stored by the store. Do not overload that description with legal wording: long text next to a payment option makes the choice harder.

Standard VirtueMart restrictions help prevent the method from appearing where it should not. If the store operates in multiple countries and Revolut Merchant is not available for every business scenario, check the country field carefully. If some categories contain products with separate payment rules, use category restrictions carefully. If payment depends on shipping, pay attention to the Shipments field: it lets you show the method only when a specific shipping option is selected.

When to Leave Restrictions Empty

In VirtueMart documentation, many standard restrictions are described with the same safe approach: an empty value usually means "for all." That is useful for the first test because it makes the method easier to see and verify. After a successful test, you can narrow visibility gradually. If you immediately choose a shopper group, country, category, and shipping method, and the payment method does not appear on checkout, you will have to untangle multiple conditions at once.

When Restrictions Really Are Necessary

Restrictions are useful when they reflect a real business rule. For example, the method should not be shown for a currency or country where you do not accept payments, for products that require manual approval, for shipping methods that are paid another way, or for shopper groups that use post-payment terms. But every such rule should be verified with a separate test order.

Environment and API Keys

The Environment field determines where the plugin sends the payment flow: to the test environment or the production environment. Use the sandbox key for testing and the production key for live payments. A mismatched environment and key often does not fail with a clear "wrong configuration" message - it tends to show up as a vague payment failure, a missing widget, or a rejection on the payment provider side.

The secret key must never be pasted into public notes, HTML, emails, tickets without masking, or screenshots seen by a wide audience. If a key has been exposed accidentally, it should be rotated in Revolut Business or the sandbox, and the old value should be replaced in VirtueMart. A secret key is not a reference setting - it is access to the server-side integration.

Capture Mode: Automatic or Manual Capture

In Ignis.Dev documentation, the Capture mode field is described as the charge mode: either automatic capture in Revolut Merchant or manual capture through the Revolut panel. For a standard store with physical goods, automatic mode is usually simpler: the customer pays, the order receives a successful status, and the team starts processing it. Manual mode makes sense if you want to verify stock availability, confirm shipping details, or approve the order before actually capturing the payment.

Do not enable manual mode just "to be safe." It adds an operational step: someone on the team has to remember where and when to capture the payment. If that step is missed, the order can look almost complete while the money is not captured the way your business process expects. If you use manual mode, create an internal procedure: who reviews the order, where they check the authorization, when they capture it, and what they do if the order is canceled.

Creating a Customer in Revolut

The Create Revolut Customer field lets you enable or disable customer creation on the Revolut side. Turning it on can be useful if you want to see customers in the payment dashboard and connect transactions to buyers. Turning it off may be preferable if the store does not want to create extra customer records in the payment system for every test or occasional purchase.

The decision depends on your support and accounting workflow. If managers often reconcile payments by customer email, customer creation can make lookup easier. If you keep the full customer history inside VirtueMart and use Revolut only as a payment channel, you can start with the more conservative setting and enable customer creation later after testing.

Statuses for Pending, Success, and Invalid Payments

The Pending status, Success status, and Invalid status fields link payment outcomes to the VirtueMart order. This is not just cosmetic. Statuses affect emails, invoices, inventory, order processing, and staff workflows. In VirtueMart, payment plugins, shipping methods, manual updates, and third-party extensions can all change statuses, and the built-in statuses include pending, confirmed, completed, canceled, and refunded.

For a first launch, it is usually helpful to use a simple, readable scheme: a new order gets a pending status after payment selection, a successful payment moves it to confirmed or another working status, and a canceled or invalid transaction moves it to canceled or declined. If you already use custom statuses, check which emails, invoices, and stock actions they trigger.

Debug Mode and Safe Rollback

Debug is for troubleshooting, not for permanent use. Turn it on during testing or when investigating a specific issue, then turn it off. If the payment method is already visible to customers, first make sure debug mode does not expose unnecessary technical messages on the public site.

Rolling back a payment configuration should be straightforward: unpublish the payment method, clear checkout cache, restore the previous status or key, and repeat the test order. Do not delete the method immediately after an error: it contains the parameters that may help you understand what was configured incorrectly. Deletion only makes sense after the configuration has been documented and you are certain the method is no longer needed.

How the Payment Widget and Order Update Flow Work

Understanding the mechanics makes troubleshooting much faster. When the customer selects the Revolut payment method in VirtueMart and confirms the order, the store builds the payment flow based on the amount, currency, order, and method settings. The customer then sees the Revolut Checkout widget or payment window, enters card details, and completes the confirmation. After the payment result is returned, the store should receive the signal, change the order status, and show the customer a clear final result.

In the official Revolut Checkout documentation, the product is described as an embedded widget with a unified, managed interface for Revolut payment methods. The documentation for online card payments also describes the card pop-up as an interactive window that opens during checkout and guides the customer through the payment steps. For a VirtueMart store owner, the key point is not the SDK terminology, but the fact that the payment interface is handled by Revolut while your site must correctly create the order and accept the result.

Why Card Data Should Not Stay in the Store

The Ignis.Dev page states that customer data is not stored on your site and remains in Revolut. That reduces the burden on the store owner: Joomla does not become a place where card credentials are stored. But that does not mean site security can be ignored. If the site is compromised, checkout is broken, HTTPS is configured incorrectly, or admin access is compromised, the payment method will still be operating in a bad environment.

The practical minimum for security is straightforward: keep Joomla updated, keep VirtueMart current, manage admin permissions carefully, protect access to the control panel, maintain backups, use HTTPS without errors, and avoid unnecessary extensions on checkout. The payment plugin should not become your only security measure.

How the Order, Payment, and Status Are Connected

In the Revolut Merchant API, payment flows are built around the order: the order represents the customer's intent to buy goods or services, and payment attempts are attached to it afterward. VirtueMart also has an order with a status, amount, customer, shipping method, and selected payment method. The payment extension has to synchronize those two worlds as far as its configuration allows.

If the customer closes the window, fails 3D Secure, goes back, or the payment provider does not respond in time, the order may remain pending or move into an unsuccessful status. That is a normal part of payment logic and not always a bug. The real problem starts when the manager does not understand what the status means, or when the site shows the customer a success message without a confirmed payment.

What to Keep in Mind About Webhooks and Notifications

Revolut documentation describes webhooks as a way to receive an event immediately after something changes in another system, for example when an order moves from pending to completed. Revolut also warns that event delivery order is not always guaranteed, so an implementation should not rely blindly on notifications arriving in sequence. In a ready-made plugin, some of that logic is hidden from the administrator, but the practical conclusion stays the same: verify the final order status, not just the fact that the customer returned to the page.

If your version of the extension does not include a separate webhook setting in the interface, do not invent one. Work with the fields that are actually available: keys, environment, statuses, debug mode, and method visibility. If statuses update inconsistently, compare the order in VirtueMart, the payment in Revolut Merchant, and the site logs.

Practical Example: A Test Order in a VirtueMart Store

Below is the scenario you should go through before showing the payment method to all customers. It is intentionally built around a typical store setup: one test product, standard checkout, Revolut test environment, an expected order status, and verification on the public storefront.

Goal of the Scenario

You need to confirm that the customer sees the method Pay by card via Revolut, can open the payment widget, complete a test transaction, and that the order in VirtueMart changes status according to your settings. In addition, verify that emails, the invoice, inventory, and order comments do not conflict with the actual payment result.

Preparation

• Create or choose an inexpensive test product that does not affect your real inventory workflow.
• Make sure the product currency is included in the extension's supported list and is configured in VirtueMart with the correct ISO code.
• Enable the test environment and sandbox key in the payment method.
• Select statuses for pending, successful, and failed payment outcomes.
• Temporarily limit the method to a test shopper group if you do not want to show it to everyone.

Test Steps

1. Open the public storefront in a regular browser or a private window.
2. Add the test product to the cart and complete all required customer fields.
3. Select shipping if it is required for the payment method to appear.
4. Select the Revolut payment method and confirm the order.
5. Check whether the widget or payment window opens and whether there is any mixed content or JavaScript error.
6. Complete the test payment according to the sandbox rules.
7. Return to the order result page and check the message shown to the customer.
8. Open the order in the VirtueMart admin panel and compare the status, amount, currency, payment method, and history.

Expected Result

After a successful test, the order should have the selected success status, the amount should match the cart total, the payment method should be listed as Revolut, and the manager should understand whether the order can move forward. If emails are enabled for the selected status, they should communicate the correct meaning: the customer must not receive an "order paid" message if the order actually remained pending.

A Detail That Often Breaks the Test

The payment method may fail to appear not because of Revolut, but because of VirtueMart conditions: the customer's country is not in the allowed list, the selected shipping method does not match the configuration, the order total is outside the allowed range, the user group does not qualify, or the product category is blocked. That is why it is best to leave restrictions empty for the first test and add them one at a time later.

Verifying the Result After Launch

A payment method is not truly launched the moment it is published. It is only ready after several verified orders. You need at least three scenarios: a successful payment, a canceled or incomplete payment, and an order where the method should not appear because of restrictions. That is the only way to know the settings are working by design rather than by accident.

What to Check in the VirtueMart Order

Open the order list and the specific order record. VirtueMart documentation describes the order list as the place where you can see the order number, customer name, payment method, shipping method, date, paid amount, status, and total. For a Revolut-based flow, four fields matter most: status, paid amount, payment method, and comments or change history.

If the order succeeded, the status should match your Success status setting. If the customer canceled the payment, the status must not look like a paid order. If the order is still pending, do not ship it until you verify it in Revolut Merchant. In a disputed situation, compare the amount and currency in VirtueMart with the transaction in the Revolut panel.

What to Check in Revolut Merchant

In Revolut Merchant, verify whether the payment object was created and check its amount, currency, and final status. If you use manual capture mode, confirm separately that the authorization was not left uncaptured. If the order exists but there is no payment, the problem may occur before the widget opens or during payment request creation. If the payment exists but the VirtueMart status did not update, check the return flow, notifications, logs, and status configuration.

Checking the Public Storefront

The payment flow should be clear on both desktop and mobile screens. Check whether the widget overlaps template elements, whether the confirmation button disappears, or whether the customer lands on a blank page after returning. If the store uses a one-page checkout extension, test it separately: these extensions often change the order in which shipping, payment, and customer fields are refreshed.

Launch rule: until you have seen a successful test order in VirtueMart and the matching payment in Revolut Merchant, do not treat the method as ready for real customers.

Currencies, Statuses, and Localization: The Three Areas Where Mistakes Happen Most Often

Revolut Checkout for VirtueMart looks simple while the store runs in one currency, one language, and one standard order workflow. Real stores are usually more complex: multiple currencies, a multilingual site, different shipping countries, separate emails, and custom statuses. These areas are best configured before a full rollout.

Currencies and Amount Formatting

The Ignis.Dev product page lists the supported extension currencies as EUR, GBP, USD, CAD, CHF, JPY, AUD, HKD, SEK, DKK, NOK, NZD, PLN, ZAR. In VirtueMart, a currency has a name, publication state, exchange rate, ISO codes, symbol, formatting rules, and a number of decimal places. For a payment method, what matters is not just a nice storefront symbol but the correct three-letter code and the final order amount.

If the store displays prices in one currency while the payment is sent in another, check the currency settings, the store base currency, conversion rules, and whether your Revolut Merchant account supports the selected currency. Do not add a currency just for storefront display if the payment side does not actually accept it in your scenario.

Statuses and Emails

VirtueMart uses statuses for more than admin filtering. They can affect customer emails, vendor emails, invoice creation, inventory movement, coupon removal, review permissions, and other actions. That is why a successful payment status must match the real next step in your workflow. If the success status automatically creates an invoice and sends an email, make sure that email is not sent for failed payments.

Do not be afraid to use a custom status if your store workflow requires it. But check first which extensions react to it: warehouse tools, accounting, shipping, CRM, or exports to an ERP or bookkeeping system. The payment method may correctly assign the selected status while third-party automation does something you did not expect with it.

Localization of Messages

The Ignis.Dev instructions include one important note: messages, including the post-purchase thank-you message, can be overridden, and the available constants can be checked in the en-GB.plg_vmpayment_ignisdev_revolut_checkout.ini file in the admin language folder. In Joomla, it is safer to use the built-in language override system than to edit the extension file directly.

The practical approach is simple: find the exact language constant, create an override through the Joomla Language Manager, test the text on the order result page, and keep a note for future updates. Do not modify the original plugin file, because that change may be lost during an extension update and hard to find later.

Compatibility with the Template, Cache, and One-Page Checkout

The payment widget runs inside an existing checkout flow. That means the quality of the integration depends on how the template and additional extensions handle the order form. If the standard VirtueMart cart works but a one-page checkout breaks the payment method refresh, the problem may not be Revolut at all - it may be event handling, caching, or a template override.

Cache and Optimization

Cart pages, checkout pages, post-payment return pages, and customer data pages must not be cached like ordinary static pages. If an optimizer combines scripts, defers JavaScript, or caches checkout HTML, the widget may fail to open, the payment method may fail to refresh after shipping selection, and the status may appear incorrect. Start troubleshooting by temporarily disabling aggressive optimization specifically on checkout.

A safe verification sequence is: clear Joomla cache, clear the third-party optimizer cache, exclude checkout pages from caching, repeat the test in a private window, then re-enable optimizations one by one. Do not disable all caching permanently if the problem only affects the cart. The goal is to isolate the dynamic payment route.

Template Overrides

Many VirtueMart stores use template overrides for the cart and checkout. That is normal, but an older override may not account for newer fields, tokens, events, or scripts. If the widget does not open after a VirtueMart update or after installing the payment plugin, compare the behavior with the default template or temporarily disable the checkout override on a test copy.

Do not edit the VirtueMart core or plugin files. If you need visual adjustments, use Joomla or VirtueMart template overrides or your template CSS. If you need to change text, use language overrides. If you need to change payment logic, it is better to work from the developer documentation or bring in a VirtueMart specialist, because ad hoc changes to payment code can create order errors.

One-Page Checkouts

A one-page checkout can change the order of shipping selection, total recalculation, and payment display. If Revolut fails to appear only in that type of checkout, check whether the payment method list refreshes after changing the country, shipping method, and shopper group; whether the template blocks the pop-up window; and whether the payment script loads before VirtueMart creates the order. If the result is unclear, temporarily switch to the standard checkout and compare behavior.

Video Example of the Plugin in Use

The Ignis.Dev product page includes a specific YouTube video demonstrating the Revolut Checkout plugin for VirtueMart. It makes the most sense to watch it after reading the installation and configuration sections. That way, the video does not replace the instructions but helps you visually map the customer path, the payment method choice, and the final order result.

Use the video as a verification reference for the intent cluster "how to use Revolut Checkout for VirtueMart" and "example of paying through Revolut in VirtueMart." If the interface in your store looks different because of your Joomla version, template, or checkout extension, follow the scenario logic instead of copying every screen literally.

If Payment Fails or the Method Does Not Appear

Troubleshooting is best done from simple to complex. First, check whether the payment method is visible in VirtueMart and whether it is published. Then check the display conditions. After that, move on to keys, environment, HTTPS, currencies, cache, and statuses. This order saves time: many issues look like payment provider errors even though the actual cause is a standard VirtueMart condition.

The Payment Method Is Not Visible at Checkout

Symptom: the payment method exists in the admin panel, but the customer does not see it during checkout.

Possible causes: the Joomla plugin is disabled, the payment method is unpublished, the selected country or shopper group does not match, the method is linked to a different shipping method, the order total is outside the allowed range, the product category is blocked, or the cache is showing an old checkout form.

What to Check

• Plugin status in Extensions -> Plugins.
• The Published field in the VirtueMart payment method.
• Restrictions for Shopper Group, Countries, Categories, Shipments, and order amount.
• Clearing Joomla cache and any third-party optimizer cache.

How to fix it: temporarily leave restrictions empty, test the method on a sample product, then add restrictions back one at a time. If the method appeared only after clearing cache, add the checkout pages to your cache exclusions.

The Widget Does Not Open or an Error Appears After Order Confirmation

Symptom: the customer selects Revolut, confirms the order, but the payment window does not open, the page hangs, or a technical error appears.

Possible causes: the wrong environment, an invalid API key, an HTTPS issue, a JavaScript error in the template, a blocked payment script, disabled curl, or a conflict with a one-page checkout.

How to fix it: compare the Environment setting and the key, enable debug mode only for the duration of the test, check the browser console, and repeat the test on the standard checkout or without aggressive JavaScript optimization. If the error points to server-side communication, verify PHP extensions and the site's ability to make external requests.

The Order Is Paid, but the VirtueMart Status Does Not Change

Symptom: the payment looks successful in Revolut Merchant, but the VirtueMart order stays pending or remains in the old status.

Possible causes: the Success status is configured incorrectly, the site did not receive or process the notification, the customer did not return to the result page, cache or security is blocking the callback, or a third-party extension changed the status after the plugin did.

What to check: the order history, the statuses selected in the payment method, Joomla logs, server logs, security settings, and any third-party extensions that react to status changes. Compare the transaction time in Revolut with the time of the last order update.

When to roll back: if real orders remain pending, temporarily unpublish the method or restrict it to a test group until you find the cause. Do not ship an order based only on the customer's word without checking the payment.

The Payment Is Declined During 3D Secure or SCA

Symptom: the customer reaches the confirmation step, but the transaction does not complete.

Possible causes: the customer's bank declined the check, the card is not suitable, the customer closed the confirmation step, the test card does not match the sandbox scenario, or the amount or currency is rejected on the payment provider side.

How to respond: verify the payment in Revolut Merchant, do not manually change the order to a success status without confirmation, and ask the customer to try again or choose another method if one is available. If the issue is reproducible across different cards, go back to your key, currency, and environment settings.

After Payment, the Customer Sees a Confusing Message

Symptom: the payment goes through, but the thank-you text, error message, or message language is not appropriate for the store.

Possible causes: the extension's default language strings, the wrong site language, missing Joomla overrides, or a checkout template that renders the message somewhere other than where the administrator expects it.

How to fix it: find the language constants in the en-GB.plg_vmpayment_ignisdev_revolut_checkout.ini file, create a standard Joomla language override, and verify the result with a test order. Do not edit the extension file directly.

When Revolut Checkout for VirtueMart Is the Right Choice

Revolut Checkout for VirtueMart is worth using if your store already runs on Joomla and VirtueMart, your business is ready to accept payments through Revolut Merchant, and you need a manageable payment method with a widget, a test environment, configurable statuses, and a clear customer path. The strength of the extension is not a huge number of settings, but a precise connection: the VirtueMart order, the Revolut payment widget, the transaction result, and the status update.

Before you download Revolut Checkout for VirtueMart, verify three things: your site can process regular orders reliably, your currency and region match your Revolut Merchant setup, and your team understands which statuses trigger emails, invoices, and order processing. If those conditions are in place, the extension can be tested in a controlled sequence: installation, test environment, one product, one successful and one unsuccessful order, then verification in VirtueMart and Revolut.

If the store is still unstable, the checkout has been heavily modified by a third-party extension, or the business needs local payment methods that are outside the Revolut scenario, do not rush it. First, stabilize the cart and the status workflow, then compare nearby payment solutions. A good payment method should do more than appear in a list - it should become a reliable part of your order process.