Savano Laravel Package

Technical Evaluation

Architecture Fit

• Payment Gateway Abstraction: The package provides a thin abstraction over Savano’s payment API, aligning with Laravel’s modular design. It fits well in a service layer pattern where payment logic is decoupled from business logic.
• Stateless vs. Stateful: Requires external storage (DB/Redis) for order/authority tracking, which is a good practice but adds complexity if not already implemented.
• Event-Driven Potential: Lacks built-in event hooks (e.g., payment.created, payment.failed), limiting observability. A TPM could advocate for integrating with Laravel’s events or queues for async workflows.
• Monolithic vs. Microservices: Best suited for monolithic Laravel apps with centralized payment handling. Less ideal for microservices where payment could be a standalone service.

Integration Feasibility

• Low Coupling: Minimal forced dependencies (only Savano API contract). Can coexist with other payment gateways (e.g., Stripe, PayPal) via a payment facade or strategy pattern.
• API Contract Stability: Savano’s API changes could break the package. Version pinning (1.*) is risky—TPM should push for semver compliance or a wrapper layer to isolate changes.
• Webhook Support: Missing native webhook handling for async callbacks (e.g., payment success/failure). TPM should evaluate if Savano’s callback system requires manual verification logic in actionVerify().

Technical Risk

• No Tests/Documentation: Zero stars/dependents signals immature codebase. TPM must:
  • Audit the package for edge cases (e.g., retry logic, idempotency).
  • Mock Savano’s API to test failure scenarios (e.g., network timeouts, malformed responses).
• Security Risks:
  • Hardcoded PIN in controller violates secrets management best practices. TPM should enforce env variables or vault integration.
  • No input validation for price, orderId, or authority could lead to injection or race conditions.
• Performance: Synchronous API calls may block requests. TPM should assess if queues or async processing are needed for high-volume transactions.

Key Questions

1. Does Savano’s API require PCI compliance? If yes, how does this package handle tokenization or data encryption?
2. What’s the failure rate for Savano’s API? Are retries/fallbacks implemented?
3. How are refunds/cancellations handled? The package lacks this functionality—will it need extension?
4. Is there a sandbox/test mode? Critical for development/testing.
5. Does Savano support webhooks? If not, how will async notifications be handled?
6. What’s the long-term maintenance plan? With no maintainer activity, is this a temporary or strategic dependency?

Integration Approach

Stack Fit

• Laravel Ecosystem: Works natively with Laravel’s service containers, middleware, and HTTP clients. Can leverage:
  • Laravel Cashier for subscription management (if Savano supports it).
  • Laravel Horizon for async payment processing.
• Database: Requires a storage layer (e.g., MySQL, PostgreSQL) for orderId, authority, and price. TPM should define a migration for a payments table with fields:

  Schema::create('payments', function (Blueprint $table) {
      $table->id();
      $table->string('order_id')->unique();
      $table->decimal('price', 10, 2);
      $table->string('authority')->nullable();
      $table->string('status'); // e.g., 'pending', 'completed', 'failed'
      $table->timestamps();
  });
  

• Frontend: Redirect-based flow (no JS SDK), so compatible with any frontend (React, Vue, plain HTML).

Migration Path

1. Phase 1: Proof of Concept
   • Install package and implement actionRequest()/actionVerify() in a sandbox environment.
   • Test with Savano’s test mode (if available).
   • Validate storage persistence and redirect flow.
2. Phase 2: Production Readiness
   • Secure the PIN: Move to .env and use Laravel’s config caching.
   • Add Input Validation: Sanitize price, orderId, and authority in actionVerify().
   • Implement Retries: Use Laravel’s retry middleware for API failures.
   • Logging: Integrate with Laravel Log or Sentry for payment events.
3. Phase 3: Scaling
   • Async Processing: Offload actionVerify() to a queue job if Savano supports delayed callbacks.
   • Monitoring: Track success/failure rates with Laravel Telescope or Prometheus.

Compatibility

• Laravel Version: Tested with Laravel 5.5+ (assumed). TPM should verify compatibility with the target Laravel version.
• PHP Version: Requires PHP 7.2+. Check if the app meets this requirement.
• Dependencies: No major conflicts expected, but TPM should run composer validate post-integration.
• Savano API Changes: The package’s simplicity is a double-edged sword—API changes may require forking or rewriting. TPM should:
  • Monitor Savano’s API docs for breaking changes.
  • Create a wrapper class to isolate the package from API shifts.

Sequencing

1. Pre-Integration:
   • Audit Savano’s API documentation for undocumented features (e.g., refunds, voids).
   • Design the payments table schema and migrations.
2. Core Implementation:
   • Implement PaymentController with basic CRUD for payments.
   • Add a service class (e.g., SavanoService) to encapsulate Savano logic.
3. Enhancements:
   • Add webhook handling (if Savano supports it) via Laravel’s HandleIncomingWebhook.
   • Implement payment status polling for async flows.
4. Testing:
   • Unit tests for SavanoService (mock Savano API).
   • Integration tests for the full flow (request → redirect → verify).
   • Load testing for high-volume scenarios.

Operational Impact

Maintenance

• Dependency Risk: With no maintainer, the package is a single point of failure. TPM should:
  • Fork the repo and treat it as a private dependency.
  • Add CI checks (e.g., PHPStan, Pest) to prevent regressions.
• Upgrade Path: Since it’s 1.*, future versions may break. TPM should:
  • Pin to a specific patch version (e.g., 1.0.1) until stability is proven.
  • Document breaking changes internally.
• Documentation: The README is minimal. TPM must:
  • Create internal runbooks for common flows (e.g., refunds, disputes).
  • Add comments in the codebase for critical paths.

Support

• Debugging: Without tests or community support, debugging will rely on:
  • Savano’s API logs (if accessible).
  • Laravel’s error tracking (e.g., Sentry, Bugsnag).
• Escalation Path: No maintainer means no official support. TPM should:
  • Build a relationship with Savano’s support team for API issues.
  • Create a #savano-payments channel in Slack for internal triage.
• Customer Impact: Payment failures could lead to chargebacks or lost revenue. TPM should:
  • Implement a fallback mechanism (e.g., alternative gateway) for critical transactions.
  • Communicate risks to stakeholders (e.g., "Savano is unproven; expect delays").

Scaling

• Throughput: Synchronous API calls may bottleneck under high load. TPM should:
  • Rate-limit requests using Laravel’s throttle middleware.
  • Implement circuit breakers (e.g., Spatie’s circuit-breaker) for Savano’s API.
• Database Load: Storing every payment in the DB could bloat storage. TPM should:
  • Archive old payments (e.g., keep only the last 2 years).
  • Use a read replica for reporting queries.
• Geographic Scaling: If Savano has regional endpoints, TPM should:
  • Route requests based on user location (e.g., savano->setEndpoint('eu')).

Failure Modes