Laravel Viva Payments Laravel Package

Product Decisions This Supports

• Payments integration in Laravel products: Evaluates whether to build the Viva Wallet (Viva Payments) integration in-house or adopt this package — relevant for checkout, subscription billing, and marketplace payout flows in Greek/EU markets where Viva is a primary acquirer.
• Enterprise/regulated-environment readiness: The v6.5.0 Viva::withRequestOptions() addition directly unblocks deployments behind corporate proxies, custom CA bundles (internal PKI), and strict timeout policies — all common blockers in banking, healthcare, and public-sector procurement.
• Roadmap sequencing for EU expansion: Confirms a low-effort path to adding a second payment provider alongside Stripe/Adyen, reducing single-acquirer risk and supporting localized payment methods (Viva's IRIS, cards, and wallet offerings).
• Build vs. buy: Shifts the estimate toward "buy/consume" — access-token handling, request signing, and now transport configuration are handled, so engineering effort concentrates on product logic (orders, refunds, reconciliation) rather than HTTP plumbing.
• Operational resilience decisions: Configurable timeouts per-environment make it viable to define explicit SLAs for payment calls, inform retry/idempotency design, and set expectations for checkout latency budgets.
• Security/compliance posture: Centralizing TLS trust and proxy routing through one configuration surface supports audit narratives around outbound traffic and certificate management.

When to Consider This Package

Adopt when:

• The product targets Viva Wallet as an acquirer (notably Greece/EU), or Viva is being added as a secondary/fallback provider.
• The stack is Laravel (or Laravel-adjacent with a service container and config system) and the team wants idiomatic facades, config publishing, and testable service classes instead of raw HTTP calls.
• Transport control is required — the new release makes this a reason to adopt rather than a workaround: proxies, custom CA bundles, or enforced timeouts can now be set once via Viva::withRequestOptions() and apply to token acquisition as well as API calls.
• Token lifecycle management is a burden you'd rather not own; the package handles access-token retrieval transparently.
• You want per-request overrides: the release explicitly supports method-level options taking precedence over defaults, which suits mixed environments (e.g. longer timeout for payment creation, shorter for status polling).

Look elsewhere when:

• The team is not on Laravel — the value is largely framework glue; a framework-agnostic SDK or direct REST client is a better fit.
• You need features not exposed by the wrapper (newer Viva endpoints, webhook signature handling specifics); check the package's issue tracker and version cadence before committing, and be prepared to drop to the underlying client.
• Vendor support SLAs are a procurement requirement — this is a community package, not a first-party SDK; ensure an internal owner and a fallback plan exist.
• You require multi-provider abstraction out of the box; this is a single-provider wrapper, so plan an internal payment gateway interface if provider-switching is a strategic goal.
• PHP/Laravel versions in your estate fall outside the package's supported matrix.

How to Pitch It (Stakeholders)

For executives: This is a small, focused Laravel integration for Viva Wallet, a European payments provider. The just-released v6.5.0 is a low-risk enhancement, not a breaking change: it lets us centrally configure how our servers talk to Viva — including through corporate proxies, with our own certificate authorities, and with enforced timeouts. Practically, that removes a common blocker to going live in enterprise and regulated customer environments, and it reduces the custom networking code we'd otherwise maintain. Recommendation: treat this as a low-cost option to add Viva as a payment provider or as a resilience backup to our current acquirer, with engineering effort focused on product logic rather than payment plumbing.

For engineering: v6.5.0 adds Viva::withRequestOptions() to set default Guzzle request options applied to every request, including the automatically-issued access-token call — previously a real gap, since per-method options never reached token acquisition. Options passed to individual service methods still win, so we get sane global defaults (timeout, proxy, verify CA bundle) with per-call escape hatches. Integration is a facade call in a service provider; no migration work. Risks: it's a community package with a single maintainer, so assign an internal owner, pin the version, and keep our payment-service boundary thin enough to swap providers or drop to raw HTTP if needed. Add a smoke test asserting the configured options reach both token and payment requests, and document the proxy/CA settings in environment configuration.

Bottom line: Adopt (or trial) for Laravel projects needing Viva Wallet; the release closes a meaningful enterprise-adoption gap. No action required for existing consumers beyond an optional dependency bump.