Webpay Bundle Laravel Package

Product Decisions This Supports

Primary value is decision input, not delivery capability. quartet/webpay-bundle cannot ship in a Laravel product, but reading it answers real product questions cheaply.

• Build vs. buy for JP card payments: It is a thin Symfony 2 wrapper around the webpay/webpay client — one config tree, a couple of service definitions, and the token → charge call sequence. That tells you the integration surface is genuinely small (roughly a few hundred lines plus webhook handling), which is the number you need to decide "buy a supported gateway integration" vs. "write a first-party client."
• Gateway selection and abstraction strategy: The package is framework-locked (Symfony bundle, AppKernel, YAML service wiring). For a Laravel shop that is an argument for a gateway-agnostic PaymentGateway contract in our own codebase, with a provider-specific adapter behind it — not for adopting any framework's bundle.
• PCI scope: The token-form pattern (card data tokenized client-side, never touching our servers) is the reusable decision here, independent of vendor. It keeps us in SAQ-A territory and should be a hard requirement in any provider RFP.
• Vendor/business-continuity risk: WebPay's lifecycle is the real blocker. Reporting conflicts on where it landed (absorbed into a larger Japanese processor / Stripe), and its original endpoints, sandbox, and onboarding may no longer exist as documented. This alone can end the initiative before any engineering spend — a go/no-go the PM must own.
• Roadmap inputs it sharpens: Is JP card acceptance a v1 requirement? Are saved cards / repeat billing in scope (token reuse)? Do we need refunds and partial capture at launch? Is multi-gateway routing a near-term need? The bundle's surface area is a useful checklist for writing acceptance criteria even if we build our own.
• Explicitly not supported: any decision to add this as a production Composer dependency. Score 0, no stars, zero dependents, Symfony 2 (EOL 2018), likely no reachable maintainer and possibly no license — no security-review trail in a payment path.

When to Consider This Package

Only as reference material, when:

• Auditing or porting an existing Symfony 2.x integration that already processes WebPay transactions.
• Planning a migration off WebPay and needing to enumerate every touchpoint (token creation, charge, capture, refund, webhook) before decommissioning.
• Writing a spec or contract test against the vendor sandbox and wanting a worked PHP example of the request/response shapes.

Look elsewhere — decisively — when:

• The target stack is Laravel or any modern PHP/Symfony. Bundles are a Symfony packaging mechanism; there is no composer require path into a Laravel tree, and legacy Guzzle pins will conflict with a current HTTP stack.
• You need supported PHP 8.x, security advisories, or a patch cadence. An unmaintained component in the payment path is an unacceptable supply-chain posture, and zero dependents means nobody else is finding the bugs.
• You need 3-D Secure/SCA, idempotency keys, retries/backoff, or webhook signature verification — do not assume any of it exists; the happy-path charge is likely all you get.
• You need a vendor SLA or confirmed commercial availability. Confirm with the provider (or a Japanese payment partner) that onboarding and sandbox access exist for us today. If not, the evaluation ends there.

Alternatives worth pricing: the vendor's official SDK, a supported Japanese processor (Stripe, GMO Payment Gateway, PAY.JP, VeriTrans, Komoju — chosen on JP market coverage and settlement currency), Omnipay as a framework-neutral PHP layer, or a ~1–2 day first-party client implementing only the endpoints we actually need.

How to Pitch It (Stakeholders)

To executives (one paragraph): We evaluated quartet/webpay-bundle as a candidate for Japanese card payments. It is an old Symfony 2 add-on for the WebPay gateway — an end-of-life framework, no maintainers, no users, no security review, and no fit with our Laravel stack. We should not adopt it. It is still useful as a free reference: it shows the integration is small and that card data can stay off our servers, which keeps our compliance burden low. Recommendation: do not add it as a dependency; spend a half-day reading it to size a small first-party integration on a supported gateway. The decision that actually matters is commercial, not technical — confirming which Japanese gateway we can onboard with and settle through.

To engineering (brief):

• Do not add quartet/webpay-bundle to composer.json. Symfony 2 bundle on an EOL framework, unmaintained, unlicensed-or-unclear, and it would drag legacy dependencies into our graph.
• Do use it as a specification of the token-charge flow: client-side tokenization, server-side charge, refund, webhook → order state machine. Extract the wire format and note the failure modes it omits (idempotency, retries, signature verification, 3-D Secure, JPY zero-decimal amounts).
• Deliverable: a WebPayGateway/provider adapter behind a PaymentGateway interface (charge, capture, refund, token reuse), with idempotency keys, signed webhook verification, retry/backoff, log scrubbing, and contract tests against a sandbox. Estimate 1–2 days engineering plus sandbox access and a payments-competent reviewer.
• Blocking prerequisites before sprint planning: vendor availability and onboarding path confirmed, license acceptable to legal, and a chosen supported provider.
• Risks if we adopted it anyway: no security patches, no PHP 8 guarantee, framework lock-in, single-maintainer bus factor, silent double-charge on retry, cardholder data in logs, and an unclear gateway lifecycle that presents as generic HTTP errors rather than "vendor gone."