Weave Code
Payplug Php Laravel Package
payplug/payplug-php
Official PayPlug PHP library for integrating payments into your application. Create and capture payments, issue full or partial refunds, manage customers and cards, and handle installments, one-click payments, and webhooks through PayPlug's REST API. Lightweight, framework-agnostic, and easy to inst...
Payplug PHP Library
Frequently asked questions about Payplug Php
- How do I install payplug/payplug-php with Composer?
- Run composer require payplug/payplug-php:^4.2 and commit the lockfile so the exact version is pinned. The SDK is plain PHP 8.x with no exotic extensions, though you should confirm cURL or Guzzle is present in your runtime image. There is no Laravel auto-discovery, so nothing is registered automatically after install.
- Is there an official Laravel package or service provider for PayPlug?
- No. payplug/payplug-php is the official framework-agnostic PHP client for the PayPlug REST API, not a Laravel package, so it ships without a service provider, facade, or publishable config. The usual approach is a small in-house adapter: a service provider that binds a client factory, a config/payplug.php file fed from environment variables or a secret manager, and a PayplugGateway interface so application code never imports vendor classes. That interface also makes the SDK mockable in tests and swappable if a v5 arrives.
- How should I configure PayPlug API keys in a Laravel app?
- Configuration is process-global via Payplug::init([...]) with your secret key, so call it inside a service provider or client factory rather than scattering it through controllers. Read the key from config, which in turn reads from env or your secret manager, and never hardcode it. Because the state is global, treat the init call as something the adapter owns and re-establishes per tenant or per request where credentials can differ.
- Does payplug-php work with Laravel Octane and queue workers?
- It can, but the global static configuration is a live hazard under Octane and long-running workers, where credentials set for one request or job can bleed into the next. Design this out at the adapter boundary by initialising credentials per job or per request-scoped binding rather than once at boot, and avoid sharing a single client across tenants. Do not rely on testing alone to catch cross-tenant credential leaks; make the isolation structural.
- How do I create a one-off or installment payment with the SDK?
- Use the payment resource to pass the amount, currency, customer details, and the return URLs PayPlug should send the shopper back to. For split payments, supply an installment plan instead of a single capture, and for repeat purchases combine a saved customer and card with a one-click flow. Always persist the PayPlug payment id you get back, because that id is what you use for status checks, refunds, and webhook reconciliation.
- How do I issue a full or partial refund in payplug-php?
- Create a refund against the original payment id, passing the amount for a partial refund or omitting it to refund in full. Confirm the refund's returned status before showing success in your UI, and store the refund id alongside the payment for support and accounting. Keep in mind partial refunds must not exceed the captured amount, so validate against your own ledger first.
- How do I handle PayPlug webhook notifications in Laravel?
- Expose a POST route, exclude it from CSRF protection, and verify the notification's authenticity before trusting the payload. Return a 200 response quickly and push the actual processing onto a queued job so PayPlug does not time out and retry unnecessarily. Make the handler idempotent keyed on the payment or refund id, since retries and duplicate deliveries are normal.
- How can I test the PayPlug integration without taking real payments?
- Use sandbox API keys issued at onboarding together with PayPlug's test card numbers, so you exercise the real API without moving money. In Laravel, bind your PayplugGateway interface to a fake implementation in tests so feature tests never make outbound HTTP calls. Keep a small number of integration tests that hit the sandbox for the critical paths, such as payment creation, refunds, and webhook verification.
- Do I need Hosted Fields, and what does it change for PCI and CSP?
- Hosted Fields, added in 4.2.0, keeps card data out of your server by rendering inputs in a PayPlug-hosted iframe, which typically shifts you toward the lighter SAQ A questionnaire. That compliance claim needs written confirmation from PayPlug, not an inference from a changelog line, because security review will ask for it. Technically you must allow the PayPlug JavaScript bundle and iframe origins through your Content-Security-Policy frame-src and script-src, and European card flows still require a 3DS2 challenge step with return-URL handling, so confirm the SDK surfaces that cleanly. A blocked iframe looks like a blank payment form, so loop in security before launch.
- How do I upgrade from payplug-php 3.x to 4.x?
- Expect real work rather than a lockfile bump: typed exceptions replaced the older error handling, the verification helpers changed, and constant-based configuration gave way to Payplug::init(). Moving from 4.1.0 to 4.2.0 should be additive, but with no release body or diff the version is a claim rather than a guarantee, so run a regression pass. Do not let a 3.x-to-4.x upgrade ride along with a feature release, and check the PHP and Guzzle or cURL minimums against your runtime images.
Weaver
How can I help you explore Laravel packages today?