Problem Statement: Data Marshalling Payment Gateway merchant Banking ... E-commerce

                   Refer to standard definitions, terminology , procedures 

                   ....several illustrations and anologies are available over the WEB (WWW or internet)

                   Furhter to as published by this individual in the document referred below viz. projects.pdf
                   and also else where by this author.
                         

Opportunity A:  Making the process flow comparitively less cumbersome
               (in terms of electronic process flow ...URL to URL data marshalling ...URL re-direction)


               Taking into account nuancies of affliations of a client(merchant or account holder)
               banker or the bank  ...and the process flow ...of making a payment ...and the umpteen
               number of the intermediataries(potentially termable as brokers ...sub-brokers ..)
               and the end merchant account(treasury in case of governance or government) to
               whom payment needs to flow to (Questionable ?? marketing practices of branding
               said visa ...mastercard ....doesn't show-up or have shared reliable repositories ??)


               The  standard interface when negotiation with a payment  gateway is a  form (html) over https,
               ...due to nuancies of affliations of 'the Buyer or the purchaser' and the merchant
               
               data needs to be marshalled through a hierarcy of transaction points ...at times involving
               or requiring population of forms(intermediary interface ...URL to URL redirection) for the 
               transaction to pass through the end-merchant (treasury in case of governance) account,


               By using XML-DTD compliant data-sets ...with XML-rpc (for analogy) ...assuming or making it
               a norm or letting the variable naming schema adhering to a standard nomenclature...across 
               the e-commerce or electronic merchant banking data transmissions,

               thus making the form-submission or server-side (e-commerce data-processing points) to be
               compliant with both  XML-DTD and html-forms

               ....the process flow as also the token (acknowledgement ....flow) ....can be made easy
               and simple or less cumbersome to process in the parlance of ecommerce.


            [  Also interpretations of token(acknowledgement ....flow) .... understanding and interpretations
               from the point of accounting ...debit.. credits ....the amount of data required to be
               marshalled can also be limited or minimized ]

Opportunity B: Understanding interpreting ...exploiting interprocess-communication for innovative software-systems.

               eg: banking software ...client software at the counter ...or customer-interfacing-CRM ...payment/reciepts collection.


               read through 'opportunity_coupon_ticket_validation.txt'
 


Note: The above problem statement having been encountered in various scenarios
      and detailed in various 'Proof of concepts' as mentioned in 
      
       http://uk.geocities.com/ravivenkatus/projects.pdf
       http://ravishankarkv.tripod.com/projects.pdf
        ....apply appropriate
      'use-case' modeling, rationalize and arrive at a workable and feasible 
       solution both commercially and techinically viable.

  