Mollie Payment Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony-Specific: The bundle is tightly coupled to Symfony (3.4+), making it non-compatible with Laravel or PHP standalone projects. A Laravel TPM would need to abstract or rewrite core functionality (e.g., routing, dependency injection, event handling) to integrate it.
• PSP (Payment Service Provider) Pattern: Mollie’s API integration follows a standard PSP pattern (tokens, webhooks, redirects), which is architecturally sound but requires Laravel-specific adaptations (e.g., Laravel’s service container, middleware, or event system).
• Bundle vs. Composer Package: The Symfony "Bundle" structure (with AppKernel.php registration) is incompatible with Laravel’s autoloading and service provider model. A Laravel-compatible version would need to be refactored into a standalone package (e.g., using Laravel’s ServiceProvider or Package structure).

Integration Feasibility

• High Effort: Direct integration is not feasible without significant refactoring. Key challenges:
  • Symfony’s Kernel vs. Laravel’s ServiceProvider/Bootstrap.
  • Symfony’s Routing/EventDispatcher vs. Laravel’s Router/Events.
  • Symfony’s Twig templating (if used for redirects/webhooks) vs. Laravel’s Blade.
• Partial Reuse: Core Mollie API logic (e.g., payment creation, webhook handling) could be extracted and adapted, but scaffolding (commands, config, routes) would need a Laravel-native rewrite.
• Alternatives Exist: Laravel already has mature Mollie packages (e.g., mollie/mollie-api-php, spatie/laravel-mollie), making this bundle redundant unless custom Symfony-specific features are needed.

Technical Risk

• Dependency on Unstable Code: The bundle is under heavy development (per README), with no stable releases, tests, or dependents. Risk of:
  • Breaking changes during adoption.
  • Undocumented edge cases (e.g., webhook signatures, retry logic).
• Security Risks:
  • Hardcoded config paths (config.yml) may expose API keys in Laravel’s config/mollie.php.
  • No mention of CSRF protection for webhooks or rate limiting.
• Performance Unknown: No benchmarks or scalability tests provided. Mollie API calls could become a bottleneck if not optimized (e.g., caching tokens, async processing).

Key Questions for TPM

1. Why Symfony? If the goal is Laravel integration, is there a business or technical constraint preventing use of existing Laravel Mollie packages?
2. Customization Needs: What Symfony-specific features (e.g., kernel events, Twig templates) are critical that aren’t covered by Laravel alternatives?
3. Stability Requirements: Can the team block until a stable 1.0 release is published, or is a fork-and-maintain approach acceptable?
4. Webhook Handling: How will webhooks be processed? Laravel’s Queue system could replace Symfony’s event listeners, but this requires validation.
5. Testing Strategy: How will the bundle be tested in Laravel? Existing Symfony tests (if any) won’t run without adaptation.
6. API Key Management: How will secrets (api_key, api_key_test) be stored? Laravel’s .env is preferred over config.yml.
7. Migration Path: Is there a phased rollout plan (e.g., start with API calls, then add webhooks/redirects)?

Integration Approach

Stack Fit

• Incompatible by Design: The bundle’s Symfony-centric architecture (Kernel, Bundles, YAML config) conflicts with Laravel’s:
  • Service Providers (replaces AppKernel).
  • Dependency Injection (Laravel’s Container vs. Symfony’s ContainerInterface).
  • Routing (Symfony’s Router vs. Laravel’s Router with middleware).
• Laravel Alternatives:
  • Low-Level: Use mollie/mollie-api-php directly for full control.
  • High-Level: Use spatie/laravel-mollie for a Laravel-native wrapper (includes webhooks, redirects, and queues).
  • Hybrid: Extract only the Mollie API logic from this bundle and wrap it in a Laravel ServiceProvider.

Migration Path

Compatibility

• API Compatibility: Mollie’s PHP SDK is language-agnostic, so the underlying API calls (e.g., createPayment) can be reused.
• Symfony-Specific Dependencies:
  • Problematic: EventDispatcher, Twig, KernelEvents (e.g., KernelEvents::CONTROLLER).
  • Workaround: Use Laravel’s Events system or middleware for similar functionality.
• Database: The bundle exports customers to mollie_customer table. Laravel’s migrations would need to be adapted (e.g., using Schema::create).

Sequencing

1. Phase 1: API Integration

   • Replace Symfony’s API client with Laravel’s Http or Guzzle.
   • Test basic payments (create, cancel, refund).
   • Deliverable: Functional payment creation without webhooks/redirects.

2. Phase 2: Webhooks

   • Replace Symfony’s webhook listener with a Laravel Route + Queue job.
   • Validate signatures using Mollie’s verifyWebhook method.
   • Deliverable: Async webhook processing.

3. Phase 3: Redirects

   • Replace Symfony’s redirect routes with Laravel controller methods.
   • Use Laravel’s Session for redirect tokens.
   • Deliverable: Seamless Mollie redirect flow.

4. Phase 4: Commands & Exports

   • Rewrite Symfony commands (e.g., mollie:customers) as Laravel Artisan commands.
   • Deliverable: Customer export functionality.

5. Phase 5: Testing & Optimization

   • Write Laravel-specific tests (unit + HTTP).
   • Optimize for performance (e.g., cache API tokens, batch webhooks).
   • Deliverable: Production-ready package.

Operational Impact

Maintenance

• Fork vs. Upstream:
  • Forking: High maintenance burden to sync with upstream Symfony changes.
  • Rewriting: Lower maintenance if built natively for Laravel (using existing packages).
• Dependency Updates:
  • Symfony’s HttpClient → Laravel’s Http or Guzzle (minor effort).
  • Mollie SDK updates may require testing in Laravel’s context.
• Long-Term Viability: The original bundle’s lack of activity (1 star, 0 dependents) suggests low community support. A Laravel rewrite would need internal ownership.

Support

• Debugging Challenges:
  • Symfony-specific errors (e.g., KernelEvents, Twig) will require deep Laravel-Symfony knowledge.
  • Webhook failures may surface as Laravel-specific issues (e.g., queue timeouts).
• Documentation Gap:
  • No Laravel-specific docs; team will need to write internal guides for:
    • Configuration (.env vs. config.yml).
    • Webhook signature verification.
    • Redirect flow in Laravel’s session system.
• Vendor Lock-In: Custom implementations may limit future portability if switching PSPs.

Scaling

• Performance Bottlenecks:
  • Synchronous Webhooks: Processing webhooks in real-time could slow responses. Solution: Use Laravel’s Queue for async processing.
  • API Rate Limits: Mollie’s API has rate limits. Solution: Implement retries with exponential backoff (Laravel’s Retry package).
  • Database Load: Exporting customers to mollie_customer