The Initiating Party Extranet is the GUI Interface for the Initiating Party to access and use the Open Banking Platform and provides the following Modules:

Master data and Subscription Management

Transaction Management and Post Processing

Refund Processing

User Management

Secure User Login

Report Management

Documents (view and download only)

Online Help

Functional Modules with partly or without GUI Access: 

Directory Service Management ♦ Reconciliation / Clearing Module ♦ Audit Logs ♦ White Labelling

The Administrator Portal is the GUI Interface for Backoffice Users of the client to access and administer the Open Banking Platform. It provides the following modules:

Bank Selection Interface 

Initiating Party and Subscription Management

User and Access Management

Service Provider Management

Banks can set up Providers for Initiating Parties in their environment. Those Service Providers do the technical integration for them and make it more easy to offer payment means to the customers. So (e.g. smaller) Initiating Parties can avoid the effort of integrating to the routing services systems for each payment mean by choosing a PSP as Way of Integration during the onboarding The service provider needs some configuration on the system, e.g. they have to provide a valid certificate and some mandatory data.  In order to maintain the service providers per service to be offered to Initiating Parties as connection method, the Open Banking Platform provides the Service Provider Management.  

Which features are provided?
The Service Provider Management enables Initiating Parties and Bank Backoffice Admins according to their access rights to maintain the following features: Service Provider data, Account data, Service Subscription Data, Technical & Security data, Setup, check, manage, deactivate existing service providers.
 

User Login Functionalities

As standard the Backoffice includes an access control via personified login page, the user can insert his name and valid password into the according fields and submit via the Login button. If the entered data don’t match, an error message (Authorization failed) informs him and after repetition and successful validation he is logged in the application.  In case of forgotten password, additionally a link “Forgot Password” available. Using it, an according dialog starts to renew the current password. 
Also as standard solution our Backoffice includes an user login with 2FA Authentication, which can be activated per acquirer bank / tenant via the configuration management. Once activated the existing username/password is used as first factor, the smartphone functions as second factor. On the smartphone an One Time Password (The user has to install an OTP generator on his smartphone, e.g. FreeOTP Authenticator). can be used to provide a temporary valid OTP, which has to be entered into the login form.

In addition the latest possible date from which the use of the OTP feature becomes mandatory for users is configurable on per acquirer / tenant:  In this case an individual “Start of OTP” is stored for each user (new or already existing), who does the first login for his acquirer via 2FA. During every login now is checked, whether the individual "Start of OTP" date of the user is already exceeded and how many days remain until expiration. Before expiration, the user is able skip the OTP secret verification (via an according button on the GUI), afterwards he has to verify and register an OTP secret. 

As login mechanismen to the bank systems we provide Web Single Sign On functionality (Web SSO) using credentials for authentication, which are a unique username and password: By using this functionality the first step it is checked if the user is already logged in to the authentication system.  Users, who are already signed in, are marked as Single Sign On Users in the system and are granted access immediately. If not, the user is directed to the authentication system to sign in. For each session, the user must first sign into the authentication system with a unique username and password. The authentication system uses a token for the session that stays in effect until the user logs out.

After the authentication process is running, the authentication information is passed to the application, requesting verification of the user.  
To login the OB Platform via Web Single Sign On (Web SSO) the banks offer special URLs. The Certificate, which is needed for the securing the Web SSO connection, can be uploaded via the Merchant and Subscription Management Module.
 

Certificate Management

Our Certificate Management provides a central management for certificates and is operated from the Backoffice GUI. As a consequence of PSD2 this functionality allows to manage hundreds of certificates and to automatically update related keystores in all associated  Routing Service Instances during runtime: Certificates can be refreshed automatically during application runtime of the Routing service. 

The Certificate Management allows creating Qualified Website Authentication Certificates (commonly known as TLS certificates) and Qualified Electronic Seal, certificate signing request (CSR). Whereas the key pairs, consisting of a private and public key, for QWAC CSRs are generated by the module itself; keys for QSEAL CSRs are derived from HSM Boxes using the restcrypto-server application.

Once the official signing process of QWAC and QSEAL CSRs is completed by an external certification authority (CA), the resulted certificates can be uploaded to the Certificate Management Module. 

At last a functionality within the module allows the user to send the certificates (as for QWACs the private keys as well) wrapped in a keystore to the Routing Service Instances at runtime.

If the same certifiacte (fingerprint) is stored on merchant and subscription level, the certificate is only stored once. It will only be deleted, when the certifcate is deleted on both levels on Backoffice side.

I is possible to Upload Certificates for the API authentication in the BO on merchant level additionally to the ones on subscription level. This is allowing to use the same certificate for all subscriptions.
 

Transactions Processing/ Refund Processing: Overview of all IP running on the system

Initiating Party Ticketing/Support

Document Management

Dynamic Creditor Account Lookup (DCAL)

We provide a Dynamic Creditor Account Lookup Service , which can be switched on or off for each of the tenants’ Initiating Party (by the tenant’s Backoffice Admin). If the DCAL is activated, up to ten additional creditor accounts can be set up. This service will only be used for Initiating Party without Sub Ids. 
In case, the DCAL service is switched off, but DCAL entries already exist, those entries will not be deleted. When DCAL is switched back on, the data are available again. Clients, who have access to the Backoffice as Admin User can select the DCAL option itself in the Tenant GUI and on the Initiating Party GUI , in the PIS service configuration. 

Via the DCAL screen the on/off switch can be managed very easily and on the DCAL table creditor accounts can be created, updated and deleted. 

The Open Banking Platform consists of several components, that you might use depending on the product - the Back Office is one major component, allowing to onboard and manage your clients, view transactions and create refunds. Here you'll find an overview of modules, which we offer and might be of interest. 

The Administrator Portal is the GUI Interface for Backoffice Users of the client to access and administer the Open Banking Platform. It provides the following modules:

Initiating Party and Subscription Management ♦ User and Access Management ♦ Initiation Service ♦ User Login Functionalities ♦ Certificate Management ♦ Transactions Processing/ Refund Processing ♦ Initiating Party Ticketing/Support ♦ Document Management ♦ Dynamic Creditor Account Lookup

The Initiating Party Extranet is the GUI Interface for the Initiating Party to access and use the Open Banking Platform and provides the following Modules: Master data and Subscription Management  ♦ Transaction Management and Post Processing ♦ Refund Processing ♦ User Management ♦ Secure User Login ♦ Report Management  ♦ Documents (view and download only) ♦ Online Help

Functional Modules with partly or without GUI Access: 

Directory Service Management ♦ Reconciliation / Clearing Module ♦ Audit Logs ♦ White Labelling

In order to promote the use of FIDO and to help standardize the user experience, the FIDO Alliance has written some guidelines about how to display information related to FIDO when using it on a website.
However, these guidelines are mainly constructed around the use of FIDO for account log-in. In the case of transaction validation and two factor authentication using WAFL, some of the recommendations are not really applicable.

You will find here what we could extract from this official documentation that is relevant to apply in our context and that we used in our demonstration.

FIDO during the user journey - Our interpretation​

• Until the user is logged-in, no change on the website.

• Once the user is logged-in, on the their main dashboard, advertise the fact that a new way to Authenticate payments is available, and link to the settings to enable it, but only if the device supports FIDO.
  (see how to check that in the implementation guide)
  Do not mention FIDO yet, but only biometrics.
  Use a fingerprint icon matching the user platform : Apple icon for Mac and iOS; generic icon for other platforms.

• In the user settings, the section dedicated to FIDO activation should :

  • Use proper biometrics icon.

  • Start mentioning FIDO.

  • Offer registration only on supported device.

  • Mention that even though it is supported, it might be necessary to enable it in the device settings, and indicate how to do so. (Ex: Windows Hello can be disabled, but FIDO will appear as supported by the device)

  • Insist on the benefits of using FIDO : it's faster and it's simpler.

  • Display the FIDO logo.

  • At the bottom, add a link to display some FIDO key facts, as provided in the official guidelines.

• During transaction validation, if the user used an other validation method, invite the user to register FIDO after a successful transaction if their device is not registered yet.

Official extracts​

Information about Security Keys​

• What is a security key?

  A security key is a small, physical device that works in addition to your password on sites that support it. A single key can be used with multiple accounts or sites.

• Why should I use a security key?

  Security keys protect you against imposter websites that try to steal login credentials (like usernames and passwords). Other forms of 2-factor authentication (including text, email, messages, authenticator apps, and push notifications) do not give you the same level of protection as a security key.

• How security keys work

  You must first add security keys using the button above. Once added, you'll be required to use them after signing in with your username and password. Doing this creates one of the strongest forms of authentication available to protect your account.

  • What security technology do security keys use?

    Most keys use an authentication "standard" called FIDO® which allows for secure authentication without drivers or software. When a user signs in a website with a key, FIDO® cryptographically signs a challenge from the browser that verifies the website's actual domain name, which provides strong protection against phishing (e.g., when a fake website is used to trick users into sharing personal information). An attacker would need to control the website domain name or the browser to get a usable signature from the key.

• Why do security keys look like thumb drives?

  Although hardware security keys may resemble thumb drives and are sometimes inserted into your computer's USB port, they are not storage devices. Your personal information is not trackable or linkable across sites or online accounts when using a security key.

• What happens if my security key gets stolen?

  The key works in addition to your password, not as a replacement for it. If someone steals the key, they still can't get into your bank account without knowing your password (or which sites are registered with your key). You can sign in with a backup method and remove the stolen key from your account.

• Add more than one security key

  Adding multiple security keys is highly recommended. If your security key is lost or stolen and you do not have a registered backup security key (or other backup authentication method), access to your account could be interrupted while we verify your identity. We recommend keeping one key easily accessible and another stored separately in a safe space.

• Purchase security keys

  Security keys vary by manufacturer and can be purchased from mainly online retailers. We recommend FIDO certified keys. See a list of FIDOⓇ certified keys.

• Name your security keys

  Give you security key a friendly "nickname" that only you can see, so you know which key you registered with this account at a later point in time.

Information about Device Unlock​

• How device unlock works

  A technology called FIDO lets you sign in securely without relying on a password. Once you've registered your computer's PIN, facial recognition, fingerprint, or security key, FIDO verifies it's really you and doesn't transmit any of your login information over the internet.

• Why use device unlock

  Easy, safe—and private! FIDO makes signing into your online accounts much easier, while keeping your info safe from hackers. Leading companies worldwide in retail, telecommunications, finance and technology are already using FIDO.

• More information

  Registering with FIDO provides you with an additional login option for this device—your password remains valid.

Learn more content​

This part contains the information that could be used in any "Learn more" link, tooltip, popup to be displayed under the FIDO icon under Registration or Authentication buttons.

FIDO lets you sign in securely without relying on a password by keeping your login information securely on your device. Nowhere else.

How it works ?​

1. A technology called FIDO lets you sign in securely without relying on a password.

2. FIDO makes signing into your online accounts much easier, while keeping your info safe from hackers.

3. Once you’ve registered your computer’s PIN, facial recognition, fingerprint, or security key, FIDO verifies it’s really you and doesn’t transmit any of your login information over the internet.

4. Easy, safe—and private!

5. Registering with FIDO provides you with an additional login option for this device—your password remains valid.

6. Leading companies worldwide in retail, telecommunications, finance and technology are already using FIDO.

FIDO Facts content​

This part contains some facts elaborated after some studies involving final users that are designed to improve trust in FIDO.

• FIDO is a technology built into all leading desktop devices (PC and Mac) and browsers, that allows users to sign in securely without a password.

• In the same way your phone uses a biometric, FIDO now enables biometric sign-in on websites viewed on your desktop too.

• FIDO makes sign-in easy, safe, and private!

• FIDO technology uses your computer’s built-in authentication method (i.e., Windows Hello or Apple Touch ID) to ensure your sign-in information stays safe from hackers because it never leaves your computer.

• Once you’ve registered your computer’s PIN, facial recognition, fingerprint, or security key, FIDO verifies it’s really you and doesn’t transmit any of your sign-in information over the internet.

• Registering with FIDO provides you with an additional sign-in option for this device — your password remains valid.

• Leading companies worldwide in retail, telecommunications, finance, and technology are already using FIDO.

To make things easy for the frontend work, we provide a file wrapping the main Java APIs of the Relying Party Server in JavaScript : api.services.ts
It will provide APIs to register / authenticate with WAFL on the Relying Party server.

Checking availability​

To avoid providing a frustrating user experience, it is recommended to check that the device used is compatible with FIDO before inviting the user to register or authenticate with it. To ensure that the Web context supports the use of FIDO, you can use

isWebAuthnSupported(): boolean

And to check that the device supports a Platform Authenticator you can use

async checkPlatformAuthenticatorAvailable(): Promise<boolean>

Note that a Cross-Device (such as Yubikey) or Roaming (mobile) authenticator cannot be used if the device doesn't have Platform Authenticator and you use this check.

OS Specific check​

As mentionned in our FIDO Wording Guidelines page, when inviting the user to register or authenticate, it is recommended to show a biometric icon related to the platform. To do so, we have a simple isAppleHardware()that can be used to switch between Apple and generic icons.

Worldline FIDO enrolment

async waflRegistration(username: string, displayName: string, friendlyName: string): Promise<boolean>

To be able to provide FIDO authentication for transactions to your users, they first need to register the devices they want to use. This can be done by calling the above method with parameters :

• username : the technical username of the user account.

• displayName : the name that will appear in the FIDO authentication request shown by the browser.

• friendlyName : the name of the registered authenticator, to be displayed in Self-care interface.

It will return whether the registration succeeded or not.

Worldline FIDO Authentication

async waflAuthentication(username: string): Promise<boolean>

To authenticate a user, simply call this method with :

• username : the technical username of the user account.

It will return whether the authentication succeeded or not.

Self-care​

Our small API wrapper also provides the necessary APIs to allow the users to manage their authenticators from their account settings in your website.

Describing an Authenticator​

Our API file exposes the class AuthenticatorDescriptor which maps the data retrieved from the server to an object with following members :

id: string;  // The internal/technical ID of the authenticator
createdAt: string;  // The creation Date as a YYYY-MM-DD HH:MM:SS.XXXXXX
description: string;  // The official description of the Authenticator
                      // ex: "Windows Hello Hardware Authenticator"
friendlyName: string;  // The friendly name choosen by the user

Listing Authenticators

async getAuthenticators(username: string): Promise<AuthenticatorDescriptor[]>

Calling this method will return a all registered authenticators for the specified user as an array of AuthenticatorDescriptor.
If the user did not register at least one authenticator (ie: the user is not know on the WAFL backend yet) or if there is any issue in processing the request, it will throw an Error.

Renaming an authenticator

async renameAuthenticator(username: string, friendlyName: string, authId: string): Promise<boolean>

To rename an authenticator, use this method with parameters :

• username : the technical username of the user account.

• friendlyName : the new name of the authenticator.

• authId: the technical ID of the authenticator, as provided by the getAuthenticators() API.

It will return whether the renaming succeeded or not.

Deleting an authenticator

async deleteAuthenticator(username: string, authId: string): Promise<boolean>

To delete, or unregister, un authenticator for a user, call this method with parameters :

• username : the technical username of the user account.

• authId: the technical ID of the authenticator, as provided by the getAuthenticators() API.

It will return whether the deletion succeeded or not.

In today's fast-paced digital world, financial institutions are constantly looking for innovative ways to enhance their customers' experience and add value. One such way is to leverage APIs that enable seamless integration between different systems and applications. In this context, discover how our APIs can help you create value for your cardholders and provide them with a more comprehensive and personalized service.

Discover how you can utilize our APIs to generate benefits for your cardholders :

Introduction Acquiring Processing Product Services

Worldline Financial (WL FS) is the largest payment processor in Europe with over 12 billion acquiring processing transactions per year and continues to scale-up rapidly.

Acquiring Processing

Worldline Financial Services offers acquirers a full set of product services to outsource acquiring processing for international brands.

Our products cover the complete acquiring processing value chain from card Acceptance & Authorization Switching, to Clearing and Merchant Settlement.

Modular outsourcing concept

Base Transaction processing has the following main product modules:

• Front Office - Host Acceptance & Authorization Switching to the Issuer
• Back Office - Card Scheme: Clearing, Settlement and Reconciliation

• Scheme & Regulatory Compliance services - Worldline FS offers its acquirers services to help comply with scheme rules and regulatory requirements.

On top of Acquiring Base Transaction Processing services Worldline (WL) Financial Services (FS) offers a comprehensive set of Modular Processing services.

• Merchant Management - Merchant level
• Acquiring Data Services - Acquirer level
• Dispute Management
• Fraud and Risk Management
• Value Added Services

BASE TRANSACTION PROCESSING

Front Office: Acceptance & Authorization (CNP & POS)

Worldline FS offers a variety of card transaction processing products that enable Acquirers and their customers to accept a wide range of card products and brands. Payment channels include: Chip & PIN, Mobile & Contactless, Credential-On-File. Security standards include magstripe, EMV (uses EMV chip and NFC chip), Tokenization (MDES), EMV 3-D Secure v2.0.

The processing of card transactions is divided into two basic generic product services that cover the main volumes of card transactions: Acceptance on the host and Authorization switching to the Issuer. Transaction acceptance processing includes online & offline for eCommerce (Card Not Present) and POS card transactions on the host. Authorization Switching is via the card scheme network to the Issuer (unless otherwise stated in the services).

In addition to the basic card processing products, Worldline FS offers additional services to support extra functionalities. These services comprise the support of additional network protocols, terminal-to-host protocols, host-to-host protocols, offline transactions, premium brands (AMEX, etc.), non-standard transactions (Cash Advance, DCC, etc.).

ATM processing products are part of Value Added Services.

Supported card brands

Scheme: Clearing, Settlement and Reconciliation (Back Office)

The Acquiring clearing portfolio is a comprehensive portfolio of services that offer Acquirers an efficient means of processing card payment transactions into actual Merchant bookings.

As an Acquiring processor, Worldline FS offers Acquirers a range of services geared towards settlement with both the Merchant and the Schemes or Issuers.
In-cloud transaction settlement between the Acquirer and Issuer can be performed if both parties are directly connected to Worldline FS and a bilateral agreement is made between those parties.
Out-cloud transaction settlement between Acquirers and Issuers must be performed by a third-party. Worldline FS provides a clearing file to the Schemes or third-parties for the settlement of these transactions.

Scheme and Regulatory Compliance

In the fast-paced payments industry schemes and regulators are continuously changing regulations and reporting requirements.

Worldline FS offers its acquirers many services to help comply with scheme rules and regulatory requirements.

MODULAR PROCESSING SERVICES

On top of Acquiring Base Transaction Processing services Worldline (WL) Financial Services (FS) offers a comprehensive set of Modular Processing services.

Merchant Management - Merchant level

The Worldline FS (Back Office) Merchant Management cluster offers full and final merchant settlement based on WL FS: scheme clearing, scheme settlement files, merchant pricing engine, and merchant configuration as stored in the merchant contract system.

The Merchant Settlement module is where WL FS converts scheme clearing and settlement input files into a booking per merchant account in SCT/SDD format for the acquirer.

The Merchant Pricing Engine calculates transaction & service fees based on different pricing models.

The Worldline FS merchant contract management system stores Merchant Information such as merchant contract configuration, applicable pricing model, configured fees, and merchant settlement account.

Acquiring Data Services - Acquirer level

The Worldline FS Acquiring Data Service cluster offers RESTful API services to facilitate speedy direct integration of acquirers and their third party customers such as PSPs or large merchants.

The Accept Transactions API enables CNP and POS acceptance via a host-to-host connection to the WLP FO Front Office services. In addition, there is an API service to retrieve near real-time the transaction acceptance status (authorized, captured etc.).

Merchant Management (contract API) allows you to manage and retrieve your own merchant contracts in the Worldline FS acquiring merchant contract database. For third party customer's (e.g. PSP, PayFac, Merchant) retrieval and limited updating is available in agreement with your acquirer.

Back Office retrieval APIs are available for the following types of data: Transactions, Merchant Payments, Merchant contracts, Interchange, Statements (Merchant Reconciliation), Analytics.

To facilitate human interaction with the data, Worldline FS has several User Interfaces that give insight into different types of data: Acquirer Portal, Merchant Portal.

Bulk data is provided to acquirers via 3 main omni-channel Data Warehouse feeds: Authorizations, Clearing, Merchant Payments.

Worldline FS also offers Accounting and Reporting services such as: General Ledger, Financial reports, Custom reports. Regulatory reports and Scheme reports can be found in scheme and regulatory compliance.

Dispute Management

As Acquirer processor Worldline offers acquirers several services to support the different dispute resolution processes of the supported Schemes.

Risk and Fraud management

Worldline FS Risk and Fraud management cluster offers fraud analysis, investigation and monitoring for suspicious behavior.

Value Added Services

Value Added Services cluster includes: ATM, Merchant VAS, DCC, Mobile Top-up, Loyalty programs, Acquirer and Merchant Support, POS Terminal Package, Partnership Models.