Laravel Oneclick Laravel Package

Technical Evaluation

Architecture fit. The package is a standard Laravel service provider–based integration: Composer install, publishable config, a OneClick facade, guard/middleware hooks, and lifecycle events (InstallerStarted, InstallerFinished). That is the conventional shape for a Laravel add-on and imposes no architectural rework on a typical MVC or API-first app. The friction is not the design pattern — it is that the package's identity is unresolved. The repository description reads "Transbank Oneclick" (Transbank's stored-card, one-click payment product in Chile), while description.md and assessment-laravel_dev.md describe two entirely different things: a passwordless magic-link login flow and a web-based installer for shared hosting. A TPM cannot approve an integration against three mutually exclusive value propositions. Resolving this is the gating item, not a detail.

Integration feasibility. Mechanically low effort — composer require sextanet/laravel-oneclick, publish config, wire routes, gate behind an environment flag. Estimated spike effort is 1–2 engineer-days to confirm which capability actually ships in 2.1.1 and whether it works in our Laravel version. If the real capability is the installer, feasibility against our stack is near zero: it targets FTP-uploaded shared hosting with no SSH, which is almost certainly not our deployment model. If it is Transbank Oneclick, feasibility is moderate but gated on merchant credentials, sandbox access, and Transbank certification. If it is magic-link auth, feasibility is high but it duplicates functionality we can implement natively in ~50 lines with URL::temporarySignedRoute plus a single-use token — which materially weakens the build-vs-buy case for a zero-star dependency.

Technical risk. High, and concentrated in adoption risk rather than code risk:

Key questions for the maintainer / our spike:

1. What does this package actually do — Transbank payments, passwordless login, or shared-host installation? Which is authoritative?
2. Which Laravel and PHP versions are supported, and is there a CI matrix proving it?
3. Are login links strictly single-use, and how is replay prevented? Is there a revocation path for a compromised link?
4. Is the installer route registered by default, and is it disabled by default outside local/explicit opt-in?
5. How are Transbank environment (integration vs. production), commerce credentials, and callback URLs configured and validated?
6. Test coverage and last meaningful functional change — not just merge commits.
7. What is the maintenance commitment? Is there a funded roadmap or is this a personal utility?

Integration Approach

Stack fit. Only viable if we are a Laravel application on a version the package explicitly supports. Two of the three documented personas are disqualifying for us: the shared-hosting installer assumes FTP deploys, no SSH, and writable .env — incompatible with any containerized or immutable-infrastructure setup. The Transbank path assumes a Chilean merchant relationship. The magic-link path is stack-neutral and the only one broadly applicable.

Migration path. Greenfield or additive only. Do not thread this into an existing auth or checkout flow until the scope question is settled. Concretely: install into a throwaway branch, publish config, exercise every route in a sandbox, and diff observed behavior against the documentation. If the capability turns out to be the installer, close the evaluation — we should not adopt a shared-hosting bootstrap tool, and equivalent Laravel-native deployment tooling already covers us.

Compatibility. Assume nothing. Verify: Laravel version constraint in composer.json, PHP constraint, whether the service provider uses deferred loading, and whether it conflicts with our existing auth guards. For the magic-link path, signed URLs bind to APP_KEY — rotating the key invalidates outstanding links, and multi-instance deployments must share the key or links break non-deterministically behind a load balancer. For any payment path, outbound HTTPS to Transbank endpoints must be permitted from the runtime; the docs already flag that shared hosts blocking outbound connections is a real failure mode, which tells us the package does not degrade gracefully.

Sequencing.

1. Disambiguate (0.5 day). Read the source, check Packagist, open an issue. No further spend until answered.
2. Spike in isolation (1–2 days). Sandbox only, no production credentials, no production data.
3. Security review (1 day). Signed-URL replay, installer route exposure, secret handling, logging of tokens.
4. Environment-gated rollout. Feature-flag behind config, local/staging only until signed off.
5. Production with a version pin (composer require sextanet/laravel-oneclick:2.1.*), not a floating constraint.
6. Exit criteria defined up front — if the package goes >6 months without a functional release, fork or replace with a native implementation.

Operational Impact

Maintenance. The dominant cost is the dependency's fragility, not our integration effort. One maintainer, zero stars, and releases that carry no functional change mean we are effectively self-supporting. Budget for a fork-and-own contingency from day one: vendor the package, or wrap it behind a thin internal interface so it can be swapped for a native temporarySignedRoute implementation without touching call sites. Pin the version; do not allow minor-version drift in CI.

Support. No community, no issue-history signal, and documentation that contradicts the repository description. Every question routes to a single individual. Treat internal documentation as something we author, not something we inherit — our spike output becomes the team's reference.

Scaling. The magic-link path scales cheaply — signed URLs are stateless and require no storage, so cost is effectively zero at any traffic level, though we should add rate limiting on link generation and redemption to prevent enumeration and abuse. The installer path does not scale at all; it is a one-shot bootstrap and must be disabled immediately post-install (ONECLICK_ENABLED=false). Any Transbank path scales with the payment provider's rate limits and introduces retry/timeout handling we would own.

Failure modes. Ranked by blast radius:

• Installer left reachable in production — unauthenticated .env rewrite and admin-user creation. Catastrophic; also silent until exploited. Mitigation: route-level environment gate, verified in the security review before any deploy.
• Credential/link leakage — a signed login URL in a referrer header, shared inbox, or proxy log is a full account compromise. Mitigation: short TTL, single-use enforcement, redaction in logs.
• APP_KEY rotation — invalidates all outstanding links with an opaque 403. Mitigation: documented rotation runbook.
• Filesystem permissions — docs name this as the top failure: .env, storage/, bootstrap/cache/ must be writable. Surfaces as silent wizard failures.
• Missing PHP extensions — e.g. pdo_mysql; also silent, logged only to storage/logs/laravel.log.
• Blocked outbound connections on restricted hosts.

The recurring theme is silent failure. Any adoption must include explicit error surfacing and a health check, not reliance on the package's own logging.

Ramp-up. Low for an engineer fluent in Laravel — the API surface is small (facade, config, events, middleware). The real ramp-up is investigative: because the documentation disagrees with itself, the first engineer must read the source to establish ground truth, and that finding must be written down. Budget half a day of onboarding per engineer thereafter.

Recommendation. Do not adopt on the current evidence. Fund a 1–2 day disambiguation spike only. If the package is the shared-hosting installer, reject outright — wrong deployment model and unacceptable production exposure risk. If it is Transbank Oneclick, proceed only with a confirmed merchant relationship and a security review of credential handling. If it is magic-link auth, prefer a native implementation over a zero-star, single-maintainer dependency for a security-critical authentication primitive; the package's own surface area is small enough that the build cost is trivial and the ownership risk disappears.