Dotpay Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Symfony-Specific: The bundle is tightly coupled to Symfony2 (deprecated since Symfony 4+), leveraging AppKernel and YAML configuration. If the application is Symfony 2.x, this is a near-perfect fit. For Symfony 4/5/6/7+, compatibility is low due to deprecated components (e.g., AppKernel, YAML config) and lack of modern Symfony (Flex/autowiring) support.
• Laravel Incompatibility: Not usable in Laravel without significant refactoring (Symfony-specific services, event dispatchers, and routing). Would require a wrapper layer or porting effort.
• Dotpay API Abstraction: Provides a basic wrapper for Dotpay’s Polish payment gateway (dotpay.pl), but lacks modern features like webhooks, async processing, or SDK-level abstractions (e.g., no PSR-15 middleware support).

Integration Feasibility

• Symfony 2.x: High feasibility with minimal effort (Composer install + config). Risk: Deprecation warnings if using newer Symfony versions.
• Symfony 4+: Low feasibility without forking/rewriting. Would need:
  • Migration to Symfony’s config system (e.g., config/packages/).
  • Replacement of AppKernel with bundle auto-loading.
  • Potential rewrite of routing/dependency injection.
• Laravel: Not feasible without a custom adapter. Would require:
  • Reimplementing Dotpay’s API calls (PHP SDK or raw HTTP).
  • Building a Laravel-compatible facade for payments, refunds, and webhooks.
  • Handling Symfony’s event system via Laravel events or manually.

Technical Risk

• Critical Gaps:
  • No webhook support (Dotpay’s async notifications).
  • No idempotency or retry logic for failed transactions.
  • Hardcoded firewall IPs (195.150.9.37) may break if Dotpay changes infrastructure.
  • No type safety (PHP 7.4+ types missing).

Key Questions

1. Symfony Version:
   • Is the application locked to Symfony 2.x, or can it migrate to Symfony 4+?
   • If migrating, is the team willing to fork/maintain this bundle?
2. Dotpay Requirements:
   • Does the project need webhooks, async processing, or advanced fraud checks? (This bundle doesn’t support these.)
   • Are there regulatory requirements (e.g., PCI DSS) that need auditing of the bundle’s code?
3. Alternatives:
   • Should we evaluate Dotpay’s official PHP SDK (if available) or a modern Symfony bundle (e.g., Laravel Cashier-like wrapper)?
4. Security:
   • How are login/password stored? (Plaintext in config.yml is a critical risk—should use Symfony’s parameter encryption or env vars.)
   • Is TLS 1.2+ enforced for API calls? (Bundle may default to older TLS.)
5. Long-Term Viability:
   • The bundle is abandoned (0 stars, no updates). Is this acceptable for production use?

Integration Approach

Stack Fit

Migration Path

Option 1: Symfony 2.x (Minimal Effort)

1. Install:

   composer require cogitech/dotpay-bundle:dev-master
   

2. Register Bundle:

   // app/AppKernel.php
   new Cogitech\DotpayBundle\CogitechDotpayBundle(),
   

3. Configure:

   # app/config/config.yml
   cogitech_dotpay:
       production: false  # Test mode
       login: '%env(DOTPAY_LOGIN)%'
       password: '%env(DOTPAY_PASSWORD)%'
       shop_id: '%env(DOTPAY_SHOP_ID)%'
       firewall: false  # Disable if testing locally
       route_complete: 'dotpay_success'  # Define this route
   

4. Usage:
   • Inject Cogitech\DotpayBundle\Service\DotpayService to create payments.
   • Handle redirects via route_complete.

Risks:

• Deprecation warnings if using Symfony 2.8+.
• No webhook support.

Option 2: Symfony 4+ (High Effort)

1. Fork the Bundle:
   • Rename to AcmeDotpayBundle.
   • Replace AppKernel registration with config/bundles.php.
   • Migrate YAML config to PHP (config/packages/acme_dotpay.yaml).
2. Update Dependencies:
   • Replace Symfony 2.x services with Symfony 4+ equivalents (e.g., RouterInterface).
   • Add PHP 7.4+ type hints.
3. Add Missing Features:
   • Implement webhook listener (PSR-15 middleware).
   • Add async payment processing (e.g., Symfony Messenger).
4. Test Thoroughly:
   • Mock Dotpay API responses.
   • Test firewall IP validation.

Effort: 3–6 weeks (for a mid-sized team).

Option 3: Laravel (Custom Adapter)

1. Build a Facade:

   // app/Facades/Dotpay.php
   class Dotpay extends Facade {
       protected static function getFacadeAccessor() { return 'dotpay'; }
   }
   

2. Service Provider:

   // app/Providers/DotpayServiceProvider.php
   public function register() {
       $this->app->singleton('dotpay', function () {
           return new DotpayClient(
               config('services.dotpay.login'),
               config('services.dotpay.password'),
               config('services.dotpay.shop_id')
           );
       });
   }
   

3. HTTP Client:
   • Use Guzzle or Laravel HTTP client to replicate Dotpay API calls.
   • Example:

     public function createPayment(array $data) {
         return $this->http->post('https://secure.dotpay.pl/', [
             'form_params' => [
                 'login' => $this->login,
                 'password' => $this->password,
                 'shop_id' => $this->shopId,
                 'amount' => $data['amount'],
                 // ... other fields
             ]
         ]);
     }
     

4. Webhook Handling:
   • Add a route to /dotpay/webhook and validate signatures.
   • Use Laravel’s HasApiTokens or manual HMAC verification.

Effort: 2–4 weeks (depends on Dotpay API complexity).

Compatibility