path through payment process

Hey everybody,

I'm developing a payment module for a CC gateway called Jetpay. I'm not sure what's typical for the flow from other payment modules, but I'm confused on where to go.

index.php?main_page=checkout_payment - takes the CC info, etc.
index.php?main_page=checkout_confirmation - is the confirmation page - the <form> here is going to go offsite to perform the validation.

They ask for a return url. Where does zen go after this? What page do I come back to with their approval / denial codes to then go to checkout_process or loop them back through because of some verification failure.

Thanks!
Andy

index.php?main_page=checkout_payment - takes the CC info, etc
One should not write any payment process that takes CC data on the site
One should redirect to jetpay site for this

After which your return would be

index.php?main_page=checkout_confirmation

Thanks for the quick reply -
Doesn't really help me much.
Their process is that it accepts the POST vars. It feels chicken and the egg to me.
To do what you suggest is to take the CC data and send it to them for validation (which they don't do) and then have it come back to me for them to hit confirm purchase.

Which leads us back to my original question. Where does my CC processor send back to? Is this something I build by hand to handle their response? They have response codes for avs, cvv, etc validation. Does this process happen outside of the zencart process? And if that process succeeds, I send them to checkout_process?

I'm fairly certain this is what I am to do, but I just want to make sure.

I direct you to the authorize.net module for an example

/includes/modules/payment/authorizenet_aim.php

Kobra's information is not fully correct.

The authorizenet.php module (not the authorizenet_aim.php module) is the one you could use as an example. Model yours after the "offsite" mode used in that module. (Ignore/skip anything used by "onsite" mode, as you should not be collecting card data on your site using a module based after this one.)

In the module you supply the $this->form_action_url as the URL where the POST data is to be sent.
Then in the module you also supply all the POST data in the process_button() function.
That will cause the "Submit" button on the payment confirmation screen to be a direct POST to the URL you supplied.

You will then want the gateway to POST its reply back to the index.php?main_page=checkout_process URL of your store (often you accomplish this by passing that return URL as part of your POST data).

Then the before_process() function will read the data posted back to the checkout_process URL and validate the data. If anything in the response suggests payment ought to be or is declined, then you do a zen_redirect() back to the payment page after setting an error via the $messageStack.
Else if the POST indicates payment is successful then before_process() should do a return (or end without redirect).

Then the normal checkout flow will generate an order number and store the order.

Then the module's after_process() function will fire. In some modules (authorizenet does, but not all do) this is used to save extra information about the transaction to the database using the issued order number.

Then confirmation emails are sent out by the order class.

DrByte - Thank you

In your post, you mention that there will be a 'return url' that I give my CC processor. Yes - there is a field for me to send them the return path. You're spot on.

I already used the authorize.net module as the one to go from. I'm confused about how to get the payment page to my CC provider without going to the confirmation page. It seems that the way the authorize.net module works, is that on the payment page, you type in the CC info. Then you press the zencart button to go to a confirmation page which will display all of the options back to the customer. There is a hidden form set with all of the values, including the customers CC info (under an SSL certificate mind you). And THAT submit button is directed off to my CC provider.

I don't see how to get the 'Payment Method' page to go straight to my CC provider, without 'hacking' it to do so. but could confuse customers potentially.

Please understand, I'm definitely NOT trying to save any customer CC info. I'm trying to work within the framework of zencart and be as safe and secure as possible in this. Any advise is greatly appreciated.

Where I am, just as an FYI -
I have the module all built wherein on the 3 of 3 order confirmation page, that form will post to my CC provider and they are given the return url. My original question is where do I sent them. If that's checkout_process, awesome. That's where I'll send them.

Is it OK to have the customers CC info for only that one iteration of a submit, the CC info is only in a session variable - is this safe?

droidmcse:

I already used the authorize.net module as the one to go from. I'm confused about how to get the payment page to my CC provider without going to the confirmation page.You're not supposed to go to the gateway from that page. Wait til the confirmation page.

droidmcse:

It seems that the way the authorize.net module works, is that on the payment page, you type in the CC info.er, well, you're not supposed to use that "onsite" mode (it's not a PCI-compliant approach). To collect card data offsite, you're supposed to only use the "offsite" approach, where ALL the payment data is collected by the gateway and none of it via your site.

droidmcse:

I don't see how to get the 'Payment Method' page to go straight to my CC provider, without 'hacking' it to do so. but could confuse customers potentially.Don't.

droidmcse:

I have the module all built wherein on the 3 of 3 order confirmation page, that form will post to my CC provider and they are given the return url. My original question is where do I sent them. If that's checkout_process, awesome. That's where I'll send them.Yes, that's where you send them.

droidmcse:

Is it OK to have the customers CC info for only that one iteration of a submit, the CC info is only in a session variable - is this safe?In the strictest sense it's best to never hold it -- ever. But most solutions, even those PCI certified, typically do end up reading and forwarding it, but with a number of very important secure processes protecting those operations (too much detail to go into here).