Feature Request: allow to easily determine which Invoice "covers" a specific Payment

[holtkamp]

Specifications

• API Version: v1 and v2

Describe the request

Context

• A Payment is settled in a Settlement
• A Settlement is "covered" by an Invoice

Sometimes it is required to process a Payment in an administration. Which is explained here:

• https://www.moneybird.nl/kennisbank/voorbeeld-mollie-uitbetaling-verwerken/
• https://www.moneymonk.nl/help/249-hoe-boek-ik-een-mollie-betaling-met-verkoopfactuur

It would be nice if this can be automated, especially when a lot of Payments are processed.

Feature Request To properly process a Mollie Payment in a financial administration, it would be nice to be able to easily determine which Mollie Invoice "covers" the Payment.

Currently it is possible to determine which Invoice "covers" a Payment with identifier X by:

• load (all) Invoices (including Settlements)
• check whether the $invoice.settlements.paymentIds array contains identifier X

Maybe this can be simplified? For example using one of the following approaches:

• add a field Payment.invoiceId, which gets populated as soon as the Invoice is known / created
  • even beter would be a Payment.invoiceLineId, so we can also easily determine the actual costs involved with the Payment, but I noticed that the InvoiceLines do not have identifiers?
• allow to lookup Invoice by paymentId using the Invoice API, for example by using a parameter paymentId which can be used to filter

[willemstuursma]

In v2, you can go from Payment => Settlement => Invoice using the _link property, does this cover your case?

The payment will have a Settlement if it is settled, and the Settlement will have an Invoice if it is invoiced.

[holtkamp]

@willemstuursma thanks for the swift reply!

In v2, you can go from Payment => Settlement => Invoice using the _link property, does this cover your case?

https://docs.mollie.com/reference/v2/payments-api/get-payment#response describes this part of _links as:

settlement: The API resource URL of the settlement this payment has been settled with. Not present if not yet settled.

Mmm, yeah, I guess this is useful. Only when navigating object graphs, the use of API resource URLs is less useful / elegant. We should then extract the SettlementID from the URL. A more "native" approach, which does not care about APIs or URLs might be preferred?

When I think of it allowing the Invoice API to "load Invoice by SettlementId" might also do the job, since Payment.settlementId exists, the approach would then be:

• load Payment X
• determine SettlementId
• load Invoice by SettlementId

[willemstuursma]

I see that we are missing some useful accessors on the Payment object, e.g. getSettlement() which would make live a bit easier for you.

[Smitsel]

I think @willemstuursma his suggestion is the way to go. But using the _links for navigation is not really elegant for the client.

I could however add it to the Payment resource like this: $payment->settlement().

But we currently don't have a /settlement/{token}/invoices endpoint. So we can't do the same for the Settlement resource. And loading an invoice by settlementId is also not supported right now.

[holtkamp]

But we currently don't have a /settlement/{token}/invoices endpoint. So we can't do the same for the Settlement resource. And loading an invoice by settlementId is also not supported right now.

Would that be feasible to add?

I guess adding a property Settlement.invoiceId would be a first step which already would simplify life a bit 😄

[Smitsel]

We'll discuss internally and come back to you.

[willemstuursma]

Hi @holtkamp. We've added an invoiceId property and a link to the invoice on the Settlement resources (still needs to be added to this client though).

Hope this helps.

Adding an v2/invoice/inv_xxxxx/settlements endpoint is not on the roadmap, sorry.

[holtkamp]

Thanks for the response @willemstuursma

We've added an invoiceId property and a link to the invoice on the Settlement resources (still needs to be added to this client though).

Is this for both version v1 and v2 of the API?

[willemstuursma]

Only in v2 @holtkamp.