tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Pyeron <>
Subject RE: [OT] Question regarding payment processing
Date Tue, 14 Jan 2003 16:32:19 GMT

I will be able to read the docs after lunch today. What Noel was talking 
about is the asynchronous web gateways, like 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:


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?


Denise Mangano
Help Desk Analyst
Complus Data Innovations, Inc.

> -----Original Message-----
> From: Noel J. Bergman [] 
> 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:   
> <>
> For 
> additional commands, e-mail: 
> <>

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

-                                                               -
- Jason Pyeron            -
- 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:   <>
For additional commands, e-mail: <>

View raw message