Information when something goes wrong.

Edit "Problems" on GitHub


When performing operations against a resource in the Swedbank Pay API Platform, it will respond with a problem message that contain details of the error type if the request could not be successfully performed. Regardless of why the error occurred, the problem message will follow the same structure as specified in the Problem Details for HTTP APIs (RFC 7807) specification.

We generally use the problem message type and status code to identify the nature of the problem. The problems array contains objects with name and description that will often help narrow down the specifics of the problem, usually to the field in the request that was missing or contained invalid data.

The structure of a problem message will look like this:

Problem Example

    "type": "<resource>/inputerror",
    "title": "There was an input error",
    "detail": "Please correct the errors and retry the request",
    "instance": "ec2a9b09-601a-42ae-8e33-a5737e1cf177",
    "status": 400,
    "problems": [{
        "name": "CreditCardParameters.Issuer",
        "description": "minimum one issuer must be enabled"
Field Type Description
type string The URL that identifies the error type. This is the only field usable for programmatic identification of the type of error! When dereferenced, it might lead you to a human readable description of the error and how it can be recovered from.
title string The title contains a human readable description of the error.
detail string A detailed, human readable description of the error and how you can recover from it.
instance string The identifier of the error instance. This might be of use to Swedbank Pay support personnel in order to find the exact error and the context it occurred in.
status integer The HTTP status code that the problem was served with.
action string The action indicates how the error can be recovered from.
problems array The array of problem detail objects.
name string The name of the field, header, object, entity or likewise that was erroneous.
description string The human readable description of what was wrong with the field, header, object, entity or likewise identified by name.

Common Problems

All common problem types will have a URL in the format<error-type>. The URL is an identifier that you can hard-code and implement logic around. It is currently not not possible to dereference this URL, although that might be possible in the future.

Type Status Description
inputerror 400 The server cannot or will not process the request due to an apparent client error (e.g. malformed request syntax, size to large, invalid request).
configurationerror 403 A error relating to configuration issues.
forbidden 403 The request was valid, but the server is refusing the action. The necessary permissions to access the resource might be lacking.
notfound 404 The requested resource could not be found, but may be available in the future. Subsequent requests are permissible.
systemerror 500 A generic error message.

Trustly Problems

There are a few problems specific to the trustly resource that you may want to guard against in your integrations. All Trustly problem types will have the following URL structure:<error-type>

Type Status Description
systemerror 502 Happens if Trustly is experiencing technical difficulties, a contract is configured with bad account name / password, or if the operation (i.e. reversal) is not allowed on the payment due to its current state on Trustly’s end.