craftcms / commerce-mollie Goto Github PK

The composer.json requires ^1.0.0 as the version of the commerce-omnipay dependency. There has been an update to fix an error with this module and v1.0.1 has been released. Could you adjusted the composer.json to require ^1.0 so the update will be applied? Thanks.

Mollie was temporary down and I took our craft website down as well.
Are you able to fix this so that the website it self doesn’t go down and only the payment function is disabled or any other solution?

GuzzleHttp\Exception\ServerException: Server error: GET https://api.mollie.com/v2/methods` resulted in a 503 Service Unavailable

Are there any plans to support subscriptions for Mollie?

Description

I recently upgraded a webshop from Commerce 2 to Commerce 3 and quickly noticed that order confirmation emails were no longer being sent.

The email settings appear correct after testing and when I go into an order and press "Send Email" in the top right, the confirmation email gets sent.

The confirmation email is linked to the default order status, so should be sent as soon as an order is placed/paid.

There is nothing in the (error) logs.

When I use the dummy gateway in a test environment, the confirmation email does get sent automatically. So might this be an issue with the Mollie payment gateway?

Steps to reproduce

Setup a confirmation email and use the Mollie gateway for the payment. This is difficult to test in a different/clean environment due to the required Mollie-subscription/setup.

Additional info

• Craft version: 3.4.13
• Craft Commerce version: 3.1.1
• Mollie for Craft Commerce version: 2.1.1
• PHP version: 7.2.30

Somehow, in a newer install of this plugin, the webhook url doesn't get sent to Mollie, as it did previously. I think you only need to add the supportsWebhooks method to the gateway, returning true. Please do this for the feature/issuers version to, as that's the one we always use (when will this be merged into master?).

Description

Like the iDEAL payment method, the KBC needs an issuer parameter passed. If ommitted mollie returns with an error the the issuer is missing. In the current commerce-mollie plugin there is an fetchIssuers method, but that only returns issuers for iDEAL.

What I can see in the docs from mollie is the "List payment methods" has an includes option to pass along the issuers, see: https://docs.mollie.com/reference/v2/methods-api/list-methods#includes
It is alco documented here (in the get payment method): https://docs.mollie.com/reference/v2/methods-api/get-method#method-includes

This should be implemented in some way in order for the KBC method to work.

Steps to reproduce

1. Enable the 'KBC/CBC Payment Button' payment method
2. Submit an order

Description

On the front-end, I'm using the gateway.fetchPaymentMethods() function to list payment methods as radio buttons. Previously, when a radio button was selected and the form was submitted, the user would be taken directly to the corresponding payment method in Mollie. However, the current behavior is different. After selecting a radio button and submitting the form, instead of being directed to the chosen payment method in Mollie, the user is taken to the general "select-method" page on the Mollie side. This requires the user to make the same selection again.

I also attempted to use the gateway.getPaymentFormHtml([]) function, but the issue persists in this scenario as well.

Steps to reproduce

1. Navigate to the checkout page.
2. Select a payment method from the list of radio buttons generated using gateway.fetchPaymentMethods().
3. Submit the form.
4. Instead of being taken directly to the chosen payment method in Mollie, you are redirected to the generic "select-method" page on the Mollie platform.

Additional info

• Craft version: Craft Pro 4.4.17
• PHP version: 8.1.21
• Database driver & version: MySQL 8.0.33
• Plugins & versions:
  Colour Swatches 4.3.0
  Cookies 4.0.0
  CP Field Inspect 1.4.4
  Craft Commerce 4.2.11
  Default Dashboard 2.0.0
  Eager Beaver 4.0.2
  Elements Panel 2.0.0
  Embedded Assets 3.1.6
  Expanded Singles 2.0.5
  Feed Me 5.2.0
  Formie 2.0.34.1
  Hyper 1.1.11
  Image Resizer 3.0.6
  Knock Knock 2.0.10
  Mailchimp Transactional 2.0.1
  Maps 4.0.4
  Minify 4.0.0-beta.2
  Mollie for Craft Commerce 4.1.0.1
  Neo 3.8.6
  Password Policy 4.1.0
  PDF Transform 2.0.1
  Preparse Field 2.0.2
  Retour 4.1.13
  Sentry SDK 2.0.1
  SEOmatic 4.0.30
  Sprig 2.6.2
  Style Inliner 3.0.3
  Super Table 3.0.9
  Translations 2.2.1
  Typogrify 4.0.1
  Vite 4.0.6
  Vizy 2.1.8

Hi,

In the getPaymentFormHtml() method there is a check if the fetchIssuers() method works. But this method does not work if ideal is not selected in the website profile in mollie. Therefore, if ideal is not selected the payment form html is not returned.

Description

We have been noticing some overpaid orders in one of our clients Commerce-instances lately. While this wasn't a major issue at the time (albeit being undesirable behavior of course), some orders have now been sent to our fulfillment partner twice, as a result of the Order::EVENT_AFTER_ORDER_PAID.

As seen in the screenshot above, two transactions were recorded for this order. While Mollie both uses the redirect-action and the webhooks in the background, I suspect that both of these are handled as separate transactions. The webhook-processor does actually check if there's already a successful transaction for the order, but it might be that the redirect and webhook are so close to each other, that either request is not finished yet and both get recorded.

Digging through the plugin-code, I recognized the warning-message. We have been receiving quite some of these messages lately. This would confirm my theory, but luckily the redirect and webhook are not always close enough that they will produce this issue.

Orders being marked as "overpaid" in Craft are not a major problem, but when they're sent to the fulfillment partner twice and actually get shipped twice, we start to get nervous. Could we find some sort of solution to prevent this from happening?

Additional info

• Craft version: 3.5.17.1
• PHP version: 7.2.34
• Database driver & version: MySQL 5.5.68
• Plugins & versions: Craft Commerce 3.2.13.2, Mollie for Craft Commerce 2.1.2 and much more

I use the plugin with Mollie in test mode.

When I fire the commerce/payments/pay I get an error (debug toolbar)

Client error: `POST https://api.mollie.com/v2/orders` resulted in a `422 Unprocessable Entity` response:
{"status":422,"title":"Unprocessable Entity","detail":"The 'familyName' field is missing","field":"billingAddress.family (truncated...)

Additional info

• Craft: 4.2.0.2
• Commerce: 4.1.0
• Mollie Pro: 2.1.2
• PHP version: 8.0

Description

Properly using {% namespace cart.gateway.handle|commercePaymentFormNamespace %} and setting paymentMethod and issuer, Mollie opens without these preselected. Without changing the payment form itself, this used to work before.

Steps to reproduce

1. Create payment form with paymentMethod and issuer according to docs
2. Submit and see these are not preselected

Additional info

• Craft version: 4.4
• PHP version: 8.2
• Database driver & version: PostgreSQL 12
• Plugins & versions: Commerce 4.2.6 and Commerce Mollie 4.0.0.1

Will this addon be upgraded for Craft 3?

Mollie provides you with a list of available payment methods and, if iDeal is chosen, banks through its API. (How) can I get those lists from my template? I know I once did it in Commerce v1, but can't seem to find the template source for that.

Description

When trying to update to the latest version with composer (2.1.0 tot 2.1.2) I get an error the plugin can't be installed:

Syncing craftcms/commerce-mollie (2.1.2) into cache
    Update of craftcms/commerce-mollie failed

Installation failed, reverting ./composer.json and ./composer.lock to their original content.

                                                                                                             
  [InvalidArgumentException]                                                                                 
  Unknown downloader type: . Available types: git, svn, fossil, hg, perforce, zip, rar, tar, gzip, xz, phar  
  , file, path.  

I am trying to use Mollie gateway plugin and I am stuck with how one should use it. I entered the Mollie test API key but don't know how payment form should look like. Mollie plugin doesn't implement getPaymentFormHtml. I've tried making a payment form but I am again getting lost since I have no clue how to get paymentForm.

Not entirely sure how field mapping between craft commerce and gateways (e.g. mollie) work, but I would assume that there is universal API for all gateways or should one just look up the gateway documentation on how to create payment?

Anyway, as you can see I am a bit lost. When using Stripe plugin gateway everything works without any problem since plugin implements everything needed for an easy integration with the front end.

Reading this thread the OP says that Mollie is an off-site implementation. This is probably the reason I am dealing with above mentioned issues. Either way, I still don't know how to use this gateway plugin to get it working.

Nevermind, I did not understand that Mollie is an off-site implementation. So the checkout just redirects you to the Mollie environment. If you want to implement on-site payments using Mollie you'd have to write your own logic I presume.

Description

In Mollie, every order has a description. Craft automatically sets the description to "Order #xxxxxxxxx"
According to the Mollie API docs, you could use a field called description, and set the description to whatever you want. E.g.

<input type="hidden" name="description" value="TEST"/>

However, ik looks like that value (when I put in in the last form on the website, the form that posts to commerce/payments/pay), doesn't get sent to Mollie.

There seems to be a recent issue which sometimes causes successful transactions to not being processed properly. In some cases, the transaction even appears twice, causing the order to be 'Overpaid'. As well as craft\commerce\elements\Order::EVENT_AFTER_ORDER_PAID not being called, which harms our business logic.

Could this be investigated and addressed?

Using the Commerce Mollie plugin, most payments get completed without any problems. However, some payments throw the error ('payment error:'), with no further explanation.

After some searching, this is what causes the problem. The response of $gateway->completePurchase($transaction) (line 357 of commerce/src/services/Payments.php) contains the following bit of information:

["multiErrors":protected]=> array(4) { [1]=> array(2) { [0]=> string(16) "CURLM_BAD_HANDLE" [1]=> string(49) "The passed-in handle is not a valid CURLM handle." } [2]=> array(2) { [0]=> string(21) "CURLM_BAD_EASY_HANDLE" [1]=> string(165) "An easy handle was not good/valid. It could mean that it isn't an easy handle at all, or possibly that the handle already is in used by this or another multi handle." } [3]=> array(2) { [0]=> string(19) "CURLM_OUT_OF_MEMORY" [1]=> string(15) "You are doomed." } [4]=> array(2) { [0]=> string(20) "CURLM_INTERNAL_ERROR" [1]=> string(66) "This can only be returned if libcurl bugs. Please report it to us!" } }

I don't know if I should file this issue here, or under Craft Commerce. Could you look into this?

Description

Our payment form has no specific Mollie-fields and the gateway id field points to the Mollie gateway set up in Craft Commerce.

When submitting the payment form, we immediately get one specific option on the Mollie platform, credit card. Apple Pay enabled devices also show that option, but that seems to be integrated in the credit card option, so it's really just that option.
The "Payment methods" link on the Mollie platform goes to the webshop's payment page.

We've enabled several options in Mollie, so we expect to see the payment method list first, to be able to choose a method.

We've reached out to Mollie, but they say everything is configured correctly on their side and advise us to contact Craft Commerce support.

When I use gateway.fetchPaymentMethods(), I also don't see all the options - only credit card and some specific banks. When using that field to select a specific payment method (one of the banks), it doesn't make a difference.

Steps to reproduce

1. Install Craft Commerce with the Mollie gateway plugin and use a valid live Mollie API-code which has multiple payment methods enabled
2. Use the Mollie gateway (without additional parameters)
3. Submit the payment form to go to the Mollie platform

Additional info

• Craft version: 4.5.9
• PHP version: 8.1.24
• Database driver & version: MySQL 8.0.34
• Plugins & versions: Commerce 4.3.1 and Mollie for Craft Commerce 4.1.0.1

Description

Steps to reproduce

Additional info

• Craft version:
• PHP version:
• Database driver & version:
• Plugins & versions:

Description

In our commerce shop we got an order that has been marked as paid twice (aka the double of the actual amount).

I have tried setting the totalPaid db column manually to the correct amount, but that doesn't show up in the CMS (caching?). Have sent an email about this to craft support, but have gotten no response since oct. 25th. So I'll try here.. The payment gateway is Mollie. Is there some kind of race condition that is not 100% bullet proof?

Steps to reproduce

Additional info

• Craft version: 3.3.6
• PHP version: 7.2
• Database driver & version:
• Plugins & versions: Commerce: 2.1.13, Mollie: 2.1.0.1

Description

After trying all the different Mollie test states, I noticed the expired transaction state does not receive a nice error message like the failed or canceled does.

Steps to reproduce

1. Go through the checkout flow until you're in the Mollie test UI.
2. Choose the "Expired" option.
3. The transaction message in the database is the stringified JSON response from Mollie. And consequently also inside the flash messages.

Additional info

After some digging in the source, I found the location where the message is transformed:

• Craft version: 3.7.36
• PHP version: 7.2.5
• Database driver & version: MySQL
• Craft commerce version: 3.4.11
• Craft commerce mollie version: 3.0.0

Updating to the latest Commerce version causes this error with the Mollie gateway (see attachment).

Craft edition & version | Craft Pro 3.1.15
Craft Commerce | 2.1.0.2
Mollie for Craft Commerce | 1.1.1

trace.txt

Description

Using the Commerce-Mollie gateway, an increasing number of webhook requests get a 400 Bad Request status code returned.

The facts:

• Mollie POSTS to commerce/payments/complete-payment with a transaction hash
• No CSRF token is used by Mollie (of course).
• CSRF validation is enabled on the site

Could this be the issue? Why would most payments get a 200 on their webhook call, and others a 400?

• Craft version: 3.0.25
• Craft Commerce version: 2.0.0-beta.10

When there is more than 1 payment method, mollie handles correctly status "paid" only, with the redirection to the original website. For any other payment status selected it only returns to the general page with the list of available methods without any additional message.

Tested with "Test API key" on 2 different mollie accounts and I have got the same result in both cases.

Details:
Craft CMS Version 3.4.17.1
Craft Commerce Version 3.1.3
Mollie for Craft Commerce Version 2.1.1

See screenshot below. How to reproduce:

1. Initiate payment using mollie
2. Press return to website
3. This error below get's shown
   

We are using Commerce 2.1.13 (Craft 3.3.4.1) with the Mollie plugin(2.1.0.1)

And every order, when we check in Mollie, the webhook calls all fail. (every order, every webhook)
Orders are registered in Commerce as paid though, and the transaction tab is populated.

This is on a public facing production server, not a local dev environment.

(But some order numbers go missing, but thats for another issue)

See screenshot on the right: https://cl.ly/6af79facc644

Any thoughts? Is this a bug, or am I doing something wrong?

When processing an order for a digital product with Mollie the licence isn't created.

I've only tried this with the Bitcoin payment option in test mode, but I've raised this issue in the craft commerce slack channel and another user has noted they're having the experience with other payment options (iDeal, bancontact).

Interestingly, the order is set to complete but a paid date is missing;

Hi guys ! First of all, thanks for the plugin.

I just wanted to know what was your planning concerning the Mollie Orders api integration.
I have to create such a plugin in the next weeks but I trust you more on php development :P

Thanks for the update !

Description

I migrated to Craft 4 & Commerce 4 and wasn't able to place orders with Mollie as gateway.
When submitting the payment form, I receive the following error message:
TypeError
craft\commerce\omnipay\base\RequestResponse::getRedirectData(): Return value must be of type array, null returned

I noticed that the function "getRedirectData()" in omnipay/mollie/src/Message/Response/FetchTransactionResponse.php currently returns null. When changing this to return $this->data, I am able to submit the payment and everything works again as suspected.

Additional info

• Craft version: Pro 4.4.5
• PHP version: 8.0.27
• Database driver & version: MySQL 5.7.40
• Plugins & versions: Mollie for Craft Commerce 4.1.0

Description

Can't open Orders in CP after craftcms/commerce-mollie 3.0 update.

Error
Class 'Http\Adapter\Guzzle6\Client' not found

Additional info

• Craft version: 3.6.12
• Commerce version: 3.3.0
• PHP version: 7.4.18

Hi,

We've found a bug in the plug-in. You can't order when using Mollie's Bank Transfer payment. What happens if the payment status remains open (because it's a bank transfer this is normal, mollies webhook will update the site when the payment was received), you keep going back tot the site, which redirects you back to Mollie.

Normally when the payment is open, this would be fine, but an exception must be made for the bank transfer, since the user doesn't directly pay like with CC or iDeal.

As of now the gateway uses Mollies Payments API and therefore it does not support all provided payment options from Mollie.

The Omnipay mollie gateway (https://github.com/thephpleague/omnipay-mollie) supports the Orders API already and it would be nice to change "commerce-mollie", as the Orders API is the preferred implementation option.

More information about the Orders API: https://docs.mollie.com/orders/why-use-orders

Quote from the linked site:

Using the Orders API is the preferred approach when integrating the Mollie API into e-commerce applications such as webshops. Below you will find an overview which functionalities the Orders API offers as opposed to the Payments API.

Hi,

We've installed the latest version of your extension, 2.0.1. But the webhooks are not working.
The webhook URL and the returnUrl are the same. This should not be the case, because the webhook url should only handle the payment and not return a redirect. But not sure if this is the exact reason why it fails, but if you visit the webhook url with a normal browser it processes the payment, only the mollie call doesn't trigger the same.

Steps to reproduce:

1. install and configure the latest commerce and version 2.0.1 of commerce mollie
2. make an order, go to mollie to pay, then close the tab (to prevent manually triggering the url on redirect).
3. Check the mollie logs for the webhook, it says the call failed.

Support variables like $MOLLIE_API_KEY

See also craftcms/aws-s3#35