Skip to main content

Start payment cancellation authorisation process

POST 
/v1/payments/:paymentProduct/:paymentId/cancellation-authorisations

The cancellation flow is similar to a payment authorisation flow. See XS2A Framework Implementation Guidelines, Section 7.1 for additional details.

Request​

Path Parameters

    paymentProduct stringrequired

    Possible values: [norwegian-domestic-credit-transfers, instant-norwegian-domestic-credit-transfers-straks, cross-border-credit-transfers, sepa-credit-transfers]

    The product of the payment cancellation that should be authorised.

    Example: norwegian-domestic-credit-transfers
    paymentId stringrequired

    Id of the payment cancellation to authorise.

    Example: enc!!H6fD9HS7Y7peXJh1HqC34RFgGfF992bjabcRx5n==

Header Parameters

    x-accept-fix stringrequired

    Make a published future breaking change active before the date when it is going to be made default, for adopting changes early. (see Future Breaking Changes)

    Example: new-feature-name-as-publised-in-documentation
    Accept string

    Advertises which content types, expressed as MIME types, the client is able to understand. Using content negotiation, the server then selects one of the proposals, uses it and informs the client of its choice with the Content-Type response header.

    Example: application/json
    Accept-Charset string

    Advertises which character set the client is able to understand. Using content negotiation, the server then selects one of the proposals, uses it and informs the client of its choice within the Content-Type response header.

    Example: utf-8
    Accept-Encoding string

    Advertises which content encoding, usually a compression algorithm, the client is able to understand. Using content negotiation, the server selects one of the proposals, uses it and informs the client of its choice with the Content-Encoding response header.

    Example: deflate, gzip;q=1.0, *;q=0.5
    Accept-Language string

    Advertises which natural languages the client is able to understand, and which locale variant is preferred. Using content negotiation, the server then selects one of the proposals, uses it and informs the client of its choice with the Content-Language response header.

    Example: en-US,en;q=0.7,nb;q=0.3
    Host string

    The domain name of the server (for virtual hosting), and (optionally) the TCP port number on which the server is listening.

    Example: psd2.sb1ls.no
    X-Request-ID stringrequired

    Request identifier, unique to the call, as determined by the TPP.

    Example: 4eba4445-1a4b-47b8-bdd5-4e56ef026b19
    TPP-Session-ID stringrequired

    TPP session identifier.

    Example: b29f79d9-12ea-462b-ad8a-8ad38b8c57b7
    TPP-Redirect-URI stringrequired

    URI of the TPP, where the transaction flow shall be redirected to after a Redirect.

    Example: https://httpbin.org/get
    TPP-Redirect-Preferred string

    Set to false to automatically trigger biometric authentication for mobile apps whenever available. Default is true.

    Example: false
    TPP-Signature-Certificate stringrequired

    The certificate used for signing the request in base64 encoding.

    Example: MIFFTzCCAzegAkIBAgMJANnQVDLqktJUMA0GCS....8WLZOX3YxNoH4k==
    Signature stringrequired

    HTTP Message Signature as specified by https://tools.ietf.org/html/draft-cavage-http-signatures-10 with requirements imposed by Berlin Group's NextGenPSD2 Framework.

    • keyId must be formatted as keyId="SN=XXX,CA=YYY" where XXX is the serial number of the signing certificate in hexadecimal encoding and YYY is the ful Distinguished Name of the Certificate Authority having certificate
    • algorithm must identify the same algorithm for the signature as presented in the signing certificate and should be rsa-sha256
    • headers must contain date, digest, x-request-id, psu-id, psu-corporate-id, and tpp-redirect-uri when available
    • signature must be computed as Base64(RSA-SHA256(signingString))

    If any values in the Signature header is ISO-8859-1 or UTF-8 encoded you need to URL encode the Signature header according to RFC 2047 which means MIME encoding the signature.

    Also the signature must be wrapped using this format: =?charset?encoding?encoded signature?=

    Example of this encoding: =?utf-8?B?a2V5QTQsQ0E9Mi41LjQuOTc9IzB........jMTM1MDUzNDQ0ZTRmMmQ0NjUz?=

    Java example of how to implement encoding:

    if (charset.equals(StandardCharsets.UTF_8)) {
      Signature = String.format("=?utf-8?B?%s?=", Base64.getEncoder().encodeToString(signature.getBytes(StandardCharsets.UTF_8)));
    }
    Example: keyId="SN=6AEB4444FBAAD267,CA=O=PSDNO-FSA-ABCA,L=Trondheim,C=NO", algorithm="rsa-sha256", headers="date x-request-id tpp-redirect-uri psu-id", signature="***************"
    PSU-ID UUIDrequired

    The PSU identifier.

    Example: 49ae0cfe-6b72-4310-81f5-ad4eef897fe3
    X-PSU-IDENTITY string

    As an alternative to PSU-ID, the PSU can be identified by norwegian personal identification number (national identity number/D-number)

    Example: 01010123456
    X-PSU-AuthMethod-Preferred string

    Preferred authentication method will be selected if available for the PSU

    Example: N/A
    PSU-Corporate-ID string

    The PSU Corporate agreement identifier.

    Example: aog5kNSbDNo2srEPAqsCGaR8LNCAfLVlKPzbwKZQJzI=
    PSU-Context string

    Possible values: [PRIVATE, CORPORATE]

    Explicitly set PSU context. Required for single SCA payment initiation.

    Example: PRIVATE
    PSU-IP-Address stringrequired

    The forwarded IP Address header field consists of the corresponding HTTP request IP Address field between PSU and TPP.

    Example: 153.110.241.229
    PSU-IP-Port string

    The forwarded IP Port header field consists of the corresponding HTTP request IP Port field between PSU and TPP, if available.

    Example: 443
    PSU-User-Agent string

    The forwarded value for the User-Agent header field between the PSU and TPP, if available.

    Example: Mozilla/5.0 (Windows NT 10.0; …) Gecko/20100101 Firefox/63.0
    PSU-Accept string

    The forwarded value for the Accept header field between the PSU and TPP, if available.

    Example: application/json
    PSU-Accept-Charset string

    The forwarded value for the Accept-Charset header field between the PSU and TPP, if available.

    Example: utf-8
    PSU-Accept-Encoding string

    The forwarded value for the Accept-Encoding header field between the PSU and TPP, if available.

    Example: gzip, deflate, br
    PSU-Accept-Language string

    The forwarded value for the Accept-Language header field between the PSU and TPP, if available.

    Example: en-US,en;q=0.7,nb;q=0.3
    PSU-HTTP-Method string

    Possible values: [GET, POST, PUT, PATCH, DELETE]

    The forwarded value for the HTTP method used between the PSU and TPP, if available.

    Example: GET
    PSU-Device-ID UUID

    The forwarded value of the device ID used by the PSU, if available.

    Example: 35-67660-48540-8
    PSU-Geo-Location string

    The forwarded value of the Geo Location of the corresponding HTTP request between the PSU and TPP, if available.

    Example: GEO:52.506931,13.144558

Responses​

CREATED

Schema

    scaStatus string

    Possible values: [RECEIVED, PSU_IDENTIFIED, PSU_AUTHENTICATED, SCA_METHOD_SELECTED, STARTED, FINALISED, FAILED, EXEMPTED]

    _links

    object

    property name*

    Link

    href stringrequired
    verbs string[]required

    Possible values: [GET, PUT, POST, DELETE]

Loading...