At Swan, Consent is built-in. This is quite special, because other BaaS' have their clients do it themselves. Setting up consent can be a real bother...We are happy to take it off your hands.


Some operations at Swan, such as initiating a payment, are sensitive and require user consent. This is obtained by sending a text message to the user. The user then consents via the web browser.
To protect the user and comply with legal requirements, consent can be given through a Strong Customer Authentication.

Strong Customer Authentication

Strong Customer Authentication (SCA) is a requirement of the EU Revised Directive on Payment Services (PSD2) to payment service providers within the European Economic Area. The requirement ensures that electronic payments are performed with multi-factor authentication, to increase the security of electronic payments.
When a Strong Customer Authentication is necessary, when giving consent on a smartphone, the user must enter his 6-digit security passcode or use FaceID / TouchID when available.
Example of FaceID used to validate a transfer


If you want to perform sensitive operations by API, you must call our API while authentified with a User Access Token. Learn More.
The following mutations concern sensitive operations, and could require consent:
  • initiateCreditTransfers
  • addAccountMembership
  • addAccountMemberships
  • updateAccountMembership
  • resumeAccountMembership
  • addCard
  • addCards
  • addSingleUseVirtualCard
  • updateCard
  • viewCardNumbers
  • printPhysicalCard
  • activatePhysicalCard
  • viewPhysicalCardPIN
  • resumePhysicalCard
  • addDigitalCard
  • refund
  • scheduleStandingOrder

Consent notification

Swan handles consent exactly the same way for all types of sensitive operations. We won't send any notifications if the user is on their mobile, but if they're using a desktop they'll be redirected to a mobile workflow.


For the mobile workflow, you'll need to specify your preferred channel.
First, call the updateUserConsentSettings using your project token and enter the userID.
Then, specify which of 2 channels you want to use:
  • Let Swan send an SMS to the user, containing a link they must open on their mobile device
  • Receive notifications so you can then push them yourself to your user
If you're planning to send notifications yourself, you can configure the endpoint, secret key, accent color, and logo in the Consent notification menu of the dashboard.
Along with a notification, you will receive an authorizationUrl and the consent to display to your user on their mobile. On desktop, Swan will display the ConsentURL. Also, a video is displayed to your user from the time the consent process is launched until it has been either confirmed or cancelled. It features the logo and accent color defined in the Consent notification menu.
We have defined a 3-second timeout for you to answer us. If this delay is exceeded, or if you answer with any code other than 200, we'll cancel the consent and the user will be redirected.
For the OTP SMS, logins, and consents using our #nocode web banking, we'll still send an SMS, regardless of how your consent notifications are configured.
When consent is necessary, you must define a redirectURL in the mutation. This will be used to redirect the user once they have confirmed, refused, or withdrawn consent. The API will respond with a consent object containing a consentURL. Redirecting the user to this URL will trigger a text message on the user's smartphone and display a standby screen with your branding/logo. Usually, this object will be a specific status in statusInfo, for example CardConsentPendingStatusInfo.
For security reasons, the standby screen must be displayed in fullscreen mode. If you are integrating Swan into a mobile app, you must open it with a SafariViewController (iOS) or Custom Chrome Tab (Android). Using an in-application browser allows for browser-based authentication, such as shared authentication states and security contexts, without disrupting the UX by requiring the user to switch applications. Check out this compliant implementation:​
Consent must be confirmed within 20 minutes after the first request to the consentUrl. After this timeout, the consent is expired. The standby screen is no longer displayed on Swan and the user is redirected to you via the redirectURL. The expiredAt property inside the consent object is updated with the expiry date.
During the consent process, the standby screen gives the user the option to cancel. In this case, the consent is no longer displayed on the smartphone and the user is redirected to you via the redirectURL.
After a successful consent on a smartphone, the sensitive operation which initiated authentication is finalized and the user is redirected to you via the redirectURL. During redirection we add these query parameters to the URL:
  • consentId: the id of the consent
  • env: the environment. Either Sandbox or Live
  • status: Accepted ,CustomerRefused, CredentialRefused, Expired, Failed or Canceled
  • resourceId: id of the resource impacted by the consent (if only one resource is impacted). If many resources are impacted, this query param is not returned.
We recommend you use status only for displaying information. You should always check if a consent was accepted before updating your database or starting a new process.
As long as the user has not yet given their consent, you can still cancel the consent request by calling the cancelConsent mutation.
On desktop or for a 3DS transaction, users are redirected to a mobile flow either by clicking on a link in an SMS sent by Swan, or they're redirected by you. It depends on your configuration.
The consent process when you let Swan send an SMS to your user:
Consent workflow from computer
The consent process when you choose to receive notifications, so you can then push your own notifications to the user:
Consent workflow from computer
On mobile, there is no specific configuration required, you just need to display the redirectURL. Here is the sequence:
Consent workflow from smartphone
Last modified 27d ago