FAQ

What is PSD2?

The Second Payment Services Directive obliges banks to open up payments infrastructure and customer data to other organisations (third party service providers) with customers consent.

Are there any restrictions to sandbox usage?

No. Sandbox is free and available for everybody to test and develop.

What kind of data your Sandbox contains?

Our sandbox contains dynamic data to get the best out of testing.

Who maintains Open Banking Developer Portal?

Portal is maintained by Oy Samlink Ab.

How can I gain access to production environment?

Production PSD2 API for each bank will be available at omasp-psdapi.samlink.fi, pop-psdapi.samlink.fi and sp-psdapi.samlink.fi respectively. Production TPP registration API for all banks will be available at reg.samlink.fi. Production authorization service for all banks will be available at authservice.samlink.fi.

When API was available in production?

API has been available in production since 9th of September 2019.

Accessibility

Accessibility is the practice of making your websites usable by as many people as possible.
It includes:

  • Semantic HTML, which improves accessibility.
  • Caring about accessibility demonstrates good ethics and morals, which improves your public image.
  • Other good practices that improve accessibility also make your site more usable by other groups, such as mobile phone users or those on low network speed.

PSD2 Fallback solution

Service Location

The PSD2 fallback solution can only be accessed via following addresses:

Login

In order to log into NetBank on behalf of a customer, a TPP has to sign the login request using a valid eIDAS QSEAL certificate. This signature proves that the TPP is legally allowed to act as a service provider. The login request to be signed is the HTTP POST message generated from the username input form submission (or username/password when TAN list is used) on the NetBank login page.

Signing uses the same mechanism as used in the Berlin Group PSD2 API v1.3: [ https://tools.ietf.org/html/draft-cavage-http-signatures-10 ]. Headers that must be included in the login message are:

  • Digest: SHA-256 or SHA-512 digest of the message content, as specified by Berlin Group Implementation Guideline.
  • X-Request-ID: UUID, as specified by Berlin Group Implementation Guideline.
  • TPP-Signature-Certificate: TPP's eIDAS QSEAL certificate, as specified by Berlin Group Implementation Guideline.
  • Signature: as specified by Berlin Group Implementation Guideline (chapter 12.2), constructed from headers Digest, X-Request-ID and TPP-Redirect-URI.

The Digest and X-Request-ID headers must be included in the signature.

Example

Assuming a TPP login on behalf of a customer who has user identifier '00000000' and password 'password'.

The HTML form element in this login page instance has form identifier "id27" and thus the HTTP POST message is: [id27_hf_0=&fakeUserKeyDoNotRemove11=&username=00000000&password=password&loginButton=1].

The SHA-256 digest generated from the message body is: [SHA-256=RLCxP4W48XJU69Q22/glEa6BzmI9j77dM2qNFs53P0Q=].

A random UUID generated for the X-Request-ID is: [fa2d5609-b5ba-4bd2-a4d4-254e69a2972e]

Thus the headers are (the actual signature and certificate below are truncated to be human readable):

Digest: SHA-256=RLCxP4W48XJU69Q22/glEa6BzmI9j77dM2qNFs53P0Q=
Signature: keyId="SN=f3abe28bee1e8f10,CA=OID.2.5.4.97=PSDFI-ABC-123456, C=FI, O=Samlink, CN=PSD2",\
    algorithm="rsa-sha512",\
    headers="Digest X-Request-ID",\
    signature="Ntxy.....Sg=="
TPP-Signature-Certificate: MIIDDjCCAfYCCQDzq+KL7h6PEDANBg.....nRK7aXUSsmLQQDlMRtPHIbOR4sOzXX
X-Request-ID: fa2d5609-b5ba-4bd2-a4d4-254e69a2972e

Change log

2020-02-06

Consent and Payment initiation response _links/scaOAuth now points to OAuth metadata endpoint, instead of straight to authorize endpoint:

{ 
  "_links": 
    { 
      "scaOAuth": "https://sml-prod-psd2.azure-api.net/.wellknown/oauth-authorization-server",
      "self": "/psd2/v1/consents/gqHPIqjwpp",
      "status": "/psd2/v1/consents/gqHPIqjwpp/status" 
    },
  "consentId": "gqHPIqjwpp",
  "consentStatus": "received",
  "scaMethods": [] 
}

Metadata endpoint https://sml-prod-psd2.azure-api.net/.wellknown/oauth-authorization-server will return a JSON with the authorization and token endpoints:

{ 
  "issuer" : "https://sml-prod-psd2.azure-api.net", 
  "authorization_endpoint" : "https://sml-prod-psd2.azure-api.net/samlink-api-sandbox/oauth/authorize", 
  "token_endpoint" : "https://sml-prod-psd2.azure-api.net/samlink-api-sandbox/oauth/token"
}

Payment initiation response now contains the _links element as above, and transactionFeeIndicator element with value "false".

Consent usage counts are now not increased if the request contains PSU-IP-Address header, which indicates that the consent user is active in the TPP application while the request was made.

2020-03-08

Added support for future dated payments with requestedExecutionDate in the future.

New sandbox endpoint /management/execute-future-dated-payments to help with testing future payments.

2020-12-09

Added Card Account operations, and made debtorAccount optional in payment initiation.

  • Read List of Card Accounts: GET /v1/card-accounts
  • Read Card Account Transaction List: GET /v1/card-accounts/{account-id}/transactions
  • DebtorAccount is now optional in Payment initiation request. Leaving the field empty will allow the PSU to select the account after login.