Payum Lock Request Extension Bundle Laravel Package

Product Decisions This Supports

• Payment correctness hardening (idempotency / double-charge prevention): This bundle wires Payum's LockRequest extension into Symfony's DI container, giving you a supported, config-driven way to serialize capture/authorize operations per payment. The core product promise it underwrites is "a customer is never charged twice for one order" — a trust and safety requirement, not a nice-to-have.
• Checkout reliability roadmap: Directly relevant to flows with retries, browser refreshes, double-submits, multi-tab sessions, queue workers re-dispatching jobs, and webhook re-delivery. If your incident log or support tickets show duplicate captures or "charged but order failed," this is a cheap candidate fix.
• Build vs. buy for payment concurrency: The alternative is hand-rolling locks around Payum calls (custom Symfony listeners, Redis locks keyed on token/order ID, careful exception handling). This is a ~0-cost MIT "buy" against a multi-day bespoke "build" with ongoing ownership. Weigh that against the supply-chain cost of adopting a zero-star, zero-dependent dependency.
• Platform strategy input — "stay on Payum or migrate?": Adopting this bundle is a bet that Payum remains your payment abstraction. It's a useful forcing function for the roadmap conversation: if the team is already planning to move to direct provider SDKs (Stripe PaymentIntents, Adyen, etc.), provider-level idempotency keys are the stronger long-term answer and this bundle becomes dead weight.
• Operational readiness gating: The extension only helps if lock storage (Redis/DB/cache) is provisioned, monitored, and tuned. This feeds decisions on infra investment and failure-mode design — what happens when the lock store is unavailable during checkout (fail-closed vs. fail-open is a product risk decision, not just an engineering one).
• Use cases it unlocks safely: high-value or high-volume checkout, marketplace/split payments, subscription renewal capture jobs, and any async/queued payment path where at-least-once delivery is the default.

When to Consider This Package

Consider it when all of the following hold:

• You are already running Payum on Symfony with a gateway that performs stateful operations (capture, authorize, refund) against stored payment tokens — locking is meaningless for purely stateless redirect gateways.
• You have a concrete or plausible double-processing risk: retried requests, duplicated webhooks, queued jobs, or concurrent user actions hitting the same payment.
• You have (or will stand up) a shared lock backend — Redis or a database table — and a team that can reason about lock TTLs and failure modes.
• You want the smallest possible diff: configuration plus a service registration, rather than custom locking code woven through controllers and message handlers.
• You accept the maintenance profile: MIT-licensed, maintained by a known Symfony/Payum agency (Webgriffe), but effectively zero community signal — 0 stars, 0 dependents. Pin the version, vendor it if your policy requires, and treat upgrades as a deliberate act.

Look elsewhere when:

• You are not on Payum, or you're on it only incidentally. Payum's ecosystem momentum has slowed; building new payment infrastructure on it deserves scrutiny before adding bundles to it.
• Your provider offers native idempotency (Stripe idempotency keys, Adyen reference-based deduplication, most modern PSPs). Provider-side idempotency is more durable than application-side locking — it survives your infrastructure failing. Prefer it as the primary control; locks are a complement.
• You cannot operate a lock store reliably. A lock layer that fails open gives false assurance; one that fails closed turns a cache outage into a checkout outage. If neither trade-off is acceptable, fix the architecture first.
• You need audited, SLA-backed, or actively supported dependencies. A 0-star bundle with no dependents will not satisfy procurement or a security review in regulated environments without internal code review and ownership.
• The duplicate-charge risk is actually a domain-modeling problem — e.g., missing order state machines or non-idempotent order creation. A lock around Payum won't repair that.

How to Pitch It (Stakeholders)

For executives: Duplicate charges are one of the most expensive failure modes in commerce — each one costs a refund, a support contact, sometimes a chargeback fee and a dent in trust, and they're invisible until customers complain. This is a small, MIT-licensed Symfony component that makes a specific class of duplicate-payment bug structurally harder on our existing payment stack. The adoption cost is low (configuration and a Redis/DB lock store we likely already run); the payoff is risk reduction on our highest-trust transaction. The caveat is dependency quality: it's a narrow, zero-community-traction package from a credible Symfony shop, so we adopt it deliberately — pinned, code-reviewed, and covered by our own integration tests — rather than treating it as a strategic platform bet. Recommendation: approve as a tactical reliability control, not as the foundation of a payments re-architecture.

For engineering: This bundle is thin Symfony DI wiring for Payum's LockRequest extension. It gives you configurable, per-payment locking around capture/authorize without bespoke lock code in controllers or handlers. Adopt on the condition that you (a) pick and document the lock backend and TTL semantics, (b) decide and test the degraded-mode behavior when the lock store is unavailable, (c) pin the version and add a contract test that proves two concurrent captures yield one charge, and (d) confirm it actually applies to the gateways you use — it's a no-op for stateless redirect flows. Treat provider-side idempotency keys as the primary defense and this as defense-in-depth. If we're planning to leave Payum within the next two quarters, skip it and put the effort into provider idempotency instead.