SetPaymentProvider Checkout "MERCHANT_URL_NOT_SET"

Hi, I have installed Qliro locally (docker), but when I loading the checkout I get an error when setting payment provider:
Here is the errorlog from the Qliro app:

{"ErrorCode":"MERCHANT_URL_NOT_SET","ErrorMessage":"Merchant URL errors: MerchantOrderManagementStatusPushUrl is missing, MerchantCheckoutStatusPushUrl is missing","ErrorReference":"5eec4d24-cd96-4856-84c2-ac68f57e09f1"}

I have added a configuration file that has my local endpoint. I have a stable version of the dns resolver.

Litium version: 8.2

Are the app accessible on a public domain address over https?

I cant see it’s not. Got it installed.
Is there a ping endpoint to see if it’s alive i could test?

You can use the health endpoints to see if the app is up and running, example the https://your-custom-domain/health/startup

Response is healthy.

@patric.forsgard I have tried to gather more information, I dont have any, is this a configuration issue? I have taken the configuration that is on docs, is there an error in that one maybe?

If the AppMetadata__AppUrl not is a public accessible address, the push-url is not set and you should got this error message. Did you assign a public accessible address to AppMetadata__AppUrl in the docker compose file?

yes I did, this is set, it’s the same url I used to install the app. I’m using domain. Is there any other type of information I can gather to make this easier for you?

The is a public domain, but it is not public accessible. You need to have a domain name that everyone can use that will reach your container to get it to work, one way is to use ngrok to create a tunnel with a public address that you will use for your app-metadata, see example the Setting up ngrok to work with Litium apps - Tips & Tricks - Litium Forum

@patric.forsgard what is the plan to have a docker container for an app when we still are dependent on outside infrastrucutre? (is this so we could run the same container on a development server withouth having to involve you in that hosting environment?)

I can setup a ngrok tunnel, but when I want to switch between projects i have to everytime, change my ngrok url, might be nothing for some, but changing project and having multiple versions of qlliro for multiple projects is not sustainible, to start stop and changing the compose file.

If this is the official solution please update the doc site so more people can see this.

@patric.forsgard Im just gonna say it in this thread, it can become verry easy to get hanged up on the negative parts becuase this is the only thing that we talk about, or further more issues.

but Litium 8 have givven us so many good things.

Litium apps (the thought here is really good)
.Net 6 (and everything that comes with it)
Cronjobs adaptation
Better seperation between business and domain, the new sales is better.

You have done a good improvment on the naming also, there are good things! I just want to point this out a little as for the last weeks, it feels like im complaining a lot!


Qliro is the first and for the moment only app that require that they can connect directly into the Qliro payment app. If the Qliro payment app is running without container you will have the same requirement.

Ngrok is only one tool that is simple to use to make the public traffic reach the developer computer. It exists other proxy tools that doing similar thing that can be self hosted if that is a preferable choice.

If you not want to use a proxy tool you have other solutions as:

  • Expose your computer directly on the internet with a public domain address. May not be good for security reason so nothing that I will recommend.
  • Forward public traffic through the firewall into the computer that running docker and then using a custom domain name so the resource will be accessible from outside.
  • Running the container inside an orchestrator, like Kubernetes that will handle the ingress and egress traffic to the correct location, for this to work the orchestrator need to be accessible from public.
  • Using an existing IIS, or other webserver, as a proxy that will forwarding the request into your computer, in this case the existing webserver need possibility to connect to your computer.

In above cases when exposing the ISP connection; either directly or though firewall, the ISP may not providing an public address and instead using cg-nat. If the ISP is using cg-nat you will still not being accessible from the public.

To start of, to tunnel the traffic was the solution. Thank you!!

If Qliro is a special case, okey, I’ll buy the complication that is necessary, what I dont buy is that this is not written for developers on the doc site, even more, it’s the only app for the moment and this kind off information is missing? Can you guys please update this so future people wont hit the same error message as me and be confused that it’s my local site that needs to be exposed for Qliro to communicate back to me.

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.