- What is jomweb/billplz-laravel used for?
- It is a Laravel adapter for the Billplz payment gateway that helps you create bills, handle payment redirects and webhooks, and manage Billplz payment flows inside a Laravel application. It is best treated as infrastructure glue rather than a complete payment platform. Keep domain code behind your own PaymentGateway interface so you can replace or upgrade the adapter later.
- Which Laravel and PHP versions does this Billplz package support?
- The package composer.json and README are the authoritative source for Laravel and PHP version constraints. Because the last release was March 2024, confirm compatibility with your target Laravel and PHP versions before adopting it. Pin the package and transitive dependencies, then test upgrades in staging rather than assuming broad version support.
- How do I install and configure jomweb/billplz-laravel?
- Install it with Composer, publish the package configuration, and set your Billplz API credentials and collection ID through environment variables rather than committing secrets. Register the service provider and facade as documented, then configure callback and webhook routes that Billplz can reach. Validate sandbox and production configuration separately before enabling real payments.
- Does it verify Billplz webhook signatures and prevent replay attacks?
- The package includes webhook and callback handling, but you must audit whether signature verification is enforced in your integration. Billplz sends an X-Signature header, so validate it against the raw request body and your API secret before trusting any payload. Add idempotency keys, event deduplication, and replay protection, and exclude webhook routes from CSRF protection.
- Can I use it for multi-tenant Laravel apps with different Billplz credentials?
- The package is a thin adapter and is likely configuration-driven, so multi-tenant use requires careful validation of per-tenant credentials and webhook routing. Do not let domain code call the Billplz facade directly; wrap it in a tenant-aware payment adapter. Test credential isolation, collection selection, and idempotency per tenant before production.
- Does the package support refunds, partial refunds, and failed payment states?
- Do not assume the package covers refunds, partial refunds, or full payment state modeling; it is primarily glue for creating bills and handling redirects and webhooks. Map Billplz bill states to your own internal payment states and keep refunds and reconciliation in your finance operations layer. Audit the code and Billplz API documentation for the exact capabilities you need.
- How should I test Billplz payments in Laravel before going live?
- Start with a Billplz sandbox account and a minimal proof of concept that creates a bill, retrieves it, and receives a webhook. Mock Billplz HTTP responses in automated tests and use a feature flag to run Billplz alongside any existing gateway for a pilot cohort. Persist raw request and response payloads so you can debug state mismatches during reconciliation.
- Is jomweb/billplz-laravel actively maintained and safe for production?
- It is MIT licensed but has a small community footprint, around 36 GitHub stars, and a last release in March 2024, so treat it as tactical glue rather than strategic infrastructure. Require a code audit covering Billplz API drift, Laravel compatibility, webhook verification, and test coverage before production. Assign an owner and keep a fork-or-replace contingency because community support has no SLA.
- Should I use this package or the official Billplz SDK for Laravel?
- For an existing Laravel monolith using Composer and Laravel HTTP clients, this package can reduce integration glue and fit well in the infrastructure layer. For polyglot services or long-term platform work, direct Billplz API integration or an official SDK may be cleaner and easier to control. Either way, hide the vendor behind an internal PaymentGateway interface so you can switch later.
- How do I handle Billplz redirects and callbacks securely in Laravel?
- Make sure the callback URL is publicly reachable over TLS, excluded from CSRF, and authenticated by Billplz signature rather than a user session. Persist the raw callback payload, queue processing, and apply idempotency so duplicate or out-of-order events do not corrupt payment state. Run an independent reconciliation job against the Billplz API and document a fallback path for failed callbacks.