Chapter 54: PayPal Integration

Overview: The PayPal integration allows you to use PayPal as a method of payment on web orders.

• You can use any authorization service that supports PayPal processing to authorize web orders on the web storefront.

• If the web order does not receive an approved authorization on the web storefront, you can use Cardinal Commerce to authorize the web order during CWDirect batch authorization and approve deposits during deposit processing.

PayPal is an e-commerce business that allows you to perform payment and money transfers securely over the Internet. PayPal’s service builds on the existing financial infrastructure of bank accounts and credit cards and utilizes fraud prevention systems to create a safe, global, real-time payment solution.

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

The CWDirect PayPal integration allows you to use PayPal as a form of payment on online transactions with Cardinal Commerce as your service provider.

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

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

• PayPal Integration Process

• PayPal Integration Setup

• MQ Protocol Setup

• Defining Integration Layer Process Settings

• Defining Service Bureau Settings

• Creating a PayPal Pay Type

PayPal Integration Process

PayPal integration illustration:

PayPal Integration Process Flow

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

1. A customer places an order on the web storefront and pays for the order using a PayPal account.

2. The web storefront sends an online authorization request for the PayPal payment method to an authorization service that supports PayPal processing. The 16 position PayPal account number is passed in the online authorization request in the ccAccountNumber tag.

3. The authorization service sends a PayPal request to PayPal.

4. PayPal validates the PayPal account and sends PayPal information back to the authorization service. Note: The average time to process a request by PayPal is 3 seconds.

5. The authorization service sends an online authorization response back to the web storefront.

6. The web storefront completes the order and sends the order to CWDirect in the CWOrderIn message. The PayPal account number is passed on the order in the cc_number tag.

Authorized PayPal payments: If the PayPal payment on the web order has already been authorized by PayPal, the CWOrderIn message contains the following information:

• regular order information

• PayPal pay type

• PayPal transaction ID passed in the cc_number tag

• PayPal transaction ID passed in the auth_number tag Note: If you are using CWDirect version 9.0 or earlier, only the first 6 positions of the PayPal transaction ID are passed in the auth_number tag.

• Authorization date in the auth_date tag (the date the PayPal payment was authorized with PayPal)

• Authorization amount in the auth_amount tag (required to create a Void Auths (AAVOID) record)

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

• regular order information

• PayPal pay type

• PayPal 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.

7. CWDirect processes the web order.

• If the authorization date for the PayPal payment has not expired when a pick slip is processed for the order, the system will generate a pick ticket and follow normal order processing.

• If the authorization date for the PayPal payment has expired, or the PayPal payment has never been authorized, the system sends the PayPal payment for authorization before generating a pick slip. The 16 position PayPal account number is passed in the batch authorization request in the ccAccountNumber tag.

Restrictions: The CWDirect PayPal integration does not support:

• Online authorizations for orders entered in CWDirect.

• Batch authorizations for orders entered in CWDirect.

• Additions to orders through Order Maintenance that have been previously processed via the web storefront through PayPal and exceed 15% of the original order total. Note: The percentage that the order maintenance transaction can exceed the original order total is a configurable setting in PayPal.

PayPal Integration Setup

Purpose: Before you can use the PayPal 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 PayPal Pay Type

In addition:

• You must be on CWDirect version 7.5 or higher.

• You must purchase the CWAdapter product from Cardinal Commerce. The CWAdapter product allows Cardinal Commerce to interface to the CWAuthorizationRequest message and CWDepositRequest message for batch authorization and deposit processing.

• If you wish to use Cardinal Commerce as the authorization service connected to the web storefront, 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 PayPal.

• You can use any authorization service to authorize orders on the web storefront; however, the authorization service must pass the PayPal transaction ID in the cc_number tag and auth_number tag in the CWOrderIn message.

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.

• 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 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 process queue 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 process queue 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 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 process queue 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 process queue 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 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 process queue 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 process queue 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 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 process queue 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 process queue 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	CRD
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.CRD	Transmission queue (same name as the transmission queue on the other machine)	DIR.CRD
Your value:		Your value:
Sender channel (same name as receiver channel on other machine)	DIR.TO.CRD	Receiver channel (same name as sender channel on other machine)	DIR.TO.CRD
Your value:		Your value:
Receiver channel (same name as sender channel on other machine)	CRD.TO.DIR	Sender channel (same name as receiver channel on other machine)	CRD.TO.DIR
Your value:		Your value:
Remote (output) queues (same name as the corresponding local (input) queue on the other machine)	Batch authorization request: CRD.BATCH.AUTH.REQST	Local (input) queues (same name as the corresponding remote (output) queue on the other machine)	Batch authorization request: CRD.BATCH.AUTH.REQST
	Batch deposit request: CRD.BATCH.DEP.REQST		Batch deposit request: CRD.BATCH.DEP.REQST
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)	Batch authorization response: CRD.BATCH.AUTH.RESP	Remote (output) queues (same name as the corresponding local (input) queue on the other machine)	Batch authorization response: CRD.BATCH.AUTH.RESP
	Batch deposit response: CRD.BATCH.DEP.RESP		Batch deposit response: CRD.BATCH.DEP.RESP
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.

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 indicating if the authorization was approved or denied. For this process you can 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 can 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.

Defining Service Bureau Settings

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

• 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.

• 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 PayPal Pay Type

When creating a PayPal 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 PayPal payments expire. Make sure the number of days you enter matches the number of days defined in the PayPal system.

In addition, to creating the PayPal pay type, create a credit card number format if you do not want the full PayPal account number to display on CWDirect screens and reports. If you do not have authority to the Display Full Credit Card Number (B14) secured feature, the PayPal account number displays in the format specified at the Credit Card Number Layout Screen for the associated pay type. For example, **********1234 may display instead of the entire PayPal account number. See Credit Card Number Format for an overview.