- Is chargily/chargily-pay an official Laravel package or just a PHP SDK?
- chargily/chargily-pay is a framework-agnostic PHP SDK published under the Chargily GitHub organization, so it is vendor-published rather than a community package. It is not a conventional Laravel package in the sense of shipping a service provider, publishable config, or facade unless the vendor has added one since. In Laravel you should treat it as an infrastructure adapter and bind it through a small custom service provider you own.
- How do I install chargily/chargily-pay in a Laravel app?
- Install it with Composer using composer require chargily/chargily-pay, then configure your Chargily Pay secret key through environment variables. Expect to write your own Laravel binding rather than running a vendor:publish command for package config. Keep the SDK behind a domain-level payment port so its DTOs do not leak into application code.
- Does chargily/chargily-pay support Laravel 10, 11, and 12?
- The SDK is framework-agnostic and is a clean fit for PHP 8.1+ applications, including Laravel 10 through 12. Because it is not tightly coupled to Laravel, version-lock friction is low. Before committing, confirm that its HTTP client dependency does not conflict with the Guzzle version pinned by your Laravel release.
- How do I verify Chargily Pay webhooks in Laravel?
- The SDK is intended to support webhook verification, but you should audit the signature-checking code and add your own tests because this is money-critical logic. Read the raw request body, validate the signature before parsing or trusting the payload, and reject invalid requests. Make webhook processing idempotent in your application so retries and duplicate events cannot double-apply order state changes.
- Does chargily/chargily-pay support idempotency keys for checkout creation?
- The technical evaluation flags idempotency-key support as something to verify rather than assume. If the SDK does not expose idempotency keys on checkout creation, synthesize stable keys in your application and enforce idempotent processing around checkout and webhook handlers. Do not rely on generic retry logic for asynchronous settlement or delayed payment outcomes.
- Can I use chargily/chargily-pay without Laravel?
- Yes. It is a plain PHP SDK over the Chargily Pay V2 REST API, so it can be used in any PHP 8.1+ project with an HTTP client and JSON parsing. Its only meaningful dependencies are likely an HTTP client such as Guzzle or a PSR-18 implementation, which most PHP applications already have.
- What payment methods can I accept with Chargily Pay?
- Chargily Pay is aimed at the Algerian market and supports widespread local payment methods such as EDAHABIA from Algerie Post and CIB cards from SATIM. You create checkout sessions and redirect customers to complete payment through the gateway. Confirm current method availability, sandbox credentials, and base URLs in the vendor documentation before production rollout.
- Is chargily/chargily-pay safe for production use?
- The code integration surface is small, but the dominant risk is adoption and bus factor: the evaluation notes about 17 stars and 0 dependents, meaning little public production usage to learn from. There is no broad community corpus or third-party security review to rely on, so you must audit webhook verification and idempotency handling yourself. Budget roughly one to two engineer-weeks for a production-grade integration including tests, order state handling, reconciliation, and refunds.
- How do I migrate from Chargily Pay V1 to V2 with this package?
- Treat it as a hard cutover rather than a drop-in upgrade because Chargily Pay V2 changes resource shapes and the V1 SDK is not compatible. Re-test checkout creation, webhook processing, refund handling, and asynchronous settlement against the V2 API. Keep the SDK behind your own payment port so future vendor API changes stay contained.
- What alternatives exist to chargily/chargily-pay for Laravel?
- You can call the Chargily Pay REST API directly or generate a client from an official OpenAPI spec if one is available, reducing reliance on the SDK. If you need provider-agnostic payments, wrap Chargily behind your own payment port or use a multi-PSP abstraction layer. The vendor SDK remains the best option for close alignment with Chargily API changes, provided you own the surrounding lifecycle and security tests.