Google Checkout Integration

Purpose: The Google Checkout integration allows you to use Google Checkout as a checkout process on web orders, using Cardinal Commerce as a gateway between Google Checkout and CWDirect for inbound orders, credit card authorization, and deposit settlement. Google Checkout communicates with the service bureau to authorize and settle the customer’s payment information.

Google Checkout is a fast, convenient checkout process that allows customers to buy from your web storefront and pay for the purchase using their Google Checkout account.

Cardinal Commerce provides authentication services for banks, merchants, processors, and financial service providers. Cardinal Commerce is the gateway used during batch authorization and deposit processing to connect to Google Checkout in order to process Google Checkout payments.

The CWDirect Google Checkout integration allows you to use Google Checkout as a form of payment on web orders with Cardinal Commerce as the gateway service provider.

Note: You can only use Google Checkout as a form of payment on web orders. The CWDirect Google Checkout integration does not support Google Checkout as a form of payment on non-web orders.

In this topic: This chapter provides an overview of the CWDirect Google Checkout integration and the required setup.

• Google Checkout Integration Process

• Google Checkout Integration Process Flow

• Google Checkout Recovery Processing

• Google Checkout Integration Setup

Google Checkout Integration Process

Google Checkout Integration Illustration:

Google Checkout Integration Process Flow

The flow of web orders containing a Google Checkout payment method is as follows.

1. A customer places an order on the web storefront and selects Google Checkout when he is ready to pay for the order.

2. The web storefront sends a shopping cart message to Google Checkout via the Centinel Thin Client. The shopping cart message contains information about the products the customer has placed in his shopping cart that he is ready to buy.

3. Google Checkout receives the shopping cart message and verifies the customer’s shopping cart.

4. Google Checkout sends a verified shopping cart message back to the web storefront via the Centinel Thin Client. If the customer’s shopping cart could not be verified by Google Checkout, the web storefront will need to request another form of payment from the customer.

5. If the customer’s shopping cart has been verified by Google Checkout, the web storefront redirects the customer to the URL specified in the verified shopping cart message returned by Google Checkout.

6. The customer selects a shipping address and ship method in Google Checkout.

7. Google Checkout sends the customer’s shipment information to the web storefront via the Centinel Thin Client.

8. The Centinel Thin Client generates an inbound order message without payment information to send to CWDirect via Cardinal Commerce CWAdapt.

9. CWDirect receives the Inbound Order XML Message (CWORDERIN), calculates tax and shipping rates, and sends the Detailed Order XML Response (CWORDEROUT) to the web storefront via CWAdapt.

10. Google Checkout receives the order response message and the customer completes the order checkout process.

11. If processing payments on the web storefront, Google Checkout processes payment authorizations and sends the authorization response to CWAdapt.

12. CWAdapt generates an inbound order message, including the payment information, to send to CWDirect. The Google Checkout 16 digit Mod 10 transaction ID is passed in the cc_number tag.

Authorized Google Checkout payments: If the Google Checkout payment on the web order has already been authorized by the service bureau, the inbound order message contains the following information:

• regular order information

• Google Checkout pay type in the payment_type tag.

• Google Order ID passed in the order_number tag.

• Google Coupon ID, if any, passed in the source_code tag.

• Google Checkout 16 digit Mod 10 transaction ID passed in the cc_number tag.

• Google Checkout 16 digit Mod 10 transaction ID passed in the auth_number tag.

• Authorization date in the auth_date tag (the date the Google Checkout payment was authorized by the service bureau).

Unauthorized Google Checkout payments: If the Google Checkout payment was created on the web order, but not yet authorized by Google, the CWOrderIn message contains the following information:

• regular order information

• Google Checkout pay type in the payment_type tag.

• Google Order ID passed in the order_number tag.

• Google Coupon ID, if any, passed in the source_code tag.

• Google Checkout 16 digit Mod 10 transaction ID passed in the cc_number tag.

The authorization number and authorization date will remain blank so that the order can be authorized during pick slip generation.

13. CWDirect processes the web order.

• If the authorization date for the Google Checkout payment has not expired when a pick slip is processed for the order, the system generates a pick ticket and follows normal order processing.

• If the authorization date for the Google Checkout payment has expired, or the Google Checkout payment has never been authorized, the system sends the Google Checkout payment for authorization to Cardinal CWAdapt before generating a pick slip. The Google Checkout transaction ID is passed in the batch authorization request in the ccAccountNumber tag. CWAdapt sends an authorization response back to CWDirect based on predefined Google Checkout rules.

14. CWDirect fulfills and ships the order and sends the deposit request to CWAdapt.

15. CWAdapt receives the deposit request and sends the information to Google Checkout for billing.

16. Google Checkout bills the order and sends a confirmation message back to CWAdapt.

17. CWAdapt sends the deposit response to CWDirect.

Returns against a Google Checkout pay type: Returns processed against a Google Checkout pay type cannot be greater than the original deposit amount.

Restrictions: The CWDirect Google Checkout integration does not support:

• Online authorizations for orders entered in CWDirect.

• Batch authorizations for orders entered in CWDirect.

• Reauthorization of orders entered in CWDirect.

• Additions to orders through Order Maintenance that have been previously processed via the web storefront through Google Checkout and exceed the original order amount.

• Alias items.

• Promotions are not applied in CWDirect; final order amount are passed from CWAdapt. You can include a dummy non-inventory item for a negative dollar amount on the order to apply promotions to the order; see Promotions.

• Exchanges are not supported if there is a charge for the exchanged item. In this situation, you will need to create a separate order for the new charge with a customer payment.

• Multiple ship to orders.

• Gift card payments.

Google Checkout Recovery Processing

Use the following steps in the event the authorization transaction or deposit transaction sent from CWDirect to Cardinal Commerce fails to complete.

• Recovery Processing for Batch Authorization Transactions

• Recovery Processing for Batch Deposit Transactions

Note: Before running Receive/Process Authorizations using the Reprocess Authorizations Screen (RPAA) or Receiving Deposits using the Processing Auto Deposits (SDEP) menu option, you must make sure the transaction records in the CC Authorization Transaction (CCAT00) file or CC Deposit Transaction (CCDP00) file are in a *SENT status in order to receive the response transactions from Cardinal Commerce successfully. If the records are in a *RDY status when you resubmit the transaction, Cardinal Commerce will decline the transaction.

Recovery Processing for Batch Authorization Transactions

Scenario	Solution
Authorization response messages are waiting to be sent by Cardinal Commerce and the PICK_GEN job is in a MSGW wait status. The authorization request messages for the transaction exist in the MQ log (ECLGYYMMDD). The CC Authorization Transaction (CCAT00) records are in a *SENT status. Identified Issue: The Cardinal Commerce sender channel and/or CWDirect receiver channel is inactive.	1. Verify with Cardinal Commerce that the response transactions are waiting in the MQ queue. 2. If the Cardinal Commerce sender channel is down, ask Cardinal Commerce to restart the sender channel. If the CWDirect receiver channel is down, restart it. 3. Once the sender and receiver channels are running, verify that the response transactions update the MQ log (ECLGYYMMDD). 4. Verify that the CC Authorization Transaction records update to a *RCVD status with a vendor response. 5. Reply to the MSGW wait with V (Receive Pending Data). 6. Verify that the system updates the Status of the authorization history record to A (Authorized) or D (Declined) and the Response code to the response returned by Cardinal Commerce.
Authorization response messages are not waiting to be sent by Cardinal Commerce and you have replied to the MSGW wait for the PICK_GEN job with C (Cancel). The authorization request messages for the transaction exist in the MQ log (ECLGYYMMDD). The CC Authorization Transaction (CCAT00) records are in a *RDY status. Identified Issue: The Cardinal Commerce sender channel and/or CWDirect receiver channel is inactive.	1. Verify with Cardinal Commerce that the response transactions are not waiting in the MQ queue. 2. If the Cardinal Commerce sender channel is down, ask Cardinal Commerce to restart the sender channel. If the CWDirect receiver channel is down, restart it. 3. Update the integration process control record on the Work with Integration Process Control Screen from TRF (Unknown) status to SENT status. 4. Update the status of the CC Authorization Transaction (CCAT00) records from *RDY status to *SENT status. 5. Use the Receive/Process Authorizations option on the Reprocess Authorizations Screen (RPAA) to receive the response transactions. 6. Verify that the authorization request and response messages exist in the MQ log (ECLGYYMMDD). 7. Verify that the system updates the Status of the authorization history record to A (Authorized) or D (Declined) and the Response code to the response returned by Cardinal Commerce.
Authorization response messages are waiting to be sent by Cardinal Commerce and you have replied to the MSGW wait for the PICK_GEN job with C (Cancel). The authorization request messages for the transaction exist in the MQ log (ECLGYYMMDD). The CC Authorization Transaction (CCAT00) records are in a *RDY status. Identified Issue: The Cardinal Commerce sender channel and/or CWDirect receiver channel is inactive.	1. Verify with Cardinal Commerce that the response transactions are waiting in the MQ queue. 2. Update the status of the CC Authorization Transaction (CCAT00) records from *RDY status to *SENT status. 3. If the Cardinal Commerce sender channel is down, ask Cardinal Commerce to restart the sender channel. If the CWDirect receiver channel is down, restart it. 4. Once the sender and receiver channels are running, verify that the response transactions update the MQ log (ECLGYYMMDD). 5. Verify that the CC Authorization Transaction records update to a *RCVD status with a vendor response. 6. Use the Receive/Process Authorizations option on the Reprocess Authorizations Screen (RPAA) to receive the response transactions. 7. Verify that the authorization request and response messages exist in the MQ log (ECLGYYMMDD). 8. Verify that the system updates the Status of the authorization history record to A (Authorized) or D (Declined) and the Response code to the response returned by Cardinal Commerce.
Authorization request messages are not waiting to be sent to Cardinal Commerce and you have replied to the MSGW wait for the PICK_GEN job with C (Cancel). The authorization request messages for the transaction exist in the MQ log (ECLGYYMMDD). The CC Authorization Transaction (CCAT00) records are in a *RDY status. Identified Issue: The Cardinal Commerce receiver channel and/or CWDirect sender channel is inactive.	1. Verify that CWDirect does not have request messages waiting in the MQ queue. 2. Update the integration process control record on the Work with Integration Process Control Screen from TRF (Unknown) status to RDY status. 3. If the CWDirect sender channel is down, restart it. If the Cardinal Commerce receiver channel is down, ask Cardinal Commerce to restart the receiver channel. 4. Use the Transmit/Receive/Process Authorizations option on the Reprocess Authorizations Screen (RPAA) to send the request transactions. 5. Verify that the authorization request messages and the authorization response messages for the transaction exist in the MQ log (ECLGYYMMDD). 6. Verify that the system updates the Status of the authorization history record to A (Authorized) or D (Declined) and the Response code to the response returned by Cardinal Commerce.
Authorization request messages are waiting to be sent to Cardinal Commerce and the PICK_GEN job is in a MSGW wait status. The authorization request messages for the transaction exist in the MQ log (ECLGYYMMDD). The CC Authorization Transaction (CCAT00) records are in a *SENT status. Identified Issue: The Cardinal Commerce receiver channel and/or CWDirect sender channel is inactive.	1. Verify that CWDirect has request messages waiting in the MQ queue. 2. If the CWDirect sender channel is down, restart it. If the Cardinal Commerce receiver channel is down, ask Cardinal Commerce to restart the receiver channel. 3. Verify that the authorization response messages for the transaction now exist in the MQ log (ECLGYYMMDD). 4. Verify that the CC Authorization Transaction records update to a *RCVD status with a vendor response. 5. Reply to the MSGW wait with V (Receive Pending Data). 6. Verify that the system updates the Status of the authorization history record to A (Authorized) or D (Declined) and the Response code to the response returned by Cardinal Commerce.

Recovery Processing for Batch Deposit Transactions

Scenario	Solution
Deposit response messages are waiting to be sent by Cardinal Commerce and the AUTO_DEP job is in a MSGW wait status. The deposit request messages for the transaction exist in the MQ log (ECLGYYMMDD). The CC Deposit Transaction (CCDP00) records are in a *SENT status. Identified Issue: The Cardinal Commerce sender channel and/or CWDirect receiver channel is inactive.	1. Verify with Cardinal Commerce that the response transactions are waiting in the MQ queue. 2. If the Cardinal Commerce sender channel is down, ask Cardinal Commerce to restart the sender channel. If the CWDirect receiver channel is down, restart it. 3. Once the sender and receiver channels are running, verify that the response transactions update the MQ log (ECLGYYMMDD). 4. Verify that the CC Deposit Transaction records update to a *RCVD status with a vendor response. 5. Reply to the MSGW wait with V (Receive Pending Data). 6. Verify that the system updates the Status of the deposit history record to C (confirmed) and the Response code to the response returned by Cardinal Commerce.
Deposit response messages are not waiting to be sent by Cardinal Commerce and you have replied to the MSGW wait for the AUTO_DEP job with C (Cancel). The deposit request messages for the transaction exist in the MQ log (ECLGYYMMDD). The CC Deposit Transaction (CCDP00) records are in a *RDY status. Identified Issue: The Cardinal Commerce sender channel and/or CWDirect receiver channel is inactive.	1. Verify with Cardinal Commerce that the response transactions are not waiting in the MQ queue. 2. If the Cardinal Commerce sender channel is down, ask Cardinal Commerce to restart the sender channel. If the CWDirect receiver channel is down, restart it. 3. Update the integration process control record on the Work with Integration Process Control Screen from TRF (Unknown) status to SENT status. 4. Update the status of the CC Deposit Transaction (CCDP00) records from *RDY status to *SENT status. 5. Run Receiving Deposits in Processing Auto Deposits (SDEP) to receive the response transactions. 6. Verify that the deposit request and response messages exist in the MQ log (ECLGYYMMDD). 7. Verify that the system updates the Status of the deposit history record to C (confirmed) and the Response code to the response returned by Cardinal Commerce.
Deposit response messages are waiting to be sent by Cardinal Commerce and you have replied to the MSGW wait for the AUTO_DEP job with C (Cancel). The deposit request messages for the transaction exist in the MQ log (ECLGYYMMDD). The CC Deposit Transaction (CCDP00) records are in a *RDY status. Identified Issue: The Cardinal Commerce sender channel and/or CWDirect receiver channel is inactive.	1. Verify with Cardinal Commerce that the response transactions are waiting in the MQ queue. 2. Update the status of the CC Deposit Transaction (CCDP00) records from *RDY status to *SENT status. 3. If the Cardinal Commerce sender channel is down, ask Cardinal Commerce to restart the sender channel. If the CWDirect receiver channel is down, restart it. 4. Once the sender and receiver channels are running, verify that the response transactions update the MQ log (ECLGYYMMDD). 5. Verify that the CC Deposit Transaction records update to a *RCVD status with a vendor response. 6. Run Receiving Deposits in Processing Auto Deposits (SDEP) to receive the response transactions. 7. Verify that the system updates the Status of the deposit history record to C (confirmed) and the Response code to the response returned by Cardinal Commerce.
Deposit request messages are not waiting to be sent to Cardinal Commerce and you have replied to the MSGW wait for the AUTO_DEP job with C (Cancel). The deposit request messages for the transaction exist in the MQ log (ECLGYYMMDD). The CC Deposit Transaction (CCDP00) records are in a *RDY status. Identified Issue: The Cardinal Commerce receiver channel and/or CWDirect sender channel is inactive.	1. Verify that CWDirect does not have request messages waiting in the MQ queue. 2. Update the integration process control record on the Work with Integration Process Control Screen from TRF (Unknown) status to RDY status. 3. If the CWDirect sender channel is down, restart it. If the Cardinal Commerce receiver channel is down, ask Cardinal Commerce to restart the receiver channel. 4. Send deposits using Processing Auto Deposits (SDEP). 5. Verify that the deposit request messages and the deposit response messages for the transaction exist in the MQ log (ECLGYYMMDD). 6. Verify that the system updates the Status of the deposit history record to C (confirmed) and the Response code to the response returned by Cardinal Commerce.
Deposit request messages are waiting to be sent to Cardinal Commerce and the AUTO_DEP job is in a MSGW wait status. The deposit request messages for the transaction exist in the MQ log (ECLGYYMMDD). The CC Deposit Transaction (CCDP00) records are in a *SENT status. Identified Issue: The Cardinal Commerce receiver channel and/or CWDirect sender channel is inactive.	1. Verify that CWDirect has request messages waiting in the MQ queue. 2. If the CWDirect sender channel is down, restart it. If the Cardinal Commerce receiver channel is down, ask Cardinal Commerce to restart the receiver channel. 3. Verify that the deposit response messages for the transaction now exist in the MQ log (ECLGYYMMDD). 4. Verify that the CC Deposit Transaction records update to a *RCVD status with a vendor response. 5. Reply to the MSGW wait with V (Receive Pending Data). 6. Verify that the system updates the Status of the deposit history record to C (confirmed) and the Response code to the response returned by Cardinal Commerce.

Google Checkout Integration Setup

Before you can use the Google Checkout integration, you must perform the necessary setup. Information requiring setup includes:

• MQ Protocol Setup

• Defining Integration Layer Process Settings

• Defining Service Bureau Settings

• Creating a Google Checkout Pay Type

• Creating a Google Checkout Source Code

• Tax Setup

• Authorizations

In addition:

• You must be on CWDirect version 9.5 or higher.

• You must purchase the CWAdapt product from Cardinal Commerce. The CWAdapt product allows Cardinal Commerce to interface to the CWOrderIn message and CWOrderOut message for web order processing and the CWAuthorizationRequest message and CWDepositRequest message for authorization and deposit processing.

• You must purchase the Centinel Thin Client from Cardinal Commerce. The Centinel Thin Client allows you to integrate your web storefront with Cardinal Commerce and Google Checkout. In addition, the Centinel Thin Client monitors the web storefront’s Google Checkout activity to ensure that the web storefront is in sync with the order and payment activity in Google Checkout. If one of the following scenarios is encountered, the Centinel Thin Client sends a notice to the web storefront.

• New Order Notification

• Risk Information Notification

• Order State Change Notification

• Charge Notification

• Refund Notification

• Charge Back Notification

• Re-Authorize Notification

MQ Protocol Setup

IBM WebSphere MQ protocol is used for transactions sent between CWDirect and Cardinal Commerce.

MQ protocol illustration: The queues and channels required to support the CWDirect Cardinal Commerce integration are illustrated below.

MQ protocol settings required on the iSeries: On the iSeries you need the following elements:

• Local Queue Manager: The MQ manager on the iSeries. The queue manager maintains the queues and the flow of messages on the server.

• Remote Queue Manager: The MQ manager on the Cardinal Commerce system. Contact Cardinal Commerce for the name of their local queue manager.

• Sender Channel: The sender channel to send transactions from CWDirect to Cardinal Commerce. This is the receiver channel on the Cardinal Commerce system. The IP address defined for the sender channel represents the IP address of the Cardinal Commerce system. Be sure to set Convert message setting to *YES on the iSeries. Note: The IP address of the Cardinal Commerce system changes each time Cardinal Commerce performs a reset. You will need to update the IP address defined for the sender channel when this occurs.

• Transmission Queue: The transmission queue moves messages from the output queue through the sender channel to the Cardinal Commerce server; also, the transmission queue receives messages from the receiver channel and moves them to the input queue. Enter this transmission queue for the Sender Channel. The name of the transmission queue on the Cardinal Commerce system must match the name of the transmission queue on the iSeries.

• Receiver Channel: The receiver channel to receive transactions from Cardinal Commerce to CWDirect. This is the sender channel on the Cardinal Commerce system.

• Remote (output) Queues: The output queue sends messages to the Cardinal Commerce server via the transmission queue and the sender channel. When you set up a remote queue, you need to specify the queue manager on the Cardinal Commerce server that will handle the messages originating from this output queue.

• Remote queue for order responses: To send order responses from CWDirect to Cardinal Commerce. The name of the Order Response remote queue on the iSeries must match the name of the Order Response local queue on the Cardinal Commerce system. This is the Outbound queue specified for the inbound order integration layer job in CWDirect (IJCT).

• Remote queue for online authorization requests: To send online authorization request transactions from CWDirect to Cardinal Commerce. The name of the Online Authorization Request remote queue on the iSeries must match the name of the Online Authorization Request local queue on the Cardinal Commerce system. This is the Outbound queue specified for the online authorization integration layer job in CWDirect (IJCT).

• Remote queue for batch authorization requests: To send batch authorization request transactions from CWDirect to Cardinal Commerce. The name of the Batch Authorization Request remote queue on the iSeries must match the name of the Batch Authorization Request local queue on the Cardinal Commerce system. This is the Outbound queue specified for the batch authorization integration layer job in CWDirect (IJCT).

• Remote queue for batch deposit requests: To send batch deposit request transactions from CWDirect to Cardinal Commerce. The name of the Batch Deposit Request remote queue on the iSeries must match the name of the Batch Deposit Request local queue on the Cardinal Commerce system. This is the Outbound queue specified for the batch deposit integration layer job in CWDirect (IJCT).

• Local (input) Queues: The input queue receives messages from the transmission queue, and is also used for local messages on the server.

• Local queue for inbound orders: To receive inbound orders from Cardinal Commerce to CWDirect. The name of the Inbound Order local queue on the iSeries must match the name of the Inbound Order remote queue on the Cardinal Commerce system. This is the Inbound queue specified for the inbound order integration layer job in CWDirect (IJCT).

• Local queue for online authorization responses: To receive online authorization response transactions from Cardinal Commerce to CWDirect. The name of the Online Authorization Response local queue on the iSeries must match the name of the Online Authorization Response remote queue on the Cardinal Commerce system. This is the Inbound queue specified for the online authorization integration layer job in CWDirect (IJCT).

• Local queue for batch authorization responses: To receive batch authorization response transactions from Cardinal Commerce to CWDirect. The name of the Batch Authorization Response local queue on the iSeries must match the name of the Batch Authorization Response remote queue on the Cardinal Commerce system. This is the Inbound queue specified for the batch authorization integration layer job in CWDirect (IJCT).

• Local queue for batch deposit responses: To receive batch deposit response transactions from Cardinal Commerce to CWDirect. The name of the Batch Deposit Response local queue on the iSeries must match the name of the Batch Deposit Response remote queue on the Cardinal Commerce system. This is the Inbound queue specified for the batch deposit integration layer job in CWDirect (IJCT).

MQ protocol settings required on the Cardinal Commerce server: On the Cardinal Commerce server you need the following elements:

• Local Queue Manager: The MQ manager on the Cardinal Commerce system. The queue manager maintains the queues and the flow of messages on the server.

• Remote Queue Manager: The MQ manager on the iSeries. This is the local queue manager on the iSeries.

• Sender Channel: The sender channel to send transactions from Cardinal Commerce to CWDirect. This is the receiver channel on the CWDirect. The IP address defined for the sender channel represents the IP address of the iSeries.

• Transmission Queue: The transmission queue moves messages from the output queue through the sender channel to the iSeries; also, the transmission queue receives messages from the receiver channel and moves them to the input queue. Enter this transmission queue for the Sender Channel. The name of the transmission queue on the Cardinal Commerce system must match the name of the transmission queue on the iSeries.

• Receiver Channel: The receiver channel to receive transactions from CWDirect to Cardinal Commerce. This is the sender channel on the iSeries.

• Remote (output) Queues: The output queue sends messages to the iSeries via the transmission queue and the sender channel. When you set up a remote queue, you need to specify the queue manager on the iSeries that will handle the messages originating from this output queue.

• Remote queue for inbound orders: To send inbound orders from Cardinal Commerce to CWDirect. The name of the Inbound Order remote queue on the Cardinal Commerce system must match the name of the Inbound Order local queue on the iSeries. This is the Inbound queue specified for the inbound order integration layer job in CWDirect (IJCT).

• Remote queue for online authorization responses: To send online authorization response transactions from Cardinal Commerce to CWDirect. The name of the Online Authorization Response remote queue on the Cardinal Commerce system must match the name of the Online Authorization Response local queue on the iSeries. This is the Inbound queue specified for the online authorization integration layer job in CWDirect (IJCT).

• Remote queue for batch authorization responses: To send batch authorization response transactions from Cardinal Commerce to CWDirect. The name of the Batch Authorization Response remote queue on the Cardinal Commerce system must match the name of the Batch Authorization Response local queue on the iSeries. This is the Inbound queue specified for the batch authorization integration layer job in CWDirect (IJCT).

• Remote queue for batch deposit responses: To send batch deposit response transactions from Cardinal Commerce to CWDirect. The name of the Batch Deposit Response remote queue on the Cardinal Commerce system must match the name of the Batch Deposit Response local queue on the iSeries. This is the Inbound queue specified for the batch deposit integration layer job in CWDirect (IJCT).

• Local (input) Queues: The input queue receives messages from the transmission queue, and is also used for local messages on the server.

• Local queue for inbound order responses: To receive inbound order responses from CWDirect to Cardinal Commerce. The name of the Inbound Order Response local queue on the Cardinal Commerce system must match the name of the Inbound Order Response remote queue on the iSeries. This is the Outbound queue specified for the inbound order integration layer job in CWDirect (IJCT).

• Local queue for online authorization requests: To receive online authorization request transactions from CWDirect to Cardinal Commerce. The name of the Online Authorization Request local queue on the Cardinal Commerce system must match the name of the Online Authorization Request remote queue on the iSeries. This is the Outbound queue specified for the online authorization integration layer job in CWDirect (IJCT).

• Local queue for batch authorization requests: To receive batch authorization request transactions from CWDirect to Cardinal Commerce. The name of the Batch Authorization Request local queue on the Cardinal Commerce system must match the name of the Batch Authorization Request remote queue on the iSeries. This is the Outbound queue specified for the batch authorization integration layer job in CWDirect (IJCT).

• Local queue for batch deposit requests: To receive batch deposit request transactions from CWDirect to Cardinal Commerce. The name of the Batch Deposit Request local queue on the Cardinal Commerce system must match the name of the Batch Deposit Request remote queue on the iSeries. This is the Outbound queue specified for the batch authorization integration layer job in CWDirect (IJCT).

Queue and Channel Setup Summary Table

Before you create the queues and channels required for the CWDirect Cardinal Commerce integration, you should take the time to identify the names of the queues, channels, and queue managers for each type of message. The names you select for the queues and channels should not already be in use on your system. You can use a table such as the following to identify these names and use as a reference as you create the channels and queues on each server.

iSeries		Cardinal Commerce
Component	Example	Component	Example
Queue manager	DIR	Queue manager	CCM
Your value:		Your value:
IP address	123.45.6789	IP address	987.654.321
Your value:		Your value:
Transmission queue (same name as the transmission queue on the other machine)	DIR.CCM	Transmission queue (same name as the transmission queue on the other machine)	DIR.CCM
Your value:		Your value:
Sender channel (same name as receiver channel on other machine)	DIR.TO.CCM	Receiver channel (same name as sender channel on other machine)	DIR.TO.CCM
Your value:		Your value:
Receiver channel (same name as sender channel on other machine)	CCM.TO.DIR	Sender channel (same name as receiver channel on other machine)	CCM.TO.DIR
Your value:		Your value:
Remote (output) queues (same name as the corresponding local (input) queue on the other machine)	Inbound order response: CCM.ORDIN.RESP	Local (input) queues (same name as the corresponding remote (output) queue on the other machine)	Inbound order response: CCM.ORDIN.RESP
	Online authorization request: CCM.ONL.AUTH.REQ		Online authorization request: CCM.ONL.AUTH.REQ
	Batch authorization request: CCM.BTH.AUTH.REQ		Batch authorization request: CCM.BTH.AUTH.REQ
	Batch deposit request: CCM.BTH.DEP.REQ		Batch deposit request: CCM.BTH.DEP.REQ
Your value (inbound order response):		Your value (inbound order response):
Your value (online auth request):		Your value (online auth request):
Your value (batch auth request):		Your value (batch auth request):
Your value (batch deposit request):		Your value (batch deposit request):
Local (input) queues (same name as the corresponding remote (output) queue on the other machine)	Inbound order request: CCM.ORDIN.REQ	Remote (output) queues (same name as the corresponding local (input) queue on the other machine)	Inbound order request: CCM.ORDIN.REQ
	Online authorization response: CCM.ONL.AUTH.RESP		Online authorization response: CCM.ONL.AUTH.RESP
	Batch authorization response: CCM.BTH.AUTH.RESP		Batch authorization response: CCM.BTH.AUTH.RESP
	Batch deposit response: CCM.BTH.DEP.RESP		Batch deposit response: CCM.BTH.DEP.RESP
Your value (inbound order request):		Your value (inbound order request):
Your value (online auth response):		Your value (online auth response):
Your value (batch auth response):		Your value (batch auth response):
Your value (batch deposit response):		Your value (batch deposit response):

Sample MQ protocol setup:

For more information: For more information on how queues and channels work in IBM WebSphere MQ, see your IBM WebSphere MQ documentation.

Defining Integration Layer Process Settings

Use the Working with Integration Layer Processes (IJCT) menu option to define the processes that transmit data between CWDirect and Cardinal Commerce.

Online authorization process: The Online Authorization integration layer job creates an Authorization Request XML Message (CWAuthorizationRequest) in online format when you perform online authorization against the Google Checkout payment method and receives an Authorization Response XML Message (CWAuthorizationResponse) indicating if the authorization was approved or denied. For this process you must define:

• The outbound queue where online authorization messages are placed to send to Cardinal Commerce.

• The inbound queue that receives online authorization responses from Cardinal Commerce.

Batch authorization process: The Batch Authorization integration layer job creates an Authorization Request XML Message (CWAuthorizationRequest) in batch format when you perform batch authorization against the PayPal payment method and receives an Authorization Response XML Message (CWAuthorizationResponse) indicating if the authorization was approved or denied. For this process you must define:

• The outbound queue where batch authorization messages are placed to send to Cardinal Commerce.

• The inbound queue that receives batch authorization responses from Cardinal Commerce.

Deposit process: The Deposit integration layer job creates a Deposit Request XML Message (CWDepositRequest) in batch format when you process deposits against the PayPal payment method and receives a Deposit Response XML Message (CWDepositResponse) indicating if the deposit was approved or denied. For this process you must define:

• The outbound queue where batch deposit messages are placed to send to Cardinal Commerce.

• The inbound queue that receives batch deposit responses from Cardinal Commerce.

Order In process: The Inbound Order integration layer job receives the Inbound Order XML Message (CWORDERIN) containing the Google Checkout payment from the web storefront/Cardinal CWAdapt and sends the Detailed Order XML Response (CWORDEROUT) back to Cardinal CWAdapt. For this process you must define:

• The inbound queue that receives inbound orders from Cardinal CWAdapt.

• The outbound queue that sends the order response to Cardinal CWAdapt.

Defining Service Bureau Settings

Cardinal Commerce settings: Create a Cardinal Commerce service bureau in Defining Authorization Services (WASV), making note of these required settings:

• Merchant information: Set up the merchant information with the information provided by Cardinal Commerce. Note: The password that you receive from Cardinal Commerce must be in all upper case letters.

• Online authorization integration layer process: Enter the code for the integration layer process that sends authorization requests in online format to Cardinal Commerce and receives authorization responses in online format from Cardinal Commerce.

• Batch authorization integration layer process: Enter the code for the integration layer process that sends authorization requests in batch format to Cardinal Commerce and receives authorization responses in batch format from Cardinal Commerce.

• Deposit integration layer process: Enter the code for the integration layer process that sends deposit requests in batch format to Cardinal Commerce and receives deposit responses in batch format from Cardinal Commerce.

• Primary authorization service: Enter .IL to indicate the system generates an XML message for authorization and deposit transactions to send to and from Cardinal Commerce via WebSphere MQ.

• Pay type cross reference: Set up a pay type cross reference for the Google Checkout pay type.

• Currency cross reference: Set up a currency cross reference for the U.S. dollar currency code.

• Response codes: Set up response codes provided by Cardinal Commerce.

• For authorization transactions, the system sends the request in the CWAuthorizationRequest message and receives the response in the CWAuthorizationResponse message.

• For deposit transactions, the system sends the request in the CWDepositRequest message and receives the response in the CWDepositResponse message.

.IL settings: To send authorization and deposit transactions to Cardinal Commerce via WebSphere MQ, you must create the .IL service bureau. When you are setting up the .IL service bureau, please note these required settings:

• Service code: Create the service bureau using the service code .IL.

• Application: Enter ATDP to indicate the service bureau can process both authorizations and deposits.

• Merchant ID: Enter CWINTEGRATE.

• Charge description: Enter CWINTEGRATE.

Creating a Google Checkout Pay Type

When creating a Google Checkout pay type in Working with Pay Types (WPAY), you must define the following information:

• Pay category: enter 2 (credit card) as the pay category

• Card type: enter C (credit card) as the card type

• Authorization service: enter the Cardinal Commerce service bureau as your authorization service

• Deposit service: enter the Cardinal Commerce service bureau as your deposit service

• Reauthorization days: enter the number of days before Google Checkout payments expire. Make sure the number of days you enter matches the number of days defined in the Google Checkout system.

• Modulus check: enter M10 (Modulus 10) as the modulus check method in order to validate the Google Checkout transaction ID.

Creating a Google Checkout Source Code

When creating a Google Checkout source code in Working with Source Codes (WSRC), you must set up the source code to calculate tax on Google Checkout orders processed through the Generic Order Interface (Order API). Set the Price method to D (Regular Plus Reprice).

In addition, if you wish to pass a Google Coupon ID to CWDirect, set up the source code as the Google Coupon ID and define coupon information for this source code (for example, define a promotion code for the source code).

Tax Setup

Set up CWDirect tax or use the Vertex Interface (A88) to calculate tax on Google Checkout orders processed through the Generic Order Interface (Order API).

Authorizations

Set the On-line Authorizations (B89) and Use Auto Authorization Interface (C14) system control values to Y.

See On-line Credit Card Authorization Setup and CWIntegrate Authorization and Deposit Setup for additional set up information.

Google Checkout Order Type

Optional setup for Google Checkout Integration.

Create an order type for Google Checkout orders in the Establishing Order Types (WOTY) menu option.

Promotions

Optional setup for Google Checkout Integration.

To apply discounts to the order, such as a freight promotion discount, include a dummy discount item with a negative dollar amount on the order for the discount amount. For example, create a non-inventory item named DISCOUNTS in the Work with Items (MITM) menu option.