craftcms/commerce-mollie

Ability to set description

Opened this issue · 5 comments

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.

Hi team, is this feature on the roadmap for implementing? Our client would love to have better references to the invoices generated in Craft Commerce in Mollie.

Hi All

This is actually already possible using events from the underlying Commerce Ominpay library.

You can achieve this with the following code:

Event::on(
    \craft\commerce\omnipay\base\Gateway::class,
    \craft\commerce\omnipay\base\Gateway::EVENT_BEFORE_SEND_PAYMENT_REQUEST,
    function(SendPaymentRequestEvent $event) {
        $event->modifiedRequestData = $event->requestData;
        $event->modifiedRequestData['description'] = 'My Custom Description';
    }
);

Obviously you will probably want to expand the code there to do some more checks but this should get you on the right track.

Thanks!

Ok, I get that it is possible when writing a module and extending the plugin. But wouldn't it be nice to have a pretty basic feature built in? Seems like the only thing the module would do is actually add a "description" variable. It would make more sense to me to be able to set this value with a form field, just like you can set all other variables with form fields.

Hi @bartrylant

We can certainly see that setting a description value in the form field would seem like an easy option. There are things to consider here regarding hashed/validated data so as not to allow users to change the information sent to Mollie.

That is not to say that it would be an issue to put in place but it would need some consideration and updates to a few files. There may also be other things currently, or in the future, that would need to be added in a similar vein to description so there is that to consider.

We are evaluating payment gateways and how developers use the getPaymentFormHtml() method for future versions of Commerce. There are likely to be changes surrounding that, keeping any extra complexity out of there for the minute could aid a smoother transition.

We will keep this issue open as it is a valid point and therefore could become a feature.

For the moment, we believe the above solution is a valid way of achieving the goal.

Thank you for your input it is very much appreciated.

Thanks.