Moving data from http to https

[loopthis!]

For a shopping cart-enable site, what is the best way to store and transfer a
user's session data from non-secure to secure? The secure section will contain
the form for them to enter their credit card information as well as submit to
the 3rd party payment gateway and back again.

The secure folder will also be under the same domain as the non-secure. I'm
using SQL Server database and CF5.0.:camera;:confused;

[Steve Sommers]

My recommendation would be to not use a "3rd party payment gateway" and instead
get a real merchant account but I realize the unders some circumstances (low
volume), 3ppg is the only option.

What you have to do is somehow pass CFID and CFToken to the 3ppg and have it
returned in the gateway callback. Most have some sort of custom data hidden
field that you can supply when you send the customer off to their site and it
will be returned if and when the customer come back to your site. In the field,
include "CFID=#CFID#&CFToken=#CFToken#"

[loopthis!]

Well, a merchant account is part of the required pieces of information that
will be passed to the payment gateway. Although the secure folder will first
contain the form for the user to enter their credit card info, and then have it
submitted to the payment gateway.

I was thinking of using client variables to store the their ID, Token and a
timestamp in the database, which will then be used to reference their order
upon submission. I'll pass their ID/Token/TS as hidden form variables. Good,
or a better way to do it?

[Steve Sommers]

I'm a little confused and need some clarification. "3rd Party Payment
Processor" usually refers to a PayPal like processor, where PayPal is the
merchant as far as the credit card companies are concerned and PayPal's name
will appear on the customers monthly statment.

With a real merchant account, you are the merchant of record in the eyes of
the credit card companies and your name will appear on the customers monthly
statement.

With the PayPal like gateways, the customer must go to their site like the
process you describe. With a real merchant account, most gateways offer what
you describe BUT they also allow a server-to-server interface (S2S). With S2S
you don't need to do all the tricks you and I described and instead, you would
use the CFHTTP tag or a custom tag that the gateway provides to communicate
directly from your server to theres -- no customer hand off.

Are you using a 3ppg like PayPal or a real merchant account and payment
gateway? I'm just asking because I don't want to send you down the wrong path...

[loopthis!]

Sorry, misinterpretation on my part.

I have a merchant account, and am using a payment gateway only for the actual CC verification (i.e. Authorize.net).

[Steve Sommers]

Ahhh.

My recommendation would be to get your own SSL certificate if you don't
already have one and then use one of their server-to-server API's. There are
some tags in the Developer's Exchange area to help with the process. With S2S
there is no need for sending the customer off to the AN site and no worrying
how to link the session with the order when they return.

[loopthis!]

I am getting my own SSL, which will hold the CC Number form template for submission.

What specific process are you saying that the Developer's Exchange will help me with?

[Steve Sommers]

Also, the misinterpritation is not really your fault. 3rd Party Processor
originally meant any processor or gateway used to process credit card
transactions, like us (Shift4), First Data, and Authorize.Net, as opposed to
writing directly to your bank's host. Somehow, the PayPal like services, when
they shed their person-to-person payment service grabbed the 3rd Party
Processor label even though technically, they are not a processor or gateway as
far as the card associations are concerned.