In the previous posts, we explored two different methods for handling payment processing in Laravel:
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).
The Factory Pattern provides a scalable solution to dynamically resolve different implementations at runtime. Here's how to set it up step by step.
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:
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:
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.
Disclaimer: All resources provided are partly from the Internet. If there is any infringement of your copyright or other rights and interests, please explain the detailed reasons and provide proof of copyright or rights and interests and then send it to the email: [email protected] We will handle it for you as soon as possible.
Copyright© 2022 湘ICP备2022001581号-3