Bankid Laravel Package

Product Decisions This Supports

• Sweden market entry. BankID is the de facto strong-authentication and e-signature standard in Sweden (~8M+ users). This package is a direct enabler for launching Swedish-facing login, checkout, onboarding, and e-signature flows — it turns "can we do BankID?" from an open question into a scoped integration task.
• Build vs. buy for identity. It is the low-effort OSS option in a three-way decision: (a) integrate BankID directly using this package, (b) use a commercial eID aggregator (Criipto, Signicat, Tink), or (c) build an in-house relying-party client. Framing the trade-offs (cost, SLA, control, time-to-market) is the core decision this package informs.
• Feature roadmap for "verified identity" and "legally binding signature." Loans, insurance, rental contracts, age-gated commerce, and PSD2/SCA-regulated flows all become feasible once strong auth and signing are unblocked. This dependency lets product plan those features credibly.
• Compliance and trust surface. It supports the operational requirements of a BankID integration — mutual TLS with client certificates, session TTL, animated QR, cancel flows — which lets PM scope the surrounding work (secrets management, audit logging, error UX) rather than discover it late.
• Geographic sequencing. It reframes "expand to Sweden" from "weeks of custom crypto and HTTP work" to "an integration sprint plus procurement." That materially changes prioritization against other markets.
• Risk and licensing posture. MIT licensing means we can fork or vendor the code internally if the upstream project stalls — a meaningful hedge for a package with low adoption.

When to Consider This Package

Adopt when:

• You are a Laravel/PHP team and Sweden is a current or near-term target market.
• You already hold, or are prepared to sign, a BankID relying-party agreement with a bank or aggregator — this package handles the API, not the commercial or legal agreement.
• You want a framework-native integration (service provider, config, facade) and want to avoid hand-rolling the auth → collect → cancel and sign flows.
• You are prototyping against the BankID test environment and need a demo-quality login/signature flow quickly.
• You accept owning certificates (P12), secrets rotation, environment switching, and incident response.

Look elsewhere or do deep diligence when:

• You need multi-country eID (Norwegian BankID, MitID, Finnish FTN, etc.). A per-country package stack is the wrong shape — use an aggregator.
• You require a vendor SLA or 24/7 support. With ~20 stars and a small maintainer surface, treat this as "adopt with a fork-and-own plan," not "adopt and forget." Verify recent commits, release cadence, test coverage, and supported Laravel/PHP versions before committing.
• You need advanced behavior: high-volume parallel sessions, custom error taxonomy, non-Laravel PHP, or bespoke UX — compare against the official BankID documentation and better-maintained clients.
• You are unwilling to manage mutual-TLS client certificates and production secrets. The package will not remove that operational burden.

Gating questions for the spike: Does it target BankID JSON API v6 (earlier versions are deprecated)? Does it correctly generate the animated QR (rolling qrStartToken/qrAuthCode from collect)? How does it map hintCode/error states? What is the upgrade story when BankID revises the API?

How to Pitch It (Stakeholders)

For executives. BankID is the identity rail Swedish users expect — a "Log in with BankID" that is both the login and the legally binding signature, used for payments, contracts, and KYC. This is a small, MIT-licensed Laravel package that lets our team plug into it without building the protocol layer ourselves. In practice it compresses a Swedish launch from a multi-week build to a short integration sprint, and because it is MIT-licensed we retain the option to fork and own it internally.

For engineering. It is a thin, Laravel-idiomatic wrapper over the BankID relying-party JSON API: config, service provider, and the auth/sign/collect/cancel lifecycle, including QR handling. It saves roughly one to two weeks versus writing the client from scratch. It does not abstract away the hard parts — mutual TLS with client certificates, secrets management, test-versus-production environments, and correct handling of hintCode and session expiry — so plan for those explicitly.

Recommended next step. A one-to-two day spike against the BankID test environment, producing a short report on: API version support, QR animation correctness, error mapping, Laravel/PHP compatibility, maintainer health, and the effort to wrap it behind an internal interface so we can swap in an aggregator or a fork later. That gives us the evidence to make the build-vs-aggregator call on the roadmap, with the commercial BankID agreement tracked as a parallel, non-engineering workstream.