Table of Contents

PSD2 Terminology, Actors and Roles

European Payment Services Directive 2015/2366 (also known as PSD2) Defines the following actors and roles:

  • Payment Service User (PSU) - PSUs are the end-users of the services provided by TPPs and ASPSPs. They are either physical persons or entities (organisations, companies, administrations…). They do not interact directly with the PSD2 API.

  • Account Servicing Payment Service Provider (ASPSP) - These are Payment Service Providers (PSPs) which are in charge of holding payment accounts for their customers (PSU).

  • Third Party Provider (TPP) - These actors can intermediate between PSUs and ASPSPs, acting on behalf of PSU. Depending on the services they provide TPPs fall in one of the following categories;

    • Account Information Services (AISP role) will allow the PSU to get information, through a single interface, about all of his/her accounts, whatever the ASPSP holding this account.
    • Payment Initiation Services (PISP role) for requesting a Payment Request approval by the PSU and requesting the subsequent execution through a Credit Transfer.
    • Card Based Payment Instrument Issuers (CBPII role) that will check the coverage of a given payment amount by the PSU’s account.

Neteller acts as Account Servicing Payment Service Provider (ASPSP) in PSD2 terms.

PSD2 Actors and Roles

Neteller Payment Service Directive Compliance

To comply with PSD2, Neteller provides Modified Customer Interface (Mobile APIs) to qualified Third Party Payment Service Providers for the following purposes:

  • Account and Transaction Information for Account Information Service Providers (AISPs)
  • Payment Initiation for Payment Initiation Service Providers (PISPs)

Card-Based Payment Instrument Issuers (CBPIIs) use cases are not supported by Neteller

The APIs are Modified Existing Customer Interfaces fulfilling the following PSD2 requirements:

  • API access is restricted only to Qualified Third Party Providers.
  • TPP API access is restricted to their respective regulated roles
  • Access to PSU account and data from TPP requires explicit user conscent, that can be revoked
  • Transaction operations require Strong Customer Authentication

Qualified Third Party Providers

In the context of PSD2, being a qualified Third Party Provider (TPP) means:

  1. Having obtained the authorization from a National Competent Authority (NCA) to operate as a Payment Services Provider, with the roles it requires (AISP, CBPII, PISP). The list of National Register entities can be found on the Open Banking Europe Website.
  2. Having obtained from a Qualified Trust Service Provider (QTSP), Qualified Website Authentication Certificates (QWAC) and Qualified Sealing Certificates (QSealC), that have a PSD2 eIDAS certificate profile. Details on Qualified Trust Service Providers and the PSD2 eIDAS certificate profile can also be found on the Open Banking Europe Website.

Neteller supports only Qualified Website Authentication Certificates (QWAC) certificates for API access

In order for a third party to qualify for production API Access, both steps must have been completed and they must have matching data (the NCA delivers a registration number that must written in the certificate data).

It is possible for a qualified third party to lose its qualification, either because the certificate becomes invalid, or because the NCA decides to revoke the TPP’s authorization.

Third Party Provider OAuth client registration

In order to access Neteller APIs, the Third Party Providers are required to register OAuth 2 Clients for their applications. Registration and management of OAuth 2 Clients is provided by PSD2 OAuth2 and Client Management APIs.

Client Management API calls require mutual TLS authentication, with a Qualified Website Authentication Certificate (QWAC) issued to the TPP by a Qualified Trust Service Provider.

Client registration is performed through POST request on /psd2-oauth2/v1/registrations resource in Client Management API Endpoint with JSON body containing the following properties:

  • client_name - A human-readable name for the client, that will be shown to the user during the consent process.
  • scope - REQUIRED A space-separated list of scopes, that the client has (or requests) access to. In a PSD2 context, the following values are available:
    • aisp - Account Information and recent transaction history APIs
    • pisp - Payment Initiation service providers use cases APIs
    • cbpii - Card-based payment instruments issuers use cases APIs
  • logo_url - OPTIONAL URI string that specifies a logo for the client, as a data scheme URI. If available, the data will be used to show the user a logo during the consent process.
  • token_endpoint_auth_method - Token endpoint authentication method. Use urn:paysafe:oauth:token-endpoint-auth-method:eidas-qwac:psd here.
  • redirect_uris - REQUIRED A list of HTTPS URLs that describes the redirection endpoints for the client.
  • grant_types - REQUIRED Restricted to authorization_code and refresh_token. Other grant types are not supported in a PSD2 context.
  • response_types REQUIRED - Use code as a value here.
  • jwks - A JSON Web Key Set object, that describes the public keys and certificates related to the given client. In the scope of PSD2, the JWK Set must be the set of Qualified Sealing Certificates (QSealC) that can be used by the client to sign requests.

Further detailed documentation can be found in PSD2 OAuth2 and Client Management APIs Documentation.

Authentication and authorization flow

Authentication and authorization are implemented as specified in OAuth 2.0 Authorization Code Grant flow RFC 6749.

The essential prerequisities for setting up the authorization flow for TPP applications are the following:

  • OAuth 2 Client must be registered for the TPP applicaion
  • TPP application must integrate with the PSD2 OAuth2 Authorization server and Token endpoints.
  • Use of the OAuth 2 PKCE extension is mandatory, with the SHA-256 method

The detailed authorization flow proceeds as described in the sequence diagram: TPP Authorization Flow

  1. From the Third Party Provider (TPP) website/application, the Payment Service User (PSU) triggers the authorization process in order to allow access to his Neteller account resources
  2. The TPP website/application redirects the browser to the ASPSP (Neteller) OAuth 2 authorization server, with the required OAuth 2 client parameters
    • response_type - Equals to code
    • client_id - The OAuth Client ID registered by TPP during onboarding
    • scope - The desired access scope. The scope must be one of client scopes defined during client registration.
    • redirect_url - The redirect url provided by TPP, to which to return the authorization code.
    • state - The TPP session state parameter
    • code_challenge - SHA-256 code challenge parameter as defined in section 4.2 of OAuth 2 PKCE extension
  3. The ASPSP (Paysafe) OAuth 2 authorization server provides the user login and conscent interface. At this point, the Payment Service User must authorize the Third Party Provider.
  4. The browser gets redirected back to TPP’s redirect URL with the authorization code and state request parameters
  5. Third Party Provider (TTP) application uses the authorization code and PCKE secret (code_verifier) to obtain access and refresh token from OAuth authorization server. The following parameters are passed to the OAuth Authorization server
    • client_id- The TPP OAuth 2 client id
    • client_secret - The TPP OAuth 2 client secret
    • grant_type - Use authorization_code as value
    • code - The authorization code
    • redirect_uri - Should match the OAuth client redirect url
    • code_verifier - PCKE code verifier
  6. Refresh token can be persisted by TPP application and used for re-issuing access tokens as specified in Section 6 of RFC6749. Access tokens obtained in this way only provide access to information for which an SCA is not necessary.
  7. Payment Service User uses the related TPP functionality, that requires ASPSP
  8. TPP can access the corresponding ASPSP (Neteller) APIs on user behalf using the obtained access token.

Strong Customer Authentication

Strong customer authentication (SCA) is a requirement for payment actions. Upon initiation of money transfer, the transfer will get SCA challenge in the response and can not be finalized until SCA challenge is resolved by the user.

SCA Challenge Flow

One time password generation is triggered and send directly to the user according to his account configuration. The OTP is passed over from the user to the Third Party Provider and used to confirm the OTP challenge. After that the transaction can be finalized.

User presence and offline account access

TPPs are required upon calling Neteller APIs for AISP and PISP use cases to attach PSU original IP Address as HTTP header.

The following HTTP headers should be present and carry the PSU origin:

  • PSU-IP-Address
  • PSU-Present : true

The absense of the PSU IP address is interpreted as TPP accessing user data without user presence and such calls are subject to the following restrictions

  • AISP shall not access PSU account data in unattended mode more than 4 times in 24 hours unless it has collected the user consent for that.

Account Information Services APIs

The APIs allow accessing PSU Account and Transaction History information using the below listed APIs.

The APIs requires one of the following scopes:

  • aisp - Allows accessing customer account information and recent transaction history

Payment Initiation Services APIs

The APIs allow performing transactions to other Neteller Accounts.

The APIs requires pisp scope for access. During money transfer SCA challenge will be triggered.

Card Based Payment Instrument use cases support

Neteller Mobile APIs does not provide dedicated api for funds confirmation.

API Documentation and Support

Server API endpoints can be found in their respective API reference documentation:

For support contact Neteller integration support team at integrationsupport@paysafe.com