A Swedish business buying BankID integration should separate identifying a person from deciding what that person can do in the portal. Define the device journey, verify the result through the backend and map the identified person to approved accounts and roles. A successful login must not automatically grant authority over a company record.
BankID's current developer introduction describes a reseller-bank agreement, a certificate and frontend and backend components as implementation prerequisites. Its documentation distinguishes identification from signing. These are concrete integration requirements, not evidence that an application has correctly implemented its own business permissions.
TuniCyberLabs serves Swedish buyers remotely. The following fictional trade-customer portal illustrates the decisions a buyer should ask an engineering partner to resolve. It does not claim that every Swedish service needs BankID or that every potential user has it.
Define the business action that follows identification
Imagine a wholesaler whose customers need to view orders, request returns and nominate delivery contacts. An employee may represent one customer company, several companies or none of the companies already registered in the portal.
Document how that relationship is established. The business might use an approved invitation process or an existing customer administrator. The identified person's connection to a company must come from an authorised process, not from a matching surname or an email-domain assumption.
Keep sensitive actions distinct. Viewing an order, appointing another administrator and changing settlement details can require different authority. Give the supplier a role-and-action map before asking for a price.
Treat same-device and two-device use as separate journeys
BankID publishes different guidance for autostart on the same device and animated QR codes when another device is used. The QR guidance also states that the QR secret belongs on the backend. These provider-specific details should shape both implementation and acceptance.
Ask the supplier to test the journeys your users actually need. Include desktop-to-phone identification, a mobile browser opening the app and the return to an unfinished portal action. Confirm behaviour on your supported platforms using current provider instructions.
A screen that looks finished after opening the BankID app is not sufficient. Users may cancel, switch applications or return after the original action has expired. The portal should explain the resulting state and preserve only the context that remains appropriate.
Keep the completion decision on the server
The application should establish the provider result through its documented server integration before creating an authenticated session or accepting a signing outcome. A browser redirect or an app launch is a navigation event, not the application's evidence of successful identification.
Bind the completed result to the intended portal session and action. Test two browser tabs, an interrupted journey and a restarted attempt. The objective is to prevent one successful result from being attached to the wrong pending operation.
Ask what evidence support staff can inspect when a customer says identification succeeded but the portal did not continue. Preserve useful request references and state transitions while keeping secrets and unnecessary personal data out of routine logs.
Build company membership as its own workflow
For the fictional wholesaler, specify what happens after first identification. An unlinked person should receive an understandable route to request access, with approval assigned to a responsible customer administrator or internal employee.
Then define changes over time. A customer employee leaves, a purchasing manager changes roles or a group reorganises its subsidiaries. The portal needs a way to revoke access and review existing assignments without changing the person's identity.
Acceptance cases should include:
- ▸A valid user with access to exactly one customer account.
- ▸A valid user selecting between two authorised organisations.
- ▸A person who is identified but has no approved membership.
- ▸A former employee whose business access has been removed.
- ▸A user attempting to open another customer's order directly.
- ▸An administrator performing an action beyond their assigned authority.
These cases test your product's permissions. They cannot be delegated to the identity provider merely because the provider handles identification.
Decide when an action needs a separate signing flow
If the product needs an electronic signing journey, scope that action explicitly. Identify the content presented, how the user understands the request, what result the application records and which subsequent change it authorises.
Do not assume a routine login is equivalent to approving every later transaction. Equally, do not add signing to harmless actions without a business reason. The responsible product and legal reviewers should determine the assurance needed for each use case.
Preserve the relationship between an approved action and its content version. If a document or order changes after approval, the application should not quietly treat the earlier result as covering the revised content.
Include exceptions and alternative access in the purchase
Some intended users may be unable to complete the chosen identity journey. Establish the actual audience and define a supported alternative or assisted process where the business needs one. An unexplained dead end becomes an operational support problem.
Test plain instructions, keyboard interaction and the visibility of status messages. The aim is to make the identification journey understandable, including cancellation and expiry. Provider guidance and the organisation's applicable accessibility requirements should inform the detailed acceptance criteria.
Assign ownership for certificates, service agreements and provider updates. Document how the receiving team tests a change before production and what happens when a required credential becomes unavailable.
Accept the portal through realistic customer tasks
Require a demonstration that begins with an ordinary customer task and ends with the permitted business outcome. Include unsuccessful identification and successful identification without sufficient authority. Ask the receiving team to investigate one deliberately interrupted case using the handover material.
Our customer portal security requirements guide covers broader application boundaries. Use it alongside the provider documentation rather than expecting one generic security checklist to specify the complete BankID journey.
Explore software engineering services and request a Swedish portal integration review. Bring the customer roles, the actions they must perform and the devices they use.