Callback URLs and responses explained

When you register callbacks in the plugin they will also show up in the administration interface like this:

First of all, it is always important that the callbacks url are up to date. When you change credentials for example, they have to re-register so that salt keys and other data is really matching the data on Resurs Bank. This is however not a page about how that is made, but an explanation of the URLs. You may wonder why they look like this.

The callback urls are always using the format that WooCommerce and WordPress are using. From the method getWcApiUrl() in WooCommerce.php we will always get the proper API-call format from WooCommerce itself.

    public static function getWcApiUrl()
    {
        return sprintf('%s', WC()->api_request_url('ResursDefault'));
    }

By doing this, we never have to worry about if WooCommerce will be able to handle the inbound requests from a callback handler. The above image is very much based on "pretty urls". That said, in our case we are using apache and mod_rewrite. The URLs could therefore look differently on your site. The parameters are described below.

sha1/md5($callbackPaymentId . ($callbackResult !== null ? $callbackResult : null) . $saltKey)

Callback responses

When a callback is sent from Resurs Bank, the plugin may answer differently depending on what happened during the callback. For the moment we return several response codes, described below. We are also returning a json-formatted response body in case someone wants to test callbacks manually. It looks like this:

{
    "aliveConfirm": true,
    "actual": "UPDATE",
    "digestCode": 406,
    "errors": {
        "code": 0,
        "message": ""
    }
}

JSON explained

This body is not only visible in a production environment. However, as we know it the http response code is always visible in logs somewhere so for that part there's no problems. However, sometimes merchants or developers needs to extend their error checking som instead of push up breakpoints and such, in an environment, the json body response is an extra errorchecking layer. This is what you get from it (see the example above).

{
    "code": 0,
    "message": ""
}

Responses explained

First of all: Avoid using 200 as a response code. Since this is very much a system default, neither the plugin nor the support will be sure if a callback has been delivered if your system responds with 200 all the time. 200 can for example indicate reachability but not for the plugin. On specific case found on the field was that the platform itself actually had 403 error when a callback was sent, but the redirect created a 200 which made us believe that there was no errors. However, if a server blocks access with a 403, but repsonds with 200, the problem lies within the platform - not the plugin.

Responses caused by someone else

Some errors may be unpredictable, so if you get any other message or response in the callback, you may want to look up that specific error. This is an example:

{
	"aliveConfirm": false,
	"actual": "UPDATE",
	"errors": {
		"code": 616,
		"message": "You are not of type Skrull nor Kree."
	},
	"digestCode": 616
}

The error itself can also be seen in the HTTP response header in the (for Chrome) network section of the request: