Developer forum

Hi Jonatan

• Is there any logic tied to the "Place Order" button in the Swift template which MUST be executed for DynamicWeb to function as expected?

Yes. A cart needs a Dynamicweb payment method set on the PaymentMethodId property. A payment method will have a CheckOuthandler. A Checkouthandler will convert a cart to an order.

The default checkout handler in Dynamicweb is called "DefaultCheckoutHandler" in Dynamicweb - and will just convert the cart to an order without further steps.

A checkouthandler have 2 steps

1. StartCheckout - which is called when "Complete order" button in Swift is clicked (Going to the step in the cart marked as checkout step)
2. Redirect - which is called when a callback is received from the external payment gateway. 

A checkouthandler with an external payment gateway will send the user to the payment gateway in step 1, and get the callback in step 2 and in step 2 call CheckoutDone on the base class.

• We'd like to make a back-end API call to create a new Payment Session and use data from the response to list the available payment methods when the customer reaches the "Checkout" page as illustrated by the attached slides.
  Is this possible? And if do, which event do we need to create a hook for?

One Dynamicweb Payment method has one checkouthandler - it can not list payment options from the payment gateway. Instead you can create several payment methods using the same checkouthandler and configure it to use different payment methods - e.g. Visa/Master and MobilePay.

• Where do we find an event life-cycle diagrams, which illustrates which events we can create hooks for?

It does not exist - but it is 2 simple steps explained above.

• Transpayrent will send a Single Sign-On request to DynamicWeb when the consumer elects to pay with the Webshop's Wallet
  ...

This is not an integration option we have seen before and we have no guidance. I worry about PCI 4.0 compliance in a setup as you descripe. Nets easy and Klarna that does these things, will usually keep the authentication on their side of the process to avoid integration and security concerns.

• The Order object includes several properties related to a payment, including the below, and we'd appreciate guidance as to which would be best to use:
  • GatewayResult
  • TransactionNumber
  • TransactionPayGatewayCode
  • TransactionToken 
  • TransactionValue

You can use which ever you want.

• Gateway result traditionally contains the entire payload from the gateway callback - in old days an entire XML document, these days a JSON document.
• TransactionNumber is the TransactionNumber from the payment gateway - usually part of the above XML or JSON document
• TransactionPayGatewayCode is an old one - used rarely to hold information about the type of payment
• TransactionCardNumber - last 4 digit of the card, if used
• TransactionStatus - "Cancelled", "Accepted" or whatever is returned
• TransactionAmount - the amount from the payment gateway - sometimes differes because the external payment gateway adds fees after the order is created
• TransactionValue - rarely used, but can hold information about the amount send to the payment gateway
• TransactionToken - is a credit card is saved during the checkout process (Implementing the ISavedCard interface)

Thanks for the response Nicolai,

From your input I get the impression that the Checkout Handler in Dynamic Web is designed around the concept of the customer being redirected to the Payment Gateway's Hosted Payment Page?

We'd like to keep the Payment Page within Dynamic Web (without the use of iframes), so it's a seamlessly integrated part of the Webshop (read: 1st class citizen within DynamicWeb), just like all other pages in the order flow.
The intend is to not only provide complete control of the UI / UX but also enable full tracking of what the customer does on the payment page (without running into issues with PCI DSS).

Transpayrent's Single Sign-On approach is fully PCI DSS compliant (just like all of our other payment services) and by having DynamicWeb handling the Authentication we can create a true, Amazon like, 1-click payment experience where as others such as NETS, Klarna etc. would require the customer to login again with NETS and / or Klarna.

Which callback URL would we need to configure for Single Sign-On and how do we create a SingleSignOnHandler?
I imagine it could be implemented in step 2 of the CheckoutHandler by looking at the format of the Payload?

Hi Jonatan

Sounds like a very nice checkout flow. 

> From your input I get the impression that the Checkout Handler in Dynamic Web is designed around the concept of the customer being redirected to the Payment Gateway's Hosted Payment Page?

Not nescessary to do a redirect - Stripe does it more or less as you describe, Adyen, Nets easy and others also supports doing somewthing similar to what you describe.

But you have to do it client side - as you need to render some UI and need to execute some logic on the client.

Given the below could be a checkout page in Dynamicweb (this is just an example - could look like anything).

When the user selects a payment method, you can have the checkouthandler associated with that payment method, implement the RenderInlineForm method of the base class and use that to inject or render what you need in order to start payments in the client:

public override string RenderInlineForm(Order order)
{
    if (RenderInline)
    {
        LogEvent(order, "Render inline form");
        var formTemplate = new Template(PostTemplate);
        return RenderPaymentForm(order, formTemplate);
    }

    return string.Empty;
}

What other systems do in this step is that under their payment method chosen they either render a message that the user will be redirected or they render a credit card form. You can do the same here. When the user enters credit card information, checks accept terms and submit the order, you can execute your steps - make a fetch to a custom DW controller to start your payment session, get the response back, do whatever authentication you need (why authenticate at this point?). 

You can also already when the page loads, list your payment options after getting them from your service if a payment of type Transpayrent has been chosen in DW and start the flow in that way - you would do that in the markup rendered in the .RenderInlineForm method.

In the example above a template is used so it can be modified or different templates can be used depending on needs. Or you can return hardcoded markup.

IMPORTANT: You need to add a template tag to your checkout template named "Ecom:Cart.PaymentInlineForm" to control where the markup is rendered.

The above example is from DibsEasy - I have sent you the code for you to explore.

I understand that your system is PCI compliant. But with the PCI 4.0 update as of March this year, when the payment form is embedded into the webpage (using iframe or whatever), it is our impression and experience that our customer have to do a SAQ them selves to be compliant (https://blog.pcisecuritystandards.org/pci-dss-v4-whats-new-with-self-assessment-questionnaires). Adyen and Klarna is going in that direction. Now you are the gateway your self, so you might not require this from your customers, and I do not know what requirements you have from your aquirer (if you are not one you self) or the payment methods you support (Visa, MC etc.). Either way, you can still do what you decribe.

BR Nicolai

Thank you for the swift reply Nicolai,

Our intend is to create the best possible payment experience in DynamicWeb by seamlessly integrating Transpayrent's Payment Services as this increases the Webshop's conversion rate significantly. In 2023, Transpayrent's Seamlessly Integrated Payment Solution increased the coversion rate for our merchants by 9,9% on average and in some instances up to 15% compared to Industry Standards.
That's easily DKK 1M+ in additional revenue for an average Webshop, simply from caring about the Payment Experience.

Please have a look at our Payment Demo for an illustration of what we're striving to achieve.

To retrieve the available Payment Methods, including any cards stored in the customer's wallet, we'll need to start a Payment Session through a Server to Server call.
I assume we could execute this call in the suggested RenderInlineForm method and use the response to render the UI for each payment method?

This would work for most payment methods, however Apple Pay and Google Pay (and Samsung Pay...) uses the W3C Payment Request API, which imposes a few additional requirements, namely:

• The "Buy with Apple Pay" / "Buy with Google Pay" MUST be rendered by Apple Pay / Google Pay
• Execution of any custom function is prohibited when the user to click the "Buy with Apple / Google Pay" button
• Any custom logic can ONLY be executed after the user has selected the Payment Instrument from the Payment Sheet displayed by Apple Pay / Google Pay

Assuming that Transpayrent is the only configured Payment Option, a solution could be to call the CheckoutHandler automatically upon loading of the Checkout page?
This would result in the Cart automatically being converted into an Order without the consumer having accepted the Terms & Conditions, which may have unforseen consequences within DynamicWeb?

Security wise, Transpayrent's Seamlessly Integrated Payment Solution is fully PCI compliant and doesn't bring Merchants / Webshops into PCI scope.
A SAQ-A or SAQ-A-EP isn't new to PCI DSS 4.0 and is generally acquirer dependent, Adyen for instance requires a SAQ-A to be completed for Merchants / Webshops that use their "Client Side Encryption" approach where as Payment Providers like Stripe and Transpayrent does not.

This is a developer forum. No need to be a sales guys in your questions :-).

If you have specific questions I will be happy to answer them. 

To retrieve the available Payment Methods when a transpayrent payment has been selected, you can use RenderInlineForm.

If a payment with transpayrent is selected, the RenderInlineForm method from your implementatioin is executed. You can do whatever you like inside that method, but listing payments should be enough. I think it is wrong to start a payment session at this point as the user could choose to go back in the browser an alter the cart. But you can of course create the payment session at this stage and then create new ones if needed because of cart changes.

I have shared our integration to Nets Easy - you can see in there how things can be handled.