| Note: This is the latest documentation. The previous version is available. |
This document provides an overview of the Google Checkout HTML API and explains the basics of how to integrate your website with Google Checkout. Many sections of this document, in turn, link to additional documentation that explains a specific Checkout feature or aspect of the HTML API in greater detail.
This document contains the following sections:
The Technical Overview explains the different components of the Google Checkout HTML API. This section also contains a technical discussion that explains how you manage and process Google Checkout orders. Finally, this section describes Google's policy for authorizing and charging customers' credit cards.
The API Reference section explains how to submit API requests to Google and also explains the responses that Google sends to an API request. In addition, this section explains how to use HTTP Basic Authentication to send certain types of API requests.
The Testing and QA section discusses different resources that can help you to test your Google Checkout integration, including credit card test cases that allow you to submit test orders that will return a specific type of Address Verification System (AVS) response or credit verification value.
Google provides a suite of APIs that enable you to integrate your website with Google Checkout.
The Notification API lets you integrate Google Checkout with your internal order processing systems by allowing those systems to automatically receive order information from Google. Google sends notifications to inform you of new orders or to send updates for existing orders. To implement this API, you must create a web service that receives notifications from Google and then relays the information in those requests to your internal systems.
The Order Processing API lets you integrate Google Checkout with your internal order processing systems by allowing those systems to automatically send updated order information to Google. The Order Processing API enables you to automatically update an order's financial state or its fulfillment state. For example, you can use this API to relay shipment tracking information for an order or to instruct Google to charge a customer for an order.
Receiving new order notifications
When a customer completes an order, Google will notify you that the new order has been submitted using one, or both, of the following mechanisms:
Google automatically sends email notifications for new orders to all merchants who have not implemented the Notification API.
If you have implemented the Notification API, Google will send a new-order-notification to inform you of the new order. The notification will
Even if you implement the Notification API, you can still receive email notifications by setting a preference in your Merchant Center account. To set this preference, log in to your account and click the Settings tab. Then click the Preferences link on the left side of the page and check the preference that says, "Email my customer support contact each time I receive an order, cancellation or other transaction."
Charging orders
After a customer submits an order, Google performs a risk assessment in an effort to avoid fraudulent charges. Google also authorizes the customer's credit card to ensure that it can be charged for the full amount of the order. There are several ways to charge a customer for an order.
You can click the Charge button next to the order in the Merchant Center.
You can instruct Google to automatically charge orders as soon as they become chargeable. The Credit Card Authorization and Capture section explains how to set this preference in your Google Checkout account.
If you have implemented the Notification and Order Processing APIs, your internal order processing systems can notify Google when an order should be charged. After the order is submitted, Google sends a new-order-notification, a risk-information-notification, and an order-state-change-notification to notify you of the order and to inform you when the order becomes chargeable. Each notification will specify the unique order number that Google assigned to the order.
At this point, you can send a charge-order command to tell Google to capture funds for the order. This command, which is part of the Order Processing API, uses the unique Google order number to identify the order to be charged.
After charging the order, Google will send you a charge-amount-notification to confirm that the charge was successfully executed.
When you charge an order, Google will update the buyer's purchase history page to indicate that the charge was executed. Other order status changes that you initiate through either the Merchant Center or through Order Processing API commands may also be reflected on the buyer's purchase history page.
Adding shipment tracking information
After shipping the order, you can add shipment tracking information that will appear on the buyer's account page. There are two ways to add shipment tracking information to an order:
Log in to your Merchant Center account and click on the order for which you want to add shipment tracking data. In the Shipping Information section of the page, select a carrier and enter a tracking number for the order shipment. Then click the Save button.
If you have implemented the Order Processing API, your internal systems can automatically send shipment tracking information directly to Google Checkout. Line-item shipping commands let you specify shipment tracking information on an item-by-item basis. You can also identify individual items in an order that are out-of-stock as well as items that have been canceled from an order or returned by the customer.
Marking orders as shipped
After you ship an order, you can log in to your Merchant Center account and click the Ship button next to the order. This action will mark the order as Shipped in the Merchant Center and on the buyer's account page.
If you have implemented the Order Processing API's line-item shipping commands, Google will automatically mark an order as shipped after you have sent API requests indicating that each item in the order has been shipped.
Archiving orders
After an order has been delivered, you can archive the order to remove it from the list of active orders that appears in the Merchant Center. (This step is optional; you do not need to archive orders.) There are two ways to archive an order:
Log in to your Merchant Center account and click the Archive button for the order.
If you have implemented the Order Processing API, you can send an archive-order command to Google.
This section illustrates the typical flow for a Google Checkout order. The order flow begins when the buyer clicks a Google Checkout button and ends when the buyer's order is delivered and the merchant archives the order. The diagram below is followed by a list of the order processing steps shown in the diagram. The list explains how each step is completed if you are using either the Merchant Center or the Notification and Order Processing APIs.
In the diagram, the green bar represents the merchant and the blue bar represents Google Checkout. The arrows between the bars identify the type of information that is being communicated during different stages of the order flow. All of these order updates are reflected in the Merchant Center. In addition, Google Checkout may send some types of information, such as new order notifications, via email. For merchants that have implemented an order processing integration, which includes implementation of the Notification and Order Processing APIs, arrows also represent messages that are exchanged between Google and the merchant.
There are also numerous alternate order flows, such as a failed credit card authorization or a need to cancel an order and refund the customer. Please see the Alternate Order Flow Diagrams document for more information about other common order flows.
Typical flow for Google Checkout orders:
Placing an Order
Your customer selects items and clicks the Google Checkout button on your site, sending the order information to Google Checkout.
Accepting an Order
The order appears in your Merchant Center inbox with a status of NEW. Google sends you an email to notify you of the order. If you have completed an order processing integration, Google sends a new order notification to inform your internal systems of the order. (You may not receive an email notification if you implemented the Notification API.)
Google conducts a risk assessment of the order to ensure that the customer is making a valid credit card purchase. The order status in the Merchant Center updates to REVIEWING. After Google completes its risk assessment, the Merchant Center will indicate whether the order is eligible for Google's Payment Guarantee Policy. If you have completed an order processing integration, Google also sends a risk information notification to inform your internal systems of the risk associated with the order.
Google authorizes the customer's credit card to be charged for the order. The Merchant Center inbox reflects this action by allowing you to charge the customer. If you have completed an order processing integration, Google also sends an order state change notification to inform your internal systems that the order is chargeable.
Charging an Order
You charge the customer for the order. You can charge the customer by clicking the Charge button next to the order in the Merchant Center. If you have completed an order processing integration, you can also send a charge-order request to Google Checkout.
Google begins charging the customer. In the Merchant Center, the Charge button will update so that it is not clickable. The order status will also update to Charging. You cannot execute any actions on an order while it is being charged. If you have completed an order processing integration, Google also sends an order state change notification to inform your internal systems that the order is being charged.
Google completes the charge. In the Merchant Center, the order history updates to indicate that the customer has been charged and reflects the amount of the charge. If you have completed an order processing integration, Google sends two notifications about the charge. First, it sends an order state change notification to inform your internal systems that the customer has been charged. It also sends a charge amount notification to inform your internal systems of the amount of the charge.
Shipping an Order
You ship the order to the customer. In the Merchant Center, you can click the Ship button that displays next to the order to update the order's fulfillment status to DELIVERED. You can also click on the order and enter shipment tracking information. If you enter shipment tracking information, Google will update the customer's account so that the customer can track the order shipment.
If you have completed an order processing integration, you can use Order Processing API commands to notify Google that the items in the order have been shipped and to provide shipment tracking information. After you have indicated that all of the items in the order have shipped, Google will update the order's fulfillment status to DELIVERED. At that point, Google will send an order state change notification confirming the status change.
After the order has been delivered, you can archive the order in the Merchant Center by clicking the Archive this Order button, as shown in the following image. When you archive an order, the order will display in your list of archived orders in the Merchant Center rather than in the inbox. If you have completed an order processing integration, you can also send an archive-order request to Google.
When a customer places an order, the new order will appear in your Inbox in your Merchant Center account with the REVIEWING status. As long as the order's status is REVIEWING, you will not be able to charge the customer for the order. During this time, Google Checkout will authorize the customer's credit card for the amount of the purchase and run risk checks to protect you from potentially fraudulent purchases.
After the payment has been authorized, the order's status will update from REVIEWING to CHARGEABLE. You can then charge the customer for any amount up to the authorized amount. You can charge the customer in the Merchant Center by clicking the CHARGE button that appears next to the order. If you have implemented the Order Processing API, your internal systems can programmatically send the charge request to Google. You can continue charging an order until all authorized funds have been captured.
You can also instruct Google Checkout to automatically charge orders as soon as they become chargeable. To activate this feature, log in to your Google Checkout account and click on the Settings tab. Then click the Preferences link in the menu on the left side of the page. Under the Order processing preferences header on the Preferences page, check the option for the auto-charging feature.
Note: You should not ship the ordered items to the customer until the order's status has updated to CHARGEABLE.
If a credit card authorization fails, Google will email the buyer to request updated credit card information or a new credit card. If the buyer updates her credit card information, Google will try to authorize that card. However, if the buyer does not supply a new credit card within seven days – 168 hours – after the email is sent, Google will cancel the order. Google will email you to notify you of canceled orders.
The following sections provide general details about the information that you will send to and receive from Google Checkout. These sections explain the following information:
The names for the input parameters used in the HTML API correlate very closely to the names of the elements in the Google Checkout XML schema. The list below specifies key characteristics of HTML API requests and field names:
Each API request contains the _type field, which specifies the type of API request being submitted. For example, in a Checkout (Shopping Cart) API request, the value of the type field is checkout-shopping-cart. In the XML API, the <checkout-shopping-cart> tag is the root tag in a Checkout API request.
Similarly, for any other API request, the value of the _type field equals the name of the root XML tag used to execute the same request in the XML API. For example, the root XML tag for a risk information notification is <risk-information-notification>. As such, the value of the _type parameter would be risk-information-notification.
The HTML parameter name for an element in the XML schema reflects the path to that element in a tree representation of the XML schema. The name is constructed using the following conventions:
Combine the names of the elements in the path to create the parameter name for an element. The parameter name begins with the first element below the root tag, which is identified separately using the _type parameter, and element names are separated using periods (.). For example, the continue-shopping-url field appears in a Checkout API request. In an XML API request, this value appears in the following context:
|
<checkout-shopping-cart>
<checkout-flow-support>
<merchant-checkout-flow-support>
...
<request-buyer-phone-number>true</request-buyer-phone-number>
...
</merchant-checkout-flow-support>
</checkout-flow-support>
</checkout-shopping-cart>
In an HTML API request, the field uses the following format:
checkout-flow-support.merchant-checkout-flow-support.request-buyer-phone-number=true
Some XML elements can recur in a normal request. For example, an order may contain more than one item, and you might charge tax in more than one state.
To represent a recurring XML element in an HTML parameter name, you must associate an index number with that element in the HTML parameter name. For example, the following example shows HTML parameters for two items. The XML schema allows the <item> tag to recur in an API request. As such, in an HTML parameter name, you must append -# to the element name item, replacing the pound (#) symbol with the item's index number in the list. Please use the number 1 to identify the first item in a list. The following fields demonstrate how you would provide the name and description for two different items in an HTML API request:
_type=checkout-shopping-cart &shopping-cart.items.item-1.item-name=Peanut%20Butter &shopping-cart.items.item-2.item-name=Strawberry%20Jelly &shopping-cart.items.item-1.item-description=Made%20from%20peanuts &shopping-cart.items.item-2.item-description=Made%20from%20strawberries
When you sign up with Google Checkout, Google assigns you a unique identifier called a Merchant ID. Getting Started with Google Checkout (step 3) explains how to locate this value. Your Merchant ID is included in the URLs to which you send Google Checkout API requests.
The following URLs are used for Checkout API requests. The first URL is for requests from your test environment and the second URL is for requests from your production site. In the first URL, you must replace the MERCHANT_ID string with the Merchant ID for your Sandbox account. You must replace the same string in the second URL with the Merchant ID for your Google Checkout merchant account.
https://sandbox.google.com/checkout/api/checkout/v2/checkoutForm/Merchant/MERCHANT_ID https://checkout.google.com/api/checkout/v2/checkoutForm/Merchant/MERCHANT_ID
The following URLs are used for Order Processing API requests. Again, you must replace the MERCHANT_ID string with the appropriate value.
https://sandbox.google.com/checkout/api/checkout/v2/requestForm/Merchant/MERCHANT_ID https://checkout.google.com/api/checkout/v2/requestForm/Merchant/MERCHANT_ID
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 and Order Processing API requests.
Please note that Google also uses HTTP Basic Authentication to send Notification 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.
Create a properly formatted HTML file for the command being executed.
Follow these steps to create the HTTPS header for your request:
Create the Authorization header for your request.
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.)
Base64-encode the value you produced in the previous step to generate your authorization key.
Provide the Authorization header for your request using the following format. Replace the text Authorization_Key in this header with your authorization key:
Include the Content-Type header with the value application/xml; charset=UTF-8
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:
Post the HTML structure created in step 1 to Google Checkout. This URL is constructed using your Google-assigned Merchant ID.
Note: You must replace the string MERCHANT_ID with your Google Checkout Merchant ID.
You must also secure Notification and Order Processing API requests with an SSL certificate. The Implementing the Notification API document and the Order Processing API section of this document provide more information about that requirement.
Google Checkout provides a diagnostic feature that lets you verify that Checkout and Order Processing API requests are valid without actually submitting those requests. To use this feature, construct the HTML for the API request and then submit it to Google Checkout's validator by appending /diagnose to the submission URL.
For Checkout API requests, use the following URLs. 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/api/checkout/v2/checkoutForm/Merchant/MERCHANT_ID/diagnose https://checkout.google.com/api/checkout/v2/checkoutForm/Merchant/MERCHANT_ID/diagnose
For Order Processing API commands, use the following URLs:
https://sandbox.google.com/checkout/api/checkout/v2/requestForm/Merchant/MERCHANT_ID/diagnose https://checkout.google.com/api/checkout/v2/requestForm/Merchant/MERCHANT_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:MERCHANT_KEY@checkout.google.com/api/checkout/v2/request/Merchant/MERCHANT_ID/diagnose
The sample file below shows how to format a file that you will post to Google using curl or a similar application. This file simulates a form-based request. The file shows a series of name=value pairs. Each name=value pair after the first pair is preceded by an ampersand. The name=value pairs could all appear on the same line or each could be printed on its own line as shown in the sample.
item_name_1=Dog%20Food &item_description_1=Yummy%20bacon%20flavor &item_quantity_1=1 &item_price_1=10 &item_currency_1=USD
You could also write a script to submit a diagnosis request that simulates a server-to-server Checkout API request. For example, the Perl script below posts a series of name=value pairs to Google Checkout and then evaluates the response to determine whether the request was valid.
#!/usr/bin/perl -w
use LWP::UserAgent;
my $lwp = LWP::UserAgent->new;
my $id = "1234567890"; # Replace 1234567890 with your merchant ID
my $url = "https://checkout.google.com/api/checkout/v2/checkoutForm/Merchant/$id/diagnose";
my $response = $lwp->post($url, [[]'item_name_1' => 'Dog Food',
'item_description_1' => 'Yummy bacon flavor',
'item_quantity_1' => '1',
'item_price_1' => '10',
'item_currency_1' => 'USD']);
if ($response->is_success) {
print "This request is valid.";
} else {
my @error_array = split(/&/, $response->content);
foreach my $parameter (@error_array) {
my @name_value = split(/=/, $parameter);
print "Name: " . $name_value[[]0] . ", value:" . $name_value[[]1] . "\n";
}
}
Google Checkout returns an immediate response to server-to-server API requests that you post to Google, including server-to-server Checkout API requests, Order Processing API requests and diagnostic requests. The immediate response indicates whether your HTML request is valid. A valid request must conform with the Google Checkout HTML 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:
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.
If you sent a valid Order Processing API request, Google will return a request-received response. Please note that this message only indicates that your request is valid. It does not indicate that your request has been successfully processed. The following HTML shows a sample request-received response:
_type=request-received &serial-number=c821326e-7caa-4d51-9b2e-48ef7ecd6423
If you sent a valid diagnostic request, Google will return a diagnosis response. This response indicates that the API request contained valid HTML 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 HTML shows the format of a diagnosis response. Please note that the response will contain HTML parameters that return the information submitted in your diagnostic request. The example below shows the diagnosis response for a charge-order request. Each parameter from the original request is preceded by request.charge-order.
_type=diagnosis &serial-number=c821326e-7caa-4d51-9b2e-48ef7ecd6423 &request.charge-order.amount=5.51 &request.charge-order.amount.currency=USD
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 HTML request would return an error:
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.
Invalid state change errors occur when an order processing command cannot be executed on the order in its current state. For example, you must issue a refund-order request before you can issue a cancel-order request.
The following HTML shows a sample error response:
_type=error &serial-number=c821326e-7caa-4d51-9b2e-48ef7ecd6423 &error-message=Bad%20username%20or%20password%20for%20API%20Access.
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, log 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.
Note: The Notification API and Order Processing API sections of this document are only relevant for merchants that are completing order processing integrations. Order processing integrations allow merchants to integrate Google Checkout with internal order processing systems. If you are not implementing these APIs, please go to the Google Checkout Merchant Center page.
Google Checkout uses the Notification API to inform you of a new order or to send you information about an existing order. The Notification API lets you integrate Google Checkout with your internal order fulfillment systems by allowing those systems to receive order information from Google. Typically, merchants choose to simultaneously integrate the Notification API and the Order Processing API, which allows you to send Google updated information about an order's financial state or its fulfillment state.
Each Google Checkout notification is a series of name=value pairs that Google sends in an HTTP POST request. To implement the Notification API, you must build and operate a web service that receives Google Checkout notifications and then communicates the details of those notifications to your internal order processing systems.
The following list identifies the different types of notifications that the API supports. Each item in the list links to a section that describes the notification and provides a sample notification.
New Order Notifications inform you of new orders that have been submitted through Google Checkout.
Risk Information Notifications provide financial information about a transaction to help you ensure that an order is not fraudulent.
Order State Change Notifications signal an update to an order's financial status or its fulfillment status.
Amount Notifications inform you that a charge, refund, chargeback or credit card authorization has been processed for an order. These notifications also identify the amount of the transaction.
The Notification API is described in full detail in a separate document titled Implementing the Notification API. That document explains how to authenticate API requests so that you can ensure those requests are valid before you process them. It also explains how Google will interpret your HTTP response to each notification to determine whether you handled the notification successfully. That document proceeds to describe each of the different types of notifications and includes a sample for each notification type.
Note: This section is only relevant for merchants who are integrating Google Checkout with their internal order processing systems. If you are not implementing the Notification API or the Order Processing API, please go to the Google Checkout Merchant Center page.
Each Google Checkout order has a financial-order-state and a fulfillment-order-state.
The financial order state identifies the stage of the payment process where the order is located. Valid financial states include CHARGEABLE, CHARGED and PAYMENT_DECLINED.
The fulfillment order state enables you to track orders through the fulfillment process and to convey the fulfillment status to the buyer. Valid fulfillment states are NEW, PROCESSING, DELIVERED and WILL_NOT_DELIVER.
The Order Processing API provides functions that enable you to change these states by integrating Google Checkout with your internal order processing systems. The Order Processing API defines three types of commands:
Financial commands enable you to authorize or perform credit card transactions for an order. Each of these commands affects an order's financial-order-state, which identifies the stage of the payment process where the order is located. The Order Processing API defines the following financial commands, all of which are explained in a separate document titled Financial Commands in the Order Processing API.
* The cancel-order command also changes an order's fulfillment order state.
Fulfillment commands let you communicate information about the stage of the fulfillment process where either an order or individual items within that order are located. You can use fulfillment commands to identify the items in an order that have shipped and to provide shipment tracking data for those items. If you specify a fulfillment state for each item in an order, then Google Checkout will use the statuses of those items to deduce the fulfillment state of the entire order. For example, if all of the items in an order have been shipped, then the order's fulfillment status will be DELIVERED.
The following lists identify the Order Processing API's fulfillment commands. The lists are separated to specify API commands used for either a line-item shipping API integration or an order-level shipping API integration. Two commands, add-merchant-order-number and send-buyer-message, are equally relevant to both integration methods and appear in both lists.
Google recommends that you integrate using the line-item shipping commands since these provide a better buyer experience. However, since these commands were introduced in August 2007, many merchants have already integrated using order-level shipping commands. Google Checkout will continue to support order-level shipping commands indefinitely.
Line-item shipping commands allow you to specify shipment tracking information on an item-by-item basis. Using line-item shipping commands, you can specify multiple shipments for an order and identify the items included in each shipment. Line-item shipping commands also let you identify individual items in an order that are out-of-stock as well as items that have been canceled from an order or returned by the customer.
The Order Processing API defines the following line-item shipping commands, all of which are explained in a separate document titled HTML API Commands for Line-Item Shipping.
Order-level shipping commands let you provide shipment tracking information that applies to all of the items in an order. You can also use order-level commands to mark an entire order as delivered or canceled. For each order-level shipping command, you can use an line-item shipping command that provides the same functionality.
The Order Processing API defines the following order-level shipping commands, all of which are explained in a separate document titled HTML API Commands for Order-Level Shipping.
* As noted above, the cancel-order command also changes an order's financial order state.
Note: Google recommends that you use line-item shipping commands rather than order-level shipping commands because line-item commmands provide a better buyer experience. Line-item shipping commands also allow you to more easily track orders that have multiple shipments as well as returned, canceled or backordered items.
Archiving commands enable you to manage the list of orders in your Merchant Center inbox. Archiving commands do not have any impact on an order's status or on the order information that is communicated to the customer.
The Order Processing API defines the following archiving commands, both of which are explained in a separate document titled HTML API Commands for Archiving Orders.
Merchants who use the Order Processing API can also still use the Merchant Center to trigger order state changes. For example, you could use the Order Processing API for common events, such as charging orders, and the Merchant Center for unusual events like initiating a refund.
Order Processing API requests must meet the following requirements:
We also strongly recommend that you verify the authenticity of the server certificate that is presented to you when you make the HTTPS connection with Google. Please verify the items in the checklist below before sending any data or doing HTTP Basic Authentication.
This section describes several techniques that you can use to test your integration and to troubleshoot problems that you encounter. This section reviews Google Checkout tools discussed earlier in this document and also introduces other tools that you can use for testing and troubleshooting.
The Integration Issues console in the Merchant Center identifies the errors and warnings generated by API requests that you have sent to Google Checkout. Errors and warnings appear in the console as they occur, enabling you to debug errors as they occur.
Google Checkout provides a diagnostic feature that lets you validate Checkout and Order Processing API requests without actually submitting them. The Validating API Requests section explains how to use this feature.
You can perform basic experiments with the Google Checkout API using curl, an open-source tool for communicating with servers that use HTTP and other protocols. The Getting Started with Google Checkout section – see step 4 – explains how to use curl to ensure that your server can communicate with Google Checkout.
You can also use curl to test other API requests. The Validating API Requests section explains how to save an API request in a file and then use the @ option in curl to post the contents of that file to Google. When you submit a request, you will see Google Checkout's immediate response to that request. If you test server-to-server Checkout API requests, the response will contain a redirect URL that you can follow to see the order in your browser.
For more information about curl, see http://curl.haxx.se/.
The demo-failure request enables you to test your application's ability to handle error messages from Google Checkout. Google returns an error response for any demo-failure request. The response's error-message parameter element contains the text you provided in the message parameter.
The following HTML shows a sample demo-failure request:
POST https://checkout.google.com/api/checkout/v2/requestForm/Merchant/MERCHANT_ID/diagnose
_type=demo-failure
&message=Return%20an%20error%20response
This request yields the following error response:
_type=form-diagnosis &request.demo-failure.message=Return+an+error+response &serial-number=21cc0488-3afb-4fda-83f2-369658100013
Google Checkout provides a testing feature for the sandbox environment that enables you to submit an order that will return a specific type of Address Verification System (AVS) response or credit verification value. The feature also lets you specify that Google Checkout should send an order state change notification indicating that the credit card for a sandbox order was either authorized or rejected. This feature is described in the Google Checkout Credit Card Test Cases document.
The Integration Issues console in the Merchant Center will display error and warning messages from the previous seven-day period. If there are more than 1000 errors and warnings from the previous seven days, only the most recent 1000 messages will be accessible.
We recommend you check the console frequently while you are integrating Google Checkout into your website. After launching your Google Checkout integration, you should check the console periodically to ensure that your integration is working as you expect.
To locate the Integration Issues console, log in to your Merchant Center account and click the Tools tab. The console, which is shown in the diagram below, displays in the center of the page.
You can use the console to debug errors in your test environment or your production environment. To view errors in your test environment, log in to your Sandbox account. To view errors in your production environment, log in to your Google Checkout account.
Note: Google Checkout will only log errors for API requests that you send to a valid URL for posting API requests.
If you click on the description for an error or warning, you will be directed to a page that displays more information about the issue. That page will display the date and time that the issue occurred, the error or warning message that Google returned, the request that Google received and the response that Google returned. The screenshot below shows a sample Integration Issue Detail page:
