- How do I install soap/laravel-omise in a Laravel app?
- Install it with Composer using composer require soap/laravel-omise. The package supports Laravel auto-discovery, so the service provider and facade should register without manual edits. Publish the single config file, then place your Omise credentials in the environment. Run php artisan config:cache afterward to confirm credentials still resolve correctly.
- Which Laravel and PHP versions does soap/laravel-omise support?
- The package is intended for Laravel 9 through 11 on PHP 8.1 and newer, but you should pin its composer.json constraints against your application before committing. Compatibility with older LTS releases is the most common source of install friction for this kind of wrapper. If your Laravel version falls outside the supported matrix, prefer a fork over a constraint override. Check whether the supported matrix is exercised in CI.
- How do I configure Omise API credentials in Laravel?
- Publish the package config file and set the Omise public and secret keys through your .env file. Keep credentials out of version control and confirm that php artisan config:cache does not break credential resolution. The package binds credentials in config/omise.php and exposes them through the service provider. This keeps Omise calls consistent with other Laravel service configuration.
- How do I create an Omise charge using the Laravel facade?
- Use the facade to call the fluent charge API, for example Omise::charges()->create(...), rather than instantiating the raw SDK. The wrapper is a thin adapter over omise/omise-php, so request shape and response handling follow the underlying SDK. You still own tokenization, 3DS/SCA handling, idempotency, and mapping charge state onto your order state machine. Sandbox testing to a working charge is typically well under a day.
- Does soap/laravel-omise handle 3DS/SCA authentication?
- No documented 3DS/SCA challenge flow is provided by the wrapper; it is a thin pass-through over the official Omise PHP SDK. You should expect to implement the challenge and redirect flow in your application and branch on the gateway response. Confirm current behavior against the package source before designing your checkout flow. Treat 3DS/SCA as an architecture decision outside the package.
- Does this package verify Omise webhooks?
- The package does not register routes, route webhooks, or verify signatures for you. Webhook verification and reconciliation remain entirely your responsibility. You will need to expose your own endpoint, validate the signature, and make processing idempotent. The wrapper only helps with outbound Omise API calls.
- Can I pass idempotency keys when creating a charge?
- The evaluation flags idempotency key support as an open question rather than a documented feature. Check the wrapper source to see whether charge creation forwards an idempotency key. If it does not, drop to the raw omise/omise-php SDK for those calls or wrap the wrapper behind your own payment interface. Do not assume retry safety without verifying this.
- Is soap/laravel-omise safe to use in production?
- It is a single-maintainer convenience wrapper with a modest release cadence, and the v1.6.1 release notes are only a compare link, so read the diff before upgrading. Real behavior and security posture live in the transitive omise/omise-php dependency, which is maintained on a slower cadence than the gateway API. The wrapper is small enough to vendor or reimplement if maintenance stalls. Use it behind your own PaymentGateway interface to cap exit cost.
- How do I migrate from omise/omise-php to soap/laravel-omise?
- Migration is mechanical: replace direct SDK instantiation with the facade, move credentials into config/omise.php plus .env, and remove the direct omise/omise-php dependency. Keep your own PaymentGateway interface so the wrapper remains swappable. Verify facade alias registration, config caching, and exception types before rolling out. For greenfield projects, adopt the wrapper from day one but keep the same interface boundary.
- Does soap/laravel-omise change my PCI DSS compliance scope?
- No, the package does not change your PCI DSS scope. Whether you qualify for SAQ A, SAQ A-EP, or SAQ D depends on whether card data touches your servers, which means choosing Omise.js tokenization versus direct card parameters. The wrapper is silent on this architecture decision. Make the tokenization strategy an explicit design choice before integrating.