Hi Matt,

As pointed out, no new D2 accounts will be created, and Easy is the replacement :/

best, Søren

Yea, this is why it's urgent that they address this and why we suggest others keep pushing them to get the fix in place. We've had a few people asking, but right now their API isn't compatible. Continue/Cancel URL registration is a pretty common pattern in payment providers, including in their own D2 so not sure why it wasn't implemented for Dibs Easy.

Matt

Hi Bo

Yes, it is working, but it might need some additional testing. You can follow the progress in the PR here: https://github.com/vendrhub/vendr-payment-provider-dibs/pull/12

Previous it had some issues, because both a successful payment and a cancelled payment via the "go back" link in the payment window, both triggered the payment.checkout.completed webhook event, so when getting the response from the webhook, we had no way to know if the payment was actually cancelled or successful.

I have been in touch with DIBS/Nets a lot regarding this, and suggested we could have both the existing payment.checkout.completed and payment.checkout.cancelled and also a payment.checkout.failed like other payment gateways have.

However at the time of this writing we still only have the payment.checkout.completed (unless they haven't documented new webhooks).

However they have changes the cancelled payment, so it no longer trigger the payment.checkout.completed (I would say this was a breaking change), but anyway this is already released).

Instead cancelled payments would return to the webshop with a status=cancel querystring, which should rely on Referrer-Policy.

I got the following explaining from Nets here: https://github.com/vendrhub/vendr-payment-provider-dibs/pull/12#issuecomment-778838684

I have also updated the payment provider to support the new PriceAdjustment entity in Vendr v1.4.0, so it should work with discounts, gift cards on custom discounts/fees, e.g. a deposit fee, but I haven't fully tested this.

/Bjarne

Hi Bjarne.

Ive also been in touch with NETS with the same issue. We have some D2 we need to change to Easy.

I havent testet it yet, but i was told by NETS that they got a cancel and return url you can set. Would that help?

I haven't heard of a specific cancel url, but they may refer to the Referrer-Policy header.

Payment gateways like e.g. Stripe, Reepay and Adyen has a configuration option in their admin tools to configurate, where the webhook event should POST the response to - the callback URL (ProcessCallback method).

Here is an example for Stripe: https://vendr.net/docs/payment-providers/stripe/1-1-0/stripe-checkout/getting-started/configuring-stripe/#webhook

DIBS Easy doesn't handle this same way, but the callback URL is sent as part of the payment request.

Unfortunately their documentation is lacking from recent updates and especially the documentation on the HostedPaymentWindow is limited.

/Bjarne

Hi Bjarne.

I looked into the mail i got from DIBS (now NETS). The cancelUrl can only be used in the hosted payment window (which make sense, i guess). It should be set the same place where you set the returnUrl. So that would be in the "checkout" object. They send me these 2 links https://tech.dibspayment.com/node4555edit/checkout-introduction and https://tech.dibspayment.com/easy/api/paymentapi

Can you use that for anything?

Hi Bo

Yes, I could try the cancelUrl property, but pretty hard to know about this as developer, when it hasn't been documented. It may be a hidden gem that we magically should know about :)

Furthermore the webhook has been updated wiht headers (previous it only had eventName, url and authorization), but yet nothing about the use of it and valid values. https://tech.dibspayment.com/easy/api/paymentapi#webhooks

Now it has only been a year since I first raised the issue to Nets and told them a lot of times to update the documentation.

/Bjarne

Hi Bjarne.

I agree. They need better documentation and also better support mail response times.

Its proberbly something they added later and forgot to document.

Did you know that the api also require the order items? I did not know that, but was told by their support that its a requirement. In my opinion that should be handled by the shop and not by the payment provider.

"order":{  
   "items":[  
      {  
         "reference":"Reference 001",
         "name":"Test product 001",
         "quantity":1,
         "unit":"units",
         "unitPrice":5000,
         "taxRate":100,
         "taxAmount":50,
         "grossTotalAmount":"5000",
         "netTotalAmount":"5000"
      },
      {  
         "reference":"discount",
         "name":"discount",
         "quantity":1,
         "unit":"units",
         "unitPrice":0,
         "taxRate":0,
         "taxAmount":0,
         "grossTotalAmount":"-1000",
         "netTotalAmount":"-1000"
      },

   ]
}

Hi Bo

I will try with the cancelUrl and see if it has any effect. Hopefully they will update the documentation, so developers know how to integrate with DIBS Easy.

It seems the focus has more been on the embedded checkout option, but not much on the hosted payment window.

Yes, you are right DIBS Easy require the order items to be set, which I already have configurated, but not all payment gateways require this, but for some acquirers like Klarna the do, e.g. in Adyen it isn't required, but if is if using Klarna: https://github.com/vendrcontrib/vendr-payment-provider-adyen

I just tried generating a payment link using cancelUrl and it actually seems to redirect to this, when clicking "go back" from payment window.

Need to test it further now.

Do you have any further knowledge about the webhook headers? It has been added to the documentation, but nothing about what is used for. The authorization property is already returned as a header in the webhook notification event.

/Bjarne

Hi Bjarne.

I think they updatet the webhook documentation again. So i guess you have to make a webhook for each event you want to get a server to server call.

notifications - Used to get the status of a transaction (optional)

webhooks - List of webhooks the merchant wants to register for the payment. Maximum number of webhooks is 32.

eventName - Input the event you want to listen for

• payment.created (When a payment is created)
• payment.checkout.completed (When Checkout is completed)
• payment.charge.failed (When a charge has failed)
• payment.refund.failed (When a refund has not gone through)
• payment.cancel.created (When a reservation has been canceled)

url - The callback is sent to this url on the merchant site. Must be https. Maximum length is 256 characters.

authorization - Authorization header of the callback sent to the merchant site will be set to this value. You may choose whatever key you want as long as it fits the format described in this section. Format: * 8 to 64 characters * "a-z," "A-Z", "0-9" and "-" (regex: [a-zA-Z0-9-])

headers - I guess you can set custom headers here, that they return to you. But i dont know.

"notifications":{  
      "webHooks":[  
         {  
            "eventName":"string",
            "url":"string",
            "authorization":"string",
            "headers": [
               {
                  "string": "string"
               },
               {
                  "string": "string"
               }
            ]
         }
      ]
   }

One thing i just found out is that there aint no way to set an errorUrl atm, only cancelUrl and returnUrl. They said they are working on it (whatever that means)

The documentation looks pretty much the same as previous. The cancelUrl is working yet not documented.

Only the headers on webhook events was added some time ago, but not documented furhter. I wonder what would happen if sending authorization headers since authorization property already is returned as header in the response.

The payment provider is already using the payment.checkout.completed webhook event.

Regarding capture, refund and cancel it is currently using the POST endpoints for these, but works well also if manage the actions from DIBS Easy portal, since the GET is checking payment status, but I guess it should work using the webhook events as well.

/Bjarne