Re: credit card reciept response

Paul Furman wrote:
Jerry Stuckle wrote:

Paul Furman wrote:

I'm setting up credit card payment through authorize.net and they have the option to send a POST string back to my site once complete. I'm not sure how to proceed. They don't have much to read about this, their tech support seemed to think I've got the general idea though & said I might have have my hosting server set up permissions to recieve POST data that way.

Let me paste their explanation:
-----------
Gateway Response API
This section describes the response returned by the gateway when a transaction is submitted for processing. The gateway response to a transaction submitted via SIM is either a Receipt Page that is displayed to the consumer or a POST string to a site designated by the merchant. The merchant can then parse the POST string, customize a response, and submit it back to the gateway. The gateway will then relay the response to the customer’s browser.

x_response_code
Indicates the result of the transaction:
1 = Approved
2 = Declined
3 = Error

x_trans_id
This number identifies the transaction in the system and can be used to submit a modification of this transaction at a later time, such as voiding, crediting or capturing the transaction.

x_invoice_num
This is the merchant's supplied invoice number

etc...
--------

So best I figure I'm going to get a redirect to my server And I'm guessing I'd use something like this:

if (isset($_REQUEST['x_response_code'])) {
//then finalize the order, subtract from inventory
// and generate a reciept

And I'm not so comfortable with the idea of setting up a page on my site that lets any external server send POST data & retrieve customer's order details. I think I'm not understanding all this. I do need to know if their credit card was accepted to continue processing the order on my end though. I don't want to update the inventory & they end up getting their card rejected or give up.


Paul

It's just a page they POST the information to, just like a browser.

Set up the page you want them to access. The data they send will be in the $_POST array.

OK I got it working sort of... problem is, one more step that's optional for the customer... there is no automatic redirect, the customer has to click another button to go back to our site and finalize the transaction on our end. At that point, their credit card is already charged though. The alternative is to use the Relay method which sounds considerably more complicated, perhaps I'll just trust that they will click that last button... if I word it right.

[Checkout] [Cancel]
-type in CC number, seeded $amount, name address & 255 character description, etc.
[Submit]
-reciept page shows at authorize.net minus full list of what's ordered
-email copy sent from them
[Finalize Transaction]
-returns to our site with confirmation status in POST where we then remove inventory and another email is sent out with the full order list.

I'm guessing there is a security issue with my web site if it can recieve POST data from an external source like that, I haven't actually checked if it's coming through yet.

OK, you have a couple of options here.

To send the data to authorize.net you could use CURL to post the information, get the results back and parse it. You can then redirect the customer based in the results being good or bad.

Alternatively, you can do the stuff on your end to complete the sale before sending it to authorize.net, then do a javascript redirect to submit the form to authorize.net (ensuring javascript is enabled on the browser first). You then use the page authorize.net posts the response to to indicate whether the payment was accepted or not.

As for the page being insecure, that can be a problem. You could call it something strange like poewqgapmv.php. But many programmers will tell you that security through obfustication is inherently insecure - and they are correct. You could check with authorize.net to see if, for instance, they always send from the same IP address (or group of IP addresses). This is impossible to fake because the server has to know what IP address to converse with. If it's coming from the wrong IP address, log the information (just in case they do change their ip address) but don't mark the order as paid for until you manually check it out.

Just a couple of ideas here. My recommendation would be to use CURL to send the info and then parse the response.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@xxxxxxxxxxxxx
==================
.