[madinchina]

Just waiting on the client for now, as I don't have his Auth.net login details. I'll keep you updated.

[madinchina]

Okay, so we changed the MD5 hash field in his auth.net account and on the module settings to an 11-letter keyword (as Auth.net's tech support suggested) instead of a full MD5 hash value. We also tried using an actual 128-bit MD5 hash, but no luck on either front. The module is still sending no CC data. I'm going to spend some time diving into to the module's PHP and OSC's checkout process PHP to see if I can't find out what's going on. Any suggestions or guidance would be great.

What's your MD5 setup like on your site? Are you using an actual MD5 hash in both fields (the osCommerce module setup and the auth.net account settings), a "keyword" in both fields, or are there two different values between fields? I'm pretty sure we had it set up correctly (which is why I'm going to explore some other areas), but I just want to make sure.

Thanks!

[madinchina]

So, I sent a support ticket to the client's web host, and it seems they tinkered around with something (even though they said they couldn't help any further). Whatever they did (I'm assuming they recompiled cURL or something), they partially fixed the problem. Then emailmaomao's (Vger's) version of the AIM module started giving me the following error code from Auth.net, instead of absolutely nothing from Auth.net as it was doing earlier today:

RESPONSE: 3,2,13,The merchant login ID or password is invalid or the account is inactive.

I realized that the version of the AIM module has the wrong production mode URL (https://test.authorize.net/gateway/transact.dll instead of 'https://secure.authorize.net/gateway/transact.dll), so I fixed that and now AIM is working again!

Thanks again for all your help. If you're still interested in the problem with the other AIM module (Ponce's version), let me know and we can work on it more, but it's not a big priority any more now that we have some form of AIM running on the site.

[hwkd]

RoninS14, on Feb 18 2008, 11:00 PM, said:

Okay, I've been researching this for a week and still haven't figured out why my authorize.net module isn't working. I haven't even been able to find a thread which was dedicated entirely to "setting up" the authorize.net module so I've been searching the hundred of threads relating to auth.net to find a solution to my problem.

Now depending on which authorize.net module I use, I get a different error.

I've tried vger's version march 18 and I get the "There has been an error processing your credit card".

I've tried ponce's version jan 11 2008 and I get the "There has been an error processing your credit card".

I've tried the default authorize.net version bundled in OSC and still no luck.

There appears to be a million threads about the many different errors and solutions for each. I've looked through just about all of the one's that I thought pertained to my problem and I still can't get it to work.

I have followed all instructions provided by each thread and each modules without success.

Some seem to have a easy time getting auth.net to work while others never seem to find a solution to their problems.

--------------------------------------------------
"There has been an error processing your credit card
Please try again and if problems persist, please try another payment method."

above is the error I am getting using ponce's version of AIM for authorize.net. which is the version that I would prefer to use. Now if I'm told to use a different version, then I will. But it seems that ponce's version is the newest of the greatest and I'd like to get it to work.


I am hosted with pair networks (the osc sponsor) running php5/mysql5. I have curl compiled on there so I know that this is not the problem. With ponce's version of the AIM module, I tried setting the curl field to "usr/bin/curl" and just "curl". I get the same results, error.

===In my settings for A.net (TESTMODE)

-I have enabled the following in " Upload Transaction File Format":

Email Customer: yes
Apply AVS Filter: no
Apply Card Code Filter: no
field separator: comma(,)
Field Encapsulation Character: blank

-In the "transaction version", I am using the 3.1 version

-In the "response/receive URL", I have the following:

URL
https://www.mydomain...out_process.php Default Receipt URL Edit
https://www.mydomain...out_process.php Default Relay Response URL Edit

-I did not touch

-In the "address verification service", I have the default values seclected.

-I've set my MD5hash and entered it in the "MD5hash" field in OSC's administration > modules > payment > Authorize.net Credit Card AIM

-I've enabled "password required mode"

-I've enabled "file uploads capabilities"

-I do not have weblink activated

-and I've entered my API and transkey into the proper fields of OSC's administration > modules > payment > Authorize.net Credit Card AIM


Am I missing something?

To all,

I know this is a dated post, but my understanding (according to authorize.net) is if you enable Password required, you cannot activate Weblink and that Relay/Response should be left blank.

Cordially,
Hank

[hwkd]

joshmorris5, on Jul 25 2008, 03:19 PM, said:

Ok... I got it to work. Hope this helps everybody.

Its not a problem with the script. Don't comment out the script. I was on the Live help with Authorize.net for a couple of hours now.

Thurns out you need to make sure that certain fields are not required for your authorization to go through.

Go to https://account.authorize.net

Click on the following:

Under "Account"
Click=> Settings
Click=>Payment Form
Click=>Form Fields

You should come to a page that looks like this. Fill it in with your personal settings similar to this.

Remember: **If you require it here, and you don't require it in OSCommerce account setup, your customers will recieve an error for those blank fields and payment will be impossible.**
With the line of code I put above, you can now require an invoice number.


-------------------------------------------------------------------------------------------------------------------------------------------
Payment-Form Fields

Field Name--------------------------------------View-------------Edit------------Required

Payment Information
Recurring Billing Transaction-----------------o-----------------o------------------o
Card Code------------------------------------------o-----------------o------------------o

Order Information
Invoice No---------------------------------------x------------------o------------------x
Description--------------------------------------x------------------o------------------x

Customer Billing Information
First Name--------------------------------------x------------------x------------------x
Last Name--------------------------------------x------------------x------------------x
Company---------------------------------------x------------------x------------------o
Address-----------------------------------------x------------------x------------------x
City----------------------------------------------x------------------x------------------x
State--------------------------------------------x------------------x------------------x
Zip Code----------------------------------------x------------------x------------------x
Country-----------------------------------------x------------------x------------------o
Phone-------------------------------------------x------------------x------------------o
Fax----------------------------------------------x------------------x------------------o
Email--------------------------------------------x------------------x------------------x
Customer ID-----------------------------------x------------------o------------------x

Shipping Information
First Name--------------------------------------x------------------x------------------x
Last Name--------------------------------------x------------------x------------------x
Company---------------------------------------x------------------x------------------o
Address-----------------------------------------x------------------x------------------x
City----------------------------------------------x------------------x------------------x
State--------------------------------------------x------------------x------------------x
Zip Code----------------------------------------x------------------x------------------x
Country-----------------------------------------x------------------x------------------o

Additional Information
Tax-----------------------------------------------o-----------------o------------------o
Freight-------------------------------------------o-----------------o------------------o
Duty----------------------------------------------o-----------------o------------------o
Tax Exempt--------------------------------------o-----------------o------------------o
PO Number--------------------------------------o-----------------o------------------o
-----------------------------------------------------------------------------------------------------------------------------------------------------------------

Let me know if this helps anybody.

Joshua Morris

Good day,

How do you discern what fields are set as required in osCommerce?

Cordially,
Hank

[hwkd]

joshmorris5, on Jul 25 2008, 12:56 PM, said:

For the record, I still don't have it working. I am close though. I got the response that the payment has been authorized and it is routing me to the proper page. However, I still haven't taken Authorize.net live because I still haven't seen any transactions on their site.

Well, here's the latest.

So I found that even though you are testing, you need to make the "Authorize.net Credit Card AIM" Live. Turns out that in the default settings for osc's authorizenet, "Test" means that you are submitting requests to https://test.authori...ay/transact.dll. This is the wrong gateway to send it to unless your API login starts with "cpdev" or "cnpdev". The server will return error 13 message (basically wrong username or password). The correct test server if your API login doesn't start with "cpdev" or "cnpdev" is the same as the live server: https://secure.autho...ay/transact.dll
For testing, you need to make sure that Authorize.net is in test mode.

To do this, log in to Administration.
In the left navigation click on Modules then Payment
In the center list, click on Authorize.net Credit Card AIM
On the right, you will see the settings. Set them as follows:


--------------------------------------------------------------------------------------------------------------------------------------------
Enable Authorize.net Credit Card AIM
Do you want to accept Authorize.net Credit Card AIM payments?

True *
False

Login ID xxxxxxxxxx
The login ID used for the Authorize.net service


Transaction Key xxxxxxxxxxx
Transaction key used for encrypting data


MD5 Hash xxxxxxxxxxxxxxxxxxxxxxx (same as in authorize.net settings)
The MD5 hash value to verify transactions with


Transaction Server
Perform transactions on the live or test server. The test server should only be used by developers with Authorize.net test accounts.

Live *
Test

Transaction Mode
Transaction mode used for processing orders

Live *
Test

Transaction Method
The processing method to use for each transaction.

Authorization
Capture *

Payment Zone (personal configuration)
If a zone is selected, only enable this payment method for that zone.



Set Order Status (personal configuration)
Set the status of orders made with this payment module to this value


Sort order of display. **Not necessary**(0=first in the list 99=last in the list)
Sort order of display. Lowest is displayed first.


cURL Program Location
The location to the cURL program application.
--------------------------------------------------------------------------------------------------------------------------------------------------


After these settings were correct, I was at least getting Authorize.net to correctly identify me, but I was still getting errors. The error I was getting was that it wasn't sending an invoice number. So I added some code.

You need to BACKUP!! BACKUP!! BACKUP!! BACKUP!! then find a bit of code in catalog/includes/modules/payment/authorizenet_cc_aim.php that looks like this:

function before_process() {
global $HTTP_POST_VARS, $customer_id, $order, $sendto, $currency;

$params = array('x_login' => substr(MODULE_PAYMENT_AUTHORIZENET_CC_AIM_LOGIN_ID, 0, 20),
'x_tran_key' => substr(MODULE_PAYMENT_AUTHORIZENET_CC_AIM_TRANSACTION_KEY, 0, 16),
'x_version' => '3.1',
'x_delim_data' => 'TRUE',
'x_delim_char' => ',',
'x_encap_char' => '"',
'x_relay_response' => 'FALSE',
'x_first_name' => substr($order->billing['firstname'], 0, 50),
'x_last_name' => substr($order->billing['lastname'], 0, 50),
'x_company' => substr($order->billing['company'], 0, 50),
'x_address' => substr($order->billing['street_address'], 0, 60),
'x_city' => substr($order->billing['city'], 0, 40),
'x_state' => substr($order->billing['state'], 0, 40),
'x_zip' => substr($order->billing['postcode'], 0, 20),
'x_country' => substr($order->billing['country']['title'], 0, 60),
'x_phone' => substr($order->customer['telephone'], 0, 25),
'x_cust_id' => substr($customer_id, 0, 20),
'x_customer_ip' => tep_get_ip_address(),
'x_email' => substr($order->customer['email_address'], 0, 255),
'x_description' => substr(STORE_NAME, 0, 255),
'x_amount' => substr($this->format_raw($order->info['total']), 0, 15),
'x_currency_code' => substr($currency, 0, 3),
'x_method' => 'CC',
'x_type' =>

And Replace it with this:

function before_process() {
global $HTTP_POST_VARS, $customer_id, $invoice_id, $order, $sendto, $currency;

$next_inv = '';
$inv_id = tep_db_query("select orders_id from " . TABLE_ORDERS . " order by orders_id DESC limit 1");
$last_inv = tep_db_fetch_array($inv_id);
$next_inv = $last_inv['orders_id']+1;

$params = array('x_login' => substr(MODULE_PAYMENT_AUTHORIZENET_CC_AIM_LOGIN_ID, 0, 20),
'x_tran_key' => substr(MODULE_PAYMENT_AUTHORIZENET_CC_AIM_TRANSACTION_KEY, 0, 16),
'x_version' => '3.1',
'x_delim_data' => 'TRUE',
'x_delim_char' => ',',
'x_encap_char' => '"',
'x_relay_response' => 'FALSE',
'x_invoice_num' => substr($next_inv, 0, 20),
'x_first_name' => substr($order->billing['firstname'], 0, 50),
'x_last_name' => substr($order->billing['lastname'], 0, 50),
'x_company' => substr($order->billing['company'], 0, 50),
'x_address' => substr($order->billing['street_address'], 0, 60),
'x_city' => substr($order->billing['city'], 0, 40),
'x_state' => substr($order->billing['state'], 0, 40),
'x_zip' => substr($order->billing['postcode'], 0, 20),
'x_country' => substr($order->billing['country']['title'], 0, 60),
'x_phone' => substr($order->customer['telephone'], 0, 25),
'x_cust_id' => substr($customer_id, 0, 20),
'x_customer_ip' => tep_get_ip_address(),
'x_email' => substr($order->customer['email_address'], 0, 255),
'x_description' => substr(STORE_NAME, 0, 255),
'x_amount' => substr($this->format_raw($order->info['total']), 0, 15),
'x_currency_code' => substr($currency, 0, 3),
'x_method' => 'CC',
'x_type' =>


Now I am still having trouble with this script because it keeps requiring company. If you customers have a blank field where company is, then it will return a an error. I am still playing with it, but I think if you just comment out that line, it may just pass through without any errors. I realize that commenting it out isn't much of a solution, but if it posts transactions for the time being, I'm all for it.

Let me know if you guys can think of anything that might help.

Joshua Morris

Joshua and All,

The settings and URL solution before all the scripting stuff worked for me.

So, thanks.

I do not currently have any fields listed as required in the Merchant Interface with Authorize.net.

Cordially,
Hank

[adrenalynn]

Hi Joshua and All,

Whew. Fighting this waay to long. And dropping your logging code into place, I see a surprising result: The processor approved the transaction. The module just doesn't understand that.

Anyone that have this working care to share their Authnet settings? I've changed mine so many times even my documentation of what I've changed burst into flames and committed suicide (delimits, with/without pass, etc)

Some details:
- $Id: authorizenet_cc_aim.php 1803 2008-01-11 18:16:37Z hpdl $

- ID, Trans Key, Hash obviously correct (since it spits back an approved message)

Live, Live, Capture, No Zone, default Order Status, Sort #0, /usr/bin/curl [RH Enterprise 5/cpanel/dedicated/godaddy SSL-128]

Heavily Sanitized Log:

SENT: x_login=********&x_tran_key=****************&x_version=3.1&x_delim_data=TRUE&x_delim_char=%2C&x_encap_c
har=%22&x_relay_response=FALSE&x_invoice_num=10&x_first_name=*****&x_last_name=********&x_company=&x_address=
****+******+**&x_city=**+****+****&x_state=California&x_zip=*****&x_country=United+States&x_phone=******
*****&x_cust_id=2&x_customer_ip=**.***.3.27&x_email=*****%40*****.com&x_description=*********
s&x_amount=0.04&x_currency_code=USD&x_method=CC&x_type=AUTH_CAPTURE&x_card_num=4**************&x_exp_date=03
**&x_card_code=***&x_ship_to_first_name=*****&x_ship_to_last_name=*****&x_ship_to_company=&x_ship_to_addre
ss=****+****+****&x_ship_to_city=***+****+****&x_ship_to_state=California&x_ship_to_zip=*****&x_ship_to_
country=United+States&x_freight=0.01&x_line_item=1<|>Test+Product<|>Test+Product<|>1<|>0.03<|>NO
RESPONSE: "1","1","1","(TESTMODE) This transaction has been approved.","000000","P","0","10","*****
**","0.04","CC","auth_capture","2","**first**","**last**","","**address**","**city**","California
","**zip**","United States","**phone**","","**email**","**first**","**last**","","**address**","
**city**","California","**zip**","United States","","","0.0100","","","**my-hash-hex**"
,"","","","","","","","","","","","","","","","","","","","","","","","","","","","","",""
POST: cc_owner=**Full Name**
POST: cc_number_nh-dns=**CC Number**
POST: cc_expires_month=03
POST: cc_expires_year=**YY**
POST: cc_cvc_nh-dns=***CVC***
POST: x=78
POST: y=5
Done.

The funny thing is that if the processor returns a bad card number, I get an error message in the cart saying that it was declined. But if the processor approves it, I get the generic:
"There has been an error processing your credit card

Please try again and if problems persist, please try another payment method. "

Predictably, I'm really behind the 8-ball on this project. Any advice? I didn't get anywhere with the latest "$Id: authorizenet_aim.php 23rd August, 2006 18:50:00 Brent O'Keeffe $" module - not even this far...

TIA for *any* pointers (most especially for those that are "right" )

--- Jodie

hwkd, on Sep 12 2008, 08:09 AM, said:

Joshua and All,

The settings and URL solution before all the scripting stuff worked for me.

So, thanks.

I do not currently have any fields listed as required in the Merchant Interface with Authorize.net.

Cordially,
Hank

This post has been edited by adrenalynn: 19 September 2008 - 08:25 AM

[adrenalynn]

Sorry - doesn't appear that I can edit after n# of mins. . .

I put ANet into live mode and confirmed that it IS nailing the card for the amount, the transaction is going all the way through - the osc module is still returning failure. Funky, huh?

[adrenalynn]

adrenalynn, on Sep 19 2008, 01:41 AM, said:

Sorry - doesn't appear that I can edit after n# of mins. . .

I put ANet into live mode and confirmed that it IS nailing the card for the amount, the transaction is going all the way through - the osc module is still returning failure. Funky, huh?

Holy Crud-ole-le' - I think I figured it out. I started excessively logging everything that moved or even wiggled in the module's error handling. I noticed that my MD5 just didn't seem to match-up. I tried puttering with it and it was still not working.

Then it dawned on me that what was coming back from Authorize.net didn't LOOK like 128 bits of data (16 hex pairs). Turns out that Auth.net chops off the md5 data in the data input box at [drumroll] 80 bits (10 hex pairs).

Of course, when I generated my MD5, I just did an "echo secret |md5sum" giving me 128 bits, and blindly pasted it into the fields at both Auth.net and on OSC. I didn't bother to count the characters at Auth.Net, and it hides them after submit.

So, with little hope of success, I just took the 80 MSb (what Auth.Net was returning) and slapped it into OSC - submitted my data not really expecting any love, and BOOM. Checkout Success. [boggle]

I'll run a few more tests, but this feels right. Is it too late to go get drunk? "I think I picked the wrong week to stop sniffing glue!" - [Airplane]

Thanks all!

--- Jodie

[Agtronic]

That's GREAT news for you! I would definitely get drunk if I was you.

I'm still not getting mine to work. If I get a general error all the time, except when I put in a wrong CC number (where I get a CC declined error instead), I must be getting past the MD5 portion of the problem right? Meaning that this probably won't fix my problem?

This post has been edited by Agtronic: 20 September 2008 - 02:56 AM

[adrenalynn]

I was in the same place. I was logging the exchange and the Auth.net was giving a "transaction approved" response but OSC was failing it. When I gave it a bad number/date/etc. I was getting a "good" failure message instead of a generic failure. But on an approved transaction, OSC was giving the generic fail response.

Near as I can tell, OSC was cranky that the message didn't contain the correct hash. The module decided it was fake because the signature hash was invalid - if that makes sense.

It's worth looking into. If you put logging code in, look at the returned hash from Auth.net and compare it to what you have stored in the module configuration...

Good luck! Just as an FYI - I didn't have to change any code on the stock module (with a fairly stock cart). , [Comma] delimited, " [double-quote] encapsulated - as/per the modules code.

I haven't turned on AVS and CVC fraud check yet - probably tomorrow. We have about 800 more products to get into the catalog, and I still need to do some SEO work before we introduce it to Google and start the ad campaign.

Agtronic, on Sep 19 2008, 07:55 PM, said:

That's GREAT news for you! I would definitely get drunk if I was you.

I'm still not getting mine to work. If I get a general error all the time, except when I put in a wrong CC number (where I get a CC declined error instead), I must be getting past the MD5 portion of the problem right? Meaning that this probably won't fix my problem?

[geoffreywalton]

Hope you are not manually loading the products, the contribution Easy Populate will allow you to load them all from a csv file.

[adrenalynn]

geoffreywalton, on Sep 20 2008, 12:07 AM, said:

Hope you are not manually loading the products, the contribution Easy Populate will allow you to load them all from a csv file.

Oh sure - NOW you tell me!

I'm not sure how easily I could get all this data into a csv, but I'll check out that contribution, thanks!

I'm cheating a little bit. I have a few SQL snippets I whacked into a macro that I run a few times a day. No reason to manually set things like tax zones, product quantity, shipping weight, etc in our case. It's really a lot of cut-and-paste html at the end of the day. I was thinking about getting rid of the preview step temporarily and going straight to insert, then it'd be about even.

Thanks for the heads-up! I'll go download it and take a peek.

[Agtronic]

adrenalynn, on Sep 20 2008, 02:58 AM, said:

I was in the same place. I was logging the exchange and the Auth.net was giving a "transaction approved" response but OSC was failing it. When I gave it a bad number/date/etc. I was getting a "good" failure message instead of a generic failure. But on an approved transaction, OSC was giving the generic fail response.

Near as I can tell, OSC was cranky that the message didn't contain the correct hash. The module decided it was fake because the signature hash was invalid - if that makes sense.

It's worth looking into. If you put logging code in, look at the returned hash from Auth.net and compare it to what you have stored in the module configuration...

Good luck! Just as an FYI - I didn't have to change any code on the stock module (with a fairly stock cart). , [Comma] delimited, " [double-quote] encapsulated - as/per the modules code.

I haven't turned on AVS and CVC fraud check yet - probably tomorrow. We have about 800 more products to get into the catalog, and I still need to do some SEO work before we introduce it to Google and start the ad campaign.

Wow, light at the end of the tunnel!!!

Okay, this sounds exactly like my problem. But I'm not sure I understand what you did to solve it. You're saying that the MD5 hash that was being returned from Authorize.net was not the same as what the module expected? So where did you make the change for them to match?

Also, if I read correctly, your transactions were at least going through, where as mine do not appear to be, since there is no record of any activity on my Authorize account. I show zero transactions.

Thanks so much for continuing to participate on here, many people disappear once their problem is solved. Much appreciated!

This post has been edited by Agtronic: 21 September 2008 - 02:40 AM

[adrenalynn]

Hi Agtronic,

No worries! I've found quite a few answers to questions, and some *incredible* contributions, here (I just finished installing Header Tags SEO - WOW! Need to remember to go and virtually shake the author's hand on that one). Gotta pay it forward, right?

Have you put in something like Joshua's logging code or something similar? You really need to be able to see the transaction bidirectionally. I beefed the logging up in mine even more, but starting with Joshua's simple logging was probably all I needed, had I known what I was looking for without having to be hit in the head with a logging brick.

No guarantees that my solution is your solution ultimately until you can see the whole transaction. So many problems can masquerade to look identical when they're really not when you're doing EDI transactions like this...

If you post the content of the log that Joshua's code generates here, make SURE you completely sanitize it... It contains a lot of info you don't want to post.

Anyway - I looked at the MD5 in the hash being transmitted back from authnet and the MD5 in the admin control for the authnet module, and they didn't match. Without logging, I'd have never seen it.

I found that in test mode that authnet doesn't process all the transactions, and sometimes it takes more than one time through the unsettled before they show up. [shrug]

Make sure your other settings (like the Authnet side) are the same as in my post too!

Keep me/us posted?

--- Jodie

P.S. Quick note: The way I got them to match was by copying the one that Authnet was sending and pasting that into the admin control for the module and updating.

REMEMBER to remove/comment-out/whatever the logging when your issues are resolved, and before taking it live!

Agtronic, on Sep 20 2008, 07:38 PM, said:

Wow, light at the end of the tunnel!!!

Okay, this sounds exactly like my problem. But I'm not sure I understand what you did to solve it. You're saying that the MD5 hash that was being returned from Authorize.net was not the same as what the module expected? So where did you make the change for them to match?

Also, if I read correctly, your transactions were at least going through, where as mine do not appear to be, since there is no record of any activity on my Authorize account. I show zero transactions.

Thanks so much for continuing to participate on here, many people disappear once their problem is solved. Much appreciated!

This post has been edited by adrenalynn: 21 September 2008 - 10:54 AM

[Agtronic]

Hi Jodie Lynn,

This logging code you are referring to, is it contained in the block Joshua posted in post #25?

I'm sorry if this sounds basic, I'm not that bad in PHP, and am not too lazy to check for myself, just wondering before I plunged into it hard tomorrow. I'm just always in a rush with the business. I will sit down and take care of this problem tomorrow.

Thanks again for your enthusiastic help!

[adrenalynn]

Agtronic, on Sep 23 2008, 03:08 PM, said:

Hi Jodie Lynn,

This logging code you are referring to, is it contained in the block Joshua posted in post #25?

I'm sorry if this sounds basic, I'm not that bad in PHP, and am not too lazy to check for myself, just wondering before I plunged into it hard tomorrow. I'm just always in a rush with the business. I will sit down and take care of this problem tomorrow.

Thanks again for your enthusiastic help!

No problem! I understand - that's why I didn't respond yesterday too.

I was more thinking of what Joshua had in #30, I believe: http://forums.oscomm...o...t&p=1283835

'cause ya can't fix what ya can't see, right?

This post has been edited by adrenalynn: 24 September 2008 - 06:45 PM

[Agtronic]

Hey!

Well, that explains it!

"(TESTMODE) The supplied currency code is either invalid, not supported, not allowed for this merchant or doesn't have an exchange rate".

I will now try and figure out a solution. I'm in Canada and would really like to use CAD currency.

Thanks again for all your help! That little logging code did the trick! I might modify it to log just error codes and leave it behind the public_html tree.

Thanks again!!

[Agtronic]

Wow, just found out Authorize.net doesn't support CAD funds, and apparently is only available to US merchants. They sure didn't mention that when I setup the account and paid all the start up fees! :S

I switched my default currency over to USD and it worked first shot! I'm still not seeing the transaction on my Authorize.net account. Does it take a few hours to show up normally? (The auth.net account is in TEST mode currently).

Thanks guys!

[adrenalynn]

Agtronic, on Sep 25 2008, 02:48 PM, said:

Wow, just found out Authorize.net doesn't support CAD funds, and apparently is only available to US merchants. They sure didn't mention that when I setup the account and paid all the start up fees! :S

I switched my default currency over to USD and it worked first shot! I'm still not seeing the transaction on my Authorize.net account. Does it take a few hours to show up normally? (The auth.net account is in TEST mode currently).

Thanks guys!

Wow! That's a bummer on the one hand - good news on the other.

Make sure you're selecting "unsettled transactions" - but no, should show up right away if you're using the right report with the right date.