- How do I install shipu/bkash in a Laravel application?
- Install it with Composer using composer require shipu/bkash, then let Laravel package auto-discovery register the service provider and facade. Publish the package configuration with php artisan vendor:publish and add your bKash credentials to the generated config or environment variables. Run your test suite and a sandbox payment flow before enabling it in production.
- Which Laravel and PHP versions does shipu/bkash support?
- The v2.0.0 line is aligned with Laravel 8.0+ and Apiz v4, while older Laravel 6/7 applications are pushed to the frozen v1.x line. The provided evaluation notes that the exact CI matrix for Laravel 9/10/11 and PHP versions is not explicitly stated, so confirm those versions before adopting it for a major upgrade. Also check that your runtime meets Apiz v4's PHP requirement.
- How do I configure bKash credentials for sandbox and live payments?
- After publishing the package config, set the bKash app key, secret, username, password, and callback or base URL values for the environment you are targeting. Keep sandbox and live credentials in separate environment files or config sets and never commit live secrets. If upgrading to v2, republish and diff the config rather than overwriting it, because keys may have changed.
- How do I create and execute a bKash payment with shipu/bkash?
- The package wraps bKash's tokenized checkout flow, so you typically create a payment, redirect or hand off the customer to bKash, and then execute the payment after the callback. Use the facade or injected client provided by the package to call payment creation and execution methods, and read the response for the bKash payment ID and redirect URL. Validate the callback and verify status before marking an order paid.
- How can I query a bKash payment status or transaction?
- Use the package's status query methods with the bKash payment ID returned during payment creation or execution. Always treat the bKash API response as the source of truth rather than relying only on your callback handler. Log the request and response IDs so you can reconcile disputed transactions later.
- How do I issue a refund through shipu/bkash?
- The package exposes bKash refund operations through its API client, typically using the original payment or transaction ID plus the refund amount. Confirm the refund response status and store the bKash refund identifier with your order record. Test refunds in the bKash sandbox first, and account for partial versus full refund rules from bKash.
- What changed in shipu/bkash v2.0.0 and how do I upgrade from v1?
- v2.0.0 moves the package to Laravel 8.0+ and Apiz v4, but the provided release note does not enumerate the breaking changes. Before upgrading, inventory direct and transitive Apiz dependencies, branch, bump shipu/bkash to ^2.0 and Apiz to ^4.0, and run composer update --with-dependencies in isolation. Then republish and diff the config, run contract tests against a bKash sandbox endpoint, and keep a tagged v1.x fallback if Apiz v4 adoption is not scheduled.
- Does shipu/bkash work with Laravel 9, 10, and 11?
- The package's stated floor is Laravel 8.0+, but the supplied technical evaluation flags that it is unclear whether Laravel 9/10/11 are validated or merely not excluded. Treat 8.0+ as a minimum, not a guarantee, and check the maintainer's CI matrix or test install on your target Laravel version. If you need certainty for a production upgrade, get the supported matrix confirmed in writing.
- How should I test a bKash integration without taking real payments?
- Use bKash sandbox credentials and the package's configurable environment settings to run payment creation, execution, status, and refund flows end to end. Add automated tests around your own order state transitions and a small set of contract tests against the sandbox to catch API response changes. Never point test suites at live credentials, and verify callback handling with simulated or sandbox callbacks.
- Is shipu/bkash safe to use in production, and what should I check?
- The package is a standard Laravel integration layer with a service provider, facade, and publishable config, but the v2.0.0 major release carries an undocumented breaking-change surface around Apiz v4. Before production, confirm the Laravel/PHP/Apiz compatibility matrix, check for transitive Apiz ^3 conflicts, review the maintainer's release cadence and security policy, and test against bKash sandbox. Keep a pinned lockfile and a rollback plan to v1.x if needed.