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.

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.


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


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


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.