How to initiate a payment ?
One of our customers makes a transaction on an e-commerce website or wants to initiate a transfer.
Through this API “Payment initiation” available for Banque BCP customers, you can submit a real time payment initiation request.
The connected customer will be requested by his bank to validate this transaction :
- He identifies and authenticates himself
- Then, he selects his bank account with a sufficient balance for the transaction amount
- Finally, the bank seals the transaction after the client has strongly authenticated himself to validate the transaction (some exemptions of this authentication process exist)
In addition, this version brings a single SCA flow if the debtor IBAN is forwarded in the PIS request :
- PSU verifies the displayed transaction information
- Finally, the bank seals the transaction after the client has strongly authenticated himself to validate the transaction (some exemptions of this authentication process exist)
You can only use this API if you are a Payment Initiation Service Provider (“PISP”), this prerequisite is described in “Eligibility” use case.
Once this prerequisite has been fulfilled, the global process will be the following one :
01- As a PISP provider, you can propose funds transfer services to customers, or allow them to pay their purchases on an e-merchant web site you have contractualized with. Thru your interfaces, the customer selects in which bank (ASPSP) his account(s) is/are domiciliated and you collect the transaction information (purchase amount, IBAN creditor, …).
02- During the first exchange with ASPSP’s infrastructures, you will have to request an authorization token. As PISP, you have to get this token BEFORE you can use ressources of the API. This token is generated by the ASPSP AFTER you authenticate as a PISP service provider using your eIDAS certificates.
As banking account holder (ASPSP), we will verify if your certificates and national agreements are valid.
For this step, it is not necessary that we identify and authenticate the customer before generating the access token.
03- If all above checks are correct, you will be able as PISP to get the OAUTH2 access token thru a secure exchange with BPCE API platform (see “Retrieve your access token” use case).
04- By presenting this access token valid only for this transaction, you can then use ressources of the “payment initiation” API in order to :
- Initiate a payment/transfer (see “Send a payment initiation request” use case) ;
- Retrieve the status of a payment/transfer initiation request (see “Retrieve the status of a payment initiation request“) ;
- Confirm a payment/transfer initiation request or a payment/transfer cancellation request (see “Confirm a payment initiation request”)
Consume the API
Prerequites
As TPP you have to be accredited by a national competent authority for this Payment Initiation Service Provider (“PISP”) role.
To access payment initiation API methods, you have to get an OAUTH2 access token provided by customer’s banking institution, obtained with your credentials.
You and the customer’s banking institution have successfully processed a mutual check and authentication (exchange of eIDAS QWAC certificates).
Then, you present your OAUTH2 access token to consume the payment initiation API’s methods.
Initiate a payment
Two use cases exist for a payment initiation :
1) The PISP forwards a payment request on behalf of a merchant : the customer (PSU) purchases goods or services on an e-commerce website (see top of the diagram below).
There is a contract between the merchant and the PISP.
The merchant forwards the requested payment characteristics to the PISP and redirects the customer to the PISP portal.
The PISP asks the customer in which banking institution (ASPSP) is located his account. Then he prepares the payment initiation request and sends this request to customer’s bank.
The beneficiary, as being the merchant, is set at the payment level.
2) The PISP forwards a transfer request on behalf of the owner of the account. The customer provides the PISP with all information requied for the transfer.
The PISP asks the customer in which banking institution (ASPSP) is located his account. Then he prepares the transfer request and sends this request to customer’s bank.
As a PISP, you forward to the ASPSP the request for payment initiation via the POST /paymentRequests method (see “Send a single payment request initiation” use case).
The authentication method supported by the ASPSP is the REDIRECT approach :
1) The customer is redirected to identification screen proposed by his banking institution and he will enter his online banking identifier
If the PISP provides client’s online banking identifier directly in this request, this step will be skipped.
2) The customer is redirected to an authentication screen proposed by his banking institution in order to validate its identity
3) The customer is redirected to account selection screen proposed by his banking
If there is only one eligible IBAN, or if the PISP has already collected customer’s account to be debited and include it in the request, it will be automatically selected and displayed.
4) The customer selects (if applicable) and validates his account to be debited
5) The customer is redirected to a strong customer authentication (SCA) screen proposed by his banking institution to validate is payment/transfer
The process for this step depends on SCA method provided to the PSU by his bank institution (OTP SMS, secur’pass, etc.).
It also depends on PSU’s device (PC, mobile, smartphone, tablet).
6) The customer is redirected to a payment request confirmation screen proposed by his banking institution
7) The customer accepts or declines the transaction and is redirected to PISP app using call back URLs
In order to do so, the payment initiation request posted by the PISP includes one or two call back URLs :
The first one will be called by the customer’s banking institution if the payment request is processed without any error or rejection by the PSU (the PSU has given his consent for the payment)
The second one is to be used by the customer’s banking institution in case of processing error or rejection by the PSU (refusal of consent). This second URL is optional : the first url will be used if the second one is not transmitted
8) the TPP has to forwed a last confirmation request using POST /payment-requests/{paymentRequestResourceId}/o-confirmation for executing the PIS operation.
In addition, this version brings a single SCA flow if the debtor IBAN is forwarded in the PIS request :
1) The customer is redirected to a payment request confirmation screen proposed by his banking institution
2) The customer accepts or declines the transaction
3) The customer is redirected to an identification screen proposed by his banking institution in order to validate its identity
4) The customer is redirected to PISP app using call back URLs
5) the TPP has to forwed a last confirmation request using POST /payment-requests/{paymentRequestResourceId}/o-confirmation for executing the PIS operation
Retrieve the status of a payment of a payment request initiation
You may recover ay anytime the status of an initiation of payment via the method GET / paymentRequest (see “Recover the status of a payment request initiation” use case).
This call allows you to retrieve all the payment initiation data enriched with the resource identifiers and the status of the payment initiation request and the payment it contains.
The data is available for 35 days.
Cancellation of a payment/transfer request
You may cancel an initiation of payment via the method PUT /paymentRequests (see “Cancel a payment request initiation“) effective as soon as it has been processed.
The SCA is performed using REDIRECT mode.
1) The customer is redirected to an identification screen offered by its banking institution and in which it will enter its remote banking identifier.
2) The customer is redirected to a strong authentication screen offered by its banking institution to validate its identity.
3) The customer is redirected to a summary screen of the operation being canceled proposed by its bank.
4) The customer validates the cancellation of the transfer.
5) The customer is redirected to a confirmation screen for the operation offered by its bank.
6) The customer is redirected to the TPP PISP application.
The PISP provides one or two call back URLs with its cancellation request:
The first will be called by the banking establishment if the cancellation request is processed and if the customer has given its consent for this transaction cancellation.
The second URL will be used by the banking establishment in the event of refusal of consent or of a problem.
This second URL is optional: the first call back URL will be used if the second is left blank.
Confirmation of a payment request (PISP)
You may confirm a payment initiation request or payment initiation cancellation via the method POST /paymentRequests/{paymentRequestResourceId}/o-confirmation (see “Confirm a payment initiation” use case).
There is no confirmation for a PIS cancellation.
How to use the fallback mode ?
Principle
In order to comply with PSD2 regulations, banks available on this BPCE API developer portal have setup contingency measures in case of unplanned unavailability of the dedicated API interface.
The principle of this « fallback » solution is explained below:
This fallback mechanism meets PSD2 regulatory requirements (article 33/RTS). It can be used with the same conditions and prerequisites applicable for the dedicated API interface which are specified in the “Eligibility” use case.
Roadmap
Please do find below our estimated roadmap :
| Version | Fonctionnalités | Sandbox
Date de déploiement BPCE API Dev Portal & Sandbox |
Live
Date de déploiement BPCE Live API Gateway |
| v1.0 | Fallback (*) | Non applicable | Fin Septembre 2019 |
(*) Main features :
- Use the same API dedicated interface endpoint. The list of our banking institutions and the possible values of <bkcode> are specified in the “Limitations” use case ;
- A parameter (header ‘fallback:1’ present or absent) managed directly by the TPP allows do differentiate any « Fallback » request from dedicated interface PSD2 API requests ;
- Use of same TPP eIDAS certificate (QWAC) to be presented for mutual TLS authentication ;
- Use the same PSU authentication procedure and means for accessing online banking services ;
- This fallback solution is always active, even so the dedicated interface API must be used systematically in first priority. Its usage is subject to strict conditions as described in Article 33 of RTS, and can’t be used as the main access for PSD2 features. It will be monitored as such and every abuse will be automatically reported to our national competent authority.
Example
- If PSD2 API are not available due to unplanned unavailability or systems breakdown (see RTS Art. 33), TPP should use the following request with <codetab>=17515 as an example :
POST https://www.12579.live.api.89c3.com/stet/psd2/oauth/token
with :
- its live eIDAS QWAC certificate
- fallback:”1″ parameter in the header
2. If all checks are successful, the TPP will receive in the header of the response with url online (allowing to access banking login web page) as well as the JWT token.
3. TPP can then apply its proprietary login process using PSU credentials.
For more details about POST request, see STET V1.4.0.47 / Part I / section 3.4.3.2 / page 22 or STET V1.4.2.17 / Part I / section 3.4.3
Note
Please note the following constraints which apply on this fallback mechanism :
- No re-use of the API dedicated interface context, neither any of 180-day validity access token generated for AISP role
- Only online internet banking features are used as a reference (excl’d mobile banking features) and are accessible thru the fallback mode. As an example, online banking doesn’t propose any e-commerce transactions to customers, so PISP could NOT propose this feature in fallback mode
- The user of payment services (PSU) must be connected to the TPP PSP app, so no AISP batch process is possible
- PSD2 also imposes a reinforcement of strong customer authentication (SCA) for accessing direct online banking services. Therefore fallback mechanism leverages on reinforced PSU online banking authentication procedures and means such as (non exhaustive list) :
- Soft token
- OTP SMS
- Physical token (corporate market)
Try-it console
Process
By connecting to the portal, you can:
- Use the “payment initiation” API via a form in which you select your application and the authentication/access token
- Then enter the parameters of the method you wish to test (either headers or body), with the mandatory parameters indicated by a star.
Once the parameters are entered, you can execute the query: you get a result or an error.
The user can chain the requests by selecting the customer profile either for the Banque Populaire or for the Caisses d’Epargne from which he wishes to test the methods, the implemented features being different depending on the bank (see “Limits” use case).
Overview of the Try-it form
Resource owner = “ClientBanquePopulaire” must be selected test for Banques Populaires institutions.Resource owner = “ClientCaisseEpargne” must be selected for Caisses d’Epargne institutions.
Overview of the generating Oauth2 token screen
The screen is accessible when you edit the application (TPP PISP) and allows you to generate or edit an Oauth2 token that you will select in the Try-It execution form.
Send a payment request initiation with a Try-it form
Below is a description of the various parameters to initiate a payment request with POST /paymentRequests method:
| Parameter | Description | Type of data | Type of parameter | Madatory |
| Authorization* | Access token, must be provided in the headers | String | Header | yes |
| PSU-IP-Address | IP address used by the PSU when connecting to the TPP
*mandatory if the client is connected but not filled in case of access through batch |
String | Header | non* |
| PSU-IP-Port | IP port used by the PSU when connecting to the TPP | String | Header | non |
| PSU-HTTP-Method | HTTP method used in the most accurate request made by the PSU towards the TTP | String | Header | non |
| PSU-Date | Timestamp used in the most accurate request made by the PSU towards the TTP | String | Header | non |
| PSU-GEO-Location | Geo location of the PSU given to the TPP by the PSU mobile terminal if it exists | String | Header | non |
| PSU-User-Agent | Header “User-Agent” sent by the PSU when connecting to the TPP | String | Header | non |
| PSU-Referer | Header “Referer” sent by the PSU when connecting to the TPP. Please note that in previous specifications of the RFC 1945 the name ‘referrer’ (mispelled) was recommended. It can be used at the risk of not being understood. | String | Header | non |
| PSU-Accept | Header “Accept” sent by the PSU when connecting to the TPP | String | Header | non |
| PSU-Accept-Charset | Header “Accept-Charset” sent by the PSU when connecting to the TPP | String | Header | non |
| PSU-Accept-Encoding | Header “Accept-Encoding” sent by the PSU when connecting to the TPP | String | Header | non |
| PSU-Accept-Language | Header “Accept-Language” sent by the PSU when connecting to the TPP | String | Header | non |
| PSU-Device-ID | UUID (Universally Unique Identifier) of the device used by the PSU, if possible | String | Header | non |
| Digest* | Request data | String | Body | yes |
| Signature* | Signature http of the request (see https://datatracker.ietf.org/doc/draft-cavage-http-signatures/) The keyId of the header should be formatted as keyId=”SN=XXX,CA=YYYYYYYYYYYYYYYY” where “XXX” is the serial number in hexadecimal without any prefix (as 0x, from the QSEAL certificate which private key has been used as signature)
“YYYYYYYYYYYYYYYY” is the DN transmitter, complete name of the certification autority |
String | Header | yes |
| X-Request-ID* | Correlation Header to set up in the request that must be retrieved in the response | String | Header | yes |
For the request body, you have the possibility to copy-paste an example into the form (located to the right of the screen) by using the small blue magnifier from the parameter description, changing some specific values:
The magnifier expands a pop-in containing a model of the swagger and an example:
You may then click the pink arrow located below the pop-in to paste the example into the Try-It form. Please note that the example is issued from the STET specifications and it contains an error in the schemeName’s codes.
A request sample is given below and the following data must be unique, otherwise the request is rejected because of duplicate (replay of the request is not allowed) :
- paymentInformationId ;
- instructionId ;
- endToEndI ;
- x-request-id
{
“paymentInformationId”: “MyPmtInfld123”,
“creationDateTime”: “2019-07-22T09:25:22.527+02:00”,
“numberOfTransactions”: 1,
“debtorAgent”: {
“bicFi”: “CCBPFRPP512”,
“name”: “B.P Grand Ouest”,
“postalAddress”: {
“country”: “FR”,
“addressLine”: [
“15 Boulevard de la Boutière”,
“CS 26858 35768 SAINT GREGOIRE CEDEX”
]
}
},
“initiatingParty”: {
“name”: “MyPispName”,
“postalAddress”: {
“country”: “FR”,
“addressLine”: [
“5 avenue Anatole France “,
“75007 PARIS”
]
},
“organisationId”: {
“identification”: “12FR5”,
“schemeName”: “COID”,
“issuer”: “ACPR”
}
},
“paymentTypeInformation”: {
“serviceLevel”: “SEPA”,
“categoryPurpose”: “CASH”
},
“debtor”: {
“name”: “Marc “,
“postalAddress”: {
“country”: “FR”,
“addressLine”: [
“512 rue de la coupe du monde”,
“94512 Charenton-le-Pont”
]
},
“privateId”: {
“identification”: “D0999990I0”,
“schemeName”: “BANK”,
“issuer”: “BICXYYTT512”
}
},
“debtorAccount”: {
“iban” : “FR7613807008043001965405255”
},
“beneficiary”: {
“creditor”: {
“name”: “myMerchant”,
“postalAddress”: {
“country”: “FR”,
“addressLine”: [
“Place Charles de Gaulle”,
“75008 PARIS”
]
},
“organisationId”: {
“identification”: “852126790”,
“schemeName”: “BANK”,
“issuer”: “FR”
}
},
“creditorAgent”: {
“bicFi”: “CCBPFRPP512”,
“name”: “B.P Grand Ouest”,
“postalAddress”: {
“country”: “FR”,
“addressLine”: [
“15 Boulevard de la Boutière”,
“CS 26858 35768 SAINT GREGOIRE CEDEX”
]
}
},
“creditorAccount”: {
“iban”: “FR7613807008043001965406128”
}
},
“purpose”: “COMC”,
“chargeBearer”: “SLEV”,
“requestedExecutionDate”: “2019-07-23T13:25:22.527+04:00”,
“creditTransferTransaction”: [
{
“paymentId”: {
“instructionId”: “MyInstrId123”,
“endToEndId”: “MyEndToEndId123”
},
“instructedAmount”: {
“currency”: “EUR”,
“amount”: “327.12”
},
“remittanceInformation”: [
“MyRemittanceInformation123”
]
}
],
“supplementaryData”: {
“acceptedAuthenticationApproach”: [
“REDIRECT”,
“DECOUPLED”
],
“scaHint”: “scaExemption”,
“successfulReportUrl”: “https://www.api.89c3.com/fr/”,
“unsuccessfulReportUrl”: “https://www.api.89c3.com/fr/nous-contacter”
}
}
After having filled the mandatory parameters, you can submit the request clicking the Execute button. The result is displayed under the Execute button:
RESULT
Status code : 201
{ “appliedAuthenticationApproach”: “REDIRECT”,
“_links”: {
“consentApproval”: {
“href”: “TPPPISPurlConsentApproval/psuId.html?resourceId=0000000180-1551358254000131359238543&nonce=Id-2ed9775ce61639e9a3c94ecc”,
“templated”: null
}
}
}
You can also consult the data sent in the header by expanding the Headers area:
Retrieve the status of a payment request initiation with a Try-it form
The description of the different parameters to retrieve the status of a payment initiation with the GET /paymentRequest method is the same as those for the POST /paymentRequest method.
It is necessary to pass:
- as a paymentRequestRessourceId argument the value of the field of the same name obtained in response to the POST /paymentRequest method;
- the same x-request-id passed to the POST / paymentRequest method.
RESULT
Status code : 201
{
“paymentRequest”: {
“resourceId”: “0000000a22-146329369000016907660677”,
“paymentInformationId”: “MyPmtInfld123”,
“creationDateTime”: “2019-07-22T09:25:22.527+02:00”,
“numberOfTransactions”: 1,
“debtorAgent”: {
“bicFi”: “CCBPFRPP512”,
“name”: “B.P Grand Ouest”,
“postalAddress”: {
“country”: “FR”,
“addressLine”: [
“15 Boulevard de la Boutière”,
“CS 26858 35768 SAINT GREGOIRE CEDEX”
]
}
},
“initiatingParty”: {
“name”: “MyPispName”,
“postalAddress”: {
“country”: “FR”,
“addressLine”: [
“5 avenue Anatole France “,
“75007 PARIS”
]
},
“organisationId”: {
“identification”: “12FR5”,
“schemeName”: “COID”,
“issuer”: “ACPR”
}
},
“paymentTypeInformation”: {
“serviceLevel”: “SEPA”,
“categoryPurpose”: “CASH”
},
“debtor”: {
“name”: “Marc “,
“postalAddress”: {
“country”: “FR”,
“addressLine”: [
“512 rue de la coupe du monde”,
“94512 Charenton-le-Pont”
]
},
“privateId”: {
“identification”: “D0999990I0”,
“schemeName”: “BANK”,
“issuer”: “BICXYYTT512”
}
},
“debtorAccount”: {
“iban”: “FR7613807008043001965405255”
},
“beneficiary”: {
“creditorAgent”: {
“bicFi”: “CCBPFRPP512”,
“name”: “B.P Grand Ouest”,
“postalAddress”: {
“country”: “FR”,
“addressLine”: [
“15 Boulevard de la Boutière”,
“CS 26858 35768 SAINT GREGOIRE CEDEX”
]
}
},
“creditor”: {
“name”: “myMerchant”,
“postalAddress”: {
“country”: “FR”,
“addressLine”: [
“Place Charles de Gaulle”,
“75008 PARIS”
]
},
“organisationId”: {
“identification”: “852126790”,
“schemeName”: “BANK”,
“issuer”: “FR”
}
},
“creditorAccount”: {
“iban”: “FR7613807008043001965406128”
}
},
“purpose”: “COMC”,
“chargeBearer”: “SLEV”,
“paymentInformationStatus”: “PDNG”,
“statusReasonInformation”: null,
“fundsAvailability”: null,
“booking”: null,
“requestedExecutionDate”: “2019-07-23T13:25:22.527+04:00”,
“creditTransferTransaction”: [
{
“paymentId”: {
“resourceId”: “0000000a22-146329369000016907660677”,
“instructionId”: “MyInstrId123”,
“endToEndId”: “MyEndToEndId123”
},
“instructedAmount”: {
“currency”: “EUR”,
“amount”: “327.12”
},
“remittanceInformation”: [
“MyRemittanceInformation123”
],
“transactionStatus”: “PDNG”
}
],
“supplementaryData”: {
“appliedAuthenticationApproach”: “REDIRECT”,
“scaHint”: “scaExemption”,
“successfulReportUrl”: “https://www.api.89c3.com/fr/”,
“unsuccessfulReportUrl”: “https://www.api.89c3.com/fr/nous-contacter”
}
}
}
Sandbox assembly
Introduction : detailed features of the Sandbox
You can use the BPCE API sandbox:
- Via the BPCE portal Try-It (see « Try-It console » use case) ;
- Directly through your application by calling the payment initiation API of the BPCE-API platform (sandbox assembly).
In sandbox assembly, there are two types of requests:
- A first request to retrieve the authorization token (see “Retrieve your access token“) ;
- A second one to send a request to the payment initiation API (see “Send a single payment initiation request” and “Retrieve the statuts of a payment request initiation“).
Your application must request the AS (authentication server) to get an access token via its authentication key.
This access token will enable your application to submit the POST /payment-requests and the GET /payment-requests methods of the payment Initiation API.
You can perform a series of requests :
- Submit POST /payment-requests method to initiate a payment
- Then, submit GET /payment-requests/{paymentRequestResourceId} with the parameter paymentRequestResourceId got in response of the first request, to get the payment status
The data used in the tests are based on persona (see “Test data” use case). This will enable you to choose specific profiles according to the tests.
The list of current available bank institutions for sandbox assembly for this API is detailed below (“bkcode” parameter used in URLs) :
| Bank code | Bank name | Bank short name |
| 13807 | B.P Grand Ouest | BPGO |
| 13807 | CMM Grand Ouest | CMMGO |
| 17515 | Caisse d’Epargne Ile De France | CEIDF |
| 12579 | Banque BCP | BBCP |
Sequence stets to test access to the PISP API from your APP
Prerequisites
You must declare your APP on BPCE API portal (see “My apps” menu) and send us your QWAC and QSEALC test certificates public keys so we can :
- Declare your APP as a consumer application of the API ;
- Integrate your QWAC and QSEALC test certificates public keys in our infrastructure ;
- Retrieve and control your organizationId and your “PISP” role in our TPP registry.
Please note that as a TPP, you must be accredited (or in the on-going accreditation process) by any european competent authority (ACPR in France) for this Payment Initiation Service Provider role (“PISP”).
STEP #1 : Retrieve your access token
This call allows you to retrieve the access token from the institution’s authentication server, which is a prerequisite for each access to one of the payment initiation API methods. The description of this feature and the fields of the request are given in the “Retrieve your access token“.
The entry point for accessing to the sandbox assembly is : www.<bkcode>.sandbox.api.89c3.com
Request :
POST https://www.13807.sandbox.api.89C3.com/stet/psd2/oauth/token
Headers :
Content-Type : application/x-www-form-urlencoded; charset=utf-8
Params :
client_id : PSDFR-ACPR-12345
grant_type : client_credentials
scope : pisp
Notes on parameters :
<bkcode> => bank code available in this environment :
13807 (Banque Populaire Grand Ouest) ;
17515 (Caisse d’Epargne Ile de France).
client_id : your agreement number as defined by your national competent authority. (PSDXX-YYYY-ZZZZZ)
grant_type => unchangeable = “client_credentials”
Response :
{
“access_token” : “firstAccessToken_ABCXdBobTpdwRRaYy2H3w7pP5Xe61e1R9rwxMuhk7G0fULg8x6kJHz”,
“token_type” : “Bearer”,
“expires_in” : “3600”,
“scope” : “pisp”
}
Notes on parameters :
access_token => tokenCredential to transmit in the header authorization of payment initiation API requests, next to Bearer XX.
expires_in => period of validity of the token in seconds
STEP #2 : Send a payment initiation request
This call method post /payment-requests/ allows you to initiate a payment by asking the connected customer to give his consent for the payment.
The description of this feature and the fields of the request is given in the “Send a single payment request initiation” use case.
Reminder: the authentication method supported by the bank is the REDIRECT authentication approach => the sequence of PSU identification and strong authentication (SCA) screens described below correspond to this authentication mode.
The entry point for accessing to the sandbox assembly is identical : www.<bankcode>.sandbox.api.89c3.com
Request :
POST https://www.13807.sandbox.api.89C3.com/stet/psd2/v1.4.2/payment-requests
Headers :
Authorization: Bearer firstAccessToken_ABCXdBobTpdwRRaYy2H3w7pP5Xe61e1R9rwxMuhk7G0fULg8x6kJHz
Content-Type: application/json
Signature: keyId=\”https://<www.myUrlPath.to>/myQsealCertificate_<footprint-sha256>\”, algorithm=\”rsa-sha256\”, headers=\”(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\”, signature=\”LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4xh679gdGwmlKzn7E+ZtZ1I4qalRxcdLp4gBL7fll+C2lVBNJrViMJBezFK7AYVjnSWH7t1QxiMVg3CmoRM=\”
X-Request-ID : MyXrequestId123
Body :
{ “paymentInformationId”: “MyPmtInfld123”, “creationDateTime”: “2021-09-05T09:25:22.527+02:00”, “numberOfTransactions”: 1, “requestedExecutionDate”: “2021-09-06T14:10:10.109+01:00”, “debtorAgent”: { “clearingSystemMemberId”: { “clearingSystemId”: “clearingSystemId”, “memberId”: “memberId” }, “bicFi”: “CCBPFRPP512”, “name”: “Cpy Name”, “postalAddress”: { “country”: “FR”, “addressLine”: [ “512 rue De Gaulle”, “85000 LRSY” ] } }, “initiatingParty”: { “name”: “Pisp Name”, “postalAddress”: { “country”: “FR”, “addressLine”: [ “512 rue Reaumur”, “75512 PARIS” ] }, “organisationId”: { “identification”: “12FR5”, “schemeName”: “COID”, “issuer”: “ACPR” } }, “paymentTypeInformation”: { “serviceLevel”: “SEPA”, “categoryPurpose”: “DVPM” }, “debtor”: { “name”: “Customer Name”, “postalAddress”: { “country”: “FR”, “addressLine”: [ “512 rue Leclerc”, “94512 Charenton-le-Pont” ] } }, “beneficiary”: { “creditor”: { “name”: “Amazon SA”, “postalAddress”: { “country”: “FR”, “addressLine”: [ “512 avenue Maupassant”, “75512 PARIS” ] }, “organisationId”: { “identification”: “852126790”, “schemeName”: “BANK”, “issuer”: “FR” } }, “creditorAgent”: { “name”: “Creditor Name”, “bicFi”: “CCBPFRPP512”, “postalAddress”: { “country”: “FR”, “addressLine”: [ “512 rue de la primaube”, “12512 RODEZ” ] }, “clearingSystemMemberId”: { “clearingSystemId”: “clearingSystemId”, “memberId”: “memberId!” } }, “creditorAccount”: { “iban”: “FR7613825002000400000541718” } }, “chargeBearer”: “SLEV”, “creditTransferTransaction”: [ { “purpose”: “COMC”, “paymentId”: { “instructionId”: “instructionId 1630919339”, “endToEndId”: “endToEndId 1630919339” }, “instructedAmount”: { “currency”: “EUR”, “amount”: “2.41” }, “remittanceInformation”: { “unstructured” : [ “remittanceInformation01” ] } } ], “supplementaryData”: { “acceptedAuthenticationApproach”: [ “REDIRECT” ], “scaHint”: “scaExemption”, “successfulReportUrl”: https://extensions.bpce.fr/OAuth2Callback.aspx&state=OK- 12345&code_challenge_method=S256&code_challenge=ABCD } }
Notes on parameters :
Authorization : Bearer => access_token recovered for the tokenCredential
Following data must be unique, otherwise the request is rejected because of duplicate (the replay is not allowed):
– paymentInformationId ;
– instructionId ;
– endToEndId ;
– x-request-id.
debtor/privateId/identification => customer remote banking identifier : when filled, the identification screen of the customer is not displayed.
debtorAccount => customer’s IBAN : when it is filled, the only account selectable for the customer is the one that corresponds to this IBAN.
The implemented features may differ between the Banques Populaires and the Caisses d’Epargne (see “Send a single payment initiation” use case).
Réponse :
{
“appliedAuthenticationApproach” : “REDIRECT”,
“_links” : {
“consentApproval” : {
“href” :”https://www.13807.sandbox.api.89c3.com/89C3api/accreditation/v2/identificationPisp?paymentRequestResourceId=00000000a22-156688979900016807956016&nonce=qJammuGI0OGCwznaZ0YO”,
“templated” : true
}
}
}
Headers :
X-Request-ID : MyXrequestId123
Status code : 201 OK
Notes on parameters :
paymentRequestResourceId => identifier to pass to the GET /payment-requests request to recover the status of the payment initiation request.
appliedAuthenticationApproach” = “REDIRECT” => only allowed value
href => URL of the redirection page to the identification and authentication screens of the banking institution
nonce => technical anti-replay
currency => recovered from the body given as input
successfulReportUrl => recovered from the body given as input
unsuccessfulReportUrl => recovered from the body given as input
iban => recovered from the body given as input
creditorName => recovered from the body given as input
X-Request-ID => transmitted as input
STEP #3: Nominal sequence of PSU identification & SCA
Sequence of identification and strong authentication screens:
Using the URI returned in consentApproval, it is possible to play the sequence of screens.
1) The PSU is redirected to an identification screen presented by his ASPSP (redirection mode) in which he will enter his remote banking identifier.
Warning : only one call to this screen can be made
=> the “nonce” parameter in the URL that gives access to this screen can only be used once (any second call with this nonce will rejected)
=> if necessary, a new call to PaymentRequests is required to get a new token
The remote banking identifier of the customer is to be entered (see “Test data” use case for the data sets of the banking institution), example for the persona “Marc” of the Banques Populaires :
Note: If the PISP provides the remote banking identifier of the customer in its request (field “debtor/privateId/identification“), the following step is directly triggered.
For Caisses d’Epargne, if the customer is a professional or a corporate, he will have to enter is user number in addition to his remote banking identifier.
2) The customer is redirected to a first authentication screen proposed by its ASPSP in order to validate his/her identity:
The SMS code for authentication is to be entered (see “Test data” use case for the data sets of the banking institution), example for the persona “Marc” of the Banques Populaires:
This sequence depends on the strong authentication method proposed to the customer by the bank (SMS OTP, soft token, etc…).
It also depends on the equipment connected to the PISP APP used by the customer (PC or mobile / smartphone / tablet).
3) The customer is redirected to a screen where he will have to select its account to be debited.
Example for the persona “Marc” of the Banques Populaires who has 4 accounts, three of which are eligible for DSP2 payment initiations (see “Test data” use case for the datasets of the banking institution):
IMPORTANT NOTE : If the PISP provides the IBAN of the customer to be debited in its request (field “debtorAccount“), only the corresponding account will be selectable and proposed to the customer : example below for the persona Tech’n Co of the Banques Populaires.
Note: If the customer does not have an account, the request for payment initiation will not succeed and the customer will be redirected to your APP. Example for the persona “Thomas” of the Banques Populaires.
4) The customer selects and validates the account to be debited :
5) The customer is redirected to a second strong authentication screen proposed by his banking institution to validate his payment (dynamic linking).
Screens are identical to the strong authentication screen of step 2) to validate the customer’s identity.
The final decision whether or not to apply an authentication exemption is still at the discretion of the ASPSP as described in article 2 of the RTS of the DSP2. So far, exemptions are not possible for the SCA step to validate the payments.
6) The PSU is redirected to a confirmation screen of the transaction proposed by its ASPSP.
Note: when the customer does not validate the payment initiation (or in the event of a timeout on the account selection page for example) the customer is redirected to the next page :
The customer is redirected to the PISP APP which provides in its first initiation request one or two call back URLs:
The first (successfulReportUrl) will be called by the banking institution in case the payment initiation request is processed and if the customer has given its consent for the payment.
A “code” parameter is added to this successfulReportUrl which is mandated to request the access token for the /o-confirmation method :
Example : https://<votre SuccessfulReportUrl>?code=GbmTn1ZZ76bibgvCRLxD4lNp8wMzkd
The second one (unsuccessfulReportUrl) will be used by the bank in case of refusal of consent or if the validation kinematics of the payment initiation is interrupted at one of its stages (example: timeout on the identification screen, on the account selection screen to be debited or the strong authentication screens). This second URL is optional : the first URL call back (successfulReportUrl) will be used if the second is not filled.
Sequence of the identification and strong authentication screens when the remote bank identifier of the customer (*) is transmitted in the request:
When the access identifier for the remote bank for the customer (debtor/privateId/identification field in the payment initiation request) is filled in, the call to the identification screen of the customer is not performed, cf. drawing below :
(*) for Caisses d’Epargne, Banque BCP, Crédit Coopératif et BTP Banque PSU segments PRO & ENT : we require having the PSU subscription number separated fomr the usage number by a “-“.
STEP #4 : Retrieve the Status of a payment initiation request (only available in live production)
This method get /payment-requests/{paymentRequestResourceId} allows you to retrieve all the payment initiation data enriched with the resource identifiers and the status of the payment initiation it contains.
The description of this feature and fields of the request is described in the use case “Retrieve the status of a payment request initiation“. The data is accessible for 35 days.
For accessing to the sandbox assembly, the entry point is identical :
Request :
Headers :
Authorization: Bearer firstAccessToken_ABCXdBobTpdwRRaYy2H3w7pP5Xe61e1R9rwxMuhk7G0fULg8x6kJHz
Content-Type: application/json
Signature: keyId=\”https://<www.myUrlPath.to>/myQsealCertificate_<footprint-sha256>\”, algorithm=\”rsa-sha256\”, headers=\”(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\”, signature=\”LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4xh679gdGwmlKzn7E+ZtZ1I4qalRxcdLp4gBL7fll+C2lVBNJrViMJBezFK7AYVjnSWH7t1QxiMVg3CmoRM=\”
X-Request-ID : MyXrequestId123
Notes on parameters :
Authorization:Bearer => access_token retrieved for tokenCredential.
x-request-id => must be the same as for the payment initiation request.
The paymentRequestResourceId is retrieved in response to the payment initiation request, when the payment initiation has been processed and the PSU has given its consent for the payment.
Response :
{
“paymentRequest” : {
“resourceId” : “0000000a22-146329369000016907660677”,
“paymentInformationId” : “MyPmtInfld123”,
“creationDateTime” : “2019-07-22T09:25:22.527+02:00”,
“numberOfTransactions” : 1,
“debtorAgent” : {
“bicFi” : “CCBPFRPP512”,
“name” : “B.P Grand Ouest”,
“postalAddress” : {
“country” : “FR”,
“addressLine” : [
“15 Boulevard de la Boutière”,
“CS 26858 35768 SAINT GREGOIRE CEDEX”
]
}
},
“initiatingParty” : {
“name” : “MyPispName”,
“postalAddress” : {
“country” : “FR”,
“addressLine” : [
“5 avenue Anatole France “,
“75007 PARIS”
]
},
“organisationId” : {
“identification” : “12FR5”,
“schemeName” : “COID”,
“issuer” : “ACPR”
}
},
“paymentTypeInformation” : {
“serviceLevel” : “SEPA”,
“categoryPurpose” : “DVPM”
},
“debtor” : {
“name” : “Marc “,
“postalAddress”: {
“country” : “FR”,
“addressLine” : [
“512 rue de la coupe du monde”,
“94512 Charenton-le-Pont”
]
},
“privateId” : {
“identification” : “D0999990I0”,
“schemeName” : “BANK”,
“issuer” : “BICXYYTT512”
}
},
“debtorAccount” : {
“iban” : “FR7613807008043001965405255”
},
“beneficiary” : {
“creditorAgent” : {
“bicFi” : “CCBPFRPP512”,
“name” : “B.P Grand Ouest”,
“postalAddress” : {
“country” : “FR”,
“addressLine” : [
“15 Boulevard de la Boutière”,
“CS 26858 35768 SAINT GREGOIRE CEDEX”
]
}
},
“creditor” : {
“name” : “myMerchant”,
“postalAddress” : {
“country” : “FR”,
“addressLine”: [
“Place Charles de Gaulle”,
“75008 PARIS”
]
},
“organisationId” : {
“identification” : “852126790”,
“schemeName” : “BANK”,
“issuer” : “FR”
}
},
“creditorAccount” : {
“iban” : “FR7613807008043001965406128”
}
},
“purpose” : “COMC”,
“chargeBearer” : “SLEV”,
“paymentInformationStatus” : “PDNG”,
“statusReasonInformation” : null,
“fundsAvailability” : null,
“booking”: null,
“requestedExecutionDate” : “2019-07-23T13:25:22.527+04:00”,
“creditTransferTransaction” : [
{
“paymentId” : {
“resourceId” : “0000000a22-146329369000016907660677”,
“instructionId” : “MyInstrId123”,
“endToEndId” : “MyEndToEndId123”
},
“instructedAmount” : {
“currency” : “EUR”,
“amount” : “327.12”
},
“remittanceInformation” : [
“MyRemittanceInformation123”
],
“transactionStatus” : “PDNG”
}
],
“supplementaryData” : {
“appliedAuthenticationApproach” : “REDIRECT”,
“scaHint” : “scaExemption”,
“successfulReportUrl” : “https://extension.bpce.fr/calback.aspx&state=OK-12345&code_challenge_method=256&code_challenge=ABCD”
}
}
}
Headers :
X-Request-ID : MyXrequestId123
Status code : 200 OK
Notes on parameters :
resourceId => equals to paymentRequestResourceId
paymentInformationStatus => gives payment initiation status
transactionStatus => gives transaction status
X-Request-ID => transmitted as input
STEP #5 : Confirm payment initiation status (only available in live production, NOT in sandbo)
This mandated method POST /payment-requests/{paymentRequestResourceId}/o-confirmation allow to confirm a payment status for security reasons.
Please note that the method POST /payment-requests/{paymentRequestResourceId}/confirmation is not implemented.
The TPP needs to request a specific access token :
Request :
POST https://www.13807.live.api.89C3.com/stet/psd2/oauth/token
Headers :
Content-Type : application/x-www-form-urlencoded; charset=utf-8
Body :
grant_type : authorization_code
client_id : the one generated if the TPP is enrolled using our API Register
code : code extracted from previous call in the successful URL at the end of STEP #3
code_verifier : depends on your PKCE data
redirect_uri: :predeclared uri communicated to ASPSP in the enrolment process
Response :
{
“access_token” : “secondAccessToken_NBVcxwwmLkjhgfdspoie00OIuyTRPFs”,
“token_type” : “Bearer”,
“expires_in” : “3600”,
“refresh_token“: “1ji8KA9RJ5eXeJV1xKSDj1WDp8wwg3pRgDO2j0WhtbMsWz”,
“scope” : “pisp”,
“state“: “OK-12345”
}
Notes :
access_token => tokenCredential to be included in the next method Authorization field after the Bearer
It is now possible to use the confirmation method (in live production environment only)
POST https://www.13807.live.api.89C3.com/stet/psd2/v1.4.2/payment-requests/0000000a22-156688979900016807956016/o-confirmation
Headers :
Authorization: Bearer secondAccessToken_NBVcxwwmLkjhgfdspoie00OIuyTRPFs
Content-Type: application/json
Signature: keyId=\”https://<www.myUrlPath.to>/myQsealCertificate_<footprint-sha256>\”, algorithm=\”rsa-sha256\”, headers=\”(request-target) psu-ip-address psu-ip-port psu-http-method psu-date psu-user-agent psu-referer psu-accept psu-accept-charset psu-accept-encoding psu-accept-language digest\”, signature=\”LbkxgICM48J6KdWNaF9qT7OWEorNlAwWNo6R+KkP7cP4TIGkk8wxcsGQXJ9ZnC+ZiA8mjL5S8WQyL41M7iPt+vJX4xh679gdGwmlKzn7E+ZtZ1I4qalRxcdLp4gBL7fll+C2lVBNJrViMJBezFK7AYVjnSWH7t1QxiMVg3CmoRM=\”
X-Request-ID : MyXrequestId123
Body :
|
{
}
|
Notes :
Authorization : Bearer => access_token extracted in the response of the previous POST /token method (the second one)
{paymentRequestResourceId} : same id used in previous GET /payments-requests
Response :
{
“paymentRequest” : {
“resourceId” : “0000000a22-156688979900016807956016”,
“paymentInformationId” : “MyPmtInfld123”,
“creationDateTime” : “2021-09-05T09:25:22.527+02:00”,
“numberOfTransactions” : 1,
“debtorAgent” : {
“bicFi” : “CCBPFRPP512”,
“name” : “Cpy Name”,
“postalAddress” : {
“country” : “FR”,
“addressLine” : [
“512 rue De Gaulle”,
“85000 LRSY”
]
}
},
“initiatingParty” : {
“name” : “Pisp Name”,
“postalAddress” : {
“country” : “FR”,
“addressLine” : [
“512 rue Reaumur”,
“75512 PARIS”
]
},
“organisationId” : {
“identification” : “12FR5”,
“schemeName” : “COID”,
“issuer” : “ACPR”
}
},
“paymentTypeInformation” : {
“serviceLevel” : “SEPA”,
“categoryPurpose” : “DVPM”
},
“debtor” : {
“name” : “Customer Name”,
“postalAddress” : {
“country” : “FR”,
“addressLine” : [
“512 rue Leclerc”,
“94512 Charenton-le-Pont”
]
},
“privateId” : {
“identification” : “D0999990I0”,
“schemeName” : “BANK”,
“issuer” : “BICXYYTT512”
}
},
“debtorAccount” : {
“iban” : “FR7613807000243021933556300”
},
“beneficiary” : {
“creditorAgent” : {
“bicFi” : “CCBPFRPP512”,
“name” : “Creditor Name”,
“postalAddress” : {
“country” : “FR”,
“addressLine” : [
“512 rue de la primaube”,
“12512 RODEZ”
]
}
},
“creditor” : {
“name” : “Amazon SA”,
“postalAddress” : {
“country” : “FR”,
“addressLine” : [
“512 avenue Maupassant”,
“75512 PARIS”
]
},
“organisationId” : {
“identification” : “852126790”,
“schemeName” : “BANK”,
“issuer” : “FR”
}
},
“creditorAccount” : {
“iban” : “FR7613825002000400000541718”
}
},
“purpose” : “COMC”,
“chargeBearer” : “SLEV”,
“paymentInformationStatus” : “PDNG”,
“statusReasonInformation” : null,
“fundsAvailability” : null,
“booking” : null,
“requestedExecutionDate” : “2021-09-06T14:10:10.109+01:00”,
“creditTransferTransaction” : [
{
“paymentId” : {
“resourceId” : “0000000a22-146329369000016907660677”,
“instructionId” : “instructionId 1630919339”,
“endToEndId” : “endToEndId 1630919339”
},
“instructedAmount” : {
“currency” : “EUR”,
“amount” : “2.41”
},
“remittanceInformation”: {
“unstructured”: [
“remittanceInformation01”
]
},
“transactionStatus” : “PDNG”
}
],
“supplementaryData” : {
“appliedAuthenticationApproach” : “REDIRECT”,
“scaHint” : “scaExemption”,
“successfulReportUrl” : “https://extension.bpce.fr/calback.aspx&state=OK-12345&code_challenge_method=256&code_challenge=ABCD”
}
}
}
Headers :
X-Request-ID : MyXrequestId123
Status code : 200 OK
Version history
STET specifications
This REST-based API is compliant with the STET standard developed by the french market initiative (https://www.stet.eu/en/psd2/) in order to comply with PSD2 regulatory requirements. It takes into account functional limitations specific to Crédit Coopératif savings banks network.
As a reminder :
- payment services directive (PSD2, (UE) 2015/2366 of 25/11/2015) went into force on january 13, 2018 : http://eur-lex.europa.eu/legal-content/FR/TXT/?uri=CELEX:32015L2366
- it is supplemented by regulatory technical standards for strong customer authentication (RTS, Commission Delegated Regulation (EU) No 2018/389) and common and secure open standards of communication that will apply on september14, 2019. These standards are called RTS (Rules Technical Standards) : https://eur-lex.europa.eu/legal-content/FR/TXT/?toc=OJ%3AL%3A2018%3A069%3ATOC&uri=uriserv%3AOJ.L_.2018.069.01.0023.01.FRA
In France, the ordinance n° 2017-1252 of August 9, 2017 implements the PSD2 directive into the regulatory section of the monetary and financial code. This ordinance has been supplemented by two decrees (n° 2017-1313 and n° 2017-1314 on August 31, 2017), and five orders that were published on August 31, 2017
| Our API version | STET standard version |
| v1 | v1.4.0.47 |
| v1.4.2 | V1.4.2.17 |
You can consult the virtual assistant on this portal.
Description of TPP support
According to Article 30 (5) of the RTS, a support for third-party providers is available. This support can be joined via the form on this 89C3 API portal (https://www.api.89c3.com/en/contact-us). Responses are sent during office opening hours (09:00 – 18:00 Central European local Time) even so a 24h/7d monitoring process of our IT systems exists.
Its general principle is shown below, taking into account delays of Article 30 (4) of the RTS :
Release notes
Important changes made since the first version was delivered :
| Method(s) | Effective date | Description of the evolution |
| POST/paymentRequest GET/paymentRequest | May 17, 2019 | Portal documentation : addition of clarification about the mandatory or optional nature of parameters and fields of requests. |
| Fallback | July 26, 2019 | Portal documentation : insert Fallback use case |
| Roadmap | September 18, 2019 | Portal documentation
|
| All | December 21, 2020 | Portal documentation :
|
| All | June 30, 2021 | Switch to STET V1.4.2 & new features linked to this version :
|
| Payment Initiation
Roadmap |
October 13, 2021 | SCT Core activation for ENT Segment
Note on urgent changes out of regulatory notice period |
| Payment Initiation | April 20, 2022 | BIC not mandated anymore (excl’d non eurozone) + precision for pkce + new TurboSign physical token SCA |
Roadmap
Deprecation process
According to API product life cycle, an API version can be deprecated (means this API is not any more accessible on gateways and sandbox). An overlap period between two major API releases is provided as described below :
The communication on the deprecation of a version N will be done at the release date of version N+1 through this portal / “roadmap” section.
Planning
This API can evolve. Please note that API modifications can occur out of the three-month regulatory notice period (art. 30 des RTS / paragraphe 4). We apply this in case of :
- urgent functional issue to solve impacting all PSU of at least one major customers segment
- security issue
- evolutions requested by the national competent authority
Please do find below our roadmap :
| Our API versions | Features | Sandbox
Deployment date BPCE API Dev Portal & Sandbox |
Live
Deployment date BPCE Live API Gateway |
| v1.4.0 |
|
September 20th, 2020 | June 30th, 2021 |
| v1.4.2 | Additional features in bold
|
March 30th, 2021 | June 30th, 2021 |
Limits
Functional limits
General limits
- Apply only to authorized and eligible payment accounts (the determining criterion for the purposes of that categorisation lies in the ability to perform daily payment transactions from such accounts) that are accessible online (cf. PSD2 Directive text)
- Use the authentication with redirect reinforced mode only (Strong Customer Authentication required and handled by the bank, which IS NOT an obstacle according to french national competent authority) & call for o-confirmation method
Note : TPP are not allowed to send to ASPSP the PSU credentials, and only ASPSP SCA redirect screens can be used (no embeding process as clarified by European Banking Authority based on articles PSD2 #95.5 & RTS #31)
- Manage only single payment initiation requests in euro currency either in SCT CORE (immediate or differed or recurring/permanent) or Instant Payment for all customer segments of ASPSP Banques Populaires
- The following methods are available :
- POST/paymentRequest
- POST/paymentRequest/{paymentRequestResourceId}/o-confirmation)
- GET/paymentRequest and PUT/paymentRequest (only for differed PIPS) are the only ones available
- Field “chargeBearer” is mandatory as of POST /payment-requests method and must be valued to “SLEV”
- Field “categoryPurpose” is mandatory as of POST /payment-requests method
- Field “creditorAccount” is mandatory as of POST /payment-requests method
- Field “successfulReportUrl” is mandatory as of POST /payment-requests method
- If debtor account is included in PIS request, the PSU UX is reduced to one SCA (no SCA exemptions apply)
- Cancellation of differed PIS operations can only be made thru the API (before the same deadline applied for online banking environment)
- Creditor BIC is mandated
- If no PSU actions is performed during 04 mns on redirect screens (or 30 mns overall), the PSU will be considered as disconnected and no redirection will be provided back to the TPP
Customer segments limitations
- PART segment is retail segment (adult customer)
- PRO segment gathers small companies
- ENT segment gathers medium to large corporations
Payment account limitations
- Payment accounts are those available through the online banking
- Some business rules can apply and may limit fund tranfer operations (anti-fraud rules, …)
SCA limitations
- retail PSU : password + OTP SMS and/or CAP reader and/or soft token Sécur’Pass
- small professionals : hard token certificate and/or soft tokenSécur’Pass and/or password + CAP reader and/or password + OTP SMS
Note : CASH PISP operations will be rejected if the PSU is not using Secur’Pass SCA and if the creditor IBAN is not registred by the PSU in his direct access.
Access to live data
According to PDS2 regulation, the data set available thru this dev portal, Try-it mode and sandbox are based on fictive data (or non-real ones). These data are described in the use case “Test our API“.
In order to access to live data, please use first our API Register (see the product data sheet www.api.89c3.com/en/component/bpceportal/products/543/usecases/533).
Please note that a weekly slot is reserved for a programmed maintenance (all IT infrastructure incl’d backends and API gateways) Sunday morning from 02:00 to 06:00 am, and could generate some perturbations during this period.
For live operations, the parameter “bankcode” allows TPP to send API requests to the right ASPSP backend thru a dedicated « endpoint » www.<bankcode>.live.api.89c3.com(or www.<bankcode>.live.api.banquepopulaire.fraligned on direct access domain name www.banquepopulaire.fr). Once chosen, this entry point shall also be used for all subsequent requests.
| Bank code | Bank name | Bank short name | Try-it & Sandbox availability | Live availability |
| 10807 | B.P Bourgogne Franche Comté | BPBFC | Yes | |
| 16807 | B.P AUvergne et Rhône-Alpes | BPAURA | Yes | |
| 10207 | B.P RIves de Paris + BICS | BPRI | Yes | |
| 18707 | B.P Val de France | BPVF | Yes | |
| 13507 | B.P du Nord | BPN | Yes | |
| 16607 | B.P Sud | BPS | Yes | |
| 10907 | B.P Aquitaine Centre Atlantique | BPACA | Yes | |
| 10907 | CMM Littoral du Sud OUest | CMSOU | Yes | |
| 14707 | B.P Alsace Lorraine Champagne | BPALC | Yes | |
| 17807 | B.P OCcitane | BPOC | Yes | |
| 13807 | B.P Grand Ouest | BPGO | Yes | |
| 13807 | CMM Grand Ouest | CMMGO | Yes | |
| 14607 | B.P MEDiterranée | BPMED | Yes |
