>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 customer’s 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.
