By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,987 Members | 997 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,987 IT Pros & Developers. It's quick & easy.

credit card reciept response

P: n/a
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.
Mar 1 '07 #1
Share this Question
Share on Google+
11 Replies


P: n/a
Michael Vilain wrote:
I setup credit card charging with a combination of php and perl. It's
running on a shared server, so I had to use a protected perl script with
the constants like passwords and hash keys in the script. The script is
run by CGIwrap under my account's UID rather than as the web server's
UID.

Perl seems to be suited to do SSL submissions to authorize.net, receive,
and process their reply. I had no problems getting it to work with
their excellent documentation. I didn't see away of getting PHP to do
it and the Perl CPAN modules to emulate a browser client worked without
problems.
Thanks for the input.
Yikes, hmmm, maybe I'll look at the perl documentation, nothing is
explained in the php sample coding. I know nothing about perl. Ugh.

PS I just ran it with the POST method enabled & no redirect occured.

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 to 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.

Mar 1 '07 #2

P: n/a
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.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 1 '07 #3

P: n/a
Michael Vilain wrote:
I setup credit card charging with a combination of php and perl. It's
running on a shared server, so I had to use a protected perl script with
the constants like passwords and hash keys in the script. The script is
run by CGIwrap under my account's UID rather than as the web server's
UID.

Perl seems to be suited to do SSL submissions to authorize.net, receive,
and process their reply. I had no problems getting it to work with
their excellent documentation. I didn't see away of getting PHP to do
it and the Perl CPAN modules to emulate a browser client worked without
problems.
In article <wB*****************@newssvr22.news.prodigy.net> ,
Paul Furman <paul-@-edgehill.netwrote:
>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.
CURL would have worked fine here.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 1 '07 #4

P: n/a
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.
Mar 1 '07 #5

P: n/a
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.
js*******@attglobal.net
==================
Mar 1 '07 #6

P: n/a
C.
On 1 Mar, 05:35, Michael Vilain <vil...@spamcop.netwrote:
I setup credit card charging with a combination of php and perl. It's
running on a shared server, so I had to use a protected perl script with
the constants like passwords and hash keys in the script. The script is
run by CGIwrap under my account's UID rather than as the web server's
UID.
I can't imagine what problem this sensibly solves. What is a
'protected' perl script? I assume you mean with different permissions
on ownership, and running under a different uid. If the POST is
initiated by the CC handler, then there's no need to store passwords
in order to receive it.
Perl seems to be suited to do SSL submissions to authorize.net, receive,
and process their reply.
Why?
Paul Furman <p...@-edgehill.netwrote:
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.
I can't imagine why a hosting company would not allow POST by default.
Why not test it for yourself - just write a form with a POST method
and fire it at your PHP script.
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
No, you need to validate the origin of the request. How do you know
this came from the CC handler? You should also be checking that its
'1' and not anything else. Also you might avoid some CSRF by checking
$_POST instead of $_REQUEST.
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.
That's exactly right - you don't want to let ANY server see an order.
You valid the remote host as the CC handler and tie the request back
to a session that the customer initiated. You make hard to predict the
token used to identify the order.

C.
Mar 1 '07 #7

P: n/a
C. 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.

I can't imagine why a hosting company would not allow POST by default.
Why not test it for yourself - just write a form with a POST method
and fire it at your PHP script.
>>>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

No, you need to validate the origin of the request. How do you know
this came from the CC handler? You should also be checking that its
'1' and not anything else. Also you might avoid some CSRF by checking
$_POST instead of $_REQUEST.
Yep, that was just the first step.
>>>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.

That's exactly right - you don't want to let ANY server see an order.
You valid the remote host as the CC handler and tie the request back
to a session that the customer initiated. You make hard to predict the
token used to identify the order.
I got it working (test mode so far) and really all it does is gather the
response code. The user & shopping cart info is already stored in
cookies so the script knows who's cart to confirm. I think I'm alright,
that's why I'm letting the CC server handle all the sensitive info. If
someone could hack into my system's login, they could get names &
addresses but not credit card numbers. Worst case is maybe they screw up
our inventory numbers but there's no money to be had on our server.

Well, I need to look at the fingerprint hash script, theoretically that
stuff could be used to hack the CC server. They suggest setting
permissions on the password data file to only respond to my script
though I'm not sure how to do that.
Mar 1 '07 #8

P: n/a
>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.

Mar 2 '07 #9

P: n/a
Thanks for the comments but I've solved it in a pretty simple way.
Interesting read though.
Here's my reply to 'C.' above:

I got it working (test mode so far) and really all it does is gather the
response code. The user & shopping cart info is already stored in
cookies so the script knows who's cart to confirm. I think I'm alright,
that's why I'm letting the CC server handle all the sensitive info. If
someone could hack into my system's login, they could get names &
addresses but not credit card numbers. Worst case is maybe they screw up
our inventory numbers but there's no money to be had on our server.

Well, I need to look at the fingerprint hash script, theoretically that
stuff could be used to hack the CC server. They suggest setting
permissions on the password data file to only respond to my script
though I'm not sure how to do that.

Gordon Burditt wrote:
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.
Ah this makes sense, something I'm familiar with... perhaps that's a way
to protect the password data file. The CC setup is pretty secure though,
they don't require us to encrypt or protect that, it is sent as a binary
hash thing (not sure how that works exactly):
(bin2hex (mhash(MHASH_MD5, $data, $key)))
etc.
Mar 2 '07 #10

P: n/a
Michael Vilain wrote:
In article <11**********************@31g2000cwt.googlegroups. com>,
"C." <co************@gmail.comwrote:
>On 1 Mar, 05:35, Michael Vilain <vil...@spamcop.netwrote:
>>I setup credit card charging with a combination of php and perl. It's
running on a shared server, so I had to use a protected perl script with
the constants like passwords and hash keys in the script. The script is
run by CGIwrap under my account's UID rather than as the web server's
UID.
I can't imagine what problem this sensibly solves. What is a
'protected' perl script? I assume you mean with different permissions
on ownership, and running under a different uid. If the POST is
initiated by the CC handler, then there's no need to store passwords
in order to receive it.

In the shared environment of my ISP, all the web pages must be readable
by the web server. In order for a file containing passwords etc. to be
protected from other users with shell access, I had to set permissions
to rwx------. The web server would not be able to "see" that page and
would report a "forbidden" return code if it were run as a web page. By
placing the perl script in my cgi-bin and setting it's permissions to
700, it could only be run by the ISP's CGIwrap package as my UID, thus
allowing it to be "seen" by the web browser.

http://cgiwrap.sourceforge.net/
>>Perl seems to be suited to do SSL submissions to authorize.net, receive,
and process their reply.
Why?

Not sure what you're asking here. All I can say is that the code to
open the SSL connection and send the payment info to authorize.net's
processor site was very straightforward (LWP::UserAgent CPAN module).
The result of the connection is the information returned as a binary
array. I just parse it and display the OK or credit card failure page
accordingly.

Of course, YMMV. I just couldn't see how to code PHP to connect to a
SSL web site, submit a POST request, and process the result. I'm sure
it could be done, but then I'd have to embed passwords which others
could read. If PHP were offered as a CGI scripting language, then I
would have tried it. But my ISP didn't offer that option.
You should have checked out CURL.

And no, if your webserver is set up properly, other users (with the
exception of sysadmins) would not be able to read your files - even
though the webserver could. Unlike Perl, PHP doesn't need to be set up
as a CGI for this level of security.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
js*******@attglobal.net
==================
Mar 2 '07 #11

P: n/a
As Jerry has said many times CURL is your friend. This is super easy
to do and plenty of PHP Auth.net Examples on the net. Just setup
Auth.net to responde with comma delimited values. Explode check for
success then store response and direct customer to Card Has been
charged page.

You should have checked out CURL.
Eric
Mar 7 '07 #12

This discussion thread is closed

Replies have been disabled for this discussion.