Buy now, pay later is a payment method that allows consumers to buy a product immediately and pay later. This payment method is gaining popularity around the world, especially among younger consumers.

Buy Now Pay Later works like this: Consumers make purchases online or in-store, then select the Buy Now Pay Later payment method. The consumer can then select a later payment date that is convenient to him. Depending on the terms of the contract, fees or interest may apply to this payment method.

Buy now, pay later offers consumers several benefits, including the ability to defer payments to a later date, which can help during temporary financial hardship. Additionally, consumers can better manage their budgets by spreading payments over multiple months.

Pay later usage are rising

Global sales using Buy Now Pay Later reach €93B in 2020

Will exceed €181B in 2022, and would reach 10X this volume in 2025

75% of Buy Now Pay Later users are aged 18-36

How does it work ?

Instalment via push notification

In the moment of card purchase, the banking app receives a push notification

User can tap on it, see the details and select an instalment plan

Split of transactions confirmed in banking app

Card control

Read more about Card control

Card Control enables the cardholder to manage his card in real-time. Cards can be managed via the banking app or online banking through our APIs

The cardholder knows best his habits and preferences for card usage. Card Control allows him/her to customize a card in different aspects. Some examples: set card limits on different channels – in-store/online/contactless payments, cash withdrawals at ATM. As well it is possible to block chosen payment channels or certain merchant categories (e.g., casinos, liquor store, etc.). Geographical reach can also be controlled: countries can be blocked or enabled for card payments. All the mentioned features can be set for a specific period of time. Altogether, a variety of features and its combination provide a detailed customization.

Thanks to a comprehensive customization, Card Control becomes a first step towards risk mitigation. Through spending limit management, country and merchant category blocks, spend notifications, etc. the cardholder gets alert about fraudulent activities and can prevent it. Next to this, extensive card self-management options lead to fewer disputes and a lower number of calls to the customer care center.

The cardholder loses a physical card. He/she opens the banking app and blocks the cards easily.

A new card is issued instantly. The cardholder customizes it by setting spending limits, blocking some merchants and activating notifications?

The cardholder is getting ready for a trip. Before travelling, he/she activates payments by his/her card in specifi countries.

How it works ?

Card Control allows the cardholder to personalize his card overriding the issuer specific standard settings. The customization is achieved by updating and overriding cards authorization restrictions and velocity limits.

Each authorization restriction override is based on an existing authorization restriction. First step is to retrieve the authorizationRestrictionReference through the list of existing authorization restriction by calling the API List of authorization restriction for account. Second step is to modify the authorization restriction using the API Create authorization restriction override. The override created could be then updated using the appropriate API.

Similar process applies to velocity limits. A default velocity limit could be overwritten by Velocity limit overrides API that allows to modify number and amount of authorizations allowed for a specific time period. The override created could be then updated and deleted using the appropriate API.

Merchant management (old version)

Technical Description

The WL FS merchant contract API enables retrieval and updating at site & terminal level. Access to contract data is restricted to your acquirer and own merchant contract identifiers. For third parties, contract updating is limited depending on the generic user role (e.g. PSP, PayFac, Merchant) limitations agreed with the acquiring bank.

Version note:
Please be aware that these API interfaces may be changed and improved (e.g. addition of fields).

The "Try out" feature does not work at this time because the sandbox is being improved to support new functionality.

View Documentation

Read more about Merchant management (old version)

Accounts

Read more about Accounts

Accounts (Features For All Card Types)

Accounts are used to process operations, manage a balance in a dedicated currency, control the credit risk, perform transaction charging, calculate interest (credit or debit), generate an invoice (statement), process payments.

Three types of account working modes are being supported; Pay Later, Pay Now, Pay Before.

Pay Later account working mode is used to implement classical credit card products like charge cards or revolving credit. Pay later accounts are settled by a cyclic closure process and typically produce an invoice (statement) with an amount due which can represent the full or partial statement balance. Credit or debit interest algorithms may apply.
Pay Now account working mode is used for all types of debit cards. Such accounts are typically settled in short frequencies (e. g. daily) and produce debit orders, immediately forwarded to customers’ current accounts. Interest calculation never applies.
Pay Before account working mode is used for the wide range of prepaid card products. The balance is always positive.

The below diagram presents different use cases covered by the API in the account domain.

ob-p-ideal-notification

Read more about ob-p-ideal-notification

Notification API

for iDEAL 2.0

API Reference

The notification APIs described in this chapter needs to be implemented on the Initiating Party side, if the Initiating Party decides to use them. The Open Banking Service will post notifications to these endpoints. For the iDEAL product the post status notification is part of the product, a value-added service is not required (because the notification is part of the iDEAL scheme and the Open Banking Service doesn't have to-do additional polling).

POST Status

Endpoint: POST /status

This API will notify the initiating party about the status of the payment. More details about the fields can be found in the API reference.

Data model

Legend

Orange fields: mandatory for an iDEAL payment
Purple fields: conditionally mandatory for an IDEAL payment

Request (click to enlarge)

Response

Example: Notification for Standard iDEAL payment

Request (Signature-related fields "Digest" and "Signature" are conditionally present):

Address: https://checkout.company.com/transaction/webhook/91FA6EEC30844FAAB5/v3/notification/status
  HttpMethod: POST
  Headers: {Authorization=Bearer 123456789, X-Request-ID=c1452392-6c3f-4365-93f8-40558f61ac36, MessageCreateDateTime=2023-03-15T11:51:24.185+01:00, Digest=SHA-256=0hq1mKzxB1yyc6+hut2bEX7ps+nWyWb2pgQb6AhfhfM=, Signature=keyId="3EBEF6033C00730D9C6DA05165A3CAA1F31036FB",algorithm="rsa-sha256",headers="messagecreatedatetime x-request-id digest",signature="uYgovoK+ibAE7+MzJEKrApDUAgWfUv7RQK22zAxWHCdKCuG4d0HgqpDSqcGlKmP2IMFsC787zDU3oqKeeIIVXR72uZBiOnm0/84UL9e7LVDHDLQsRbfDnmvgX/4xQvdwROmyqh8kkcXTf/48zY0wo2n9iDspCbgTn1DEqAqtAlwunIpea8eYA3FQc+pV2px77wVP7l+9mTxexzLSmum61wWbqE4ESJn0K37gXY54229ZtCnNSlu9rsvjQ5xmDf1e6MvMLBOblXHIReN2t8IH85VGK7mpi8T7JeKb8rIG8qDbQ5TD3BmIS1+RspI95FldLCKLH91/KNrxsgPsrC2QgQ==", Content-Type=application/json}
  Payload: {
  "PaymentProductUsed" : "IDEAL",
  "CommonPaymentData" : {
    "GuaranteedAmount" : "10.00",
    "PaymentStatus" : "SettlementCompleted",
    "PaymentId" : "19928",
    "AspspPaymentId" : "0001070883053837",
    "AspspId" : "10002",
    "DebtorInformation" : {
      "Name" : "Edsger Wybe Dijkstra - Callback",
      "Agent" : "ABNANL2AXXX",
      "Account" : {
        "SchemeName" : "IBAN",
        "Identification" : "NL44RABO0123456789",
        "Currency" : "EUR"
      },
  "UseWaitingScreen" : false
}

Response:

ResponseCode: 204

Example: Notification for iDEAL Payment with Fast Checkout

Request (Signature-related fields "Digest" and "Signature" are conditionally present):

Address: https://checkout.company.com/transaction/webhook/91FA6EEC30844FAAB5/v3/notification/status
  HttpMethod: POST
  Content-Type: application/json
  Headers: {Authorization=Bearer 123456789, X-Request-ID=c1452392-6c3f-4365-93f8-40558f61ac36, MessageCreateDateTime=2023-03-15T11:51:24.185+01:00, Digest=SHA-256=0hq1mKzxB1yyc6+hut2bEX7ps+nWyWb2pgQb6AhfhfM=, Signature=keyId="3EBEF6033C00730D9C6DA05165A3CAA1F31036FB",algorithm="rsa-sha256",headers="messagecreatedatetime x-request-id digest",signature="uYgovoK+ibAE7+MzJEKrApDUAgWfUv7RQK22zAxWHCdKCuG4d0HgqpDSqcGlKmP2IMFsC787zDU3oqKeeIIVXR72uZBiOnm0/84UL9e7LVDHDLQsRbfDnmvgX/4xQvdwROmyqh8kkcXTf/48zY0wo2n9iDspCbgTn1DEqAqtAlwunIpea8eYA3FQc+pV2px77wVP7l+9mTxexzLSmum61wWbqE4ESJn0K37gXY54229ZtCnNSlu9rsvjQ5xmDf1e6MvMLBOblXHIReN2t8IH85VGK7mpi8T7JeKb8rIG8qDbQ5TD3BmIS1+RspI95FldLCKLH91/KNrxsgPsrC2QgQ==", Content-Type=application/json}
  Payload: {
  "PaymentProductUsed" : "IDEAL",
  "CommonPaymentData" : {
    "GuaranteedAmount" : "10.00",
    "PaymentStatus" : "SettlementCompleted",
    "PaymentId" : "19928",
    "AspspPaymentId" : "0001070883053837",
    "AspspId" : "RABONL2UXXX",
    "DebtorInformation" : {
      "Name" : "Edsger Wybe Dijkstra - Callback",
      "Agent" : "ABNANL2AXXX",
      "Account" : {
        "SchemeName" : "IBAN",
        "Identification" : "NL44RABO0123456789",
        "Currency" : "EUR"
      },
      "ContactDetails" : {
        "FirstName" : "Edsger",
        "LastName" : "Dijkstra",
        "PhoneNumber" : "+31612345678",
        "Email" : "edsger@domain.nl"
      },
    "ShippingAddress" : {
        "FirstName" : "Edsger",
        "LastName" : "Dijkstra",
        "PostCode" : "52066",
        "Country" : "NL"
        },
    "BillingAddress" : {
        "FirstName" : "Edsger",
        "LastName" : "Dijkstra",
        "PostCode" : "52066",
        "Country" : "NL"
        }     
    }
  },
  "UseWaitingScreen" : false
}

Response:

ResponseCode: 204

POST Debtor token

Endpoint: POST /debtorToken

This API will provide a debtor token update to the Initiating party. More details about the fields can be found in the API reference.

Data model

Legend

Orange fields: mandatory for an iDEAL payment
Purple fields: conditionally mandatory for an IDEAL payment

Request

Response

Example: Debtor Token Notification for Standard iDEAL payment

Request (Signature-related fields "Digest" and "Signature" are conditionally present):

Address: https://checkout.company.com/transaction/webhook/91FA6EEC30844FAAB5/v3/notification/status
  HttpMethod: POST
  Content-Type: application/json
  Headers: {Authorization=Bearer 123456789, X-Request-ID=c1452392-6c3f-4365-93f8-40558f61ac36, MessageCreateDateTime=2023-03-15T11:51:24.185+01:00, Digest=SHA-256=0hq1mKzxB1yyc6+hut2bEX7ps+nWyWb2pgQb6AhfhfM=, Signature=keyId="3EBEF6033C00730D9C6DA05165A3CAA1F31036FB",algorithm="rsa-sha256",headers="messagecreatedatetime x-request-id digest",signature="uYgovoK+ibAE7+MzJEKrApDUAgWfUv7RQK22zAxWHCdKCuG4d0HgqpDSqcGlKmP2IMFsC787zDU3oqKeeIIVXR72uZBiOnm0/84UL9e7LVDHDLQsRbfDnmvgX/4xQvdwROmyqh8kkcXTf/48zY0wo2n9iDspCbgTn1DEqAqtAlwunIpea8eYA3FQc+pV2px77wVP7l+9mTxexzLSmum61wWbqE4ESJn0K37gXY54229ZtCnNSlu9rsvjQ5xmDf1e6MvMLBOblXHIReN2t8IH85VGK7mpi8T7JeKb8rIG8qDbQ5TD3BmIS1+RspI95FldLCKLH91/KNrxsgPsrC2QgQ==", Content-Type=application/json}
  Payload: {
  "PsuId": "TestOSZ",
  "PaymentId": "12345",
  "DebtorToken": "absjrfergd"
 }

Response:

ResponseCode: 204

Event Stores

Read more about Event Stores

Event Stores

Our issuing solution is composed of several applications that pushes different types of events into one information repository.

Each Application can notify events toward this repository.

Event stores contains comments or business events that can be generated by the different applications (CMS, authorization server, customer service GUI,..) part of our solution.

Retrieve Event Stores

This API enables the list of events associated to a business reference type and a business reference value, for given period of time, to be retrieved.

A business reference type corresponds to a business domain like a CONTRACT, CARD, ACCOUNT whereas a business reference value can be typically a card, account, card contract reference.

The same event can be retrieved for different business reference types and business reference values. Event can be uniquely identified by its correlationId.

Currently, this API is mainly used to get the comments linked to a business reference value (e.g., a given card identifier).

API links

GET api/v2/issuers/{issuerId}/businessRefType/{businessRefType}/businessRefValue/{businessRefValue}/event-stores

Search Event Stores

TThis API enables to retrieve the list of events associated to provided set of business reference types and a business reference values for given period of time.

A business reference types correspond to a business domain like a CONTRACT, CARD, ACCOUNT whereas a business reference values list for each provided type can be typically a card, account, card contract reference.

The same event can be retrieved for different business reference types and business reference values. Event can be uniquely identified by its correlationId.

Currently, this API is mainly used to get the comments linked to a business reference value (e.g., a given card identifier).

API links

POST api/v2/issuers/{issuerId}/event-stores/search

Subscribe to