Weave Code
Jms Payment Bridge Laravel Package
payum/jms-payment-bridge
Bridge between Payum and the JMS Payment library, adding gateway factories and actions so JMS payment gateways can run inside Payum's unified payment workflow. Useful for projects already on JMS Payment that want Payum's abstraction layer.
payum/jms-payment-bridge connects Payum with the JMS Payment components, letting existing JMS-based payment code run through Payum's unified gateway abstraction. It adapts JMS payment instructions and gateway implementations into Payum actions and gateways, so you can migrate incrementally or reuse legacy integrations without rewriting business logic.
- Bridges JMS Payment gateways into Payum's action pipeline
- Supports JMS payment instructions and token handling
- Enables gradual migration to Payum without full rewrites
- Works with Symfony service configuration and DI
- Keeps legacy JMS integrations reusable behind Payum APIs
Frequently asked questions about Jms Payment Bridge
- What is payum/jms-payment-bridge and what is it used for?
- It is a small integration bridge that lets you run JMS Payment plugins behind Payum-style gateways. JMS Payment models a PaymentInstruction advanced by a state machine and executed by plugin classes (purchase, authorize, completePurchase), while Payum models gateways as Actions operating on Requests. The bridge translates the JMS side into the Payum side so existing JMS setups can be called through Payum's API. It is not a standalone payment library and is only useful if you already have JMSPaymentCoreBundle installed.
- Does payum/jms-payment-bridge support Laravel?
- No, not in any practical sense. Its dependency graph is Symfony-centric: JMSPaymentCoreBundle, Symfony service container wiring, and Symfony HTTP-foundation and EventDispatcher calls. There is no Laravel service provider, facade, or configuration file, and the last release is pinned to PHP 5.x/7.0-era Symfony 2.x with Payum 0.x/1.x. For Laravel applications, use Payum's Laravel integration or a direct gateway SDK instead.
- Is payum/jms-payment-bridge still maintained?
- Effectively no. The last release was 2016-05-31, the repository shows one star and zero dependents, and JMSPaymentCoreBundle itself has been dormant since roughly 2015-2016. Several JMS gateway plugins wrap retired API generations such as PayPal NVP/Express Checkout and Authorize.Net AIM. Treat the code as yours from day one: fork or vendor it, assign an internal owner, and set a deprecation date.
- How do I install payum/jms-payment-bridge with Composer?
- A plain composer require will almost never resolve on modern PHP, Symfony, or Payum versions because the available constraints are pinned to 2016-era dependencies. The realistic path is a code transplant: fork the handful of adapter classes into your application or a private VCS repository and patch the service definitions yourself. Budget for constraint surgery and assume composer update will not resolve cleanly. Validate the fork against a locked runtime before committing.
- Which PHP, Symfony, and Payum versions does payum/jms-payment-bridge require?
- Expect constraints pinned to PHP 5.x/7.0-era runtimes, Symfony 2.x, and Payum 0.x/1.x. Any modern target such as Symfony 5, 6, or 7, PHP 8.x, or Payum 1.7+ will hit unsatisfiable requirements. The exact supported Payum version and JMS plugin set is not documented reliably, so read the fork's composer.json and audit the plugin inventory first. Prototype against a locked PHP 7.4 or 8.0 runtime and exercise each gateway with sandbox credentials.
- Does payum/jms-payment-bridge handle Notify/IPN and asynchronous payment callbacks?
- This is one of the biggest unknowns. Payum models Notify as a Request handled by an Action, while JMS uses controller-driven callbacks and a Doctrine-mapped PaymentInstruction, and the translation between them is inherently lossy. Do not assume the bridge maps IPN flows correctly, and do not assume refunds, partial captures, voids, or multi-currency are supported or tested. Inspect the adapter code and verify where idempotency is handled across token replay before going live.
- How do I configure payum/jms-payment-bridge in a Symfony application?
- Configuration is done through the Symfony service container: you define Payum gateways in Payum's config and register the JMS plugins as services that the bridge adapts. Expect to hand-edit service definitions and patch Symfony HTTP-foundation and EventDispatcher calls for any modern runtime. There is no YAML reference or documented configuration schema, so the test suite and the adapter classes are the real specification. Keep the gateway names stable so call sites can later be swapped to native Payum gateways.
- Is payum/jms-payment-bridge safe to run in production?
- The risk is high and structural: a dormant bridge, a dormant JMS bundle, several plugins wrapping retired gateway API generations, and a PHP runtime that is itself end-of-life. Payment code in that stack will never receive a CVE fix. It is only defensible as a short-lived transition shim inside a legacy Symfony 2.x application that already persists PaymentInstruction via Doctrine, and even then only with a funded exit plan. Never introduce it into greenfield work.
- How do I migrate from JMS Payment to Payum using this bridge?
- Treat it as step one of a three-step exit. First, wrap existing JMS plugins behind Payum gateways so call sites move onto the Payum API. Second, replace each bridged gateway one at a time with a native Payum or Omnipay-backed gateway registered under the same gateway name. Third, delete the bridge and the JMSPaymentCoreBundle. Step two must be funded up front, because step one on its own buys you nothing.
- What are the alternatives to payum/jms-payment-bridge and how should I test it?
- For modern stacks, use Payum's Omnipay bridge, native Payum gateway packages, or a direct gateway SDK; for Laravel, use Payum's Laravel integration rather than this Symfony-only bridge. The repository offers no meaningful test signal, so build your own coverage: fork the bridge, pin it against a locked PHP 7.4 or 8.0 runtime, and run each gateway through a mock gateway plus sandbox credentials. Exercise refunds, partial captures, voids, and multi-currency explicitly, and only then decide whether the bridge is worth keeping.
Weaver
How can I help you explore Laravel packages today?