Download the PHP package krafsys/payment-manager without Composer
On this page you can find all versions of the php package krafsys/payment-manager. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package payment-manager
krafsys/payment-manager
A single, consistent PHP interface for five Nigerian payment gateways — Paystack, Flutterwave, Monnify, Kora (KoraPay), and Bachs. Initialize, verify, refund, and handle webhooks the same way regardless of which gateway is behind it, and switch gateways without touching your application code.
- Zero runtime dependencies — built on
ext-curl, not Guzzle or PSR-18. Installing this package installs nothing else. - Framework-agnostic core with an optional Laravel service provider + facade.
- Requires PHP 8.1+.
⚠️ Before going live: this package was built from each provider's public API documentation, but payment provider APIs change. Two things are still worth double-checking against current docs before you rely on them with real money: Monnify's webhook hash formula, and Bachs's refund endpoint + exact webhook header names (the core Bachs checkout flow — endpoint, request/response shape, verify-by-checkout_id — has been confirmed against docs.bachs.io; see
src/Gateways/BachsGateway.php).
Installation
Quick start (plain PHP)
Every gateway returns the same PaymentResponse shape, so this code doesn't change if you swap 'paystack' for 'kora'.
Verifying a transaction
Refunds
Webhooks
Every gateway adapter exposes the same two methods: verify the signature first, then parse the payload. Never trust a webhook you haven't verified.
| Gateway | Webhook header to read | Verification method |
|---|---|---|
| Paystack | x-paystack-signature |
HMAC-SHA512 of the raw body with your secret key |
| Flutterwave | verif-hash |
Direct comparison against the hash you set on your dashboard (webhook_secret config) |
| Monnify | monnify-signature (confirm in your dashboard) |
SHA512 of secret key + payload fields — verify field order against current docs |
| Kora | Kora-Signature |
HMAC-SHA256 of the payload's data object with your secret key |
| Bachs | provider-specific — verify header name against your dashboard | HMAC-SHA256 of {timestamp}.{body} (Stripe-style) — concatenate the timestamp yourself before calling verifyWebhookSignature() |
Laravel usage
The service provider and facade are auto-discovered once you composer require laravel/framework alongside this package (it's a suggested, not required, dependency).
Publish the config file:
Set your credentials in .env (PAYSTACK_SECRET_KEY, FLUTTERWAVE_SECRET_KEY, MONNIFY_API_KEY, MONNIFY_SECRET_KEY, MONNIFY_CONTRACT_CODE, KORA_SECRET_KEY, BACHS_SECRET_KEY, etc. — see config/payment-manager.php for the full list), then:
Or inject Krafsys\PaymentManager\PaymentManager via the container as normal.
Gateway-specific notes
- Paystack and Kora — straightforward amount + currency charges, matches the package's normalized model closely.
- Flutterwave — refunds require Flutterwave's internal transaction id, not your reference, so
refund()transparently callsverify()first to resolve it (one extra API call). - Monnify — requires exchanging your API key/secret for a short-lived Bearer token before every other call. The adapter fetches and caches this token in memory (refetching ~5 minutes before expiry), so you don't need to manage it yourself.
- Bachs — endpoint is
POST {base}/v1/checkout-sessions(note the/v1/prefix and hyphen — not/checkout_sessions), and amounts must be decimal strings ("5000.00"), never floats or minor units. Itsverify()works differently from the other four: it takes Bachs's owncheckout_id(e.g.chk_5b6e19d42f8a), not a reference you invented.initialize()returns thatcheckout_idasPaymentResponse->reference— store that value and pass it intoverify()later. Bachs is also natively architected around pre-created Products; this adapter uses the documentedpricing: {amount, currency}root field to charge an ad-hoc amount without one. The refund endpoint and exact webhook signature header names are not yet confirmed against a primary Bachs reference — check your dashboard before depending on them.
Testing this package
Tests run entirely against a fake in-memory HTTP client (tests/Fakes/FakeHttpClient.php) — no network calls, no real API keys needed.
License
MIT.
All versions of payment-manager with dependencies
ext-curl Version *
ext-json Version *