Posted by Jerry Stuckle on 03/01/07 20:11

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@attglobal.net
==================

[Back to original message]