Making Payments..

Traditionally we have approached the development of payment interfaces as a separate design element for each project that I have worked on, due to the differing nature of the various agencies used by each client, and the various permutations of requirements in relation to validation on each.

Recently however we started looking at a better way of doing this, with the intent of delivering a single interface that can be all things to all installations, and thanks to the work of our design team (specifically DL, thanks for all the effort expended in relation to this interface), we believe that we now have a re-usable interface that can easily be extended to cater for processing of payments from a variety of agencies, in a variety of formats.

 

The historic approach was always similar to: traditional_payments.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This meant that any changes required as a result of the introduction of additional business validation rules had to be applied to numerous code modules to ensure a consistent approach to each interface file. It also meant that the introduction of new payment agencies required further development of new modules specific to these new file formats.

 

Our new approach is:

Develop a common routine which accepts an XML interface definition file as an input, along with an associated payment file. This XML file is defined once, and contains the definition of the input files received from this agency.

 

This file contains:

  • An indicator of whether the file is Column-Delimited, Comma-Delimited or XML
  • Whether a Header record exists, and associated identifiers (e.g. Record type)
  • Field mapping for this Header record
  • Validation requirements in connection with this Header record
  • Whether a Footer record exists, and associated identifiers (e.g. Record type)
  • Field mapping for this Footer record
  • Validation requirements in connection with this Footer record
  • Detail record identifiers (e.g. Record Type)
  • Field mapping for detail records

 

This logic is then applied to the incoming payment files at run-time, and the resulting records are validated and loaded into the Payment Upload Staging Table for processing by the base product PUPL batch process. The new process takes the form of:
new_payments.jpg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This has the advantage of allowing clients to extend the number of payment agencies that they are able to interface to via CC&B with minimal additional configuration (i.e. the documentation of the interface specification in the associated XSD file, and the definition of a new Batch Control in CC&B, to utilise this XSD), with no additional coding requirements. It also ensures that a single code-mass is responsible for processing these records resulting in reduction of code duplication and easier maintenance in the event that business rule changes are required.

 

A Sample interface XML definition is available here
The Design document associated with this interface is available in pdf format here
Comments:

Hi Stuart ,

I gone through design it looks okay and more generic. but how can you make this design for csv file or delimited file? can i see sample java code and sample xml payment file for this to understand this design more thoroughly.

Thanks

Posted by guest on October 25, 2012 at 05:06 AM EST #

Hi Prashant,

the java classes associated with processing of each of the different file formats are listed in Appendix E of the design, and the interface file samples are attached to the blog posting above (and included in the design). Unfortunately I cannot post Java code to my blog.

Posted by Stuart on October 29, 2012 at 10:51 AM EST #

Hi Stu,

This is really good stuff and I can see how it'll work for XML-formatted, fixed, and CSV files - i.e. if it's a CSV file, make sure that the fieldSequence element is populated, if it's a fixed format file, then the fieldPosition and fieldLenght must be populated, if it's an XML file, then the xmlTagName and xmlAttributeName must be populated.

The only thing that is not so clear to me is the purpose of the validationText element. I cannot see from the attached design document how this controls the validation process of the upload.

A possible enhancement that I can see is to add this pair of optional elements in the transaction data group - payeeAccount and payAmt. This will enable the upload to cater for the following scenarios: a) payments where the payor account is different from the payee account, and b) payments where a single tender is allocated to multiple payee accounts.

Cheers

Posted by guest on February 07, 2013 at 09:59 AM EST #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Stuart Ramage

I am a Consulting Technical Manager for Oracle Corporation, and a member of the OU Black Belt Team, based in Hobart Tasmania.
I have worked in the Utility arena since 1999 on the Oracle UGBU product line, in a variety of roles including Conversion, Technical and Functional Architect.

Contact me on:

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today