DW10 Payment Handler and User Creation

These issues represent significant technical challenges in our composable headless solution, and we seek insights to resolve them effectively.

User Creation Endpoint:

When dealing with the user creation process in our composable headless solution, there are two specific concerns: setting the user's password and associating the user with a specific group. The challenge we face here is that the Create User endpoint accepts a UserViewModel, but upon inspecting the schema of this model, we encounter two notable omissions: the absence of fields for password and group assignment. However, upon reviewing the API documentation at https://doc.dynamicweb.dev/webapi/delivery-api.html#Dynamicweb_API_10_0_0_RC9_Users_Create, it seems there may be a provision for setting at least the password during user creation. Our primary query revolves around how to achieve this password setting and group association using this endpoint.

Order Creation and Payment Handling:

Another issue we've encountered pertains to the creation of orders via the /dwapi/ecommerce/carts/{secret}/createorder endpoint. In this scenario, we've noticed that the process doesn't trigger any interaction with the designated payment provider configured for the order. Consequently, we're faced with a critical question: how should we appropriately manage payment processing when creating orders through the API? It's imperative to note that, during API-based order creation, we haven't been able to retrieve any information related to payment forms or tentative payment IDs. We're keen to understand the correct workflow and configuration steps to ensure seamless payment handling within the DWAPI context.

Thanks

/Umar

Hi Umar

Good questions

@1: Setting the password and adding groups to a user on an anonymous endpoint is a security issue that we have not solved as part of the delivery API yet. If these 2 settings where open anyone can create a user and put the user into any group giving access to things that might not be intended. So to solve this in a secure way, there need to be some kind of mechanism to validate that it is a real user and that the user is allowed to be put into given groups - and users might need admin approval. Using the regular frontend for Dynamicweb, there are settings on the user management module that will send emails to users when they are new and you have a list of groups the user is allowed to become member of. These settings are currently unavailable on the delivery APIs and that is why you cannot do that as of now.

Another issue related to this is that if we do send an email to the user - what URL should we give them to validate? Since the URL and logic is now in the JS implementation and not in Dynamicweb frontend we do not know.

The solution might be to send an email to the created user that provide a /dwapi/user/approve/{secret} url that will redirect the user to a URL you specify with the user creation.

I'll be happy to hear your thoughts on how you think this could and should be implemented.

Related to this, you also have the management API in Dynamicweb 10 - it requires authentication for the backend - but it can be used to do everything in the backend. I.e. setting the password, send out emails etc. So this can be used now to fill the gap.

@2: In the latest additions to the Dynamicweb 10 delivery API, a /carts/{secret}/checkout and /carts/{secret}/callback endpoint have been added (See below). Using these you can kind of start a checkout using Dynamicweb payment providers (as of current writing only Quickpay and Nets easy are supported on headless).

But - since you are doing a headless implementation, payments can be handled quite differently. You do not need our providers to do payments. You can pretty simple integrate to almost any payment gateway in your headless implementation and complete the order when done.

Headless implementations use "Micro services" - Dynamicweb being one, i.e. Clerk for personalisation and recommendations, Angolia for search and so on. Payments are one of these micro services and you can and should consider integrating them directly. Usually really simple. A competitor of ours that is a pure headless commerce tool, only support payment gateways in this way (they have recently added their own payment gateway integration that can be used more natively)

You can however as mentioned use the /checkout endpoint in DW10 - but it will return markup to actually start the payment window. Each payment provider have quite different ways of starting payments and what is needed to start the payment windows cannot be exposed in json data. So we return markup to start the payment and you have to inject that markup to your DOM of your app. Not 'pure' headless, but it works.

Yet another alternative is to have the actual payment checkout step on a regular Dynamicweb page (not the cart and not the options the user is making). So when the user walk through the cart, fills out information etc. and eventually clicks "Place order" you submit to a Dynamicweb page /default.aspx?id=123 that has nothing but the payment checkout step - this step will then imediately start the payment window and handle the callback etc. The receipt is then again shown in your JS app.

Developer forum

DW10 Payment Handler and User Creation

Replies