Payment Ogone Bundle Laravel Package

Product Decisions This Supports

• Keeping an existing Symfony app alive: it enables continued Ogone (Ingenico/Worldline) payment processing for applications already built on JMSPaymentCoreBundle, avoiding a forced re-platforming.
• Payment provider consolidation: adds Ogone as a provider option within an existing payment abstraction, useful for European/Benelux/Swiss market coverage.
• Legacy migration sequencing: acts as a bridge if the roadmap includes moving off JMSPaymentCoreBundle — it defers a rewrite rather than blocking on one.
• Build vs. buy/adopt: this is an "adopt" only for teams already inside the JMS payment stack; for greenfield work, the correct decision is to build against Worldline's current SDK or a maintained abstraction (Sylius, Payum, Omnipay).
• Explicit non-decision: it should not support any roadmap item requiring modern Symfony (5/6/7), current PHP versions, or actively maintained, security-reviewed dependencies.

When to Consider This Package

Consider it only when:

• Your codebase already depends on JMSPaymentCoreBundle (typically a legacy Symfony 2.x/3.x application).
• Ogone/Worldline is your contracted acquirer and you need a low-effort provider plugin instead of a re-architecture.
• You accept ownership: 12 stars and 0 dependents means the community is effectively nonexistent — you will be maintaining a fork, not consuming a supported library.
• Your payment requirements are basic (redirect-style flows) and do not hinge on modern features (3-D Secure v2, tokenization, webhooks).

Look elsewhere when:

• You are on Symfony 5+/6+/7 or modern PHP; JMSPaymentCoreBundle itself is effectively unmaintained, so this package inherits that risk.
• You need vendor support, SLAs, or a security-maintenance guarantee.
• Modern payment features (tokenization, 3DS2, webhook-driven reconciliation) are on the roadmap.
• You can integrate directly with Worldline's current APIs or use a mainstream abstraction — that is the better long-term bet.

How to Pitch It (Stakeholders)

Executives: This is a narrow legacy connector, not a strategic platform choice. It is worth adopting only if we are already running a JMSPaymentCoreBundle-based Symfony application and need to keep Ogone/Worldline payments working. Treat it as a maintenance stopgap — not a foundation for new products or new revenue streams.

Engineering: Cheap to evaluate, expensive to depend on. The package is small, thinly adopted (12 stars, 0 dependents), and built on a dependency (JMSPaymentCoreBundle) that is effectively end-of-life. If we adopt, we adopt a fork: pin the version, own the code, and run a security review of the payment flow. If the roadmap touches modern Symfony or new payment capabilities, the right call is to build against Worldline's current SDK or a maintained abstraction instead.

Bottom line: Bridge, don't build on it. It buys time for migration planning; it does not buy a payments platform.