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

Allow creating Mollie payment links for orders for draft orders #2690

Open
martijnvdbrug opened this issue Feb 21, 2024 · 6 comments
Open

Allow creating Mollie payment links for orders for draft orders #2690

martijnvdbrug opened this issue Feb 21, 2024 · 6 comments
Assignees

Comments

@martijnvdbrug
Copy link
Collaborator

martijnvdbrug commented Feb 21, 2024

Is your feature request related to a problem? Please describe.
As an Administrator, I would like to be able to generate payment links for draft orders from the admin UI.

Describe the solution you'd like
After creating a draft order, I would like to be able to send my customer a payment link, to finalize the order. Currently, the shop-api mutation is depending on the active order, but for an admin it would be nice to pass an orderId.

  • Add a dropdown menu item createPaymentLink
  • Add a mutation on the admin API createMolliePaymentIntent(orderId)

Current situation

Currently there are 2 ways to configure the Mollie plugin: Make the client pass in a redirectUrl or set in in Vendure. The config useDynamicRedirectUrl enforces the use of one of these options. This option is marked for deprecation.

Dynamic redirect url:

MolliePlugin.init({
   useDynamicRedirectUrl: true
})
// Storefront then does:
createMolliePaymentIntent(redirectUrl: "some-url")

Or, non-dynamic redirect url:

MolliePlugin.init({
   useDynamicRedirectUrl: false
})

And in Vendure UI you then specify the redirect url:
image

Proposed implementation

⚠️ The current situation described above forces the use to pick one of the options, but this new feature requires both options to be possible:

  1. Use dynamic redirect url on the storefront: createMolliePaymentIntent(redirectUrl: "some-url")
  2. Set a fallback redirect url in the admin that is used by the createPaymentIntent button in the Admin UI. Otherwise the admin would have to specify a redirect URL everytime the button is clicked.

Proposed changes:

  1. Remove useDynamicRedirectUrl. It's already deprecated right now
  2. Rename the payment handler argument redirectUrl to fallbackRedirectUrl
  3. When a redirect url is passed in via createMolliePaymentIntent("some-redirect") it always takes precedence over the fallback URL
@martijnvdbrug
Copy link
Collaborator Author

@michaelbromley This can be assigned to me

@martijnvdbrug
Copy link
Collaborator Author

@casperiv0 I know you are also using Mollie. I would like to hear your thoughts on the proposed implementation, since it also affects your project probably.
(No worries, I will implement it 😄 just a quick scan of the proposal is asked)

@casperiv0
Copy link
Contributor

We're indeed using the Mollie plugin, with the dynamic URLs feature 👀. The way we handle payments goes as following:

  1. Go through checkout
  2. Payment method list (molliePayments query)
  3. Click on a payment method will execute the payment flow through Mollie, using the createPaymentIntent:
await fetchClientGraphQL(
  createMolliePaymentIntentMutationDocument,
  {
    locale: options.locale,
    variables: {
      input: {
        molliePaymentMethodCode: options.code,
        paymentMethodCode: options.paymentMethodCode,
		// Generated by us using the storefront's URL and some additional information in search params & actual redirect URL
        redirectUrl: options.redirectUrl,
      },
    },
  },
);
  1. Goes through Mollie flow
  2. Redirects to the URL in the redirectUrl as a "successful payment" page.

I see no major breaking changes in your proposal and could possibly be useful for us too in the future.

When handling a payment intent in the admin UI, I'm guessing it would then use the fallbackRedirectUrl if non is set for its mutation execution?

@martijnvdbrug
Copy link
Collaborator Author

Thanks for the quick response 🙏 It should indeed not break anything.

When handling a payment intent in the admin UI, I'm guessing it would then use the fallbackRedirectUrl if non is set for its mutation execution?
Yep correct. The priority order is always like this, regardless of admin or shop api:

  1. Use redirect url from mutation if given
  2. Otherwise use fallbackRedirectURL

Admin UI will not have an input field to pass redirect as argument, so it would indeed fall back to nr. 2

@dlhck
Copy link
Collaborator

dlhck commented Sep 24, 2024

@martijnvdbrug I just saw the UI part is missing currently. We could do that together with #2903 unless you already have the UI part done and could provide a PR for that.

@martijnvdbrug
Copy link
Collaborator Author

@dlhck would be great if that can be picked up in that admin ui task. I'm always struggling with admin ui stuff...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: 👀 Under consideration
Development

No branches or pull requests

3 participants