Product Decisions This Supports
- Legacy triage, not new capability. EgoPay SCI is a form-post checkout gateway operated by egopay.com, which stopped being a going concern around 2015–2016 with merchant balances unrecoverable. This package is evidence of an integration surface (initiate payment, signed redirect, callback/IPN verification, status lookup, refund), which is what you need to scope a retirement, not to plan a launch.
- Build vs. buy resolves to "neither — adopt the code." Score 0, zero stars, zero dependents, no visible maintainer activity. There is no vendor relationship here to buy into and no community to lean on. Any framing of "adopt this package" is really "vendor this source into our repo and own it forever."
- Roadmap hygiene. No roadmap item — crypto checkout, e-wallet, alternative PSP, regional payment expansion — may cite EgoPay SCI as its delivery mechanism. Block it at the epic level so it doesn't get re-proposed by someone pattern-matching on an old ticket.
- Reference architecture, narrowly. Reading the signature/hash helper and the callback handling is a cheap way to shape an internal
PaymentGateway contract (paymentUrl / verifyCallback / pollStatus / refund) plus a thin Laravel service-provider binding. Use it as a shape, then write our own against a live PSP.
- Due-diligence answer for "can we just keep the old checkout running?" This package is the artifact that makes the answer concrete: yes, frozen, until migration ships — and here is the endpoint count and the estimate to replace it.
- Documentation-claim audit. The package description promises a service provider, publishable config, facade, and framework-agnostic core. The engineering read of the source is that it is a thin, PHP 5-era form builder with no Laravel auto-discovery. That gap matters: do not let a vendor-style README set expectations in a planning doc. Verify claims against
composer.json and src/ before quoting them.
When to Consider This Package
Consider it only in these narrow cases:
- Live traffic still arriving. You have systems receiving EgoPay SCI callbacks today and need them to keep working while migrating. Freeze, wrap, do not extend. Change control on this path should require sign-off.
- Historical reconciliation and audit. Parsing old callback payloads and transaction formats to close out stale orders, resolve support tickets, or satisfy a finance/audit request.
- Forensic review of an inherited codebase. Understanding what a predecessor built before you delete it.
- Protocol reference for contract design. You want a worked example of signing and callback verification to inform your own gateway abstraction.
Look elsewhere when:
- Any new integration is required. Not "inadvisable" — not possible. There is no counterparty, no endpoint, no settlement, no merchant support. A sandbox spike is a dead end, which distinguishes this from the usual "unproven SDK, spike it first" case.
- You need security or compliance guarantees. No maintainer, no CVE or disclosure path, no PCI-DSS evidence, no SLA, no deprecation policy. Zero dependents means nobody has publicly run this in production; there is no security review to inherit.
- You need modern Laravel or PHP 8 support. Expect PHP 5-era constraints, no auto-discovery, no config publishing, no facade, and fatal errors on current runtimes. You would be authoring the wrapper yourself — at which point write the wrapper against a live provider.
- You need support or an escalation path. Zero stars, zero dependents, no issue-tracker community, no Stack Overflow corpus, no one to ask at 2 a.m. during a payment incident.
- The payment path is revenue-critical. Duplicate charges, ambiguous status, and lost webhooks are unrecoverable when the counterparty no longer exists to verify against.
How to Pitch It (Stakeholders)
To executives: This is an abandoned PHP library for a payment processor that no longer exists. No maintainers, no measurable adoption, no security support, no counterparty behind it — it cannot underwrite anything on the roadmap, and it cannot be "adopted" in any meaningful commercial sense. The only decision it informs is how fast we retire the legacy checkout path. Recommendation: freeze it in place, migrate to a supported PSP, and fund a small, bounded migration — the integration surface is a handful of endpoints, so this is measured in weeks, not quarters. Every additional month on the legacy path is an uninsured operational risk with a known-dead counterparty, and any customer-impacting failure there has no vendor to escalate to.
To engineering: Do not composer require this into anything new. It is 2010s-era PHP targeting EgoPay's SCI gateway, scored 0 with no dependents — no one is patching it and no one will. Also discount the README: it advertises a Laravel service provider, publishable config, and a facade; expect a thin form builder with no auto-discovery, and verify against composer.json and src/ before believing otherwise. Where legacy traffic must keep flowing, vendor the source into our repo, bind it behind a single application-owned PaymentGateway interface with DTOs, and keep it entirely out of controllers, models, and domain logic so replacement is a one-class swap. On the callback path, treat it as hostile: CSRF-exempt route, hash verification before any DB write, lookup by our own merchant reference, idempotency guard on retries, integer minor units for money, an order_events audit table capturing raw payload plus verification result, and a fast 200 with downstream work queued. Mine it for the signing and callback-verification patterns, then delete it.