Hi Bertrand,

Firstly, I would like to sincerely apologize for the delayed response as we have been experiencing an unusually high number of tickets. I am sorry that it has taken longer than usual to respond to your concern and your patience is highly appreciated.

-

Thank you for that Video, it clearly shows a serious issue.

We need to conduct some Tests on our end with our QA Team to confirm if we can reproduce the same behaviour - in that case we will flag it as a bug and make a high priority task for our developers to build a fix;

Or if we are unable to reproduce it on our testing, that means it is an isolated issue on your Site, and we can help you debug it as quickly as possible.

While we do our tests, it is best to save time if you can grant us remote Admin access;

if we need to inspect how you set everything up on your Site - that can save us some time to configure it in a similar way for our Test, if that is OK?

Please provide me a temporary WP-admin (administrator) user for your website where this happens, 

as well as FTP credentials and access to the database ( either link with credentials for PHPmyAdmin, or access to Hosting Panel),

so we could log in and take a look ‘from the inside’ as that’s the most efficient way to see and resolve the issue. 

We do not interfere with any data or anything else except for the plugin (in case that’s a production version of the site), and of course, we do not provide login data to third parties. 

You can write credentials here just check PRIVATE Reply so nobody can see them except us.

In the meantime, we are also doing a test what happens if we try to close the window in the middle of Mollie Payment Process after booking redirection, going to let you know the results.

Thank you.

Hi Bertrand,

I also just want to add, considering your other ticket where you reported  an additional issue with our Mollie integration and Klarna, i will advise you in general in full honestly, my personal opinion on the matter.

We did have some issues with Mollie integration before, in terms of the "pending" payment status and how it gets recorded in our system.

 For example, sometimes if the waiting time for processing with Mollie payment took too long,

 Amelia would  get false responses from it, such as : 

1. sometimes an appointment does not get created at all, when it should have;

2. and sometimes failed appointments would be set as paid.

So, our developers changed that behaviour to become like this now, pending, and it is the safest way for the time being, in order to avoid said issues.

But we did not encounter this issue you reported now - we have not tested what happens if a Customer closes the window in the middle of Mollie steps for the Payment. ( For that we will still do our best to isolate if it's a bug , and if it is - our devs will work to build a fix)

-

- We will work to improve everything for Mollie in general in the future, but we can't say an exact ETA on it.

You can certainly follow our changeLog page if you'd like, where we state any changes/new features/bug fixes during updates;

and our newsletter, so you're informed about new features, bug fixes, freebies, etc.

-

So, for the time being, we are going to test all of this and i will keep you posted if this specific issue you reported is a bug or not;

but my personal advise if you wish to save time, the choices you have :

You would either have to proceed with Mollie payments like this, if the payment hangs for too long, it becomes pending, then somebody from your end, such as Admin, Manager or employee needs to approve the appointment > then the funds would get taken from customer's card;

or alternatively, you could disable Mollie payments and try another Payment method, 

for example WooCommerce is a great choice as you can use their official Add-ons to configure a lot of different Payment Methods into one Gateway. ( They also have a Klarna add-on available)

As i advised on your other ticket for the Klarna issue.

Let me know if you try to switch to WooCommerce integration ( with add-ons) in the meantime and if that could work for you.

And i will still keep you posted on our tests from here in regards to this scenario where a Customer closes the window in the middle of the Mollie Payment Processing steps ( when they still did not confirm a Card, etc).

Thank you.

Hello, Bertrand  and Brendan.

We made some tests and we can confirm we can also reproduce this behaviour on one of our Demo Test Sites.

I believe this is related to an old issue which we have with our Mollie integration from some time ago, when our developers set the 'default' behaviour for our integration with Mollie to always set any appointment to 'pending'.

We will first elaborate about those 'old issues' we encountered.

We had some issues caused by Mollie Payments integration before and this is related to it - we just did not attempt to close the browser's tab/window during the payment steps to see this additional issue.

 For example, sometimes if the waiting time for processing with Mollie payment took too long,

 Amelia would  get false responses from it, such as : 

1. sometimes an appointment does not get created at all, when it should have;

2. and sometimes failed appointments would be set as paid.

So, our developers changed that behaviour to become like this now, Mollie sets it to pending, as it was the safest way to avoid the issues described above.

- We will work to improve that in the future, but I can't say an ETA on it.

If you wish to affect the development speed of improving this issue,

Please feel free to search through our feature suggestion page, 

 to see if someone may be already suggested this improvement.

 If you can't see it, feel free to add your suggestion there, and as more people vote, 

this task will move higher on the priority list.

You can certainly follow our changeLog page if you'd like, where we state any changes/new features/bug fixes during updates;

and our newsletter, so you're informed about new features, bug fixes, freebies, etc.

-

But that issue was in regards to when a Customer goes through with the complete Mollie Payment process, this is something new that we need to assess with our management and our developers.

I am checking with them to see if we have any estimation, if this bug might get fixed in a quick way soon, or if they will need more time to work on it.

As soon as we get more information, we will report back right away.

Thank you both for your patience on this issue.

-

I just wish to add some important details here.

This will not set the appointment as 'approved' or the payment.

The payment and the appointment both get set as 'pending' status.

So even though i set the default Appointment status for this Service to "Approved", due to those other issues we have for Mollie, as we set it to be 'pending' by default, it gets recorded like that.

You can download my Video here that just demonstrates these steps and details how the appointment gets stored in Amelia.

But we still treat this as a serious bug - since it is not the expected behaviour to create a pending appointment when a Customer does not even input any Card Details, or goes through with completing the processing from Mollie in this case.

-

As mentioned, we are checking if we can provide any ETA for fixing this with our management and developers, and going to report back with more information as quickly as possible.

In the meantime, the only 'temporary solution' you could try is to try switching away from Mollie to our WooCommerce integration, because it should have all the same Payment Methods with Add-ons available, and so far we did not have issues like that with that integration.

Thank you.

Hi Brendan.

1. I just first wish to clarify, when i say we don't have any ETA, i meant for the 'old bug' that was causing some Appointments to look as they are paid, when they should not be, or they don't get created while being paid;

which was caused in situations when Mollie Process took too long;

For that reason, our developers set each Appointment Status as "pending" for the time being.

For that particular fix, we don't have an ETA at the moment.

2. But for this new bug, which was reported on this   ticket when the window is closed in the middle of Mollie Process;  or if it gets aborded - where Amelia creates the pending Appointment;

We will go in more details about that.

 Our development team has made significant progress in addressing the bug related to aborted Payment Mollie process, specifically where the payment status gets created as 'pending' in Amelia. 

This issue arises when a payment is aborted or when the payment window is closed during the transaction process, as you guys have shown and we reproduced, resulting in a similar outcome as reported in the other ticket.

While we are in the final stages of resolving this issue.

We are optimistic about integrating the solution into the Plugin's core during the next scheduled update. However, we cannot provide a guarantee of 100% certainty at this moment because comprehensive testing by our Quality Assurance (QA) Team is imperative to ensure the fix does not adversely impact other functionalities within the Plugin. 

In the event that the fix is not included in the upcoming update, but it gets finished in between two Updates, we will make sure to send it to you.

For your convenience, we recommend monitoring our changelog page for any updates, where we document changes, new features, and bug fixes during each release. 

Additionally, subscribing to our newsletter will keep you informed about noteworthy features, bug fixes, and other pertinent information.

Furthermore, I'd like to provide some important details regarding our testing observations. 

While the bug initially results in the creation of a "Pending" appointment in Amelia, it does not generate any corresponding entry in the Amelia Finances section. 

Also, during our testing, the customers do not receive any confirmation Notifications about this occurrence. 

Despite your reported case for your Site, our extensive testing across multiple sites has failed to reproduce any such notification.

To offer visual insight, attached are a couple of screenshots from our testing environment.

 Notably, if the Mollie Payment steps are aborted or the window is closed, Amelia initially registers a Pending Appointment. 

However, approximately 15 minutes later, the system effectively cancels the appointment, and the paid amount reverts to zero and there are no records saved in the Finances Section. 

And we are not able to reproduce our Customers receiving any kind of Notifications during that.

You can download my Video here which demonstrates one of our Tests and see the details we described.

Until our developers add the final fix for this bug, the Customer just won't be able to go in to book the same slot right away - so they need to wait for those 15 minutes approximately, for the slot to become cancelled and available for them again.

We are sorry for the inconvenience and the waiting time, our devs are doing their best to finish the fix and testing as soon as possible.

Let us know if you have any additional questions.

Hi Brendan ,

Sorry for the waiting time.

We don't work on weekends so it adds two days to the waiting time.

we appreciate your patience.

-

1. I made testing first on our couple of Test Sites, and our Demo Sports Site, and i am not able to reproduce getting any Email ( or SMS) Notification when this bug happens of closing/interrupting the Mollie Payment Process window.

The same behaviour as for Appointments happens on our tests.

First an Atendee gets added to the Event as "pending" status.  ( That is another separate bug for booking Events with Mollie/  Events should not have a pending status for attendees, our devs are also fixing that as an individual bug);

Then after some time, approximately 15 to 20 minutes, that Atendee becomes "cancelled" and nothing is recorded in the Amelia's Finances - the same way as for the appointments.

-

In regards to receiving a Notification to the Customer, please download my Video from here;

The first Video shows a Test from our Amelia Sports Demo - as you see, my Customer does not receive any Emails.  

I still waited for some time and keep checking my Email, there is no Notification from that incident.

And i also test if other Notifications work - they are working without issues, it just does not get sent during this bug.

2. Then i also test on your Website Page for Events;

If i book your Test Event, as you said - My Customer does not receive any Email Notification.

The second test on your page https://bellaammi.com/events  ,  please download that Video here.

We stopped that Video after several minutes, but as mentioned, i am still checking and there is still no Email received from your Site.

You can double-check if that Atendee gets cancelled after 15-20 minutes, as it should from our testing.

My Customer Email is [email protected] as seen from the video.

-

If you are still able to reproduce receiving an Email Notification for your Customer during that bug;

then we will need to inspect the issue closer on your Site, for that please open a new Private ticket.

Then on this ticket, if you can record a Video to show us how you reproduce that issue with your Customer and how the Email gets sent in your Inbox.

So we can proceed to try to isolate how that happens on your Site there, since we are unable to reproduce it, even on your Site for our Customer.

I will write a separate/new reply for Bertrand  - to keep the replies 'cleaner' , as you can see, we are going in more details and it becomes more difficult to read everything as we slightly drift from one main subject to several additional topics.

Thank you.

Hi Bertrand,

1. Especially since when we want to reschedule appointments, some appointments disappear and reappear later due to errors in GET or POST requests.

For the rescheduling issues - Can you please open a new, separate ticket, and please show more detailed examples how it happens on your Site, when you try to reschedule and how the GET or POST request errors happen as you described?

The best will be if you can record a Video that shows how you catch that issue, because we are not able to reproduce it on our Testing.

Maybe you are having some option/setting different so it is best to show us examples as detailed as possible, and on a Video so we can follow the steps you do to catch the issue.

When you have multiple questions or issues which are for different subjects/topics,

 please open a new ticket for each subject, and we will help/advise more effectively. 

In that way, issues and questions which are related to different subjects will be in separate tickets so other users or our support agents can find them easily. 

Our policy is to have one issue or question per ticket for the reasons described already.

Thank you for understanding.

-

I can understand all of this is related to the Mollie integration, but we need to try and separate each issue or potential bug to have more effective way to write about them and for our developers, it will be more difficult to read everything on the same ticket like that.

-

2. There's another parameter in the settings with Mollie and Sandbox that I can't understand.

 It asks for the test key, but if I enter the test key, the payments are in test mode whether Sandbox is activated or deactivated.

 I am forced to use the live key for it to be taken into account. Why not separate the two?

- 

I am sorry, but we are not able to reproduce that issue.

Mollie Live Key is not required when you are just testing with SandBox Mode.

They are separate - We just added this "toggle" for Users to make the interface easier/more user friendly.

If you have any suggestion how we could change that to improve it, please let us know and we can pass the suggestion to our management.

-

I just recorded one quick Test, where i do not enter any Live Key - i can just input my Mollie Test Key, and activate the Sandbox Mode like that.

I am then able to make a successful Mollie accepted Payment and to book an Appointment without any issue.

You can download that Test Video here - and you can make your own test on our Sport Demo, you will see it is not possible to create that issue there.

The Sandbox and the Live Mode are completely separate and they require a different Key.

You can also just have Live Key and Live Mode - or vice-versa, just Test Key for the Sandbox Mode;

Amelia will not 'force you' to have both in order to "Save Changes".

-

You also pointed out that on your Site, the Mollie Payments are in Test Mode regardless if the Sandbox is active or not.

That should not happen and we are not able to reproduce it.

For this specific issue, you can also open a new/separate ticket, and record a Video to show us how you are able to reproduce it - as you described, to have the "sandbox mode" misbehave, and we will check it out.

Just make sure to either make a Private Ticket, or if you show any confidential data in the Video such as your Mollie Key, make the Reply as Private for security reasons.

Thanks.

Hello Bertrand.

Milos is on vacation, so I'll take over this ticket.

Since this is already being handled by Uros in this ticket https://tmsplugins.ticksy.com//ticket/3490061/, there's no need for us to keep the topic alive here as well. I checked with the developers, and they said that they are working actively on this, trying to figure out what the issue is.

Please note that it's extremely difficult to resolve an issue that we can't replicate locally. We're doing our best and we apologize for the inconvenience.

Thank you for your kind words, Bertrand.

Feel free to reach out if you have any additional questions or if there's anything else I can assist you with. We're here to provide support and ensure you have a smooth experience. 

Don't hesitate to let me know if there's any specific information or guidance you're looking for—I'm more than happy to help in any way I can!