WL 1-Click REST API Resources Diagram
WL 1-Click REST API Resources Diagram
Accept Transactions API
Technical Description
This API enables you to Accept transactions for your Merchant customers.
Transactions are accepted via a host-to-host connection between the API user and Worldline FS API Gateway. The Worldline FS API Gateway is connected to the Worldline FS acceptance host, which in turn is connected to the Issuer network.
Version note:
Please be aware that these API interfaces may be changed and improved (e.g. addition of fields).
The WL FS Sandbox for Accept Transactions API is available on request for PSPs and banks integrating with Worldline Financial Services (equensWorldline).
Latest open API spec below includes drop-down examples of requests (e.g. Purchase VISA Authorization) and drop-down examples of successful "200" responses. The “Try Out” button functionality is currently not available.
Accept Transactions API version 1.0.2 is operational for Card Not Present transactions. The API roadmap for 2025 includes (Soft-)POS transaction acceptance via this API.
Production release of Accept Transactions API version 1.0.3 is planned for January 2025.
#version 1.0.3 (19-12-2024)
- For API responses with codes other than 200, updated error codes & messages to help improve error handling
-New actionType AUTH_AND_CAPTURE_REVERSAL
#version 1.0.2 (22-11-2024)
- Changed response field “enumerations” into “examples”.
#version 1.0.1 (01-05-2024)
- Adjusted patterns of the following fields:
- 3DSecure.authenticationValue
- token.acceptorId
- token.tavvData
#version 1.0 (26-01-2024)
- Addition of header parameter Trace-ID.
- Addition of new object for Token:
- Addition new field acceptorId
- Addition new field tavvData
- Adjustment Card object:
- Removal of tavv
- Addition of new field walletId. We support wallets such as ApplePay.
-Adjustment to 3DSecure object:
- Result field is no longer required
- Addition of new field subVersion
- Addition of new field dsEci
- Addition of new field authenticationValue
- Removal of ucaf field
- Removal of cavvData field
- Removal of xid field
- Renaming from transactionId to dsTransactionId and changes in the pattern.
- Some updates to the static examples provided.
- Support Wallets e.g. ApplePay
- New actionType AUTH_REVERSAL_PARTIAL
Accept Transactions (test)
Accept Transactions (test)
This API enables you to accept Card Not Present (CNP) and POS transactions for your Merchant customers.
Transactions are accepted via a host-to-host connection between the API user and Worldline FS API GateWay. The Worldline FS API GateWay is connected to the Worldline FS acceptance host, which in turn is connected to the Issuer network.
Version note:
This is a test version. Please be aware that these API interfaces are for evaluation. The API interfaces may be changed and improved.
Initial production release is planned for Q2 2023 to accept Card Not Present transactions. The API roadmap for 2024 includes POS transaction acceptance via this API.
Benefits for you!
Third party access
Allow your third party customers (Payment Facilitators and Merchants) direct access
Intuitive interaction
Using acceptance actions (AUTH, PREAUTH, CAPTURE etc.)
Omni-channel
Accept both Card Not Present and POS transaction requests
Who can use the API?
Acquirers
PSPs
Merchants
Acceptance actions
AUTH
CAPTURE
AUTH_REVERSAL
AUTH_REVERSAL_PARTIAL
AUTH_INCREMENTAL
AUTH_AND_CAPTURE
PREAUTH
Use Cases
Purchase
Refund
Account Verification
Recurring
3D Secure v2
Card-On-File
Are you looking for more information?
Credit Insight
Credit Insight
Introduction
Credit Insight, is an Open Banking Product which relies on an AIS collection of transaction data for the selected client.
The prerequisites to provide a Credit Insight analysis are :
- At least one CHECKING account provided
- At least 20 transactions within the last 90 days
- Transactions must be in EURO
- A callback URL must be provided beforehand.
The workflow goes as follows :
-
The Initiating Party posts and initiates a registration for the client, and chooses the relevant product option.
-
Worldline responds with the appropriate URL for the consent and AIS session, and the client is then redirected to the AIS Bank selection pages.
-
Once the client has selected its bank(s) and accounts, Worldline collects the transactions and balances for the last three months from the bank(s).
-
The Credit Insight analysis is performed, and once the results are available, they are sent to the Initiating Party's callback URL.
Details
For the Credit Insight usecase the relevant and usable endpoints are within the Account Information extended service:
-
POST /register : initiates the process
-
POST /register/{registrationId}/initialisation/{psuId} : used to retrieve the URL to the AIS consent page for the PSU (client) -
GET /register/{registrationId}/status : allows the Initiating Party to know the status of the process (optional)
After the process is initiated and the client has consented to give access to his account(s), the processing begins on the Credit Insight engine.
Once it has completed, the Initiating Party receives the response on the callback URL they provided during the onboarding.
The initial POST /register call should be as follows:
POST /register
{
"RegistrationId": "<registration_id>",
"Psus": [
{
"PsuId": "<psu_id>"
},
],
"Parameter":[
{
"Key":"option",
"Value":"NONE||CS||PS||CSPS"
}
]
}
The Product options need to be specified, in the "Parameter" field. Depending on the items the Initiating party needs returned. In any case, the base response will comprise the Credit Insights, which are further detailed below. The Product options are :
- CS : Credit Score
- PS : Payment Score
- CSPS : Both
- NONE : No scores, only the insights
Credit Insights: The Credit Insights service takes the raw balance and transaction data from the bank and transforms this into an insightful financial report.
All of the transactions are categorized with a specific focus credit, important data is flagged (such as existing loans, payment rejections, etc…) and useful metrics are calculated.
All of this is delivered by API to provide you an instant analysis based on data retrieved directly from the consumer’s bank.
Credit Score: The Credit Score is a number score out of 1000 (a consumer with a score of 0 is the most risky and 1000 the least risky). This number provides a highly accurate predictive assessment of the risk of default within 12 months of the scoring.
Payment score: The payment score is designed for use with short-term credit (repayment period of around 3 months). This is provided as a score out of 10 (a consumer with a score of 0 is the most risky and 10 the least risky).
The second call (POST /register/<registration_id>/initialisation/<psu_id>) is meant to provide a base country for the initiation screens that will be shown to the client.
POST /register/<registration_id>/initialisation/<psu_id>
{
"PsuData":{
"Country": "FR||DE||XY.."
}
}
After the client has consented to the AIS process, the transactions are fetched and processed in the WL Credit Insight engine.
Once the analysis is performed, the following insights are sent within the response to the Initiating Party :
Object name |
In Object |
Description of the items |
|
Balances |
balance balanceDate |
Balances of the client's accounts. |
|
Incomes |
totalAmount incomesDetails (object) |
Summary of the client's sources of incomes. Details show a breakdown in types and temporality of incomes. |
|
Expenses |
totalAmount
expensesDetails (object) fixedCharges otherExpenses |
Summary of the client's expenses. Details show a breakdown of the expenses, notably the fixed charges. |
|
Loans |
loanRepaymentsCount loanRepayments (object) monthlyAmount loanProviders drawdownsCount totalDrawdownAmount monthlyDrawdownAmount |
Summary of the loan repayment transactions on the client's account. |
|
Risks |
gamblingTotalAmount gamblingTransactionsCount gamblingTransactions paymentRejectionsCount paymentRejections paymentRejectionsTotalAmount checkRejectionsCount checkRejections checkRejectionsTotalAmount interventionFeesCount interventionFees interventionFeesTotalAmount overdraftReachedAmount overdraftDuration overdraftFeesCount overdraftFees wageAdvancesCount wageAdvances wageAdvancesTotalAmount directRecoveriesOfDebtCount directRecoveriesOfDebt directRecoveriesOfDebtTotalAmount bankAccountSeizuresCount bankAccountSeizures bankAccountSeizuresTotalAmount |
Detailed list of all identified transactions that fit a risky behavior. |
Account Information Overview
What is Account information?
Account Information Service (AIS) is one of the services established by the Payment Services Directive 2 (PSD2) and aimed to simplify the retrieval of account information. The PSD2 allows Third Party Providers (TPPs) access to the bank's accounts to initiate a payment (PIS) or retrieve account information (AIS) after the account holder (PSU) has given his consent to the TPP.
A payer (PSU) has to consent to a TPP for account information to initiate a AIS request.
Ready to connect?
- Get in touch with our sales team: Send email
- Using PSD2 requires a Third Party Provider certificate provide by the national authority. This certificate will be stored in our solution. So that we can connect to ASPSP's with the correct authentication. We will help with the ordering process.
- We set you up on our backoffice, you will receive a username password to complete the registration process. Which includes providing a public key from the certificate you will be using to connect to us.
- Call the post token api, to retrieve the token which you will use to connect to our other api's
- Call the get aspsps api, to retrieve the list of banks you will be able to reach with our solution
AIS Delete Consents
Using this scenario initiating party (user) can request to revoke a consent given by customer (PSU). When this endpoint is called the TPP solution will also try to revoke the consent at ASPSP side.
If this is successful the status of the consent will be changed to ‘Revoked’.
If it’s not possible to revoke the status at the ASPSP side the status of the consent will be set to ‘RevokedAtTpp’, The consent might still be active on the ASPSP side bit will no longer be used by the TPP solution.
For this scenario, it has been considered that consent has been revoked successfully at ASPSP Mock side.
Take the following steps to complete this scenario.
Step – 1 : Get the reach details :
Reach details provides list of APIs needs to be used for this scenario and mandatory fields needs to be passed for successful API call towards ASPSP mock.
Call the reach API – GET /aspsp. Get the ASPSP details with Name = “AIS Delete Consents” and the ASPSP ID = “20101”, which has to be used to initiate the consent with redirect mode of authorisation and other further requests.
Remark : Details of reach information provided in developer portal are limited and informational purpose to give initiating party (user) an idea about how reach information looks like. Initiating party (user) can skip this step and use specified ASPSP ID for the scenario to try out. User can get the ASPSP ID for appropriate scenario from "Scenario Guideline" page or from the list of "Account Information Services Scenarios" page.
Step – 2 : Acquire customer’s (PSU) consent :
Call the POST /consentextended API to obtain customer’s (PSU) consent. In response of POST /consentextended, initiating party (user) will receive consent ID, ASPSP redirect link to authorise the initiated payment and link to call GET /consent/status API to get the status of the consent.
If GET /consents/status endpoint has been called before user provides his / her approval, initiating party (user) will receive payment status = “Open” from the ASPSP Mock in response.
Step – 3 : Authorise or Cancel the consent at ASPSP Mock :
With ASPSP redirect link received in response of POST /consentextended, customer (PSU) will get redirect to ASPSP Mock GUI login page. On this login page, customer (user) can enter any username and password as this is example purpose only. Once customer (PSU) provides his / her dummy credentials, he / she will be redirected to ASPSP Mock GUI page with “Approve” & “Deny” buttons to authorise or reject the consent.
If customer (PSU) “Approve” the consent, consent will be created with the ASPSP Mock and customer (PSU) will redirect back to initiating party (user).
If customer (PSU) “Deny” the consent, ASPSP Mock will reject the consent and customer (PSU) will redirect back to initiating party (user).
Remark : GUI page of ASPSP Mock to approve or deny the consent is just a demo purpose. Actual ASPSP GUI page to approve or deny the consent may vary based on ASPSP.
Step – 4 : Get the consent status :
Call the GET /consents/status API to get the latest consent status from ASPSP Mock.
If consent is authorised by customer (PSU), initiating party (user) will receive consent status = “Authorised”.
If consent is deny by customer (PSU), initiating party (user) will receive consent status = “Rejected” as final consent status.
Remark : Consent status provided for this scenario is just to guide initiating party (user) for consent process. Actual consent status may vary based on scenario from actual ASPSP.
Step – 5 : Delete the consent :
If consent status = “Authorised”, call the Delete /consents API to revoke the consent.
Step – 6 : Get the consent status :
Call the GET /consents/status API to get the latest consent status from ASPSP Mock.
If consent is revoked successfully by ASPSP Mock, initiating party (user) will receive consent status = “Revoked” as final consent status.
Remark : Consent status provided for this scenario is just to guide initiating party (user) for consent process. Actual consent status may vary based on scenario from actual ASPSP.
Sequence Diagram :
