Closed alecpl closed 1 year ago
Hi @alecpl , can you confirm this behaviour is still occurring?
@sandervanhooft Yes, this is still an issue.
@JorikMollie any ideas?
Any progress? This is still an issue.
I think there's a slight misunderstanding here. You'll need to redirect the customer to the checkout. As soon the payment is paid, the get payment response will bear the mandateId. Which is generated by the customer going through checkout.
Sorry, but I think the misunderstanding is on your side.
It is not documented precissely, but this is a regression. An initial request to create a payment used to return payment object with mandateId
specified. I had my tests based on that, that's why I see it changed.
What's the reasoning for this change? Why the immediate response could not return the mandate id?
Documentation says mandateId
is set "if the payment is a first or recurring payment".
If I have to wait for the payment to be paid to get the mandate, what is mandate's pending
status for?
I expect the mandate to be created and in pending
state when I create the first payment. I think this is fair expectation, and this is how it worked before. I also am not 100% sure, but I see no complaints from my customers, so maybe the issue is only in test mode, but I didn't verify that.
Can you point me to the place where you found this in the documentation?
I just verified that the behavior is the same for both test and live, in both cases there is no mandateId
being returned for payments that are open
. Also I personally can't remember it being any other way, but your tests are certainly failing for a reason, so I have reached out to our teams to research any change that might have lead to a change in behavior.
The documentation around Get Mandate indeed states
A status can be
pending
for mandates when the first payment is not yet finalized or when we did not received the IBAN yet.
I'll come back once I have more info :)
Indeed I can confirm this behavior changed around that time. This was due to us rolling out Mollie Components on the hosted payment page, which lead to us restructuring the order of things internally a bit.
We want to change it back to the old behavior though and have put this up as a roadmap item for the relevant team. I can't, however, really give a time commitment at this time.
As this is not an issue with the PHP client, but rather with the API in general, I'll close this issue here for now.
Just FYI, I found out that it's not only a missing mandateId in the fist
payment response. It looks like the mandate is not being created at all. If I try to list mandates using API, after the first
payment creation, the result is an empty list.
Specifications
Describe the issue
First, note that my project's automated tests were working a few months back, so to me it looks like something changed on Mollie side.
Problem is that
mandateId
is not returned in a payment create response. Here's my request:The response is: