Przelewy24 Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony 3.3+ Focus: The bundle is tightly coupled to Symfony 3.x (last release 2021), which may conflict with modern Laravel ecosystems unless abstracted via a facade or adapter layer. Laravel’s service container and event system differ significantly from Symfony’s, requiring custom wrappers or middleware.
• Event-Driven Design: The bundle leverages Symfony’s event system (przelewy24.event.payment_success), which can be replicated in Laravel using Laravel Events or Laravel Echo for real-time callbacks. The PaymentEventInterface would need translation to Laravel’s ShouldBeBroadcast or Dispatchable interfaces.
• Payment Workflow: The core logic (redirect-to-P24, session-based payments) aligns with Laravel’s HTTP routing and session management, but the ProcessFactory and Payment model would need Laravel-specific implementations (e.g., PaymentService facade).

Integration Feasibility

• High: The bundle’s primary function (P24 payment redirection) is achievable in Laravel with minimal effort, but the event system and dev tools require customization.
• Key Components to Replace:
  • Symfony ProcessFactory → Laravel PaymentService (using Guzzle HTTP client).
  • Symfony Payment model → Laravel Payment Eloquent model or DTO.
  • Symfony events → Laravel events (e.g., PaymentSucceeded).
  • routing.yml → Laravel’s routes/web.php or API routes.

Technical Risk

• Deprecation Risk: Symfony 3.3 is outdated; the bundle may not support newer P24 API versions. Risk mitigation: Use the underlying P24 PHP SDK directly (e.g., przelewy24/php-sdk) as a fallback.
• Event System Gaps: Laravel’s event broadcasting (e.g., Pusher) differs from Symfony’s kernel events. Risk: Missed real-time notifications if not properly adapted.
• Dev Tools Limitation: The /p24-test and /p24-fake-success routes are Symfony-specific. Risk: Local testing requires custom Laravel routes or manual API calls.

Key Questions

1. API Compatibility: Does the P24 PHP SDK support Laravel natively? If not, how will we abstract the bundle’s logic?
2. Event Handling: Should we use Laravel’s built-in events or a queue-based system (e.g., Horizon) for payment callbacks?
3. Session Management: How will we handle sessionId in Laravel’s stateless environment (e.g., via cookies, database, or Redis)?
4. Testing Strategy: How will we replicate the Symfony dev tools in Laravel (e.g., fake success endpoints)?
5. Maintenance: Given the bundle’s archived status, who will handle updates if P24’s API changes?

Integration Approach

Stack Fit

• Laravel Compatibility: The bundle’s core (Guzzle HTTP calls, payment redirection) is stack-agnostic. The challenge lies in Symfony-specific components (events, routing, kernel).
• Recommended Stack:
  • HTTP Client: Guzzle (already a dependency) or Laravel’s Http client.
  • Events: Laravel’s Event facade or Illuminate\Queue for async processing.
  • Routing: Replace routing.yml with Laravel’s Route::get() or API resources.
  • Models: Use Laravel Eloquent or DTOs (e.g., app/Models/Payment.php).

Migration Path

1. Phase 1: Core Payment Flow

   • Replace ProcessFactory with a Laravel service:

     // app/Services/PaymentService.php
     class PaymentService {
         public function createPayment(array $data): string {
             $client = new Client();
             $response = $client->post('https://secure.przelewy24.pl/', [
                 'form_params' => [
                     'merchant_id' => config('przelewy24.merchant_id'),
                     'amount' => $data['amount'],
                     // ... other fields
                 ]
             ]);
             return $response->getBody();
         }
     }
     

   • Use Laravel’s redirect() helper to send users to P24.

2. Phase 2: Event System

   • Create a Laravel event:

     // app/Events/PaymentSucceeded.php
     class PaymentSucceeded implements ShouldBroadcast {
         public $payment;
         public function __construct($payment) { $this->payment = $payment; }
     }
     

   • Dispatch in a webhook controller:

     // routes/web.php
     Route::post('p24/webhook', [P24WebhookController::class, 'handle']);
     

     // app/Http/Controllers/P24WebhookController.php
     class P24WebhookController {
         public function handle(Request $request) {
             event(new PaymentSucceeded($request->all()));
         }
     }
     

3. Phase 3: Dev Tools

   • Replace Symfony routes with Laravel routes:

     // routes/web.php
     Route::get('p24-test', [P24TestController::class, 'testConnection']);
     Route::get('p24-fake-success/{sessionId}', [P24TestController::class, 'fakeSuccess']);
     

Compatibility

• Guzzle: Already compatible with Laravel (no changes needed).
• Symfony Events: Requires custom Laravel events or queue listeners.
• Routing: Fully replaceable with Laravel’s router.
• Configuration: Replace config.yml with Laravel’s config/przelewy24.php.

Sequencing

1. Extract Core Logic: Isolate P24 API calls into a Laravel service.
2. Implement Events: Replace Symfony events with Laravel’s event system.
3. Add Webhooks: Set up P24 webhook endpoints in Laravel.
4. Test Locally: Use Laravel routes to simulate /p24-test and /p24-fake-success.
5. Deprecate Bundle: Gradually phase out the Symfony bundle in favor of native Laravel code.

Operational Impact

Maintenance

• Pros:
  • Laravel’s ecosystem (e.g., Horizon for queues, Echo for events) simplifies long-term maintenance.
  • Direct access to Laravel’s logging (Log::channel()) and monitoring (e.g., Laravel Debugbar).
• Cons:
  • Custom event/webhook logic may require more boilerplate than Symfony’s kernel events.
  • No official updates from the bundle’s maintainers (archived repo).

Support

• Debugging: Laravel’s built-in tools (Tinker, DumpServer) improve debugging over Symfony’s VarDumper.
• Community: Laravel’s larger community may offer quicker solutions for P24 integration issues.
• Vendor Lock-in: Minimal risk if using the P24 PHP SDK directly instead of the bundle.

Scaling

• Performance: Laravel’s queue system (e.g., Horizon) can handle high-volume payment events more efficiently than Symfony’s kernel events.
• Statelessness: Laravel’s session management (e.g., Redis) may require adjustments for sessionId persistence.
• Webhooks: Laravel’s queue:work can process P24 webhooks asynchronously.

Failure Modes

Ramp-Up

• Team Onboarding:
  • Document the custom Laravel service layer and event system.
  • Provide examples for webhook handling and fake-success testing.
• Developer Experience:
  • Create a przelewy24 Artisan command for testing connections.
  • Add Laravel-specific tests (e.g., PaymentServiceTest).
• Training:
  • Highlight differences between Symfony events and Laravel’s Event facade.
  • Train on Laravel’s queue system for async payment processing.