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 notification to Swan app. The user then consents via the app.

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 the app, the user must enter his 6-digit security code (FaceID, TouchID, and fingerprint will replace this soon 🙂).


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

  • addBeneficiary

  • addAccountMembership

  • updateAccountMembership

  • resumeAccountMembership

  • addCard

  • addSingleUseVirtualCard

  • updateCard

  • viewCardNumbers

  • printPhysicalCard

  • activatePhysicalCard

  • viewPhysicalCardPIN

  • resumePhysicalCard

  • addDigitalCard

  • refund

  • scheduleStandingOrder

Swan's consent framework is exactly the same for all sensitive operations.

Here is the consent sequence diagram:

When consent can be requested by Swan, you must define a redirectURL in the mutation in question, that will be used to redirect the user once he has confirmed, refused, or withdrawn consent.

When consent is required, the API will respond with a consent object containing a consentURL. Redirecting the user to this URL will trigger a notification on the user's app and display a branded standby screen. 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 app 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 Swan app and the user is redirected to you via the redirectURL.

If the user has successfully consented on Swan app, the sensitive operation which initiated authentication is finalized and the user is redirected to you via the redirectURL.

As long as the user has not given their consent, you can cancel the consent request by calling the cancelConsent mutation.