|
|
Posted by Gordon Burditt on 03/02/07 00:13
>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.
I suspect you want the POST string here. You get to know when it's
paid. (although the payment can still be challenged and reversed
later) Note that the POST will likely NOT have the customer's session
cookie in it. It's coming from the processor, not the customer.
>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 customers browser.
Here you accept the POST data, validate it, and mark the invoice
PAID if appropriate. Note you need to handle the case of its being
ALREADY paid (a replay attack, or customer fiddling with the BACK
button). Then you compose a response, which I suggest should be a
REDIRECT to your "transaction completed" page, which gets sent back
to the customer. DO NOT send any order details back to the payment
processor. Just send a redirect. When the customer's browser gets
to the transaction completed page, you will have the customer's
session cookie and login details available, and THEN you can print
out a confirmation of the order for the customer.
>x_response_code
>Indicates the result of the transaction:
> 1 = Approved
> 2 = Declined
> 3 = Error
Obviously, you're going to check this code before proceeding. You
may want to change the destination of the redirect depending on
this code (e.g. if declined, give them a chance to use a different
card).
>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.
Log this in the database if a payment is successful. You'll need
this if the transaction ever gets reversed (e.g. use of stolen card,
or customer cancelled order) to match up the transaction with the
order.
>x_invoice_num
>This is the merchant's supplied invoice number
This is part of your security, and your hook to figure out which
order is being paid. The "invoice number" you present to the payment
processor should be as long as it possibly can be, and consist of
the real invoice number plus some security info, say, a cryptographic
hash of data associated with the order and a secret string. Don't
present the full invoice number to the customer, either. I doubt
your payment processor will accept x_invoice_num as a 1024-character
alphanumeric string, but make it as hard to guess and as long as
possible. The invoice number you print on the customer's receipt
can be shorter and more managable by humans and might, for instance,
be the first few digits of the full number.
It also wouldn't be a bad idea that the page used by the payment
processor to POST to is restricted to a very small number of IP
addresses owned by the payment processor (e.g. Apache .htaccess).
Ask the payment processor about this.
If the "merchant's supplied invoice number" that you get back doesn't
match any invoice in the database, log a hacking attempt with as
much trace information as possible and don't mark anything paid
(you can't - it doesn't match any record).
>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
You really need to check that the payment SUCCEEDED, that the
merchant invoice number matches one in the database, that the POST
is coming from an IP of the payment processor, and that this order
hasn't ALREADY been paid before proceeding. You could, and probably
should at this point, update the inventory if everything is GO, but
DON'T send the details to the payment processor, and don't discover
errors to hand to the customer. Generate the receipt at the target
of the redirect. The customer might want multiple copies of the
receipt (his printer jammed or computer crashed) but not multiple
orders.
>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.
Don't let it retrieve order details. And use an invoice number that's
very hard to guess. And, if possible, limit the IP addresses this
POST can come from to a very small number.
>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.
Navigation:
[Reply to this message]
|