Laravel Phonepe Autopay Laravel Package

Getting Started

• Install the tagged release, not a branch. composer require <vendor>/<package>:^1.1 — v1.1.1 is the version Packagist now indexes against the commit that actually contains the final documentation, so it is the only 1.1.x tag worth pinning to. Anyone who pulled v1.1.0 before the re-tag may be sitting on a commit whose docs don't match the published listing.
• Confirm the framework constraint before you plan an upgrade. Laravel 13 support landed in v1.1.0 and is carried unchanged into v1.1.1. If you are still on an older Laravel line, check composer.json constraints in the package rather than assuming the 1.0.x constraint set still applies; composer why-not <vendor>/<package> 1.1.1 is the fastest way to see which of your locked dependencies is holding you back.
• First place to look is the README on the tagged commit. Because the entire point of this release was getting the correct commit indexed, read the docs from the repo tag (or vendor/<vendor>/<package>/README.md after install) — not from a cached search result or a blog post, which are most likely describing a pre-1.1 API.
• Standard package bootstrap: discover the service provider (auto-discovered via extra.laravel.providers in most cases — verify before manually registering), publish anything the docs tell you to publish (php artisan vendor:publish --provider="..."), and re-read the config file once it's in config/ rather than guessing at keys.
• First use case: wire the package into exactly one feature end-to-end — one controller action or one queued job — and run it in a non-production environment before touching anything shared. Packages that alter framework internals (middleware, container bindings, model behaviour) have a habit of looking fine in isolation and misbehaving under real request lifecycles.
• Sanity check the install: composer show <vendor>/<package> should report 1.1.1 and a commit hash matching the tag on the repo. If it doesn't, you have a stale lock file or a mirror lagging behind.

Implementation Patterns

• Treat the package as a dependency behind a seam. Wrap its calls in a thin application-level service or adapter class. This costs one file and buys you a single place to change if the package's API shifts in a future major — which matters more than usual here, since the 1.1 line is the first with Laravel 13 support and the next compatibility jump will likely be a similar "support new framework, bump minor" release.
• Prefer config over hardcoded values. Once published, drive behaviour from config/<package>.php and .env rather than editing vendor-adjacent defaults inline. Keep the published config in version control so that a future upgrade's config changes show up as a readable diff instead of a silent behavioural shift.
• Laravel 13 upgrade workflow: bump the package and the framework in the same branch, run your test suite, and specifically exercise anything the package touches at boot (middleware ordering, service container bindings, event listeners). Compatibility releases in this space are usually low-risk but occasionally rely on framework behaviour that changed subtly.
• Use it in queued jobs and console commands, not just HTTP. If the docs only show a controller example, deliberately test the same call from a queued job — serialization of any package objects, container resolution outside a request, and config-cache behaviour are the usual sources of surprises.
• Testing integration: if the package ships migrations or model concerns, use RefreshDatabase and assert on your application's observable behaviour (records created, events dispatched, responses returned) rather than on the package's internals. If it offers fakes or a testing helper, use those instead of stubbing the vendor classes yourself.
• Pin and lock. Use a caret constraint on the minor (^1.1) plus a committed composer.lock. Given that this release existed purely to correct what Packagist indexed, you want reproducible installs that don't silently resolve to a differently-tagged commit on a CI machine.
• CI matrix: if the package supports more than one Laravel version, run at least one job per supported framework major. Add Laravel 13 explicitly so the compatibility you just gained is actually covered.

Gotchas and Tips

• v1.1.1 contains no code changes. Do not go looking for behaviour differences, changelog entries, or new configuration options — there are none. The only change is the tag/commit alignment and documentation. If you are already on a working v1.1.0 install, upgrading is optional and cosmetic; do it for cleanliness and to keep lock files aligned with what Packagist advertises.
• Documentation drift is the real risk here. The fact that a re-release was needed to get Packagist to index the correct commit means older references to 1.1.0 may point at incomplete or outdated docs. When something doesn't behave as documented, check the installed vendor/ README against the tag hash before assuming a bug.
• Clear caches after upgrading. php artisan config:clear (and cache:clear in non-production) — a cached config file referencing an old key set is a classic cause of "the update broke everything."
• Be careful with vendor:publish --force. It will overwrite your published config. Publish without --force, diff the changes, then merge deliberately.
• Composer constraint failures on Laravel 13 almost always mean some other dependency in your tree still caps at an older framework major — not that the package is broken. Read composer why-not output before raising an issue upstream.
• Extension points to know before you need them: container bindings exposed by the service provider, any events the package dispatches, and any middleware it registers. These are the three places you can typically intervene without forking. If the docs don't name them, vendor/ is small enough to read directly.
• Assess upgrade cadence with caution given limited release history. This is the second release in the 1.1 line and the first two entries are effectively one feature plus a packaging fix. Keep the adapter seam in place and avoid depending on undocumented internals until the package has a longer track record of stable minors.