Here is the list of Belgian banks that you can initiate payments or
retrieve data from using our Open Banking products:
Here is the list of Austrian banks that you can initiate payments
or retrieve data from using our Open Banking products:
We support payments and account data in 20 countries,
covering at least 80% of payment accounts in each.
We are continually expanding our reach and updating our list.
If you're interested in a specific country or bank not listed,
please reach out to us - we're here to help!
As a registered user, you can jump straight to the country pages and
check out the list of banks from which you can initiate payments or
retrieve data using our Open Banking products.
Not signed up yet? Just register here!
You need to keep your client_id and secret_id that was sent to you by mail.
If you lost your secret_id, please contact us to generate a new one for you.
There is two types of credentials with different scope. The firsts credentials you received are for the administrative scope, to manage your relying parties servers. You have to use these firsts credentials to create a relying party via API, and in response you will received second credentials related to your relying party with "service" scope that will enable you to configure it and handle your users via API.
These credentials are needed for all interactions with the Fido Server by Worldline.
You also need the audience to access generate bearer tokens.
OAuth2 Server URL : https://access.fido.worldline-solutions.com
Audience : https://my-wafl-api-gateway-6glqflxv.ew.gateway.dev - to update
The FIDO Server by Worldline (also called WAFL Server) API uses the OAuth Client Credentials Flow to authenticate API calls.
curl --request POST \
--url 'https://access.fido.dev.worldline-solutions.com/oauth2/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--header 'Authorization: Basic Base64Encode(concat('client_id', ':', 'client_secret'))' \
--data 'grant_type=client_credentials' \
--data 'audience=https://my-wafl-api-gateway-206w9c7e.ew.gateway.dev'If all goes well, you'll receive an HTTP 200 response with a payload containing access_token, and expires_in values:
{
"access_token": "eyJz93a...k4laUWw",
"expires_in": 3600
}The lifetime of a token is set to 3600 seconds
Once you received your credentials by mail with the "admin" scope, you can declare your relying party server with the admin/relying-parties API, where you give the name of your relying party, and get the credentials with the "service" scope that you can configure in your relying party server to use the FIDO authentication service.
You also have to declare the origins of your relying party application with the admin/relying-parties/{id}/origins API.
You can use our Browser SDK to facilitate the integration of FIDO protocol into your web application and use the browser APIs.
The registration is a two steps action as it contains an initiation step to generate the challenge that will be used by the authenticator for cryptographic operations.
In the initiation step your relying party gives information about the registration like the username, friendlyName and authenticator properties. The Worldline FIDO server respond with a challenge to give to the authenticator.
The attestationBlob, response of the authenticator, is passed through the finalization step so that the Fido server complete the registration.
The authentication is also a two steps action as it contains an initiation step to generate the challenge that will be used by the authenticator for cryptographic operations.
The initiation step is where your relying party informs the server for which user you want to do an authentication. The response contains the challenge on which the authenticator will have to make cryptographic operations.
The result of these operations is passed through the finalization step in the assertionBlob where the Fido Server will do the authentication.
Once your users are registered, you can list their authenticators, update the friendlyName of an authenticator (for the user to better identify his authenticator) and delete them via the /users APIs.
The API allows the transaction details to be retrieved.
The main input fields are:
It is also possible to request some additional data relative to addendum (to retrieve lodging information, car rental information, air itinerary information) by using the embedded fields.
In return, the interface provides the generic information (mainly master data) relevant to the transaction.
API links
The API provides possibility to retrieve a list of transactions (original first presentments received from the card schemes), based on certain criteria.
To prevent overly broad searches, at least one of the following conditional search criteria must be provided :
If requested, the API allows also to:
The API response contains all matched transactions sorted by descending transaction date.
API links
The API allows an issuer to create a dispute folder in the system for a given transaction. This API enables the issuer to initiate the dispute from its application.
Several actions can be performed :
Main data in input are :
In response, the created dispute folder identifier is provided back systematically; then depending on the additional requests, the response includes also the posting, event creation and documents add response.
Idempotency is managed by the API; that is, if the request with the same WL-Correlation-ID is sent multiple times, it will be executed only once. The response will be retrieved directly from our system.
API links
The data export solution is a new external Push Service totally independent from the existing scoring notification request, containing a maximum of information of the transaction and the authentication process.
The platform HUB purposes two kinds connectivity with banks for this purpose.
or
The data export solution defined is based on data conveyed in the AReq and RReq messages + Scoring and authentication process.
It takes advantage of the HUB to provide the necessary available data from those messages.
The HUB is the key module to collect and to treat those data as it is the central module involved in the 3DS authentication process.
The messages contain most of the relevant information needed to get the context of a transaction and to provide enough information to consolidate and refine the authorization process.
Workflow of the process:
With this solution, bank will be able to receive the data just after the authentication transaction ending (after RReq/RRes message).
The data are pushed to bank through a dedicated Webservice API.
The data will be sent on a REST JSON format. The Web Services will be transmitted in HTTPS - TLS 1.2 and will be configured on the Worldline PCI-DSS Proxy as followed:
A rate limiter is defined (max TPS) on the HUB push platform and must be configured depending on Issuer Bank transaction volume and IS Bank Server capacity.
If the HUB cannot reach the bank Webservice, a retry process is forecasted. This retry flow is ordered by a FIFO rule.
Two kind of errors are defined, some are due to context and triggers a retry attempt, some are due to data or configuration error and will no triggered any retry. Cf. 3.5.1.2
The retention of data is fixed for a 4 days period. During this time laps the transactions are systematically pushed to the bank until the bank module responds.
After 4 days, the transaction and data not transmitted are deleted from the queue.
With this solution, bank will receive the data through a file.
The file will be generated with a frequency of at least 2 files per day (one per site).
A ‘pull’ or ‘push’ process could be implemented to share the files with IS Bank.
A file system solution will allow Worldline to keep the file during 2 weeks. After this period, the files will be deleted.
The data will be sent on a JSON format through the PCI-DSS gateway on sFTP or PESIT SSL. File could be encrypted in GPG or SMIME.
Referential WS Client is the standard referential interfaces exposed by the Issuers' Bank.
ACS is therefore client of the Bank Information System.
Thanks to this API ACS can :