Dynamic Payment Processor Selection in Laravel 11: Using the Factory Pattern

In the previous posts, we explored two different methods for handling payment processing in Laravel:

• hardcoded service bindings
• contextual binding.

While both methods are effective, they have their limitations when it comes to selecting payment processors dynamically based on runtime conditions (e.g., user input, configuration settings).

In this third and final part, we’ll look at a more flexible approach: using the Factory Pattern. This design pattern allows us to choose the appropriate implementation of PaymentProcessorInterface based on the context (e.g., selecting between Stripe or PayPal depending on the request).

Implementing the Factory Pattern

The Factory Pattern provides a scalable solution to dynamically resolve different implementations at runtime. Here's how to set it up step by step.

Step 1: Create a Factory Interface

First, let's define a PaymentProcessorFactoryInterface that outlines how to resolve different payment processors.

<?php

namespace App\Contracts;

interface PaymentProcessorFactoryInterface
{
    public function getProcessor(string $provider): PaymentProcessorInterface;
}

This interface ensures that any factory we create will have a getProcessor method, responsible for returning the appropriate payment processor based on the provided argument (e.g., 'stripe' or 'paypal').

Step 2: Create the Factory Implementation

Next, we'll implement the factory that resolves the appropriate payment processor based on the provider input.

<?php

namespace App\Services;

use App\Contracts\PaymentProcessorInterface;
use App\Contracts\PaymentProcessorFactoryInterface;
use App\Services\StripePaymentProcessor;
use App\Services\PayPalPaymentProcessor;

class PaymentProcessorFactory implements PaymentProcessorFactoryInterface
{
    public function getProcessor(string $provider): PaymentProcessorInterface
    {
        switch ($provider) {
            case 'stripe':
                return new StripePaymentProcessor(); // Can be resolved via the container if needed
            case 'paypal':
                return new PayPalPaymentProcessor(); // Can also be resolved via the container
            default:
                throw new \Exception("Unsupported payment provider: $provider");
        }
    }
}

This factory dynamically selects the correct payment processor based on the input provided at runtime. In this example, we directly return new instances of StripePaymentProcessor and PayPalPaymentProcessor. If needed, these classes can also be resolved from Laravel's service container for better management.

Step 3: Implement Stripe and PayPal Processors

Make sure you have both the StripePaymentProcessor and PayPalPaymentProcessor classes that implement the PaymentProcessorInterface.

Example: StripePaymentProcessor

<?php

namespace App\Services;

use App\Contracts\PaymentProcessorInterface;

class StripePaymentProcessor implements PaymentProcessorInterface
{
    public function createPayment(float $amount, string $currency, array $paymentDetails): array
    {
        // Stripe-specific implementation
    }

    public function processPayment(array $paymentData): array
    {
        // Stripe-specific implementation
    }

    public function refundPayment(string $transactionId, float $amount): bool
    {
        // Stripe-specific implementation
    }
}

Example: PayPalPaymentProcessor

Similarly, implement the PayPalPaymentProcessor class, following the same pattern as the StripePaymentProcessor.

Step 4: Bind the Factory in the Service Container

To ensure that the factory is available throughout your Laravel application, you need to bind the PaymentProcessorFactory to Laravel’s service container. You can do this in the AppServiceProvider.

In App\Providers\AppServiceProvider.php, add the following inside the register method:

public function register()
{
    $this->app->singleton(\App\Contracts\PaymentProcessorFactoryInterface::class, \App\Services\PaymentProcessorFactory::class);
}

This binding tells Laravel to use the PaymentProcessorFactory whenever the PaymentProcessorFactoryInterface is requested, ensuring that there's only one instance of the factory throughout the application.

Step 5: Using the Factory in a Controller

Now that the factory is set up, you can inject it into your controllers to dynamically select the appropriate payment processor based on runtime data, such as the request input.

Example: PaymentController

<?php

namespace App\Http\Controllers;

use App\Contracts\PaymentProcessorFactoryInterface;
use Illuminate\Http\Request;

class PaymentController extends Controller
{
    protected $paymentProcessorFactory;

    public function __construct(PaymentProcessorFactoryInterface $paymentProcessorFactory)
    {
        $this->paymentProcessorFactory = $paymentProcessorFactory;
    }

    public function makePayment(Request $request)
    {
        $provider = $request->input('provider'); // E.g., 'stripe' or 'paypal'
        $amount = $request->input('amount');
        $currency = $request->input('currency');
        $paymentDetails = $request->input('details');

        // Get the appropriate payment processor based on the provider
        $paymentProcessor = $this->paymentProcessorFactory->getProcessor($provider);

        // Use the selected payment processor to create a payment
        $response = $paymentProcessor->createPayment($amount, $currency, $paymentDetails);

        return response()->json($response);
    }
}

In this controller, we inject the PaymentProcessorFactoryInterface via dependency injection. When a payment is requested, we determine the payment provider (e.g., Stripe or PayPal) from the request, pass it to the factory, and dynamically resolve the appropriate payment processor.

Step 6: Handling Different Payment Providers

In this setup, the controller can now dynamically handle different payment providers by simply switching the provider name in the request. This method is particularly powerful when you need to handle multiple payment gateways without duplicating logic or tightly coupling your code to specific implementations.

Conclusion

Using the Factory Pattern in Laravel 11 offers a highly flexible approach to selecting different payment processors at runtime. Here’s a summary of the steps we covered:

• Factory Interface and Implementation: Created a factory that dynamically resolves the correct payment processor based on a string input.
• Processor Implementations: Ensured that both StripePaymentProcessor and PayPalPaymentProcessor classes implement PaymentProcessorInterface.
• Service Container Binding: Bound the factory in the service container to allow easy injection throughout the application. Dynamic Selection in Controllers: Used the factory inside a controller to dynamically select and use the appropriate payment processor based on runtime data.

Software Design Principles and Design Patterns

We started this 3 parts tutorial using a single payment processor, with a hardcoded selection, then we were using an in code("compile time") configuration by using Laravel Service Container Binding, then in this part we kept refactoring with design principles and design patterns in mind, which allowed us to refactor the code, achieving:

• Dynamic Flexibility: The Factory Pattern allows for the selection of different payment processors at runtime, making your application more flexible and scalable.
• Loose Coupling: By injecting the factory, your controllers are loosely coupled to the payment processors, making it easier to add or replace payment gateways in the future.
• Maintainability: This approach provides a cleaner and more maintainable codebase, especially when dealing with multiple payment options.

With this setup, we now have a powerful, flexible system for handling payments in Laravel. If we need to support additional processors, we can easily extend the factory to support and modify the logic for selecting providers, and handle different business logic scenarios.