The payer needs to approve payment execution to their bank. Payer’s bank will apply a strong customer authentication (SCA) to ensure payer's identity. This can lead to multiple flows in which a payment can be completed. 

If you are Using the Worldline Open Banking functions directly, depending on the payment flow, you have to implement the Payment Authentication API's.

For faster integration and better user experience we offer a Bank Selection Interface that could be customised with your branding allowing to choose the payer's bank and handling the complexity of different PSD2 authorization flows (redirect / decoupled / embedded), so that you will be able to focus on your product and leave the boring stuff to us. 

As part of this stage you submit a payment to Worldline using Payment API.

Worldline performs technical validations of the payment and forwards the payment request to the bank.

Click on the relevant payment type to learn specific implementation details:

• Single Payment
• Scheduled Payment
• Periodic Payment
• Bulk Payment

As part of this step, you will determine payment details such as payment amount, payment product (e.g. SEPA Credit, SEPA Instant credit, domestic or cross-border payments), whether  it is a single or bulk payment etc. Typically, this will be done as part of shopper’s check out or in context of invoice payment and will be handled by your software.  

You will need to let the payer choose their bank out of the list returned by the Reach Directory. We recommend refreshing the list of banks and their attributes once a day. Please note that some of the banks require additional information such as payer’s IBAN to be collected in advance.  You will find this information under the bank details provided by the Reach API. In addition, you can determine the preferred payment authorisation flow out of the ones supported by the bank (redirect / embedded / decoupled). 

As there is a lot of complexity related to the implementation of different payment flows and handling bank specific information, we recommend using our Bank Selection Interface for single payments – this is a set of predefined screens that can be customised to match your branding. As they are already integrated with the Reach API and Payment API, you only need to embed them as part of the user flow in your system. This will simplify the integration effort but its usage is optional.

In case you decided to not use the Bank selection interface, once you gathered all the necessary details, you can move to Step 2 - payment initiation.

There are 3 main types of payment flows:

1. Redirect

In the Redirect Approach the browser session of the payer is redirected from your software to payer's bank. In that case the bank provides all the pages required for Strong Customer Authentication (SCA). Once the authorisation is complete, the payer is being redirected back to your software.

2. Decoupled

In the Decoupled Approach no redirection takes place. Instead the payer's bank notifies the payer, for example using mobile banking app. The authentication is executed by the app. Since this approach is asynchronous, you need to check payment status to know when the authentication process has been finished. 

3. Embedded

In the Embedded Approach you have to provide all the screens required for the authentication process and to communicate all necessary steps over the API of the Open Banking Service to the ASPSP. 

Authorization Steps

Depending on the payment flow you will need to implement a different sequence of API call. Please check below sequence diagrams to understand each flow.

You can indicate your preferred SCA method by using PreferredScaMethod (Embedded, Decoupled, Redirect) parameter, but there is no guarantee that the bank will actually use it to authenticate the payer. You can check what payment method is supported by each bank from Reach API.

For faster integration and better user experience we offer the Bank Selection Interface, it will then always become a redirect flow from you to this interface. This interface can be customised with your branding allowing to choose the payer's bank and handling the complexity of different PSD2 authorization flows, so that you will be able to focus on your product and leave the boring stuff to us. 

The selected flow with which authentication will go through, is being identified by the name of a hyperlink, provided in the response.

Redirect Flow 

Below is a sequence diagram showing a typical redirection payment flow. Depending on the individual implementation of the bank, the actual flow may differ slightly. The green vertical bars indicates who is responsible for the interaction with the payer (PSU).

Redirect back to the Initiating Party

Once the PSU has interacted with the ASPSP, the session will be redirected back to the Initiating Party. Here, the Open Banking Service appends the Initiating Party Return URL with the Service Name and the payment ID so that the session can be recognised. This enables the Initiating Party to display the correct screen to the PSU.
An example of a return URL is as follows: https://www.example.org/?scope=UElTOjE1NjQzMTYw
The Initiating Party would need to base64 decode this string : UElTOjE1NjQzMTYw
The example above results in: {ServiceName}:{paymentId}, i.e. PIS:15643160

Decoupled Flow 

Below is a sequence diagram showing a typical decoupled payment flow. Depending on the individual implementation of the bank, the actual flow may differ slightly. The green vertical bars indicates who is responsible for the interaction with the payer (PSU).

Embedded Flow

Below is a sequence diagram showing a typical embedded payment flow. Depending on the individual implementation of the bank, the actual flow may differ slightly. The green vertical bars indicates who is responsible for the interaction with the payer (PSU).

Flow steering by links

The table below includes every possible step with the corresponding approach. In the response of each request the named link informs about the next request to be sent according to the actual state in the flow.

Version 2.16.1 to 2.16.2

Version 2.15.1 to 2.16.1

Our solution enables to represent and manage any company with its original hierarchy structure, where the company representation key elements are the following:

• Corporate contract
  • An agreement between the issuer and the company
  • Corporate contract owner is the company itself, with its proper address management (statement delivery address, etc.)
• Corporate organization
  • Corporate organization represents the company
  • Can fully correspond to the company original organization
  • Can be represented by a simple 2-level organization or a complex one (where multilevel organization structure applies)
• Corporate account organization/corporate account
  • Account organization is a mirror of corporate organization, where each corporate entity has its own account
  • For simple 2-level account hierarchy these are the company account and employee card accounts
  • For multilevel complex account hierarchy structure these are the intermediate accounts in between the company account and employee card accounts, where it is possible to have an employee entity attached to any level within the corporate organization
• Corporate card
  • Can be a physical or a virtual one
  • Corporate card owner is the employee itself or the organization (e.g., lodged cards)
    • In general, the same person can represent an employee within corporate cards structure or an individual within consumer cards’ structure, where different addresses can be managed for the same person within corporate or consumer cards (E.g., for the same cardholder (person) a corporate and consumer card statement delivery addresses can be different, card delivery addresses can be different, etc.)

Our solution offers multiple APIs related to corporate contracts and their features such as

• Company management (see Company’s management)
  • including company itself and all its possible entities such as countries, divisions, departments, cost centers
  • creation and update of company data such as company name, external company reference
  • possibility to manage company’s contact(s)
• Employee management (see Customer)
  • Employee, as person, can have both consumer and corporate cards
  • Employee can have 1 or several corporate cards
  • Creation and update of employee data
• Corporate contract management
  • Creation with company organization, employees and cards
    • Company organization can be built later at any moment
    • Employees and cards can be added later at any moment/li>
    • Possibility to e.g.
      • indicate the membership and account setup fees payer (the company, employees)
      • define default, can be changed for each corporate card, such as
        • a default logo reference (transmitted to the embosser)
        • if the company should receive a duplicate of the statement for cards paid by employees
        • the dispatch code (in order to deliver all cards for the given corporate contract to the same corporate address)/li>
        • if cards open-to-buy should be reset to their maximum credit limit, by default, at cyclic closure date (for credit cards only – e.g. credit limit of 3.000€, cardholder has spent 2.000€ then current open-to-buy of 1.000€ is reset to 3.000€ at cycle closure date even if repayment not already received).
  • Update of corporate contract data such as logo reference, membership and account setup fees payer
  • Company organization management
    • Modification of the company organization (e.g. new country and its organization)
    • Update of a certain company entity (change of delivery channels, advertisement options)
  • Close a corporate contract immediately or in the future
    • As soon as the contract is closed all cards are closed (next authorizations are declined) and related accounts start the standard account closing process
• Add employee and its card to a certain entity of the company
  • A new or existing employee can be added with its card and related card account to an entity of the company organization
  • e.g. add employee to a cost center 123456, to division AAAA (e.g. employee is the division manager)
  • possible to e.g.
    • indicate whether the card is repaid by the employee or the company
    • indicate the repayment mode (self-payer, direct debit)
    • provide a specific credit limit value/li>
• Possibility to change how are repaid cards for a certain contract at any moment
  • from repaid by the employee to repaid by the company/li>
  • from repaid by the company to repaid by the employee)

API links

API links

API links