Strong Customer Authentication

Some actions are considered sensitive by Xpollens. As a result, these actions are protected and request a Strong Customer Authentication (SCA).

Endpoints concerned have an /sca/ in the URL.

Server-Initiated SCA, triggered by Xpollens

These SCA are generated by Xpollens when requests with /sca/ are received.Endpoints concerned:

General sequence diagram

sequenceDiagram
Title: Example of an endpoint protected by SCA
autoNumber
Actor User
Participant Partner
Participant SCA.Provider
Participant XPO

Note over User, SCA.Provider: SCA requested
User ->> Partner: Sensitive action
Partner ->> XPO: POST xx/sca/xx
XPO ->> Partner: http 20x
XPO ->> SCA.Provider: push SCA
SCA.Provider ->> User: SCA requested

Note over User, SCA.Provider: SCA validation
User -->> SCA.Provider: SCA validation
SCA.Provider -->> XPO: SCA validation
XPO -->> Partner: callback 36

In the case the SCA failed, the action requested by the POST/PUT is not performed.

Status diagram

stateDiagram

[*] --> Succeeded 
[*] --> Failed
Succeeded --> [*]
Failed --> [*]    

📘

Note

The lifespan of SCAs is 5 minutes.

Callback 36 structure

The callback 36 payload is composed of :

Header: this part is composed by attributes regarding the SCA (requestDate, Status, ... )

Payload: Which includes the request result upon successful SCA validation.

Link between request and webhook

authenticationId: this data enables you to establish a link between the original request and the callback 36 received, confirming the SCA validation.

Functional aspects

Depending on the endpoint, technical or functional controls may be executed either before or after SCA validation.

For example, when using PUT /sca/v2.0/users/appUserId, the email uniqueness check is performed before SCA validation.In contrast, when creating a beneficiary via POST /sca/v2.0/users/appUserId/beneficiary, controls on the BIC and IBAN are performed after SCA validation.

Payload examples for a succedeed SCA (callback36)

PATCH fatca eai

Example

"Payload": "{\"VraisemblanceStatus\":\"OK\",\"FatcaEaiStatus\":\"OK\",\"RequiredDocuments\":[]}"

POST beneficiary

Example

"Payload": "{\"id\":1562417,\"beneficiaryId\":\"7e6bcd81-eab5-41ea-a806-cef3328bbbb8\",\"displayName\":\"John Doe nathalie\",\"bic\":\"SMOEFRP1\",\"iban\":\"FR7612869000940001215321034\",\"creationDate\":\"2025-04-01T08:45:35Z\",\"modificationDate\":\"2025-04-01T08:45:35Z\"}"

BIC and IBAN are fully visible. Bin and Iban displayed in this example are false.

POST CGU

Example

"Payload": "{\"card\":true,\"partner\":true,\"account\":true}"

POST card activation

Example

"Payload": ""

PUT user

Example

"Payload": ""

Payload for failed SCA

SCA on demand, initiated by you

For specific cases on your business case, SCA can be created on demand.This SCA is not linked to the action that will be performed afterward. It is your responsibility to properly orchestrate the SCA and then make the call according to the SCA result.

Sequence diagram

sequenceDiagram
Title: SCA on demand
autoNumber
Actor User
Participant Partner
Participant SCA.Provider
Participant XPO

Partner ->> XPO: POST v2.0/strong-authentication-request
XPO -->> Partner: callback StrongAuthenticationRequestCreatedOrUpdated <br/> {status: Approved}
XPO ->> SCA.Provider: push SCA
SCA.Provider ->> User: SCA requested

Status diagram

stateDiagram

[*] --> Rejected : Xpollens checks failed
[*] --> Approved : Xpollens checks succeed
Approved --> Completed: Authentication succeed
Approved --> Rejected: Authentication failed

Rejected --> [*]
Completed --> [*]
   

Technical details

context: Attribute at your disposal to specify the SCA reason.

data: details to display on the mobile application

Online payment: 3-D Secure (3DS)

In the case you offer card to your enduser, and the possibility to pay online, 3DS validation is needed to validate the online payment.

In this case, the SCA is pushed by the ACS

sequenceDiagram
Title: SCA on demand
autoNumber
Actor User
Participant Merchant
Participant Partner
Participant VISA
Participant ACS
Participant SCA.Provider
Participant XPO

Note over User, SCA.Provider: SCA expected for the payment
User ->> Merchant: online payment
Merchant -->> VISA: SCA
VISA ->> ACS: push SCA
ACS ->> SCA.Provider: SCA requested
SCA.Provider ->> User: SCA requested
User ->> SCA.Provider: SCA validated

Note over Merchant, XPO: SCA validated, SAE controls

You must create an intermediate page that displays a summary of the operation.
This page will serve as a confirmation step before proceeding further.

To obtain the necessary data for the summary page:

• Use the PushAuthenticationRequest object.
• This object is already available in the onRequestReceived method.
• It contains all the required information to properly display the operation summary.

By leveraging this object, you can extract and present all relevant details without needing additional data sources.

📘

Note

No callback is sent for the SCA requested for the 3DS payment.If this SCA is not performed, the authorization failed. Then you receive the webhook CardOperationCreatedOrUpdated..

What you have to do

You need to manage SCA notification.Refere to this page for more details : https://doc.antelop-solutions.com/latest/wallet/sca/sca-intro.html

Front initiated Strong Customer Authentication

The principle of these front-initiated SCAs is:1/ Generate an SCA request from the SCA Provider SDK.2/ Once the SCA is validated, include the authentication proof in the Xpollens request.

For these cases, refer to the dedicated pages provided in the table.

Technical details

Refere to this page: https://doc.antelop-solutions.com/latest/wallet/sca/mobile-overview-integration.html