OS EB Molpay - Joomla Extension

OS EB Molpay: Configuring Payments for Events Booking Registrations

This guide looks at OS EB Molpay in its intended role: an add-on payment plugin for the Joomla component Events Booking, not a standalone event directory, registration form, or seller dashboard. It connects a payment route to a paid registration that has already been set up. A working payment flow therefore depends on several pieces: the event and its price, the list of published payment methods, the seller account with the payment provider, the response after a transaction, and the attendee’s status in Events Booking.

We’ll cover how to assess whether this older extension is still suitable, install it in Joomla, enable the required method in Events Booking, and test the full flow from the event page to a paid registration. We’ll also look at what to do with an incomplete payment, how to test a visitor’s return safely, and how to distinguish a plugin issue from an incorrect price, a hidden menu item, or an unreachable callback address. Check the exact settings against the installed OS EB Molpay build: the available public listing does not specify the form fields or the protocol used by that version.

The Molpay name refers to a payment service that has gone through several rebrandings. Provider materials use Razer Merchant Services and, more recently, Fiuu. These names can help you match an older integration to the seller dashboard, but they do not prove that the 2016 OS EB Molpay package works with every current account or provider interface. This guide explains how to evaluate the integration; it does not guarantee that the older package is still maintained or works without an update.

What the payment plugin adds to Events Booking

Events Booking stores events and registrations. In a typical visitor flow, someone opens an event, chooses an individual or group registration, enters their details, and selects an available payment method. The payment plugin then connects the registration to the selected gateway. The OS EB Molpay extension listing identifies Molpay as its target gateway. The plugin should not manage events itself: dates, capacity, descriptions, registration fields, and attendee lists belong to Events Booking.

This division of responsibility helps when troubleshooting. If OS EB Molpay is missing from the form, first check that the plugin is installed and published in Events Booking’s payment methods. If a visitor can select it but never reaches the payment page, check the integration settings, merchant details, and site availability. If the seller dashboard shows a completed transaction but the registration is still pending, the issue may be with how the payment response is handled, rather than with the event form. Each stage has its own observable signal; reinstalling the plugin to fix every kind of failure often just adds uncertainty.

Where the event, registration, and payment meet

The event defines what the visitor is registering for and how much it costs. The registration form collects details about the attendee or group. Events Booking creates a registration and associates it with a payment method. The payment plugin sends the required information to the provider and should report the outcome to the component. The provider accepts or declines the payment, and Events Booking updates the attendee’s registration. In a real integration, a visitor may close the browser before returning to the site, so the visitor’s return and the payment system’s server notification should not be treated as the same signal.

This distinction matters especially when visitors are sent to an external payment page. A return confirms that the browser opened the site again, but it does not always confirm that the payment was completed. A reliable payment flow must validate the response against an accepted status and the specific registration. Provider materials describe separate browser return and server notification endpoints; Events Booking materials describe how a registration moves from pending to paid after successful confirmation. However, the available information does not show which of these mechanisms a particular OS EB Molpay build implements. Do not blindly copy callback URLs from another shopping cart or a newer integration into this package.

Key check: The successful transaction in the payment provider’s dashboard and the "Paid" status for the correct attendee in Events Booking must refer to the same transaction. A screenshot of a "Thank You" page is not enough to verify the payment.

When it may be a good fit

Consider the plugin if your site already uses Events Booking, your seller account supports the relevant payment service, and the installed OS EB Molpay build is officially supported with your Joomla and Events Booking versions. It is particularly suited to paid seminars, courses, conferences, and meetups where attendee records need to remain in the event directory and payment is part of registration.

Look at another solution if you are still choosing an events component, your bank or regional provider is no longer supported through the current seller account, you need modern payment methods that the available plugin does not confirm it supports, or you cannot test the integration safely. It is also the wrong tool for selling arbitrary products, subscriptions, or donations: it is designed to work with Events Booking, not a general-purpose shopping cart.

Before installing: verify the version, seller account, and payment flow

The public OS EB Molpay listing gives a brief description and shows an update date from an earlier generation of Joomla. It currently lists several compatible Joomla generations, but that listing does not identify the specific ZIP package or explain which Events Booking versions it was tested with. For a payment integration, this gap matters more than a minor visual mismatch: an incorrectly handled response can leave someone without a confirmed place, trigger an ambiguous second payment, or require manual reconciliation.

Before downloading the package, make a brief dependency checklist. Record the exact Joomla version, the installed Events Booking version, where the plugin file came from, the package name and date, the developer’s support status, and the provider name in the seller’s current agreement. If the dashboard now says Fiuu while the package and its instructions say Molpay, do not assume the older protocol automatically matches the current service terms. Ask the integration provider a specific question: can the current account accept the messages and formats sent by this OS EB Molpay release, and who is responsible for maintaining the extension?

Check the existing components separately

You need a working Joomla and Events Booking installation, an HTTPS certificate on the site, a published event with a nonzero price, and registration enabled for that event. Events Booking requirements call for HTTPS when visitors enter payment details directly on the site. The data flow may differ for redirect-based payments, but HTTPS is still needed to secure the admin session and support reliable returns. Do not disable site security on the live domain just to "see if" the payment route works.

Make sure the test site is publicly reachable if the payment provider needs to contact it directly. A local copy behind a password, a restricted preview, or an IP allowlist may block an external request even when the form works. You do not need to open the test server to everyone, though: use only an access method supported by the provider, and remove any temporary access after testing. Do not copy production secrets to the test site without direct authorization from the person responsible for the merchant account.

Gather the required details, but keep them out of plain-text notes

Depending on the integration generation, the payment dashboard may provide a merchant ID and one or more keys for verifying a signature or request. A third-party Razer Merchant Services tutorial lists a Merchant ID, Verify Key, and Secret Key, but it covers a different integration and does not prove that OS EB Molpay uses the same fields. Enter only the details shown in the installed plugin’s actual form and specified in its own instructions. Do not invent fields or paste secrets into public pages, email, screenshots, or code examples.

Decide in advance what counts as a successful registration: which attendee ID you will look up, where you will see the payment status, who receives a notification, which email should arrive, and whether an electronic ticket is required. Record the test amount, currency, event, test time, and transaction ID in a private log without secret keys. This log will help distinguish "the provider confirmed the payment" from "the registration processed the notification" and will make it easier to request support about a specific transaction.

If current requirements for a particular bank, supported payment channels, currency, refunds, or response times are critical, confirm them in the seller dashboard or provider agreement. A listing for an older Joomla plugin is not a current pricing or technical agreement.

Install OS EB Molpay in Joomla and run an initial check

In Events Booking, an add-on payment plugin is installed from the component’s own payment methods area. This is different from installing a standard Joomla extension through the general extensions screen. According to the Events Booking instructions, an archive upload area appears at the bottom of the payment methods list: an administrator selects the file and starts the installation. The plugin should then appear in the list, where it can be opened, configured, and published.

1. Back up the site files and database, and do the initial installation on a copy or staging site running the same Joomla and Events Booking versions.
2. In the Joomla administrator panel, open Events Booking and go to Setup, then Payment Plugins. In some builds, the same screen is available from the component dashboard or through Components; the exact menu depends on the version.
3. Scroll to the payment plugin installation area at the bottom of the page, select the OS EB Molpay ZIP package, and start the installation.
4. Return to the list and find the Molpay row. Open it, review the available settings, and confirm that the form saves without a Joomla error.
5. Publish this payment method only when you are ready to test the full flow. If the site uses other methods, leave them as they are so you do not disrupt the existing visitor flow.

Installation, publication, and a successful transaction are three different outcomes. A successful installation message confirms only that Joomla accepted the archive. A published row means Events Booking can offer the method, subject to the other settings. A full transaction test is needed to verify the handoff and attendee status update. If the file installs but no row appears, do not upload the package repeatedly. First review Joomla’s message, check that the ZIP is the type expected by the Events Booking installer, and find out whether the archive is meant for a different Joomdonation product.

Safely roll back a failed installation

If installing on the staging site causes an error or changes how other methods behave, first disable OS EB Molpay in the component list and compare the registration flow before and after. Restore the backup of the database and files if needed. Uninstalling an extension does not always undo every change if the package created tables, settings, or log entries, so a pre-installation backup is more reliable than counting on an "Uninstall" button.

Do not edit Joomla, Events Booking, or payment plugin core files to work around an incompatibility. An undocumented change may break during an update and make transaction troubleshooting harder. If a specific PHP error points to an outdated class or interface, record the exact message without secrets and send it to the developer. Until it is fixed, use a confirmed payment method that is supplied and supported for your version.

The event and form determine whether payment is offered

OS EB Molpay is not enabled independently of an event. Events Booking first determines whether someone can register, what the registration costs, which form to show, and which payment methods are available. The payment plugin may be installed correctly but not appear if the event is free, registration is disabled, the registration period has ended, capacity has been reached, or the visitor does not have the required access level. When configuring payments, check the event first, then the form, and only then the gateway settings.

Match the price to the registration type

For an individual registration, the price usually applies to one attendee. For a group registration, Events Booking may ask for the number of places, details for each attendee, and the payer’s billing information. Depending on the configuration, the component can collect information about every group member or only about the person submitting the registration. Before testing, make sure the form type matches how you actually sell places. For one place per person, enable individual registration; if a manager is registering several employees, test the group form separately.

Set the price and number of places before redirecting visitors to an external payment page. For example, when testing a group of three, compare the total with the amount shown on the form, not with the price for one person. A group discount, paid field, or rate for multiple ticket types can change the total. Enable these one at a time and record the expected amount. If the payment form receives the wrong amount only for group registrations, do not change the plugin’s price: first check whether Events Booking calculated the fee correctly before sending it to the gateway.

Registration fields also affect the payment experience, even though the plugin does not create the form. Collect only the details needed to run the event, process the payment, and contact the attendee. Extra fields make long forms more likely to be abandoned and complicate follow-up. If you need to collect information about dietary requirements, job title, certificates, or add-on services, create the field in Events Booking and check that it appears on the right event. Any extra field charge should be visible before the visitor selects a payment method; otherwise, they may see a different amount elsewhere and abandon the process.

Capacity and the waitlist affect what Pending means

A pending payment status is more than a technical flag. For an event with limited capacity, it may temporarily hold a place, affect whether another person can register, and trigger an email. Before publishing the event, decide how long an incomplete registration stays in the system and when its place becomes available again. If you enable cleanup for these records, set the time limit based on the usual bank redirect time, support availability, and event rules. Do not choose a short timeout just to keep the attendee list tidy.

A waitlist and a pending payment are different situations. A pending payment means the person has started registration or needs to finish paying; a waitlist means standard capacity is full and the person has not become a regular attendee. Do not combine these statuses in a notification. Before testing a full event, add one pending registration, then check that the next visitor sees the route you intended: the waitlist, a registration-closed message, or another event date.

If Events Booking is configured to move people from the waitlist automatically when an attendee cancels, test the new registration status and the timing of the move separately. These features are not part of OS EB Molpay’s payment handling, but they affect availability: a person may become eligible to pay after a place opens up. If the order of invitations matters, do not enable automatic cleanup and automatic waitlist promotion at the same time until you have tested the notification sequence.

Make sure the Joomla menu item and access level lead to the same registration

Events Booking offers several ways to show upcoming events: a menu item for an event list, category, individual event, or registration form. In Joomla, these items can be assigned to a specific menu and access level. A routing issue can look like a payment plugin problem: an administrator tests a direct URL and sees the method, while a visitor arrives through the main menu and gets a different event, form, or restricted page.

Check the menu item using the same role and language as a visitor. Make sure it uses the correct Events Booking menu item type, points to the intended category or event, and is published in Joomla. If the page is restricted to registered users, it may be accessible to an administrator in the panel but unavailable to an actual attendee. To test payments, open a new private browser window, do not sign in as an administrator, and follow the route from the first public page instead of using a saved link from an earlier session.

Keep the site’s languages in mind. Translated method and event names are part of the user-facing interface. They do not create a separate merchant account or change the technical payment route. Check that the email uses the same language as the form and does not expose internal code names such as os_molpay unless that identifier is meant for visitors. Do not change the method label through Joomla’s translation system until you know where Events Booking stores it and which translation mechanism your build uses.

Test the flow as a guest: Joomla menu → event list or page → selected registration form → available payment method. If an administrator sees a different page, resolve the menu and access-level mismatch before testing the gateway.

How the payment flow works: event, method, gateway, status

It helps to think of a registration as a sequence of states, rather than as a single "Pay" button. First, the event must allow registration and have the correct price. The visitor fills out the form, and Events Booking creates or prepares a registration record. OS EB Molpay hands control to the payment provider. After the visitor uses an available payment method, the provider returns a page or notifies the server of the outcome. Finally, Events Booking must match the response to the expected registration and save the correct status.

The flow may vary between payment methods. For example, Razer Merchant Services integration materials distinguish browser returns, server notifications, and callbacks for specific use cases. The available OS EB Molpay listing does not publish handler names, signature details, URLs, or the required confirmation format. The flow above is therefore a safe model for testing, not a description of the older extension’s undocumented implementation. Do not create a callback URL by copying another plugin or enter a random address from instructions for a different CMS shopping cart.

Publication status and method order

Events Booking lets you publish or unpublish payment plugins. If visitors should not use a method, it is safer to unpublish it temporarily than to leave it on the form and hope no one selects it. This is reversible: you can enable the method again when it is ready. The order also affects the default selection on the registration form: according to the component’s documentation, the first method in the list is selected first. Before rearranging the list, check that it will not disrupt the main payment flow for other events.

You can change the method name shown to visitors and localize it through the Events Booking translation mechanism. Do not use a label that promises a payment option that the seller account does not enable. If the method has a simple label such as "Bank Payment," add a clear explanation to the event or form only if your version supports it. After changing the label, check the actual registration page in every language version.

What general provider guides cannot tell you

Materials for current RazerMS/Fiuu integrations show that a payment may involve a Merchant ID, keys, a list of allowed payment channels, and several result URLs. That is not a confirmed list of OS EB Molpay fields. Products from the same company may use different protocol generations, signature formats, settings screens, and redirect flows. Copying a setting from a current guide may not help and, worse, could send a notification to the wrong place.

Use the provider dashboard to check the merchant account status, permitted methods, and details issued specifically for the Events Booking integration. Then compare them with the fields in OS EB Molpay and the instructions for your package version. If they do not match, stop before enabling live payments and contact the integration provider with the archive name, Joomla version, Events Booking version, and list of field names, without their secret values. Do not send a full configuration export containing keys.

Do not change the registration status manually before reconciling the payment. If the gateway accepted the funds but Events Booking still shows a pending status, check the transaction amount and ID in the dashboard. Only after reconciling them should you decide whether to reprocess the notification, change the status manually, or issue a refund.

Configure the plugin after installation

Start configuration by answering four questions, not by guessing what belongs in each field: who owns the merchant account, which environment will be used for testing, which methods are enabled for the seller, and how Events Booking recognizes a successful payment. The names and number of settings in OS EB Molpay may vary by release. The steps below show how to verify them without inventing fields that are not documented publicly.

1. Check the merchant account and account name

Open the seller dashboard and confirm that the account is active, belongs to the legal entity named on the site, and is set up for the required transactions and market. If the account was created as Molpay, later became part of Razer Merchant Services, and the interface now says Fiuu, ask the person responsible for the merchant account to confirm whether the old keys and protocol still work with your integration. The provider’s dashboard name does not automatically update the plugin listing.

Enter only values explicitly identified in the instructions for the installed plugin release. Do not put similar-looking keys into the wrong fields, change their capitalization, or add spaces when copying them. After saving, reopen the form and check that the settings were stored. Do not share a screenshot of the fields, even if the secret appears masked: sensitive details could remain in the admin URL, browser notifications, or somewhere else on screen.

2. Keep test and live configurations separate

If the installed build explicitly supports a test mode, start there and use only the test keys issued for that environment. Do not assume OS EB Molpay has a test mode just because PayPal or a newer gateway plugin does. If the form has no environment setting, do not look for a hidden switch in the files. Ask the developer how to test this specific package, and do not make a real payment until you have an answer.

Keep the test site separate from the live site, but reproduce its setup as closely as possible: Joomla and Events Booking versions, template, menus, and HTTPS settings. Create a separate event with a small, clearly identified test price, mark it as private, and restrict access with Joomla’s built-in controls. Remove the test event from the main menu when testing is complete. If you use a separate merchant sandbox, do not copy its keys to the live site.

3. Match the currency, price, and displayed amount

Set the event price in Events Booking, and confirm that the seller account supports the available currency and payment channels. Check that the site currency matches the currency accepted under the merchant agreement. The available OS EB Molpay documentation does not list supported currencies or guarantee automatic conversion. Do not rely on how the amount looks in the form: verify the exact format, decimal separator, rounding, and total in the payment dashboard.

If the registration form supports group bookings, promo codes, deposits, or paid fields, the total may be calculated differently than for a simple individual registration. Turn off optional price adjustments for the first basic test. Compare the price per attendee, number of attendees, tax, or additional line item, if your setup uses them, with the amount in the payment request. Then test the more complex flow separately: one successful payment at a basic price does not confirm that every combination is calculated correctly.

4. Check publication and the method’s position in the list

Find OS EB Molpay in the payment methods list, open its form, save the settings, and check its publication status. If visitors should see the method, it must be published; if it is still being tested, leave it disabled on the live site. The list position determines which method is selected by default, so choose the order deliberately. Do not reorder the other options until you have checked the forms for all event types.

On a multilingual site, check the translated display name separately from the payment settings. Translating the label does not change the method code, account, or payment flow. After changing the language string, open the registration page in each language and make sure visitors understand where they will be redirected and what they need to do. The label must not promise card, digital wallet, or local bank support unless the merchant account enables that channel.

5. Verify the domain, HTTPS, and return flow

The payment dashboard may require a registered domain or return address. Use only addresses generated or officially confirmed by the installed plugin. Check that the main site domain uses HTTPS, the certificate has not expired, and Joomla does not redirect visitors between different domain variants, such as www and non-www, after a transaction has started. A mismatch in scheme, domain, capitalization, or path can sometimes send a visitor back to the wrong page even when the gateway recorded the transaction.

If the provider offers a separate server notification URL, do not treat it as the post-payment page URL. One is for the visitor-facing flow; the other carries status between systems. RazerMS materials distinguish these roles. The integration developer must provide the path and format for OS EB Molpay. If the plugin form does not explain which addresses to register, do not guess.

6. Save the settings and test without exposing secrets in logs

After making changes, save the plugin record, leave the form, and reopen it to confirm that the visible settings are still as expected. If the plugin version has a built-in exchange log, enable it only on the test site and only if you know where it is stored, who can read it, and whether it is removed automatically. Payment logs must not contain full card numbers, CVVs, dashboard passwords, signing keys, or data that is not needed for troubleshooting.

Record configuration details by name, such as "test environment," "method published," "currency set," and "return address matches," without recording any secret key value. If an error appears after saving, capture only the safe part of the screen or copy the message text. Disable the method if you suspect the live keys are incorrect, and do not retry the payment until you know whether a transaction was already created.

Example: paid registration for a one-day seminar

Imagine a small association hosting an in-person seminar with limited capacity. The organizer wants to keep the attendee list in Joomla, collect names and work email addresses, accept payment through a Molpay/Fiuu merchant account, and send confirmation after payment is actually completed. This example does not assume OS EB Molpay supports any particular payment channel: the seller agreement determines which channels are available, and the extension must be tested in the relevant environment.

Goal and preparation

The goal is one attendee record linked to one event and one confirmed transaction. Before testing, Events Booking is installed, a "Seminars" category has been created, the event menu item is configured, and the payment method has been tested on a copy of the site. The organizer has test access to the provider dashboard and written confirmation that the installed plugin build is current. The event has a clear title, date, short description, price, and registration type.

Do not begin the test until you know who will verify the outcome. One person can monitor the seller dashboard and another the attendee list in Events Booking. If one person is doing both, open two tabs in advance and note the start time. For group registration, choose one mode ahead of time: collect details for each attendee or only for the payer. That choice affects the registration data and should not change in the middle of the payment test.

Step 1. Set up the event and the route to its form

In Events Booking, open the event list, add a test event, and fill in the details visitors need: title, category, date, short description, and full description. Confirm that the event is published, registration is enabled, capacity has not been reached, and registration is still open. Create or use a Joomla menu item that shows the list of upcoming events. For a direct test, you can add a menu item to the registration form for a specific event if your version offers that item type.

First, open the page as a regular visitor without administrator access. Confirm that the event listing is visible, the date and price are clear, and the registration button leads to the form for that event. An administrator may see content that is hidden from regular visitors, so testing only while logged in will not reveal an access-level issue. If the menu item is restricted to a Joomla user group, check its access assignment and menu item settings.

Step 2. Confirm that the method appears on the right form

On the test site, go to Events Booking - Setup - Payment Plugins, check that OS EB Molpay is published, and review the settings confirmed for your version. Then fill out the registration form with a test name and email address, select the intended method, check the displayed amount, and only then continue. If the method is missing, stop before entering payment details. Check the event price, method publication status, registration type, and event restrictions.

For a group registration test, compare the number of attendees with the total amount and expected registration details. If you are unsure how the plugin sends the group size in the payment request, do not proceed with a real payment; ask the developer how this version handles it first. An individual registration is usually simpler for the first end-to-end test because it involves fewer variables.

Step 3. Run the test without ending the flow too early

Continue with the payment only in the agreed test environment. Record the registration number shown by the system, the time, and the test payment ID, but do not record card details. Complete the test through the provider dashboard as instructed, then return to the site normally. Do not refresh the payment page repeatedly or click Back until you know the transaction status: resubmitting the request may create a duplicate.

In the Events Booking admin panel, open the attendee list for the event, find your test registration, and check its status, method, and transaction ID if those details appear in the list or record. Match the registration to the test transaction in the dashboard. Then confirm that the confirmation is sent only after the event that counts as a successful payment in your setup.

Step 4. Check the email and what happens after a failure

Run a second test using a decline or cancellation in the test gateway, if that option is available. Confirm that Events Booking does not mark the registration as paid or send an email confirming the attendee’s place. Check whether the record stays pending, whether it is removed according to your settings, and whether an administrator can send a payment request again. Do not simulate a decline by cutting off the connection on the live site; that is not a substitute for an official test transaction.

After testing, delete or cancel the test registration using the standard procedure, disable the test menu item, and turn off the test method on the public site. If the test gateway has kept transaction records, retain them as a test log. A brief test summary should answer five questions: the form is visible, the method can be selected, the amount matches, the gateway accepts the request, and Events Booking saves the expected status and sends the right notification.

Verify the outcome after configuration

"The payment went through" is too vague for accepting an integration. Record the visitor-facing outcome, the payment system outcome, and the Joomla outcome separately. The visitor should see a clear status without having to click again. The seller dashboard should show the final status expected from the provider. In Events Booking, the specific registration should have the corresponding status, and the attendee list and emails should agree.

Do not check only whether an email arrived. It may have been sent when the registration was created rather than after payment, or it may have gone to spam. Events Booking provides notifications for registrations, payment failure messages, and confirmations; the specific templates and send times depend on the configuration. On the test site, read the email as an attendee and check its subject, amount, event name, date, language, and instructions for an incomplete payment.

Check the front end in a clean browser window, preferably in a separate session without Joomla privileges. Page cache may show an old form state, but it should not be used to explain a mismatch in payment status. If the method is still hidden after publication, clear the component and page cache only after checking the URL, publication status, and menu item. Do not clear database cache tables manually.

Do not treat a browser return as proof of payment. Check the provider’s final status and the corresponding Events Booking record. If they do not match, pause repeat payments and investigate before trying again.

Incomplete payments, repeat requests, and manual reconciliation

Even without a technical error, a visitor may change their mind, close the window, fail to complete a bank login, or receive a decline. Events Booking distinguishes these cases with registrations that may remain pending. The component documentation describes a way to email an attendee a payment request again from the attendee list using Action - Request Payment. The email lets the attendee continue payment for the existing registration instead of filling out the same form again.

This feature is useful only after you have checked the registration. Find the attendee by name, email, event, and time. Confirm that they have not already paid in another window and that the provider does not show the payment as still processing. If the payment has already cleared, do not send another request just because the visitor’s return was delayed. Check the transaction in the dashboard, verify that the notification was handled, and only then decide whether to change the status manually.

When to leave a registration pending

If the seller dashboard shows no completed transaction and the attendee says they closed the page or saw a decline, the registration can remain pending until they finish paying. An administrator can use the built-in payment request feature. The email should explain which event needs to be paid for, where the attendee should return, and how to ask for help. Do not send several nearly identical messages in a row: the attendee may open an old link or start a second payment.

If the site is configured to clean up incomplete registrations on a schedule, decide the operational rule before changing the time limit: how long a place can be held without payment, how the organizer will contact the attendee, and what happens if the event fills up. Events Booking documents a separate task for removing incomplete online payments after a specified number of days. This applies to the component itself and does not confirm how OS EB Molpay handles every type of decline.

When manual reconciliation is needed

If the dashboard shows a successful payment but Events Booking still shows pending, do not change the status until you have checked the amount, currency, transaction ID, and registration. Save a safe transaction record from the dashboard without the full card number, and find the attendee entry. If the discrepancy appears to involve a callback, ask the developer to check delivery and response handling. Then agree with the organizer whether the place should remain reserved while the status is investigated.

If an attendee says their funds were charged but the seller dashboard has no matching payment, do not immediately ask them to pay again. The bank may be slow to show the transaction, the authorization may be incomplete, or the payment may have gone to another merchant. Have the responsible person verify it through the seller’s official support channels. Neither a Joomla email nor a screenshot of the attendee page replaces bank confirmation. Record the time, amount, currency, and safe transaction ID in the incident log so you do not have to search by name alone.

A deposit and balance require separate business rules

Events Booking has its own deposit feature: an event can have a fixed deposit or percentage, and a registered attendee may choose to pay part or all of the amount. The balance is collected later. Do not assume a particular OS EB Molpay version handles deposits correctly just because the basic test passed. First confirm that the payment plugin supports the partial payment type you use, run a separate deposit test, reconcile the balance, and configure emails and reminders so the attendee understands what has been paid and what remains due.

A deposit test should show the initial payment, remaining balance, registration status, and method for making the next payment. If the balance is collected manually, an administrator confirms receipt and updates the registration. If payment is made through the site, check that the link opens the existing registration and that the amount matches the remaining balance. Do not set up a deposit for a paid event until you have tested cancellation, refund, and repeat payment flows.

Good practices for support, recordkeeping, and security

A payment method handles attendees’ personal information and financial reconciliation, so plan support access in advance. Give seller dashboard access only to staff who need it. Do not give event volunteers general access to the Joomla administrator panel just so they can check one payment status. Use separate roles and permissions in Events Booking and Joomla to give staff the minimum access they need, if your setup supports it.

Keep a working log with the date, event code, registration ID, amount, currency, method name, and a safe transaction ID. Do not include keys, passwords, full card details, or attendee documents that are not needed to resolve the issue. If you need a screenshot of an error, hide email addresses and personal fields while keeping the section name and technical message visible. Review the attachment again before sending it to the developer.

Avoid changing critical settings during an event

When registrations are already open, do not change the primary domain, payment methods, price, currency, and form all at once. During an incident, preserve the current details, temporarily pause new payments through the affected method, and tell attendees how to contact the organizer. Once you identify the cause, make one change at a time and test it with a separate registration. That makes it easier to connect an improvement or new problem to a specific setting.

If the registration template or translation changes after configuring the plugin, repeat the test on the actual event route, not only the home page: list, description, individual form, group form, external redirect, and return. In Joomla, menu items and access levels can create different URLs for the same item, so your test should follow the route visitors will actually use.

Set clear cancellation and refund rules separately

Paying for an event place does not automatically cancel the registration if someone withdraws. Before launch, decide who can approve a refund, how the provider records it, and who updates the registration status. Check which operations your version of Events Booking can record directly and which are done in the seller dashboard. Do not promise automatic refunds on the event page unless the integration supports them.

For a refund, verify the original payment ID, amount, currency, and attendee. Then check how the place is released and what happens to emails, tickets, and the registration list. If partial refunds are available, test them in a test environment first and confirm they do not put the whole registration in the wrong state. OS EB Molpay documentation does not describe a built-in refund screen, so do not attribute refund features to the extension without confirmation.

Treat an update as a migration

When Joomla, Events Booking, or the provider is updated, the payment plugin becomes part of the migration risk. Before changing versions, back up the files and database, record a successful test transaction, and review the main component’s changelog. If there is no confirmed release of OS EB Molpay for the new setup, ask the developer for details; an Events Booking update does not automatically update an add-on extension.

After an update, repeat the full safe flow: event, individual registration, test amount, handoff, dashboard status, attendee status, and email. If the provider rebranded or replaced the old merchant API, confirm that backward compatibility remains. If you cannot get a clear answer, keep the current configuration unchanged until testing is complete, and do not use it for live transactions.

Going live: control changes and prepare for failures

Enabling the method on a live site is different from testing an installation: visitors can start registering as soon as it is published. First record the site’s current state: the Events Booking version, published payment methods, menu item that opens the form, and events already accepting registrations. Make a backup and identify the person responsible for enabling the method, along with someone who can verify transactions in the seller dashboard. Then change only settings that have been tested in the test environment.

Make a short launch checklist

1. Confirm that the exact OS EB Molpay archive and current Events Booking version passed testing on a copy of the live site.
2. Check that the live credentials belong to the live environment and that test data has been removed or isolated.
3. Verify the primary HTTPS domain, event menu, price, and guest access to the form.
4. Publish only the required method and confirm that existing payment methods are still available.
5. Assign someone to monitor the first registration and reconcile it manually if the status does not update.

This sequence minimizes the number of settings changed at once. If an error appears after launch, you can identify the step where it started. Do not change the domain, price, currency, method label, and payment method order all at once: even if the flow improves, the team will not know what caused the change or how to reproduce a safe configuration.

Provide a backup payment route without making unsupported promises

For an event that is already accepting registrations, it helps to have an agreed backup registration method. This could be another published Events Booking method or a manual invoicing process, if the organizer can support it. Explain the backup route clearly to attendees: whether they need to wait for confirmation, how long a place will be held, and who can answer payment questions. Do not publish a second payment option "just in case" if no one is monitoring its reconciliation and confirmation.

Before enabling a backup method, check that it will not create two competing records of the same transaction. If an attendee first sends a bank transfer and then pays through the online gateway, the organizer needs a way to spot the duplicate and cancel the extra registration or return the funds. Joomla statuses and the seller dashboard must be considered together. If several payment methods are available, give staff a short reference that lists each method, where to check it, and who is responsible.

Resolve the first ambiguous transaction before moving on

If the first transaction gets stuck after launch, do not keep testing with live customers while the cause is unknown. Stop new attempts through that route while keeping a way to contact the attendee. Reconcile the specific Events Booking registration with the transaction in the seller dashboard, check that the site is reachable from outside, and contact integration support. A browser return in the log does not prove that the server notification arrived. If the dashboard shows an in-progress status, do not mark the registration as paid before the provider confirms the final status.

After fixing the issue, repeat the check in the test environment and record the outcome. Resume registrations only when you know what should happen and have a clear procedure for attendees who were already affected. When a visitor returns to the live page, show only information confirmed by the transaction status. Do not display "Successful" if the handler has not received the provider’s final status.

Prepare a safe support request

A good support request saves time when it includes precise details without sensitive credentials. Include the Joomla, Events Booking, and OS EB Molpay versions; archive name; method name in the admin panel; transaction time and time zone; registration ID; safe transaction ID; amount; and currency. Copy the exact error message and say how far the visitor got: form, handoff, payment page, return, status update, or email.

Do not attach the Merchant ID together with keys, a full database dump, configuration contents, a full card number, or passwords. If a specialist needs to check a secret setting, use only an agreed secure channel and provide the minimum access required. Do not create a temporary Super User account or send its password by regular email without an agreed procedure. After troubleshooting, revoke temporary access and confirm that test keys are not left on the live site.

When OS EB Molpay is suitable for a live site

Consider OS EB Molpay if your site already uses Events Booking, you have an active account with the required payment provider, the developer confirms that the specific plugin build is compatible, and an end-to-end test confirms that the amount and registration status match. In this setup, the extension has a limited job: offer visitors an appropriate payment route and return the outcome to the attendee management flow.

If the build has not been updated in a long time, the provider has moved to a new platform, the exact confirmation flow is unknown, or you do not have a test environment, do not switch the extension straight to live mode. First confirm compatibility, then test one registration, a decline, the visitor return, and manual reconciliation. After that, you can enable the method, keep a backup payment option, and check transaction records periodically. When you are ready to review the installed package and access the extension file, use get the OS EB Molpay file on the product page.