Support

A plan is collection of API resources or subsets of resources from one or more APIs. A plan can contain a mixture of operation types from different APIs. A plan can have a common rate limit for all the resources or each resource can have a different rate limit. Rate limits specify how many requests an application is allowed to make during a specified time interval.

Use this Developer Portal to browse the different plans that are available to you and select a plan that is most suitable for your requirements. Some plans have restricted access that you must request access to use. When you submit your request, the organization is notified, the API administrator assesses your request and they might contact you for more details. Other plans are available to use straight away.

The numbers of requests, for different APIs, that your application has made are shown on your application page.

Click 'Apps' in the main menu and then click on your application. In the 'Product Subscriptions' table you will see all plans your application is subscribed to.

For each API contained in that plan you can see the usage compared to the rate limit of the plan.

It is possible to test an API from this Developer Portal.

When looking at the details of an API you will see a list of the operations contained in the API. This will show the verb and path to use for the operation.

If you click on the operation you will see more information about it, what parameters it might take, what it returns, what possible return codes it might use and what they mean.

There is also a 'Try' button on REST APIs which enables you to try the operation out direct from the Developer Portal.

If the API requires a client ID or a client secret for identification then you can specify these using your application credentials at the top of the 'Try' section.

Open Banking refers to the use of APIs that enable third-party developers to build applications and services around financial institutions. Traditional closed banking is breaking up to give way to open access, transparent service, and most importantly of all, collaboration.

OneLinQ is an innovative payment and financial crime compliance platform for Fintechs and Third Party Providers (TPPs), providing easy onboarding and a streamlined global payments process. OneLinQ provides PSD2 Payment Initiation and Account Information services, accessible to all organizations who are seeking for genuine Pan-European and interoperable payment gateway solution.

OneLinQ provides Account Information Services (AIS) and Payment Initiation Services (PIS).

Currently, OneLinQ offers following plans: Beta, Bronze, Silver and Gold. Please visit API product for more details about plan.

No. Registering on OneLinQ is free. However, to test some APIs you may be required to subscribe to the plan.

No. You’ll always need to approve any payment made from your account. OneLinQ ensures that no payment will be initiated without proper consent of user.

The data used in Sandbox environment is dummy, but will follow the same structure as the data in production environment.

APIs are secured with API Key using ClientId and ClientSecret, OAuth2 – client credentials & authorization code, grant type and SSL/TLS.

The token is the credential that is needed to use an API. It is the result of a valid call to the authorization process. 

You can find more on the authorization process in the Getting Started guide.

Refer How to in order to make your first call to our APIs.

The data is being transferred using SSL/TSL security.

Your account information is only accessible to you.

OAuth 2.0 is an open standard for access delegation, commonly used as a way for Internet users to grant websites or applications access to their information, most commonly using access codes and tokens on other websites but without giving them the passwords.

To create OAuth token you have to call ‘/authorize’ and ‘/token’ API. For more details refer Getting Started guide.

You might have subscribed the plan which requires approval. So, you will get an e-mail once your subscription to the plan is approved and then you can use/access the APIs.

The request field must be generated by using JWT. The JWT will have the following JSON structure:

Header:

{ 
  "alg": "HS256" 
}

Payload:

{ 
  "request_id": "THE REQUEST ID", 
  "iss": "CLIENT ID " 
}

The Currently supported algorithms is: HS256 The request_id value will be different while creating access AIS APIs and authorizing payment. 
AIS: While accessing AIS API's the request_id will be AccountRequestId. The AccountRequestId can be generated by calling Account Requests API of AIS. 
Authorizing Payment: While authorizing a payment the request_id will be a PaymentId.

You might have subscribed to the plan which does not offer those APIs. Please verify your subscription plan.

To access the OAuth2-secured APIs, you must have a valid access token generated by calling ‘/authorize’ and ‘/token’ API. Follow the Getting Started guide for more details on the creation of an access token.

First, check your browser settings to make sure the "allow cookies" option is enabled.

If the problem persists you can reset your password here.

Still, having problems? Please contact us by clicking here.

Yes, the pagination functionality is provided in the  GET /accounts/transactions API of OneLinQ PSD2 AIS API. 

The transaction details can be viewed by calling the GET /accounts/transactions API of OneLinQ PSD2 AIS API. As complete transaction details may not be fetched in response, so the functionality of pagination is provided.

You will receive the link for the "Self", "First", "Prev", "Next" and "Last" pages in the response of GET /accounts/transactions API to navigate to the desired pages.

The lifetime of the token received in the response of the POST /token endpoint of the OneLinQ PSD2 Security API depends on the ASPSP.

If the ASPSP does not support a refresh token then the expiration time is returned in the response of the /token of OneLinQ PSD2 Security API whereas if ASPSP supports a refresh token then it is internally handled by OneLinQ PSD2 framework and expiration time is not returned in the response of the /token API.

TPP can initiate domestic payments.

The payment product types supported by OneLinQ are SEPA, Instant SEPA and by default the domestic payment product type of respective countries.

For e.g. For UK the payment product type supported by OneLinQ is FPS.

We have a Beta plan available that allows you to make 100 Security API, 40 PIS API, 60 PIS API calls per hour in our sandbox environment.

The Beta plan is free – there are no costs involved.

The terminology "destination bank" mentioned on the portal are the banks that the user is going to connect via OneLinQ APIs (Source being OneLinQ APIs or OBWG APIs or Berlin APIs) or in other words, we can say that the terminology "destination bank" refers to the banks which hold debtor account.

The test data to be used during the bank's API call can be acquired through mail at the request of the subscriber.

OneLinQ will send the test data set for the bank whose APIs need to be consumed through the mail. The request can be raised from the support page or via mail.

The "PSU-ID-Type" header can be ignored as its value is internally handled by our solution. So it's not required to pass this header in the API call request.

Even if it is added in the request header its value should be as per the test data shared for the sandbox and in production its value should be the one of the values supported by the bank.

For AIS API consumption, the value against the field “AisPreStep” guides for the first API to be consumed. If the value of the field "AisPreStep" is "AuthorisationCodeOauth", then, the Authorisation code flow needs to be triggered and If the value of the field "AisPreStep" is "ClientCredentialsOauth", then the Client credentials code flow needs to be triggered.

Similarly, for the PIS APIs flow journey, the value against the field “PisPreStep” guides for the first API to be consumed. If the value of the field "PisPreStep" is"AuthorisationCodeOauth", then the Authorisation code flow needs to be triggered whereas if the value of the field "PisPreStep" is "ClientCredentialsOauth", then, Client credentials code flow needs to be triggered.

The complete detail step can be referred to on the "How To" page of our developer portal.

We can generate the token by two ways:

       A) Generate a token through various libraries

       B) Generate a token online through the https://jwt.io/ website

A)   Generate JWT through Various libraries are present for Signing/Verification of JWT, Refer https://jwt.io/libraries/

       For implemetation refer GitHub link https://github.com/jwtk/jjwt/

       Please find below sample snippet of the code:

             RSAPublicKey publicKey = //Get the key instance

             RSAPrivateKey privateKey = //Get the key instance

             try {

                         Algorithm algorithm = Algorithm.RSA256(publicKey, privateKey);

                         String token = JWT.create()

                                     .withIssuer("auth0")

                                     .sign(algorithm);

              } catch (JWTCreationException exception){

                     //Invalid Signing configuration / Couldn't convert Claims.

                }

The resultant token string looks like this:

       eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJKb2UifQ.1KP0SsvENi7Uz1oQc07aXTL7kpQG5jBNIybqr60AlD4

B)    Generate a token online through the https://jwt.io/ website by using the following steps: 
               1) Select the algorithm RS256 from the Algorithm drop-down menu. 
               2) Enter the header and the payload. For more information, see the 'Header and payload format' section below. 
               3) Generate an SSH Key Pair. Refere - https://docs.oracle.com/en/cloud/cloud-at-customer/occ-get-started/gener... 
               4) Enter the generated private key in the Private Key field of the Verify Signature section. Ensure that you have removed the public certificate from the Public Key or Certificate field, if the certificate exists.

       A token is generated in the Encoded section. Copy this token and use it in the POST API request.

       Header and Payload format: 
       The header consists of two parameters: 
              i) alg (Mandatory): The signing algorithm being used, such as RS256. 
              ii) typ (Optional): The type of the token, which is JWT.

       For example: 
       { 
             "alg": "RS256", 
             "typ": "JWT"

       }

       The Payload contains complete JSON body of the API request

       For example: 
             {"language":"en","enabledCountries":["United Kingdom","Netherlands"],"supportedPaymentMethods":["single"],"buyerDetails":{"firstName":"Test","lastName":"User","emailId":"test@test.com","addressLine1":"Address line 1","addressLine2":"Address line 2","state":"Southampton","country":"United Kingdom","zipCode":"SO53","city":"Cherry Court","isdCode":"+44","mobileNo":"8087495330"},"paymentDetails":{"amount":10.02,"currency":"GBP","accountNumber":"50000012345602","bankBic":"NWBKGBXX","bankCountry":"United Kingdom","reference":"1024556","purpose":"Business Trip"},"successRedirectionUrl":"https://onelinq.com/callback/success","failureRedirectionUrl":"https://onelinq.com/callback/failure","transactionId":"TR00001","state":{}}

OneLinQ has always endeavored to return data enriched and user-friendly responses that should self-explanatory. Our response of API POST /account-access-consents contains information about the next APIs needed to consume. The value of the fields like "SCA Approach" and fields containing link value will guide for the next API to be consumed.  The example below for one of the scenario for the account access consent response highlight that next API to be called is GET /account-access-consents/{ConsentId}/redirect

{

          "ConsentId":"99391c7e-ad88-49ec-a2ad-99ddcb1f7721",

          "Status":"Received",

          "CreationDateTime":"2018-10-01T09:38:20+00:00",

          "ScaApproach":"REDIRECT",

          "ScaRedirect":"/onelinq/v1.0/account-access-consents/99391c7e-ad88-49ec-a2ad-99ddcb1f7721/redirect"

}

Yes, the user will be required to provide the ScaAuthenticationData regardless of the chosen method. This needs to be provided in the "Authorize Transaction" API call. This will be a single field of data.

To elaborate the process to acquire the ScaAuthenticationData by the user depends on the banks and selection of the user. It may be acquired by the user as an SMS OTP over the user's registered phone, or an external SmartTAN Photo card reader device may be required to get the TAN (ScaAuthenticationData), etc depending on SCA method selected by user.

However, in all such scenarios, the user will be required to provide the ScaAuthenticationData and it will be in the form of a token or password.

The method selection like SmartTAN plus, Smart-TAN photo, etc. and its corresponding ScaAuthenticationData can be tested only in the production environment as the sandbox environment of the banks does not support it.

An app (or application) is the way a user can manage his APIs credentials.

It is identified by a unique Client Id and Client Secret generated by the system.

When you add an application you are provided with an API Key and Secret for the application. You must supply these credentials when you call an API that requires you to authenticate your application.

To register an application click on Apps in the main menu and then click on the 'Create new app' link. Once you have provided an application name, description, etc you will be shown your application API Key and Secret.

Make a note of your API Secret because it is only displayed once.

There is no limit on the number of applications you create.

Yes, you can.

Go to the Apps tab, click on the app whose image needs to be updated; click on Edit Application and update the image.

Yes. You can update app name/description as many times as needed.

After registering your app, you will receive a Client ID and a Client secret.

The Client ID is considered public information, and is used to access AIS PIS APIs.

The Client secret must be kept confidential.

Login to API portal and click on the APPs tab. On apps if you have already created an app then you can see the Client ID of that app in that app page.

Note: Client Secret is visible only after you create the app.

If two or more sets of Client credentials are added to an application, OAuth tokens are not shared between them; each client credential set uses a different OAuth token.

There will be only one Client ID and Client Secret for an app. But Client Secret can be reset infinite times.

Your API Secret is stored encrypted so we cannot retrieve the unencrypted version to tell you the value if you forget it.

You can reset it, which will update the stored value and return the new value to you.

To do that click 'Apps' in the main menu, click on the application in question and then you can click the 'Reset' link in the 'API Secret' section.

Your new Secret will be displayed at the top of the page.

The numbers of requests, for different APIs, that your application has made are shown on your application page.

Click 'Apps' in the main menu and then click on your application. Under 'Subscribed Plans' you will see all plans your application is subscribed to. 

For each API contained in that plan you can see the usage compared to the rate limit of the plan.