Skip to content
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

Closed
fjahn opened this issue Oct 19, 2022 · 6 comments
Closed

First payments utilizing {payment_id} are rejected by Mollie #136

fjahn opened this issue Oct 19, 2022 · 6 comments

Comments

@fjahn
Copy link
Contributor

fjahn commented Oct 19, 2022

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:

  1. Submit a request to Mollie, creating a new payment with a temporary, unfilled redirect URI (e.g. https://example.com/{payment_id})
  2. Get the payment id generated by Mollie and fill in the placeholder
  3. Submit a second request to Mollie, updating the redirect URI to the correct one (e.g. 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:

Error executing API call (422: Unprocessable Entity): The redirect URL is invalid. Field: redirectUrl. Documentation: https://docs.mollie.com/overview/handling-errors

Mollie \ Api \ Exceptions \ ApiException : 114 createFromResponse
Mollie \ Api \ HttpAdapter \ Guzzle6And7MollieHttpAdapter : 175 parseResponseBody
Mollie \ Api \ HttpAdapter \ Guzzle6And7MollieHttpAdapter : 104 send
Mollie \ Api \ MollieApiClient : 538 performHttpCallToFullUrl
Mollie \ Api \ MollieApiClient : 494 performHttpCall
Mollie \ Api \ Endpoints \ EndpointAbstract : 76 rest_create
Mollie \ Api \ Endpoints \ PaymentEndpoint : 52 create
Laravel \ Cashier \ Mollie \ CreateMolliePayment : 14 execute
Laravel \ Cashier \ FirstPayment \ FirstPaymentBuilder : 131 create
Laravel \ Cashier \ Charge \ FirstPaymentChargeBuilder : 66 create
<Call in Application>

Reproduction

The (simplified) code used to create the payment looks like this:

$redirectUrl = str(route('account.buy.callback', ['payment' => 'payment_id']))
    ->replaceLast('payment_id', '{payment_id}');

$redirection = $user->newFirstPaymentChargeThroughCheckout()
    ->addItem($item)
    ->setRedirectUrl($redirectUrl)
    ->create();

Workaround

I fixed the issue temporarily by omitting the redirect URI when creating the payment and updating the correct URI myself:

$redirection = $user->newFirstPaymentChargeThroughCheckout()
    ->addItem($item)
    ->create();

$this->updateRedirectUri($redirection->payment());
private function updateRedirectUri(\Mollie\Api\Resources\Payment $payment): void
{
    $redirectUrl = str(route('account.buy.callback', ['payment' => $payment->id]));
    $payment->redirectUrl = $redirectUrl->toString();

    $updateMolliePayment = app()->make(UpdateMolliePayment::class);
    $updateMolliePayment->execute($payment);
}

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.

@sandervanhooft
Copy link
Collaborator

Investigating

@sandervanhooft
Copy link
Collaborator

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.

ag84ark added a commit to ag84ark/laravel-cashier-mollie that referenced this issue Oct 25, 2022
sandervanhooft added a commit that referenced this issue Oct 25, 2022
@sandervanhooft
Copy link
Collaborator

We've shipped a patch in 2.5.3 here.

Thanks everyone!

@Xaero
Copy link

Xaero commented Oct 26, 2022

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?

ciungulete added a commit that referenced this issue Oct 27, 2022
Update FirstPaymentBuilder.php
@sandervanhooft
Copy link
Collaborator

Thanks for pointing this iut @Xaero. @ciungulete just released a v1 patch.

@sandervanhooft
Copy link
Collaborator

https://github.com/mollie/laravel-cashier-mollie/releases/tag/v1.17.1

Thanks @ciungulete !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants