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