Sci Laravel Package

Technical Evaluation

Architecture fit. The only defensible architectural role for egopay/sci is as a reference implementation and migration artifact, not a runtime dependency. A TPM should classify it as: (a) evidence of the existing integration surface for any product still talking to EgoPay SCI, and (b) a cheap pattern source for our own PaymentGateway contract (initiate / verifyCallback / pollStatus / refund) and its Laravel service-provider binding. It should never sit in the domain layer. Where legacy traffic still exists, it belongs behind an application-owned adapter — EgoPayGateway implements PaymentGateway — bound in a service provider so the vendor namespace is referenced in exactly one place and replacement is a one-line swap.

Integration feasibility. Feasible only as a contained, frozen wrapper, not as an adopted SDK. The description claims config publishing, auto-discovery, and a facade; the engineering read of the actual repository says expect PHP 5-era code with no Laravel awareness at all. That discrepancy is itself a diligence finding — the package's own marketing copy is unverified. Zero stars, zero dependents, and no visible maintainer activity mean there is no community evidence of production use, no test suite we can trust, and no Composer compatibility guarantee against current PHP 8 / Laravel. Budget a short spike to determine whether it installs at all before it appears in any plan.

Technical risk. High, and dominated by counterparty risk rather than code quality. EgoPay ceased operations roughly 2015–2016 with merchant balances unrecoverable, so there is no endpoint, no settlement, no sandbox, and no merchant support behind the library. Secondary risks are standard for abandoned payment code: no CVE response path, no security disclosure process, no PCI-DSS evidence, unknown handling of signing/hashing, likely sensitive-data logging, and no idempotency or error semantics. Because payment defects manifest as duplicate charges, lost payments, and reconciliation breaks, the blast radius is financial and reputational, not just technical. Treat any plan that routes new money through this code as a compliance exposure.

Key questions.

• Do we currently have live EgoPay SCI traffic? Which systems, what volume, and what is the contractual or accounting obligation to keep them running?
• Is there outstanding reconciliation — unsettled orders, unrecovered balances, historical callbacks — that requires parsing old payloads?
• Does the code install on our PHP/Laravel baseline, or must it be vendored as source?
• What exactly does the signature/hash scheme do, and does our version of it match the payloads we actually received historically?
• Who is the internal owner of the legacy path, and what is the sunset date?
• Which supported PSP replaces it, and does that vendor's contract test cleanly against our PaymentGateway interface?
• Do we hold any credentials or secrets tied to EgoPay that still need rotation or destruction?

Integration Approach

Stack fit. If forced to run it, treat the package as an untrusted transport detail. Configure credentials via .env under config/services.php, resolve them through a single application-owned service provider, and keep EgoPay-specific payloads out of controllers, models, jobs, and Blade templates that aren't the redirect view. Persist the local order — with our own merchant reference and a UUID — before redirecting. Money as integer minor units or DECIMAL(12,2), converted at the boundary by one Money value object. A state machine (pending → paid → refunded | failed) with an order_events audit table beats status booleans, because when support asks "what happened to this order," the answer is a row, not an archaeology project.

Migration path. Two tracks, and the TPM should be explicit that the first is a freeze, not a build:

1. Containment (weeks). Vendor or pin the code, wrap it behind PaymentGateway, add contract tests, and stop all feature work on the EgoPay path. No new payment methods, no new currencies, no new flows.
2. Replacement (weeks, not quarters). Stand up a supported PSP behind the same interface, run both against contract tests, then cut over behind a feature flag. Because the surface is a handful of endpoints — initiate, callback verification, status lookup, refund — the estimate is genuinely small. The work is sequencing and reconciliation, not engineering volume.

Compatibility. Verify PHP constraints and autoloading first; expect non-PSR-4 or legacy composer.json schema that may simply refuse to install. Check for global state, static credential holders, hardcoded endpoint URLs, and direct curl calls that bypass Guzzle — each of those is a testability and multi-tenant problem. Confirm callback handling won't be silently blocked by VerifyCsrfToken, and that any expected acknowledgement string is returned verbatim so the (historical) gateway doesn't retry forever.

Sequencing.

1. Inventory live traffic, endpoints, credentials, and outstanding reconciliation items.
2. Security and license review; confirm the code is safe to hold internally at all.
3. Spike: vendor the source, exercise the redirect build and the hash verification against real historical payloads.
4. Define PaymentGateway + DTOs and land the adapter behind it.
5. Contract tests: success, decline, timeout, duplicate callback, refund, malformed payload.
6. Select and integrate the replacement PSP against the same contract.
7. Cut over behind a flag with manual reconciliation; decommission and destroy EgoPay credentials.
8. Publish the sunset date and remove the dependency.

Operational Impact

Maintenance. Assume zero upstream maintenance and plan accordingly. Pin an exact version or, more likely, vendor the code into our repository; assign a named internal owner; add it to the advisory-watch list even though no advisories will ever be published for it. Maintain an explicit fork-or-replace decision recorded in the runbook. The real maintenance cost is not patching — it is the standing risk that any engineer touching checkout mistakes this for a supported integration.

Support. There is no vendor to escalate to, no sandbox, no documentation, no issue tracker community, and no Stack Overflow corpus. Internal support must therefore be self-built: a runbook covering credential destruction, historical payload parsing, reconciliation procedures, and a defined "this is dead, escalate to migration" path. For any legacy traffic still flowing, confirm who inside the organization can answer questions about it — and assume that person is one departure away from being nobody.

Scaling. Effectively a non-question, since no new volume should route through it. For the residual legacy path, the constraints are ours to impose: bounded timeouts, no retries except on idempotent operations, circuit breaking if anything still resolves to a live host. Monitor error rate, decline rate, duplicate-callback rate, and reconciliation backlog. There is no rate limit to negotiate and no connection pooling to tune against a counterparty that no longer exists.

Failure modes. Network failure (endpoint gone), ambiguous status with no way to verify against the vendor, duplicate charges from naive retries, lost or unverifiable callbacks, malformed historical payloads, credential leakage in logs, and — the one that actually matters — silent accumulation of unreconciled orders that nobody notices until finance closes the quarter. Mitigations: a unique index on (order_id, batch_number) and a processed_at check inside a transaction for idempotency; raw payload logging with redaction into order_events; a scheduled reconciliation report with a nonzero-count alert; and a documented manual path for "we cannot confirm this payment with anyone."

Ramp-up. A Laravel/PHP engineer can read this codebase in an afternoon — it is small and the protocol is simple. The expensive ramp-up is domain, not framework: payment state machines, idempotency, reconciliation, refunds, and the compliance posture an abandoned library can't supply. Budget the migration as a small, well-scoped replacement effort with security review and an operational rehearsal, and communicate it to stakeholders as risk retirement with a fixed end date, not as a modernization program. Recommendation: freeze and migrate; do not adopt, extend, or roadmap anything on top of egopay/sci.