Problems with Google checkout and digital downloads and Server to Server Communication

I am having Authentication problems with Google Checkout, and hence orders do not make it through
the Google Response handler properly. This is my configuration settings:

Zen Cart 1.38a ( New Install)
Using Custom as my own Template for any changes
I have added the Google Checkout Module Version 1.47
Server: Linux based with a CGI bin
No Local install is being used
PHP is version 5.25
My SQL Version is: 5.3 I believe
What you were doing when your problem occurred?
My SSL is from GeoTrust which shows up on Googles list of acceptable SSL's
My SSL version is the version they designate. (SSL V1.3)
Port 80 is open
Port 443 is being used for SSL per my host
Have you attempted to fix the problem?
What steps have you taken?
1) I have read numerous articles on how to set up the digital delivery methods in Zen cart and have it working perfectly in PayPal using the downloads folder and zip files.
2) I went through a very careful install of the Google checkout module, and am attempting a (Level 2) integration
3) Google Analytics seem to be working fine
4) I have a Merchant ID and Merchant Key
5) I have set the .htaccess use in the module to True since I have a CGI bin
6) I used the click here in that section to create the .htaccess file and password file
7) I left the absolute path alone in the dialog box (It was a strange path that started with Hermes/ etc)
8 ) I noticed that the .htaccess password created by the dialog box was using a Merchant ID and a portion of my Merchant Key, but not the whole key. I assumed it was a truncated value and would work. It did not.

I then read in Google Checkout that there is a requirement to Base 64 Encode the MerchantID and Merchant Key
and add them into what appears to be the header of the communication??????

What I am wondering is....Does anyone know if this is accomplished automatically in the Zen Cart Application as it passes the values to Google from the Merchant ID and Merchant Key Fields in the payment module????
and if so, then why am I still getting a basic authentication failure message?

If you do need to add the base 64 encoded values, should Merchant ID references in the Google Checkout Response Handlers be replaced with the actual base 64 encoded value???

If no, then should the .htaccess password be the proper place for the base encoded value?

Finally, does it mean that in the Google Checkout Module, you should not list your actual Merchant ID number but rather the Base Encoded 64 equivalent???? Is there any quick and easy conversion app for base encoding characters and numbers?

I am just wondering if someone has been down this path and can tell me what works???? Thanks
Better yet, has anyone gotten Digital Downloads to work in Google Checkout without having to uncheck the digitally signed cart check box?

Here is what Google has posted on Base 64 encoding:

Sending API Requests with HTTP Basic Authentication
The following instructions explain how to format HTTP request headers to use HTTP Basic Authentication. You will need to follow these steps to send server-to-server requests to Google, including server-to-server Checkout API requests or Merchant Calculations API responses.
Please note that Google also uses HTTP Basic Authentication to send Merchant Calculations API requests to you. As such, when you receive a notification from Google, you can base64-decode the authorization header to confirm that the notification is valid.
1. Create a properly formatted XML file for the command being executed. The Google Checkout XML schema defines an XML structure for each type of API request.
2. Follow these steps to create the HTTPS header for your request:
o Create the Authorization header for your request.
i. Append a colon to your Google Checkout Merchant ID. Then append your Google Checkout Merchant Key to this value. (The value has the format MERCHANT_ID:MERCHANT_KEY.)
ii. Base64-encode the value you produced in the previous step to generate your authorization key.
iii. Provide the Authorization header for your request using the following format. Replace the text Authorization_Key in this header with your authorization key:
Authorization: Basic Authorization_Key
o Include the Content-Type header with the value application/xml; charset=UTF-8
o Include the Accept header with the value application/xml; charset=UTF-8

For example, if your Merchant ID is 1234567890 and your Merchant Key is HsYXFoZfHAqyLcCRYeH8qQ,
you would base64-encode the value 1234567890:HsYXFoZfHAqyLcCRYeH8qQ.
The example below shows how the base64-encoded value would appear in your request header:
Authorization: Basic MTIzNDU2Nzg5MDpIc1lYRm9aZkhBcXlMY0NSWWVIOHFR
Content-Type: application/xml;charset=UTF-8
Accept: application/xml;charset=UTF-8
3. Post the XML structure created in step 1 to Google Checkout. This URL is constructed using your Google-assigned Merchant ID.
https://checkout.google.com/api/chec...nt/MERCHANT_ID
Note: You must replace the string MERCHANT_ID with your Google Checkout Merchant ID.
Validating XML Messages to Google Checkout
Google Checkout provides a diagnostic feature that lets you verify that Checkout API requests contain valid XML without actually submitting those requests. To use this feature, construct the XML for the API request and then submit it to Google Checkout's validator by appending /diagnose to the submission URL.
• Use the following URLs to validate Checkout API requests that do not use the server-to-server posting method. You must replace the MERCHANT_ID string in each URL with your Merchant ID. The first URL will contain the Merchant ID for your Sandbox account; the second URL will contain the Merchant ID for your Google Checkout merchant account.
• https://sandbox.google.com/checkout/...NT_ID/diagnose
• https://checkout.google.com/api/chec...NT_ID/diagnose
• For server-to-server Checkout API requests, use the following URLs:
• https://sandbox.google.com/checkout/...NT_ID/diagnose
• https://checkout.google.com/api/chec...NT_ID/diagnose
When you post a diagnostic message, Google parses the request and returns a <diagnosis> response, which indicates whether the API response contained any errors.
You can use curl to send diagnostic requests to Google. For example, you could save the API request in a file and then send it to Google using HTTP Basic Authentication with the following command. Please note that you must use the appropriate URL from the list above for your request. You must also replace the FILENAME, MERCHANT_ID and MERCHANT_KEY strings with the proper values.
curl -d '@FILENAME'
https://MERCHANT_ID:[email protected]_ID/diagnose
Immediate (Synchronous) Responses to Posts
Google Checkout returns an immediate response to server-to-server API requests that you post to Google, including server-to-server Checkout API requests requests and diagnostic requests. The immediate response indicates whether your XML request is valid. A valid request must conform with the Google Checkout XML schema and must also request a legitimate action. For example, a <charge-order> request that instructs Google to charge the customer for more than the total price of an order would be invalid even if it conformed to the Google Checkout XML schema.
• If your request is valid, Google returns one of three types of responses:
o If you sent a valid server-to-server Checkout API request, Google will return a <checkout-redirect> response. This response is described in step iv of the section that explains server-to-server Checkout API requests.
o If you sent a valid diagnostic request, Google will return a <diagnosis> response. This response indicates that the API request contained valid XML and that the request was sent to the proper diagnostic URL. For example, the URL would have to contain the correct Merchant ID. The following XML shows the format of a <diagnosis> response. Please note that the <input-xml> tag will contain the complete XML document that you sent to Google in your diagnostic request.
o <?xml version="1.0" encoding="UTF-8"?>
o <diagnosis xmlns="http://checkout.google.com/schema/2"
o serial-number="49ba18e3-016b-4c52-a697-159a3lk38bf9">
o <input-xml>
o <charge-order google-order-number="552406916759246">
o <amount currency="USD">5.51</amount>
o </charge-order>
o </input-xml>
o </diagnosis>
• If your request is not properly formed or requests an invalid status change, Google Checkout will return an <error> response to your request.
There are two types of reasons that a properly formed XML request would return an error:
o Invalid argument errors occur when a value in a request is not in the range of valid values. For example, requesting a refund for more than the total amount of an order would trigger an invalid argument error.
o Invalid state change errors occur when an order processing command cannot be executed on the order in its current state. For example, if you have already charged a customer for an order, you must issue a <refund-order> request before you can issue a <cancel-order> request.
The following XML shows a sample <error> response:
<?xml version="1.0" encoding="UTF-8"?>
<error xmlns="http://checkout.google.com/schema/2"
serial-number="3c394432-8270-411b-9239-98c2c499f87f">
<error-message>Bad username and/or password for API Access.</error-message>
</error>
To help you monitor and debug your Google Checkout implementation, the Merchant Center displays a list of error messages that Google Checkout returned in response to your API requests. To see this list, sign in to your Merchant Center account and click on the Settings tab. Then click on the Integration link in the menu on the left side of the page. The error log displays at the bottom of the Integration page. Learn more about the Integration Issues Console.