[Seaside] Interaction with non-Seaside site

Nevin Pratt nevin at smalltalkpro.com
Tue Jul 15 22:29:50 CEST 2003


Derek, what did you end up doing on this issue (this thread you posted 
on about a month ago)?

I use "Novus" for credit card processing at our bountifulbaby.com site. 
 The "Novus" account in turn was obtained through Costco (via an 
Executive-level Costco membership, which costs me about $100 year to 
maintain).  They provide an internet interface via several different 
API's.  There are 3 basic API's available to me, as follows (I am 
currently just doing #1, which obviously is a bit manually intensive):

****
API #1. I collect the credit card information from the customer, via a 
secure SSL connection to my Squeak box, and then later I manually launch 
a browser (Netscape or whatever), and go to my IonGate credit card 
processing web site, and log in with my merchant account name and 
password.  I am then (by the IonGate site) presented with a merchant 
credit card authorization terminal screen where I manually type in the 
collected customer credit card details and order details.  Whatever I 
enter is then processed via the IonGate gateway each night, and the 
funds from those transactions are automatically debited/credited to my 
bank account each night.
****

API #1, above, works, but is obviously manually intensive.

(then skipping down into what you wrote below, you'll find a description 
of API #2 later)

Derek Brans wrote:

> Sure, thanks for taking the time to read that, Avi.
>
>     There are two parts to this problem:
>     1. Sending them to the payment site and
>     2. receiving them back to Seaside after payment.
>      
>     1. This part is easy: WAPaymentStep presents a form to the user
>     that upon submission posts the necessary variables to the payment
>     site.
>      
>
> Is this part clear? If not:
> i) WAPaymentStep>>renderContentOn: renders a static confirmation page 
> that says "Are you sure this information is correct?".  This page has 
> hidden fields (amount, name, address). 
> ii) When client hits submit "Yes this information is correct"  all 
> those fields get posted by the client's browser to Verisigns cgi script.


****
API #2. I can, if I wish, programmatically create a form similar to what 
you just described for your Verisign account.   And, it looks like it 
would need to work very similarly (possibly identically) to what you've 
described above and below.
****

But, there is also another way-- API #3, which might even be easier to 
do (because there wouldn't be a need to orchestrate the dance you've 
described below between your customer's browser, your credit card 
processor's system (Verisign in your case, IonGate in my case), and 
Seaside.  #3 is a server-to-server scenario.

(skip down to the bottom of your message to find API #3)

>     2. This is the hard part.  Here's my plan so far...
>     WAPaymentStep needs to register a callback that would
>     a) process the POST from Verisign site (their response) and create
>     a PaymentResponse object
>     b) return the Payment Response using #answer:. 
>      
>
> i) on Verisign's site, client enters CC info and clicks "Pay this amount"
> ii) client is presented with Verisign hosted receipt page (with hidden 
> fields...) . 
> iii) Client clicks "Done" and at that point the client's browser posts 
> the hidden fields on the receipt page ( including the results of 
> payment)  to a _static_ url of my choice.
>  
> As an aside, for whatever reason I want, I can have Verisigns server 
> "silently" POST a copy of the information to my server _before_ the 
> client gets back to my server.
> Also, when I send the client over to Verisign's site, there are up to 
> 10 variables I can include to be returned to me with the client's post 
> or the silent post.  This is where I will store my Seaside session key 
> and continuation key.
>  
> Now we're back in Seaside, at a static url, with a bunch of posted 
> fields (posted by the client's browser, including a session key). 
> This static url will probably be a Seaside service which will route 
> the payment response back to the correct session and component in the 
> following way:
>  
> I need to process the fields and create a PaymentResponse.
> Then I put the PaymentResponse in some sort of "mailbox"
> Then wake up the WAPaymentStep by invoking some continuation.
> The WAPaymentStep grabs the PaymentResponse from its "mailbox" and 
> returns it using #answer:.
>  
> Does that make any sense?
>  
> Thanks again.
> Derek


****
API #3.  This is similar to API #2, but remember, for API #2, you said:

> ii) When client hits submit "Yes this information is correct"  all 
> those fields get posted by the client's browser to Verisigns cgi script.


Well, for #3, instead of the client's browser posting the information to 
Verisigns cgi script (IonGate's asp script in my case), you let your 
server post it.  That means your server will receive Verisign's 
(IonGate's, for me) response.  And then you let Seaside send the 
appropriate info back to your client's browser, based on what Verisign's 
server told you.
****

There seems to be a couple of advantages to doing #3 instead of #2.

One difference is: For #2, the values passed to the payment processor 
(Verisign for you, IonGate for me) are visible to the client's browser 
using the "view source" within the client's browser, whereas for #3, 
those values are not visible to the client.  For the IonGate gateway, 
I've looked at those values that would be sent in, and it doesn't look 
like there is anything that could be maliciously tampered with anyway, 
but you never know.  It seems like it would be better to completely hide 
it, and by letting your server post the form to the payment processor 
rather than your client's browser, you could easily completely hide it.

Another difference is: The dance you've described for #2 might be 
simpler for #3.  For one thing, there is no need to forward the user to 
the Verisign site in the manner you've described.  The user would always 
stay connected solely to your own site.  For me, I use Stunnel for SSL 
secure connection to my Squeak box, and it works fine.  Plus, I recently 
purchased a "real" SSL certificate from GeoTrust ($349 for two years). 
 Before that I was using a self-signed certificate which most folks 
seemed satisfied with, but now with a "real" SSL certificate from 
GeoTrust, the rest of the folks should be satisified as well.  

Anyway, with Stunnel and an SSL certificate, it really is easy to handle 
all the SSL communication myself, in a very acceptable manner for the 
user, and just let the user stay at the site, and never forward them to 
any payment processor site or any other 3rd party site.

So, for #3, your server would post the credit card information to 
Verisign (after collecting it from the user), and then just wait for a 
pass/fail message from your payment processor, and then display that 
message back to your user.

But, even for #3, the difficulty for me is the fact that I still have to 
give my payment processor a specific "static" URL to post their response 
back to me.

In your case, you said the following:

> Also, when I send the client over to Verisign's site, there are up to 
> 10 variables I can include to be returned to me with the client's post


For me, this is basically the same-- there are up to 15 variables that 
the IonGate gateway will echo back to me on it's return post.  And, I 
imagine, just as you've said, this is where I would think I would need 
to store the session key and continuation key.  

When the payment processor posted back to a static URL, the rest of what 
you've described seems right:

>  
>
> Now we're back in Seaside, at a static url, with a bunch of posted 
> fields,...
> This static url will probably be a Seaside service which will route 
> the payment response back to the correct session and component in the 
> following way:
>  
> I need to process the fields and create a PaymentResponse.
> Then I put the PaymentResponse in some sort of "mailbox"
> Then wake up the WAPaymentStep by invoking some continuation.
> The WAPaymentStep grabs the PaymentResponse from its "mailbox" and 
> returns it using #answer:.


Wow.  This really does seem difficult-- far more work than what you 
would intuitively think.  If only we could just call the payment 
processor "page" like it was a subroutine, and get return values from 
it, just like a subroutine.  In other words, if only we could call the 
external payment processor "page" like it was just another Seaside 
component.  There would then be no need of the last part of this dance 
synchronization nonsense.

Anyway, what did you ever end up doing?

-- 
Nevin Pratt
Bountiful Baby
http://www.bountifulbaby.com
(801) 992-3137





More information about the Seaside mailing list