- What is s1ro/app-payment-client used for?
- It is a PHP/Laravel client library for an internal service called app-payment, intended to let your application initiate, capture, refund and reconcile payments from code. The value of the package is that it centralizes authentication, payload serialization and endpoint contracts instead of scattering raw Guzzle calls across your codebase. It is a thin client, so the capabilities you get are bounded by what the upstream app-payment service exposes. Treat it as an integration layer, not a payment gateway in itself.
- How do I install s1ro/app-payment-client in a Laravel application?
- Install it with Composer from your project root, either from Packagist if it is published there or from a VCS repository entry pointing at the GitLab repo. If the repository is private you will need a GitLab deploy token or personal access token configured in Composer auth.json, or a private mirror such as Satis or Private Packagist. The repository is hosted on GitLab, so budget time for that setup rather than assuming a plain composer require will resolve. Check the README in the repo for the exact require line before scheduling the work.
- Is s1ro/app-payment-client available on Packagist or do I need a VCS repository?
- The metadata indicates the code lives on GitLab rather than Packagist, which usually means it is private, mirrored internally, or was never published. In practice that means you either add a Composer repositories entry of type vcs with credentials, or consume it through a private package mirror. Neither approach is a blocker, but both add onboarding friction and CI credential management that should be planned explicitly. Confirm publication status before you write installation steps into documentation.
- Which PHP and Laravel versions does s1ro/app-payment-client support?
- The supported version range is not stated in the available metadata, so you must read the require block of its composer.json before committing. Look specifically at the php, illuminate/support or illuminate/contracts, and guzzlehttp/guzzle constraints and check they cover your target Laravel version. Because the package appears to have no dependents, there is little ecosystem pressure to keep those constraints current with new Laravel or Guzzle majors. If the constraints are stale you will inherit that maintenance yourself.
- Does s1ro/app-payment-client support Laravel auto-discovery and a publishable config file?
- Standard Laravel practice is a service provider registered through auto-discovery plus a publishable config file holding the base URL, credentials and timeout. Whether this package actually implements that pattern is unverified from the metadata and needs confirming during a source read. Watch for warning signs such as direct env() calls inside library code, hard-coded config reads, or static facades with no container bindings. Those are fixable but indicate how much Laravel-specific polish the package has had.
- Does the client support idempotency keys and retries on payment write operations?
- Idempotency keys, retry and backoff behavior, and timeout defaults are the three details that most often cause real financial incidents in a payment client. The package metadata does not document any of them, so they must be verified by reading the source before you rely on it for writes. If idempotency keys are not exposed, you should add them at your own wrapper layer or avoid automatic retries on capture and refund calls. Never wire a payment write to a naive retry loop without confirming this.
- Does s1ro/app-payment-client verify webhook signatures?
- Webhook signature verification is not visible in the package description or metadata, yet it is essential for any payment integration that accepts callbacks. Read the source for a signature check, a shared-secret comparison, or timestamp tolerance handling before exposing a webhook route. If verification is missing, implement it in your own controller before the payload reaches the client. Also confirm how the client handles duplicate webhook deliveries, since payment providers retry.
- How are monetary amounts represented in s1ro/app-payment-client?
- The safest convention for payment APIs is integer minor units, and anything using floats is a red flag for rounding errors. The package metadata does not state which representation it uses, so check the request and response DTOs before writing any amount handling code. If it uses floats or loosely typed values, normalize to integers at your own boundary. This is a small detail that causes disproportionately large financial bugs.
- How should I test my integration with app-payment?
- The best approach is a short sandbox spike against a real app-payment test environment, wrapped behind your own interface so you can swap in a fake in unit tests. Whether the package ships a test suite and whether that suite runs against a sandbox or only mocks is not verifiable from the metadata and should be one of your audit questions. Regardless of what the package provides, avoid calling the live client directly from your domain services so tests do not require network access. Confirm the auth model, since a static API key is far easier to run in CI than mTLS or OAuth client credentials.
- Is s1ro/app-payment-client safe to depend on in production?
- The package shows zero stars, zero dependents and no external validation, which is normal for an internal library but still represents a real gap for a payments-domain dependency. The main risks are a bus factor of one, no documented secret handling or disclosure channel, and no ecosystem pressure to keep it current with Laravel and Guzzle releases. A sensible path is a conditional go gated on a two-to-three day source audit and a sandbox spike, plus an internal wrapper so you can replace the client if maintenance lapses. Also confirm who owns the upstream app-payment service and whether there is an SLA or on-call rotation behind it.