Feature request: Allow to determine charged payment fee for a specific payment

[holtkamp]

It would be nice to be able to determine the payment fee / transaction cost that was charged for a specific Payment X.

It currently IS possible to acquire the total costs of processed Payments using a certain method, but for transaction costs which involve a percentual part, it would be nice to be able to determine the exact charges of a particular Payment X.

Observations When using the various API endpoints:

• The Payment X object does not contain this information
• The Settlement Y object that "covers" Payment X only contains the cumulative costs of all Payments in the Settlement, for example:

  
  ["costs"] => array(2) {
      [0] => object(stdClass)#23225 (5) {
        ["description"] => string(5) "iDEAL"
        ["method"] => string(5) "ideal"
        ["count"] => int(44)
        ["rate"] => object(stdClass)#23226 (2) {
          ["fixed"] => string(6) "0.2900"
          ["percentage"] => NULL
        }
        ["amount"] => object(stdClass)#23227 (3) {
          ["net"] => string(7) "12.7600"
          ["vat"] => string(6) "2.6796"
          ["gross"] => string(7) "15.4396"
        }
      }
      [1] => object(stdClass)#23228 (5) {
        ["description"] => string(6) "PayPal"
        ["method"] => string(6) "paypal"
        ["count"] => int(1)
        ["rate"] => object(stdClass)#23229 (2) {
          ["fixed"] => string(6) "0.1000"
          ["percentage"] => NULL
        }
        ["amount"] => object(stdClass)#23230 (3) {
          ["net"] => string(6) "0.1000"
          ["vat"] => string(6) "0.0210"
          ["gross"] => string(6) "0.1210"
        }
      }
    }

- The Invoice Z object that "covers" Settlement Y (also) only contains the cumulative costs of all involved Payments in the same format as the snippet above.

Especially for payments that involve percentual charges, the *actually* charged costs are required for administration and invoicing purposes. This particularly applies for payment methods with "different" percentages, like the MasterCard and Visa CreditCards:

<img width="940" alt="screenshot 2018-10-10 at 14 51 22" src="https://user-images.githubusercontent.com/776405/46737545-125f4c80-cc9c-11e8-81b4-67a04e29a3e8.png">

*Disclaimer*
Maybe the information can already be extracted from the API, could not find it though...

[holtkamp]

Hey guys, just wondering: is this a "valid" feature request? Can it be confirmed as such (or bounced of course 🤓 )

[mollierobbert]

For sure, Menno. Thank you for taking the time to write this proposal. We are working actively on upgrading our engine to be able to provide real-time payment fee insights in the near future. We cannot confirm a date yet, however, hence we can't promise much yet.

[sandervanhooft]

@holtkamp not entirely the same, but does the latest release solve your use case?

https://github.com/mollie/mollie-api-php/releases/tag/v2.5.0

[holtkamp]

@sandervanhooft thanks for the heads-up.

but does the latest release solve your use case?

Mmm, I haven't looked at in detail, but it seems the pricing() helper gives information about the pricing of a Payment method. Not the actually charged / to-be-invoiced costs of an actually processed transaction.

[holtkamp]

We are working actively on upgrading our engine to be able to provide real-time payment fee insights in the near future

@mollierobbert just wondering, are there any updates regarding this issue?

Rationale Currently, under PSD2 "surcharging" is still allowed to some extent. Also see:

• https://help.mollie.com/hc/nl/articles/360012564454-Mag-ik-de-kosten-die-ik-maak-voor-betaalmethodes-doorberekenen-aan-mijn-klanten-
• https://www.acm.nl/nl/publicaties/invoering-psd2-wat-gaat-er-voor-u-veranderen

However, I expect that surcharging will (eventually) become completely unallowed. In that case the situation will occur that the charged transaction costs need to be forwarded/invoiced elsewhere. To generate such invoices, it would be nice to have insight in the actually charged transaction fees.

This does not need to be "real-time", but at the moment a Mollie invoice is received (by the end of the month), it would be nice to have insight in these details...

[mollierobbert]

@holtkamp No update yet. The pricing is currently still determined on a settlement level. We are indeed still working on calculating fees in real-time and making quite some progress, but I cannot share a timeline for when that feature would reach our Payments API.

[christopheg]

Dear @mollierobbert, can you please explain why this is so difficult and why it takes so long to implement? Basically we could do the same by following this procedure:

• On webhook callback, check if the status is 'paid'
• fetch the fees via the 'methods' API call
• try to match the brand/cardAudience/feeRegion with fetched fees
• do the calculation

Problems that may arise are situated in:

• matching the fees with the chosen method: There is no ways to link the response from the 'method' call with the response of a payment/get call. This will end up in a very big if/then/else statement that needs to be updated on every adjustment on the side of Mollie.
• The calculation: We will probably end up with rounding errors. The goal should be that we could match the totals mentioned on the settlements.

These problems are easily overcome if Mollie would implement this procedure on there side.

[mollierobbert]

Thanks for the suggestion @christopheg.

We currently can only provide an overview of the fees once the settlement has been processed. Would it suffice for you both, @christopheg and @holtkamp, if these fees are made available in the Payments API after the payment got settled (i.e. to your bank account)?

As noted before we are actively working on a big engine upgrade that will allow us to do provide this information as soon as the payment moves to 'paid'. We are getting there, slowly but surely.

[holtkamp]

Would it suffice for you both, @christopheg and @holtkamp, if these fees are made available in the Payments API after the payment got settled (i.e. to your bank account)?

@mollierobbert That would be a nice first step indeed 😃

[christopheg]

@mollierobbert, in our use-case this is not sufficient. We charge our customers the exact cost of the transaction. I just don't understand why you need a bit engine upgrade in order to create something which we could develop ourselves with existing API calls...

[christopheg]

@mollierobbert I've created a pull request that adds cost calculation of transactions via existing API calls. This is for me a temporary solution but it fixes our problem. Pull request: https://github.com/mollie/mollie-api-php/pull/409

PS: I want to point out that this is not only a technical limitation of the Mollie system. For the moment there is no way to clarify the costs that are calculated on any invoice. I think that therefore also from a commercial point-of-view it is important to come up with a better solution.

[mollierobbert]

Thanks for the pull request, Christophe. 👏

We could indeed take your suggested shortcut, but we would not be able to expose this endpoint to our entire user base reliably, since costs are simply currently not yet confirmed in real-time. It would solve your problem, and cause issues for us elsewhere (for users with more complex pricing models).

I do of course agree on the importance of this issue, both from a business and a technical standpoint.

I'm tempted to merge the pull request, but we would have to put heavy disclaimers around it that it's highly experimental. @willemstuursma @leonardogcsoares what do you guys think?

Alternatively, you are free to fork the package.

@holtkamp Would Christophe's PR solve your issue for now as well?

[sandervanhooft]

In order to prevent breaking changes down the road, I strongly recommend to only use this code locally. As soon as the API is ready this code is very likely to be deprecated.

If this is the feature set you’re looking for and you are adamant to have a solution via the client class I suggest to decorate it locally for now.

[sandervanhooft]

“Locally” being “in your application”.

[holtkamp]

@mollierobbert

Would Christophe's PR solve your issue for now as well?

Well, yes. But I understand the arguments to not adopt this (approach) in the API and advise to keep it in "user land" code instead.

[christopheg]

I also agree on the fact that it is not ideal to have this code in the Mollie API client. However I was looking for a way to distribute the code in such a way that in can be improved and maintained by you or other developers. Do you see any other solution?

[sandervanhooft]

Good thinking @christopheg , I'd recommend a dedicated package for that, pulling in this client. Once the feature set is available on the client itself, you could deprecate the package or refactor it to use the then-new client features instead.

[sandervanhooft]

If that's a bit "too much", consider a github gist.

[mollierobbert]

A gist would be nice. I was thinking we could also just leave the PR open until we can offer the functionality natively, but that's a bit messy perhaps.

Thanks all for collaborating on this. 👍 And for understanding our delay in solving this issue.

[noezdev]

Are there any new developments on the matter? Especially when receiving callbacks via credit card payments, it is almost impossible to calculate the correct fees.

This is mandatory for our accounting. The Mollie support always refers to the settlements and that you have to calculate it manually, but I think this is extremely inconvenient.

Especially since the fees per payment are also displayed in the Mollie backend under transactions, I assume a technical possibility.

[mollierobbert]

Thanks for the reply noezdev, and sorry for the wait on this topic.

We are planning to roll out a more mature reporting API in the next 6 months or so. It took some time for us to migrate everyone to a new balance system that enables us to build more reliable reporting for our users.

The new reporting APIs will likely offer:

• Aggregations of all received payments and charged fees within a given period (e.g. 5 iDEAL payments totaling €50, 5 iDEAL fees totaling €1,45).
• A list of all transactions happening on your balance (e.g. iDEAL payment of €10 with a €0,29 total fee and €9,71 settled on your balance).

It doesn't (yet) offer a breakdown of what fees exactly were charged on each payment, but it does offer the fee sum per payment, which is a great leap forward.

The functionality is already available in the dashboard, so the next step is to 'soften the edges' and publish it as a public API.

I sadly cannot offer an inbetween solution, but if you are interested I can put you on the list for beta testing the new reporting endpoints once they are ready to go into beta.

[Jay031]

@mollierobbert any update on this? I still use this quick fix, but it does't support directdebit and some other methods. So 50% of my transactions don't get any transactionCosts.

[christopheg]

Hi @Jay031, Unfortunatly, I don't think Mollie wants to implement this feature so don't expect a solution by them.... I created the PR but on my account not all payment methods are enabled. I believe that my patch can be extended for other methods. Just try to list all your payment methods via API and check the 'id'. With this 'id', the PR can be extended.

[Jay031]

Hi @Jay031, Unfortunatly, I don't think Mollie wants to implement this feature so don't expect a solution by them.... I created the PR but on my account not all payment methods are enabled. I believe that my patch can be extended for other methods. Just try to list all your payment methods via API and check the 'id'. With this 'id', the PR can be extended.

Yeah well, the annoying thing is, that my recurring payments only show 'directdebit' as payment method, so no iDeal, KBC/CBC, Sofort etc. thats only in the initial payment. So that leaves an annoying amount of extra work, I think it's so lame, because the data is already there in Mollie..

[mollierobbert]

No update yet, sadly. We are getting closer to a beta release, but my earlier time indication was clearly too optimistic.

Before we can put the endpoints in beta, we still have to address some performance issues and add multicurrency compatibility.

[RobinvanderVliet]

Is there an update in the meantime? In the API documentation of the payment endpoints, I still cannot find any information about the charged payment fees.

[mollierobbert]

The new Balances API is currently in open beta, available here:

https://docs.mollie.com/reference/v2/balances-api/overview

With this API you can fetch lists of balance transactions. A payment is one type of balance transaction, and fee information is included in the transaction details as 'deductions'.

Perhaps more interesting is the balance reporting endpoint though, which allows you to fetch aggregate reports for a given time period. The aggregate report will include aggregated information on how many payments came in, how many fees were charged, etc.

Hope this helps!