| Note: This is the latest documentation. This page has been separated from the previous version. |
This document provides an overview of the Google Checkout XML 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 XML API in greater detail.
This document contains the following sections:
The Technical Overview explains the different components of the Google Checkout XML API and discusses different Checkout integration options. 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. This section also describes a Google Checkout diagnostic feature that lets you verify that an API request contains valid XML. Finally, this section explains how to use HTTP Basic Authentication to send certain types of API requests.
The Notification API and Order Processing API sections provide specific details about these different Google Checkout APIs. Each of these sections links to one or more additional documents that contain instructions for implementing specific API features.
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.
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.
After completing your shopping cart integration, you also have the option of implementing the Notification and Order Processing APIs to further integrate Google Checkout with your website and internal order processing systems. Typically, merchants that integrate the Notification API and the Order Processing API will implement both APIs at the same time.
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 list the items in the order as well as other transaction details like the shipping method, shipping address and taxes for the order.
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. For example, the order illustrated in the diagram does not use the Merchant Calculations API. As such, one alternate order flow involves the merchant calculating taxes and shipping charges for an order after sending the order information to Google Checkout. Other alternate order flows include 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.
After a buyer confirms a new order, Google will attempt to authorize the buyer's credit card for the full order amount.
If the authorization succeeds and the order passes Google's risk checks, the order's financial order state will be updated to CHARGEABLE. At that time, you can charge the order for any amount up to the authorized amount. You can continue charging an order until all authorized funds have been captured. However, please note that there are two reasons that an authorization will become invalid:
Google Checkout credit card authorizations expire exactly seven days – 168 hours – after the time they are issued.
When you partially charge an order, the order's initial authorization becomes invalid even if its seven-day window has not expired. As such, any time an order has been partially charged, additional charges for the same order will not be authorized unless you request an explicit reauthorization.
If the authorization fails, Google will email the buyer to request a new credit card. If the buyer supplies a new credit card, 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.
Note: If an order's initial authorization becomes invalid, and you have implemented the Notification API and the Order Processing API, you can explicitly reauthorize an order to verify that the credit card charge for the order will be successful. This feature allows you to wait until items are available before charging customers for those items, providing a better experience for customers who preorder items or order out-of-stock items. Explicit reauthorizations also benefit merchants that have a policy of shipping an item before charging the customer for that item. By explicitly reauthorizing the customer's credit card, the merchant can ship an order with confidence that the ensuing credit card charge will be successful. For more information about this feature, see the discussion of the <authorize-order> Order Processing API command.
Merchants can 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.
When a customer places an order, the new order will appear in your Merchant Center Inbox. Initially, the Merchant Center will display a status of Reviewing for the order. This status indicates that Google Checkout is trying to authorize the buyer's credit card for the amount of the purchase. As long as the order's status is Reviewing, you will not be able to charge the buyer.
After authorizing the buyer's credit card, Google will update the order's status from Reviewing to New. You should not ship items to the customer until the order's status has updated to New. After that time, you will also have the option to charge the customer for the order. To charge the customer, click the Charge button that appears next to the order in your Merchant Center Inbox.
If you have implemented the Notification API and the Order Processing API, you can also use the <charge-order> command to instruct Google to charge the buyer. Please note that if you have implemented the Notification API, you should not ship items unless you have received the following three notifications for the corresponding order:
Buyers can ask for a refund or cancellation by clicking the Questions about this order link on their order history page. If the buyer requests a refund, Google will send you an email to notify you of the request. Note that this email does not start the refund or cancellation process. The link merely enables the buyer to inform you that he would like to cancel an order or receive a refund for an order.
The following sections provide general details about the XML messages that you will exchange with Google Checkout. These sections discuss guidelines for posting XML messages to Google, ensuring the security of your transactions and handling Google's responses to your API requests.
When you sign up with Google Checkout, Google assigns you a unique identifier called a Merchant ID. The 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 Order Processing API requests. Again, you must replace the MERCHANT_ID string with the appropriate value.
https://sandbox.google.com/checkout/api/checkout/v2/request/Merchant/MERCHANT_ID https://checkout.google.com/api/checkout/v2/request/Merchant/MERCHANT_ID
The following guidelines explain how to format XML documents that you send in Google Checkout API requests. Some of these guidelines apply specifically to XML elements that contain text strings, including URLs.
All XML messages between you and Google Checkout must use UTF-8 (Unicode) encoding. Specify UTF-8 encoding by including the following line at the start of each XML API request:
<?xml version="1.0" encoding="UTF-8"?>
To include the XML reserved characters &, <, and > in an XML element value, you must encode the characters as hexadecimal numeric character references. Note: This guideline also applies to URL parameters that are included in XML values.
The following table shows the numeric character references for these characters:
| Character | Hexadecimal character reference |
| & | & |
| < | < |
| > | > |
You can use all other UTF-8 characters directly.
Google will not render HTML tags that you include in XML element values. If you pass HTML tags, such as in the <item-name> and <item-description> elements, Google will remove the HTML tags and display the text without formatting.
Unless otherwise noted, string elements in Google Checkout are not limited to any particular length.
Time/date values use the ISO 8601 standard, which specifies time as an offset from UTC.
All money elements must have a currency attribute.
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 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 XML file for the command being executed. The Google Checkout XML schema defines an XML structure for each type of API request.
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 XML 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 Order Processing 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.
For server-to-server Checkout API requests, use the following URLs:
https://sandbox.google.com/checkout/api/checkout/v2/merchantCheckout/Merchant/MERCHANT_ID/diagnose https://checkout.google.com/api/checkout/v2/merchantCheckout/Merchant/MERCHANT_ID/diagnose
For Order Processing API commands, use the following URLs:
https://sandbox.google.com/checkout/api/checkout/v2/request/Merchant/MERCHANT_ID/diagnose https://checkout.google.com/api/checkout/v2/request/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
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 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:
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 XML shows a sample <request-received> response:
<?xml version="1.0" encoding="UTF-8"?> <request-received xmlns="http://checkout.google.com/schema/2" serial-number="58ea39d3-025b-4d52-a697-418f0be74bf9"/>
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.
<?xml version="1.0" encoding="UTF-8"?> <diagnosis xmlns="http://checkout.google.com/schema/2" serial-number="49ba18e3-016b-4c52-a697-159a3lk38bf9"> <input-xml> <charge-order google-order-number="552406916759246"> <amount currency="USD">5.51</amount> </charge-order> </input-xml> </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:
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, 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, 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 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. Each Google Checkout notification sent via this API is an XML document that constitutes the body of an HTTP POST request. The Notification API is one of two methods that Google Checkout offers for retrieving notifications. Depending on your needs, you might implement either or both of these methods:
The Notification API lets you integrate Google Checkout with your internal order fulfillment systems by allowing those systems to receive order information from Google. The API lets Google send you information about new orders or about updates to existing orders. To implement the Notification API, you must build and operate a callback service that listens for Google Checkout notifications and then communicates the details of those notifications to your internal order processing systems.
The Notification History API lets you retrieve notifications for a particular order or date range. If you have implemented the Notification API, Google will automatically send you new orders and updates as they occur. On the other hand, if you have implemented the Notification History API, you can retrieve notifications in a data-pull model.
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.
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 sample XML for that 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 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 XML 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 XML 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 XML 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 XML Messages to Google Checkout 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 XML Messages to Google Checkout 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> element contains the string "Failed as expected with:" followed by the text you provided in the message attribute of the <demo-failure> tag.
The following XML shows a sample <demo-failure> request:
<?xml version="1.0" encoding="UTF-8"?> <demo-failure xmlns="http://checkout.google.com/schema/2" message="test error handling"> </demo-failure>
This request yields the following <error> response:
<?xml version="1.0" encoding="UTF-8"?> <error xmlns="http://checkout.google.com/schema/2" serial-number="6dcd58ae-3411-4383-a4ee-9a38d7d4f0a8"> <error-message>Failed as expected with: test error handling</error-message> </error>
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 API 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:
