- How do I install mateusjunges/laravel-pix?
- Install it with composer require mateusjunges/laravel-pix, then publish the package config with php artisan vendor:publish so your PSP selections and endpoint values live in config/ rather than vendor code. After publishing, clear and rebuild the config cache in every environment. Check that the package's version constraints match your Laravel and PHP runtime before rolling it out.
- Which PIX PSPs or providers does this Laravel package support?
- The package is built as a multi-PSP abstraction: a manager resolves a driver for each PSP you configure in config/, and each driver builds requests against a base URI. As of v1.1.0 those base URIs are configurable per PSP instead of hard-coded, which is what enables sandbox hosts, regional hosts, and mock servers. Check the README and the published config stub for the exact list of shipped drivers before assuming your provider is first-class.
- Can I test PIX payments against a sandbox or homologação environment?
- Yes, that is the main practical benefit of v1.1.0. Because endpoints are now per-PSP config values, you can point a driver at a sandbox or homologação host through .env without touching code. Keep sandbox credentials paired strictly with the sandbox host, since there is no indication the package validates that host and credential environment match.
- How do I configure endpoints per PSP in laravel-pix 1.1.0?
- Publish the config file and diff the new stub against your existing config/ copy, then merge the per-PSP endpoint keys while keeping your current PSP selections intact. Put the actual host values in .env, ideally one variable per PSP per environment, so no environment-specific host is committed to the repository. Finish with php artisan config:clear and re-cache as part of the deploy.
- Which Laravel and PHP versions does laravel-pix support?
- The package follows standard Laravel conventions such as config publishing, env-backed values, and config:cache compatibility, so it should work across the framework versions its composer.json allows. Read the constraints in composer.json rather than assuming support, and re-run your payment test suite after any Laravel or PHP upgrade. The 1.1.0 release itself is a minor, non-breaking change for stock drivers.
- How do I keep production credentials from being pointed at a sandbox endpoint?
- Configurable endpoints introduce environment crossover risk: production credentials aimed at a sandbox host, or the reverse, can produce silent no-ops, test transactions in production reporting, or auth failures that look like outages. Use separate .env files or a secret manager per environment and treat each PSP's endpoint and credentials as one unit that must change together. The package gives no indication it validates that pairing, so a deploy-time check or explicit per-environment config matrix is worth building.
- Will upgrading break my custom PSP driver implementation?
- If v1.1.0 changed the driver contract to accept an endpoint, any in-house PSP driver you wrote would need updating, which is the one place a semver-minor release can break you. Verify the interface signature and any deprecations before upgrading, and pin the package version if you maintain custom drivers you cannot migrate immediately. Stock drivers should be unaffected.
- How do I write tests for PIX payments without hitting a real PSP?
- Because endpoints are configuration, you can point drivers at a mock server or the PSP's sandbox inside your test environment and run the payment integration suite safely. Use Laravel's config overrides in tests or a dedicated testing .env, and assert against the sandbox rather than production. Remember that a stale config cache can silently defeat these overrides, so clear it in CI.
- Why do my new endpoint settings seem to have no effect after deploying?
- New config keys are invisible until you clear and re-cache config, so a stale cache in a deployed environment keeps the old hard-coded behavior with no warning. Make php artisan config:clear followed by config:cache an explicit deploy step and verify the effective endpoint in each environment after release. Also normalize values such as scheme, trailing slashes, and path prefixes, because malformed hosts surface as opaque 404s from the PSP.
- What are the alternatives to laravel-pix and is it actively maintained?
- Alternatives are generally either the PSP's own official SDK wrapped in a Laravel service provider or a broader payment abstraction package; this package's value is its multi-PSP driver model with native PIX support. Judge maintenance by recent activity, changelog quality, and whether your specific PSP is a first-class driver or something you would have to implement yourself. Weigh that against your Laravel version constraints before committing.