Laravel Oneclick Laravel Package

Product Decisions This Supports

• Market-expansion gating (Chile / LATAM): Transbank OneClick is the incumbent stored-card rail for Chilean merchants, and supporting it is usually a hard prerequisite for selling there. This package is the lowest-effort way to answer "can we accept recurring/stored-card payments in Chile without a multi-week integration sprint?" — a classic validate-before-you-build decision.
• Build vs. buy on payment plumbing: the choice here isn't "use this vs. nothing," it's "use this thin wrapper vs. hand-roll against the official Transbank SDK." The package buys you Laravel-native configuration, facades, and a small surface area; you're deferring roughly a few days of glue code, not a strategic capability.
• Subscription / repeat-purchase roadmap: if the product roadmap includes recurring billing, saved cards at checkout, or merchant-initiated charges for Chilean customers, this is the enabling dependency to scope. If the roadmap is one-off checkout only, the value drops sharply.
• Compliance and scope decisions: choosing a gateway integration determines your PCI surface (hosted/redirect flows vs. handling card data) and your refund/dispute workflows. That's a decision with legal and support-cost implications, not just an engineering one.
• ⚠️ Documentation-integrity gate (do this first): the three sources disagree about what this package is — the repo metadata says "Transbank Oneclick," description.md describes passwordless magic-link authentication, and the engineering assessment describes a web installer for shared hosting. Do not put this on a roadmap until someone spends 30 minutes reading the actual source and confirms the behavior. The 0-star count means no community has independently validated any of these claims.
• If the magic-link description turns out to be accurate instead: the decision shifts entirely — passwordless login is a commodity feature Laravel's native signed URLs already cover, and the build-vs-buy answer flips to "build, it's a day of work."
• If the installer description is accurate: the decision is a deployment-strategy one for shared-hosting/SMB targets, with a real security consideration (an exposed installer route). Useful for a niche hosting constraint; not a product differentiator.

When to Consider This Package

Adopt when:

• You are shipping a Laravel app into the Chilean market and need Transbank OneClick (or you need to prototype it fast to validate demand).
• You want a bounded, single-purpose integration rather than adopting a full payments abstraction layer.
• Your team can absorb the maintenance burden of a zero-star, effectively single-maintainer dependency — meaning you pin the version, own the integration tests, and can fork if needed.
• MIT licensing is compatible with your distribution model (it is for almost everyone).
• The release cadence and test suite (2.1.1 was explicitly a test-merging release, which is a mildly positive hygiene signal) hold up under a quick repo review.

Look elsewhere when:

• You need multi-country or multi-gateway payments. Use a proper abstraction (Laravel Cashier, Omnipay, or a PSP aggregator) rather than accumulating one-off gateway packages.
• You require vendor SLAs, security disclosure processes, or procurement-approved dependencies. Zero stars and no organizational backing will fail most enterprise reviews.
• The documentation ambiguity can't be resolved quickly — an unverifiable dependency is worse than no dependency.
• You need card-data handling rather than redirect/hosted flows; the PCI burden should push you toward a fully hosted provider.
• It turns out to be a magic-link package: Laravel's built-in signed URLs plus a signed route and a guard cover this in an afternoon, with no third-party risk.
• It turns out to be a shared-hosting installer: prefer CI/CD, Forge, Vapor, or Ploi. An HTTP-reachable installer is a standing attack surface, and "conditionally load it" is a mitigation, not a design.

Due-diligence checklist before committing: confirm the actual package contents and namespace; check the last commit date and open-issue response time; verify the Transbank SDK version it pins (and whether that version is current); confirm compatibility with your Laravel and PHP versions; read the test suite to see what's actually covered.

How to Pitch It (Stakeholders)

To executives: "We can test Chilean recurring-payment demand without a multi-week build. This is a small MIT-licensed Laravel package that wraps Transbank's OneClick stored-card flow — low cost, low commitment, and we can abandon it cheaply if the market doesn't respond. The tradeoff is that it's a very small open-source project with one maintainer and inconsistent documentation, so I'm recommending a short validation spike before we commit it to the roadmap rather than treating it as a production dependency today."

To engineering: "Single-purpose wrapper, not a framework — treat it as a replaceable adapter. Isolate it behind our own payment interface so swapping to the Transbank SDK directly, or to a multi-gateway abstraction later, is a contained change. Pin the version, write integration tests against the sandbox, and confirm which Transbank SDK release it targets. First deliverable is a one-day spike to verify what this thing actually does, because the repo's own documentation contradicts itself across three sources."

Headline recommendation: time-boxed evaluation — validate scope, run a sandbox integration, and only then decide between adopting, forking, or wrapping the official SDK directly. The cost of the spike is trivial; the cost of a mis-scoped payments dependency is not.