Strategy pattern: payment pattern for Internet banking

This paper brings out the design patterns according to the various services involved in internet banking. The Pattern oriented Software Architecture uses the pattern which eliminates the difficulty of reusability in a particular context. The patterns are to be designed using BPM (Business Process Model) for effective cross cutting on process level. For implementing the above said BPM, the Internet banking has been taken to implement the pattern into it. The Analysis and identification of various processes in Internet Banking have been done, to identify the effective cross cutting features. With this process the pattern has been designed, as a reusability component to be used by the Software Architect. The pattern help us to resolve recurring problems constructively and based on proven solutions and also support us in understanding the architecture of a given software system. Once the model is finalized by analyzing, we found payment in the process of internet banking has a strategy pattern.

💡 Research Summary

The paper investigates how to apply a well‑known behavioral design pattern – the Strategy pattern – to the payment subsystem of an Internet‑banking application. The authors begin by reviewing the role of design patterns in software engineering, emphasizing that patterns improve reusability, readability, and maintainability. They then describe the three classic categories of patterns (creational, structural, behavioral) and focus on the Strategy pattern as a means of encapsulating a family of algorithms behind a common interface, allowing the algorithm to vary independently of the client code.

To ground the discussion in a concrete domain, the authors model the entire Internet‑banking workflow using Business Process Modeling (BPM). The BPM diagram captures services such as account inquiry, third‑party transfer, utility‑bill payment, credit‑card bill payment, and mutual‑fund operations. By analysing the BPM model they identify “payment” as a cross‑cutting concern that appears in many services. This observation leads to the central claim: the payment logic should be abstracted as a Strategy so that each concrete payment method (e.g., credit‑card payment, utility‑bill payment, future mobile‑payment, QR‑code payment) can be implemented as a separate ConcreteStrategy class.

The proposed architecture consists of a Payment interface (the Strategy), concrete strategy classes (CreditCardPayment, UtilityBillPayment, etc.), and a Context (the client or front‑end component) that holds a reference to a Payment object. At runtime the appropriate concrete strategy is injected, allowing the system to switch payment methods without modifying client code. This design dramatically reduces code duplication, isolates changes to a single class, and simplifies the addition of new payment channels.

Beyond the high‑level design, the paper introduces a “pattern‑mining” step. Using the BPM model, the authors automatically extract cross‑cutting concerns and map them to source‑code elements. They discuss three mapping relations – scattering (one source element linked to many targets), tangling (multiple concerns interleaved in a single module), and tangling (the inverse of scattering) – and illustrate how these mappings can be recorded in a pattern repository for future reuse.

Security considerations are also addressed. The authors conduct a structural‑equation‑model (SEM) study with 219 respondents in Korea to measure perceived security and trust in e‑payment systems. They compare three authentication schemes: single‑factor (password), two‑factor (OTP), and two‑factor with one‑time passcodes. Results show that while users find single‑factor most convenient, two‑factor methods are perceived as significantly more secure. The paper suggests that authentication logic can also be encapsulated as a Strategy, enabling the banking system to switch or combine authentication mechanisms without rewriting business logic.

In the discussion, the authors argue that the Strategy‑based payment module satisfies key software‑engineering goals: high cohesion, low coupling, and easy extensibility. By separating the payment algorithm from the client, the system can evolve with emerging payment technologies (e.g., blockchain‑based transfers) with minimal impact on existing code. The BPM‑driven pattern‑mining approach provides a systematic way to discover reusable design elements early in the development lifecycle, reducing ad‑hoc refactoring later on.

The conclusion reiterates that applying the Strategy pattern to the payment domain, guided by BPM analysis, yields a modular, maintainable, and secure architecture. The paper recommends future work on tool support for automated pattern extraction, performance evaluation of Strategy‑based payment services in a micro‑services environment, and empirical studies on developer productivity gains.