Inspiration - Payment Systems (e.g. Fusion GPP-SP) testing majorly constitutes validation payment attributes at each transaction/ payment level which are derived by code function or rules & profiles. The core idea of the ‘Payment Testing Platform‘ is to make logical use of the Payment Attributes/ GPP Logical fields across different Testing phases to make all Testing phases inline with GPP architecture.

(At the same time, it is scalable enough to be used for any Payment engine testing)

What it does?

o Automates all major Payment testing phases. o Implements unique Payment testing concept by using a library of Payment Input conditions and Validation Points.

  • Payment Input Conditions library - It contains a library of all Payment attributes/ logical fields to be used while creating a test case which would help; a. Define/ select the subset of the data setup defined in the System - solution delivered against the requirement, for which test case is being written.

b. Define the payment attributes that would be passed in AI algorithm to generate a payment message (test data) automatically for each test case. Using the same intelligence, define the variations of payment attribute test data to be used across all test cases of a project.

  • Pre-functioned Validation Points library - It is a library of Validation points covering all Payment/ GPP functionalities.

The objective is to align Validation point for each GPP/ Payment core function and at the same time, to map it with the logical fields. E.g. In GPP/ Payments, we have identified 1000 core functionalities covering all payment functional areas. Accordingly, we will create/ maintain a library of 1000 Validation Points wherein 1 validation point would be mapped to each core function. At the same time, try to map each Validation point with the Payment attribute or Logical field.

Parallel and Comparison Testing - o It is used for Parallel & Comparison Testing wherein as a part of migration or production release, we do compare the behavior/ processing of each payment at payment attribute/ logical field between; o Old legacy system and GPP version being tested o GPP Classic and GPP SP version being tested o Production env and GPP SP version being tested.

We do this comparison for millions of payments wherein each payment would be compared with the value derived at multiple Payment attribute/ logical field level.

How we built it

We build it by using Java and AI technology.

Challenges we ran into

  1. Challenges to build a library of Validation points to cover all GPP functionalities
  2. AI algorithms to create a MT/ MX payment.

Accomplishments that we're proud of

It does simplify current Payment testing process.

What we learned

We learned that current complex process of Payment Testing can be simplified.

What's next for Payments Testing Platform

In the industry, huge efforts and cost is put by Customer/ Banks for Payment Testing to simplify and automate the Payment testing but still facing multiple challenges & issues. Due to this huge demand of Payment Testing in market, few companies are coming with a Product specially for Payment Testing. As it is a very early days for Payment Testing products hence we strongly believe it could be a Next FINTECH Product that could compete with the existing payment testing product.

It would help Customers/ Banks to save efforts, time and cost. Also, most importantly, it helps Banks to implement GlobalPayPlus or Go Live at much faster rate.

Built With

  • ai
  • jave
Share this project:

Updates