Marlon Ogone Laravel Package

Product Decisions This Supports

• Build vs. buy for PSP integration. This package is a thin, MIT-licensed Laravel wrapper around the Ogone/Ingenico (now Worldline) payment gateway. It directly answers the question "do we hand-roll signature generation, payment form construction, and feedback (webhook/redirect) parsing, or do we adopt an existing adapter?" — the former is 1–3 sprints of engineering plus ongoing compliance-adjacent maintenance; this package is an accelerator toward the latter.
• European market expansion and checkout roadmap. Ogone/Worldline is heavily used in Benelux, France, Switzerland, and DACH. If the roadmap includes EU launch, EU-issued card acceptance, or a merchant-of-record alternative, this package is a low-cost way to validate demand before committing to a first-party integration.
• Payment feature sequencing. It supports the classic e-commerce flows (hosted payment page, authorise/capture, refunds, and — depending on the implementation — tokenisation for repeat payments and 3-D Secure redirects). That makes it a fast path to shipping "accept cards" as an MVP feature, deferring wallet/APM breadth, multi-PSP routing, and revenue-optimised routing to later phases.
• Vendor lock-in and TCO analysis. Because it wraps Worldline rather than an aggregator, evaluating it forces the team to price in the existing/negotiable merchant contract, interchange and scheme fees, and settlement terms — inputs a PM needs for the make-vs-buy and unit-economics model.
• Migration and consolidation decisions. For teams on legacy Ogone accounts wanting to stay on Laravel, this is a candidate "keep the rail, modernise the app" option versus migrating to Stripe, Mollie, or Adyen.
• Informs the maintenance-ownership decision. With a last release in March 2021, ~71 stars, and no known dependents, adopting it is explicitly a fork-and-own decision, not a subscribe-to-a-vendor-SDK decision. That is a staffing and roadmap-capacity signal, not just a technical one.

When to Consider This Package

Consider it when:

• You have (or can obtain) a Worldline/Ogone merchant account and commercial terms are already favourable — the integration cost is the blocker, not the contract.
• The application is on a Laravel version contemporary with the package (roughly Laravel 6–8 / PHP 7.x era) or you have appetite to port it forward; verify compatibility in a timeboxed spike before committing.
• You need a narrow, well-understood flow: hosted payment page, redirect-based 3-D Secure, authorise/capture, refunds. This is the package's sweet spot.
• Time-to-market dominates: an MVP checkout in days rather than a sprint, with a small team and no dedicated payments specialist.
• Volume and risk are modest enough that a single PSP rail is acceptable, and you can tolerate manual or scripted reconciliation.
• You are comfortable owning the code: forking, pinning, writing integration tests against the Worldline sandbox, and carrying the fork is acceptable to engineering leadership.

Look elsewhere when:

• You are greenfield on Laravel 10/11 and PHP 8.2+. An eight-year-old-plus adapter targeting a legacy gateway API is unlikely to be the cheapest path; a maintained first-party SDK will be.
• PSD2/SCA and 3-D Secure 2 are regulatory requirements in your markets and you cannot verify the package implements the current challenge flows. Treat this as a hard gate — confirm with a spike and, if absent, budget for building it.
• You need webhooks with idempotency, retries, and replay protection, or you require strong PCI scope reduction with a fully hosted/tokenised model and audited evidence. Verify; do not assume.
• You need multi-PSP routing, smart retries, network tokenisation, or local acquiring optimisation — this is a single-rail adapter, not an orchestration layer.
• Procurement or security review requires an active maintainer, a security contact, a CVE process, or an SLA. Seventy-one stars, one release in 2021, and zero dependents will not clear that bar, and rightly so.
• You want wallet/APM breadth (iDEAL, Bancontact, SEPA, Apple/Google Pay) out of the box with documentation and support.

How to Pitch It (Stakeholders)

For executives (one paragraph): We can add card payments to the product in days rather than weeks by adopting an existing open-source Laravel adapter for Worldline/Ogone, the payment provider many European merchants already use. It is MIT-licensed, so there is no licence cost and no procurement cycle. The trade-off is maintenance: the project has been quiet since early 2021, so we should treat it as code we adopt and own, not a vendor dependency — budget a modest one-off engineering effort to validate and, if needed, fork and patch it, and confirm it meets current EU strong-customer-authentication rules before we commit. Recommendation: run a one-week spike behind a feature flag with a small transaction cap; if it clears, it de-risks our EU launch at low cost and keeps the Worldline commercial relationship optional.

For engineering: This is a head start on signature generation, payment-form construction, and feedback handling, not a finished payments platform. Plan to own it: pin the version or fork it into our namespace, add integration tests against the Worldline sandbox, and verify 3-D Secure 2 / SCA coverage and webhook idempotency explicitly. Two risks to size before the spike concludes: framework and PHP version drift, and whether the underlying gateway API generation is one Worldline plans to retire. If either is worse than expected, the fallback — a maintained SDK from a provider with support — is more expensive per transaction but cheaper in engineering attention.