Denise, I will be able to read the docs after lunch today. What Noel was talking about is the asynchronous web gateways, like authorize.net. That is one of the most common situations.
Keep in mind, I have not read your docs yet, but I will write anyway. >From your descriptions it sounds like Chase has provided you with a "VPN" like client. You pass in via command line args or STDIN and it pumps out results on STDOUT or to a file. Typically gateways provide such an app to "guarantee" bug free operation, but they fail to document it as a software API. In these situations one can dumb down your application, find competent tier2 support (like I said, we might be able to help), or write your own VPN app (as a class file). I don't know what your time frame is like, but there is a chance that there is a synchronous protocol, over SSL you might be able to use. If that is the case, for security/simplicity reasons, you might want to do that. But it would be a rewrite of the comm routines. -Jason Pyeron On Tue, 14 Jan 2003, Denise Mangano wrote: 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]> -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron http://www.pyerotechnics.com - - Owner & Lead Pyerotechnics Development, Inc. - - +1 410 808 6646 (c) 500 West University Parkway #1S - - +1 410 467 2266 (f) Baltimore, Maryland 21210-3253 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
