You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In order to support the option of doing invoicing through other channels than Nets, for instance from Unit4 after the form has been submitted, we believe we need to support dynamic selection of payment processor. That would enable apps to make a custom payment processor implementation for invoices handled outside the app, which does very little and just allows the process to continue.
We ensure that it works to have multiple payment steps in a single process and leaves it up to the user to write gateways to select the task that uses the correct payment processor.
We extend the IOrderDetailsCalculator interface to give the service owner the possibility to determine the correct payment processor through C# logic, based on the form data or some other variable. Then we just use whatever they tell us when calling start payment. Luftfartstilsynet could then have a mock payment processor which does basically nothing for when they are going to do the invoicing themselves.
We create a default "Select a payment processor" GUI, where we just list the different payment processors with a friendly name and give a out-of-the-box experience for all service owners. This GUI would not show if only one payment provider is configured on the process step.
The payment processor that is used for a payment is already stored in paymentInformation.json.
The text was updated successfully, but these errors were encountered:
I updated list with the alternative to use separate payment tasks and process gateways to select the correct one.
Also I think these are not so much alternatives, but different levels of functionality we can implement.
There are no reason we should have something that does not support separate payment taks, so this solutions will be availible anyway.
Even if we add GUI for the user to select the payment provider, it makes sense to let the app developer both restrict the set of choices or provide a default selection through IOrderDetailsCalculator
In order to support the option of doing invoicing through other channels than Nets, for instance from Unit4 after the form has been submitted, we believe we need to support dynamic selection of payment processor. That would enable apps to make a custom payment processor implementation for invoices handled outside the app, which does very little and just allows the process to continue.
We ensure that it works to have multiple payment steps in a single process and leaves it up to the user to write gateways to select the task that uses the correct payment processor.
We extend the IOrderDetailsCalculator interface to give the service owner the possibility to determine the correct payment processor through C# logic, based on the form data or some other variable. Then we just use whatever they tell us when calling start payment. Luftfartstilsynet could then have a mock payment processor which does basically nothing for when they are going to do the invoicing themselves.
We create a default "Select a payment processor" GUI, where we just list the different payment processors with a friendly name and give a out-of-the-box experience for all service owners. This GUI would not show if only one payment provider is configured on the process step.
The payment processor that is used for a payment is already stored in paymentInformation.json.
The text was updated successfully, but these errors were encountered: