Noel, The problems that I am having have to do with specifically Chase's values that are being returned to me and the possible scenarios each value can cause. My frustration is that I ask a simple question such as will a decline always have SomeValue is > 5 - and what I get back is a bunch of business logic explaining that I am only concerned with approvals, anything else is a non-transaction. While this is true in the business sense, my program is concerned with every scenario, and everything that completes the process (including declines) is considered a transaction.
What do you mean by the gateway mechanism doing a "callback" to one of my pages? The way I have it set up is my JSP instantiates transactionBean with all the necessary values. The methods in this bean do the actual formatting of the input document, make the API call to the gateway to submit the input document, and receive the result document. The bean will also determine if the transaction is a success, and if it is a decline or approval. Then my JSP will access this information to relay it to the browser ( as well as include a script that writes it back to my back end app). We are not storing any user information, so a database is not coming into play for me. The backend app is a UNIX program that I pass a value to via a URL and the program on the UNIX box parses that URL and records the appropriate values. Is this a feasible scenario? If so, then wouldn't the session be persistent throughout the process? Thanks, Denise Mangano Help Desk Analyst Complus Data Innovations, Inc. > -----Original Message----- > From: Noel J. Bergman [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, January 14, 2003 4:11 AM > To: Tomcat Users List > Subject: RE: [OT] Question regarding payment processing > > > Denise, > > I haven't done Chase's gateway specifically, but I've done > some others. What's problems are you having? > > One issue I encountered in the past is that some of the > gateway mechanisms will do a callback to one of your pages. > The catch is that you want to be able to re-associate the > session, but you won't get a session cookie. In the past, I > was able to do that by explicit URL rewriting. I haven't > tried it with recent versions of tomcat, but I should still > have an example of that technique around here somewhere. > > --- Noel > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For > additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
