The payment module provides a basis for further sales functionality in our web shop. It will enable us to actually choose a payment method when we reach the checkout process of the upcoming sales module. The payment methods can generally be of various types. Some can be static, like Check Money and Cash on Delivery, while others can be regular credit cards like Visa, MasterCard, American Express, Discover, and Switch/Solo. Throughout this chapter we will address both types.
In this chapter, we will be looking into the following topics:
Our application requirements, defined under Chapter 4, Requirement Specification for Modular Web Shop App, do not really say anything about the type of payment method we need to implement. Thus, for the purpose of this chapter, we will develop two payment methods: a card payment and a check money payment. In regards to the credit card payment, we will not be connecting to a real payment processor, but everything else will be done as if we are working with a credit card.
Ideally, we want this done by an interface, similar to the following:
namespace FoggylineSalesBundleInterface; interface Payment { function authorize(); function capture(); function cancel(); }
This would then impose the requirement of having the SalesBundle
module, which we still haven't developed. We will therefore proceed with our payment methods using a simple Symfony controller
class that provides its own way to address the following features:
authorize();
capture();
cancel();
The authorize
method is used for cases where we merely want to authorize the transaction, without actually executing it. The result is a transaction ID that our future SalesBundle
module can store and reuse for further capture
and cancel
actions. The capture
method takes us a step further by first executing the authorize action and then capturing the funds. The cancel
method performs the cancelation based on a previously stored authorization token.
We will expose our payment methods through tagged Symfony services. The tagging of a service is a nice feature which enables us to view the container and all of the services tagged with the same tag, which is something we can use to fetch all of the paymentmethod
services. The tag naming has to follow a certain pattern, which we impose on ourselves as application creators. With that in mind, we will tag each payment service with a name
,payment_method
.
Later on, the SalesBundle
module will fetch and use all of the services tagged with payment_method
and then use them internally to generate a list of available payment methods that you can work with.
3.17.5.68