-
Notifications
You must be signed in to change notification settings - Fork 44
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
First payments utilizing {payment_id} are rejected by Mollie #136
Comments
Investigating |
Thanks for the detailed report and bringing this to our attention @fjahn. I have confirmed the behaviour. Mollie is fixing this validation issue in their API asap. I'll see if a patch is required in Cashier. |
We've shipped a patch in 2.5.3 here. Thanks everyone! |
Hi @sandervanhooft, we also experience this issue, but are still using the Mollie Cashier 1.0 version in one of our applications. Will there be an update from Mollie regarding the validation? Or is it necessary create a workaround/update to 2.0? |
Thanks for pointing this iut @Xaero. @ciungulete just released a v1 patch. |
Summary
Something recently (2-4 days ago) changed on Mollie's side which causes the implementation of the
{payment_id}
placeholder of this library to fail. Currently if applications utilize the{payment_id}
placeholder provided by this library, no first payments can be completed.Explanation
Currently, the placeholder is filled by this library using this technique:
https://example.com/{payment_id}
)https://example.com/tr_xxxxxxxxxx
).This is implemented in FirstPaymentBuilder.
This worked fine before, but now, Mollie validates the URI on the first request now. Because the URI contains curly braces, the validation fails, so the payment cannot be created and this error is thrown:
Reproduction
The (simplified) code used to create the payment looks like this:
Workaround
I fixed the issue temporarily by omitting the redirect URI when creating the payment and updating the correct URI myself:
Suggested fix
The cleanest design (fixing this error) would be to have Mollie fill in the payment id itself, so there are not two requests needed to create a payment. However, I would assume this solution is not feasable, since the engineers would have implemented it this way to begin with.
Another fix would be to check if the redirect URI needs to be filled in before submitting the first request. If that is the case, the library needs to create the payment with a generic redirect URI (e.g.
config('app.uri')
). Only after the payment has been created, the redirect URI can be updated as usual.The text was updated successfully, but these errors were encountered: