vendure-ecommerce / vendure

The commerce platform with customization in its DNA.
https://www.vendure.io
Other
5.81k stars 1.03k forks source link

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

Open martijnvdbrug opened 9 months ago

martijnvdbrug commented 9 months ago

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.

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

:warning: 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 commented 9 months ago

@michaelbromley This can be assigned to me

martijnvdbrug commented 9 months ago

@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 :smile: just a quick scan of the proposal is asked)

casperiv0 commented 9 months ago

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,
      },
    },
    },
    );
  4. Goes through Mollie flow
  5. 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 commented 9 months ago

Thanks for the quick response :pray: 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 commented 2 months ago

@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 commented 2 months ago

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