Chapter 9. Building the Payment Module

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:

  • Requirements
  • Dependencies
  • Implementation
  • Unit testing
  • Functional testing

Requirements

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:

  • function authorize();
  • function capture();
  • function 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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.17.5.68