12 System Operations

Operating the Background Jobs

Running Period End Processing

Using the System Utilities

Setting Up Authorization Services

Purging Tables

Flexible Payment Options

Processing Deposits

E-Commerce Interface

Workflow Management

Point of Sale Integration

Integration

Stored Value Card Integration

Importing Item/SKU and Set Data

ChannelAdvisor Integration

Merchandising Integration

Oracle Retail Merchandising Foundation Cloud Service (RMFCS) and Oracle Retail Pricing Cloud Service (RPCS) Integration

Overview: Use the integration with Oracle Retail Merchandising Foundation Cloud Service (RMFCS) to import item information.

The import from RMFCS also supports importing pricing information from Oracle Retail Pricing Cloud Service (RPCS). This import is also described below.

Note:

This integration will be deprecated in a future release. Importing Enterprise Foundation Data through Omnichannel Cloud Data Service (OCDS) can be used instead to import items and pricing.

In this topic:

• Data Flow from RMFCS and RPCS to Order Administration

• Configuration for RMFCS and RPCS Integrations

  • Configuration within Order Administration

• Additional Considerations for RMFCS Integration

• Mapping Item and Pricing Information into Order Administration

  • RMFCS to OACS Mapping

  • RPCS to OACS Mapping

Data Flow from RMFCS and RPCS to Order Administration

If your company is configured for RMFCS integration for item creation and update, processing takes place as follows:

1.Import momzip file into file storage: Use the API to place the inbound momzip file from RMFCS in the FILE_STORAGE table. See Working with File Imports for background.

Note:

You cannot use Work with File Uploads (WUPL) to process the momzip file.

About the momzip file: The momzip file must contain one or more pipe-delimited text files, each with the DAT extension, created from RMFCS. The momzip file itself is a compressed file.

Item information: The itemhdr DAT file contains the item information to import from RMFCS into Order Administration. Note that not all fields in this file are mapped into Order Administration. See RMFCS to OACS Mapping and RPCS to OACS Mapping for details.

Pricing information: RPCS provides two DAT files:

• Regular price: The REGPC DAT file includes regular pricing information for items.

• Clearance price: The CLRPC DAT file includes clearance pricing for items.

Like the Itemhdr file, the two pricing files from RPCS are pipe-delimited text files. If either or both of these files are included in the momzip file, the file contents update the RI Item Upload Table (RIIUPP) and, ultimately, the Item Offer and Item Price tables. Because no offer information is mapped from RPCS, the offer code to use defaults from the RMS Item Upload Periodic Function. See RPCS to OACS Mapping for mapping details.

File naming: The periodic function identifies DAT files containing item or pricing data by the file name. The file from RMFCS needs to begin with itemhdr, while the pricing files need to begin with REGPC or CLRPC. Each file needs to include the store ID assigned in RMFCS.

For example, a file might be named itemhdr_20180702123456_1234_delta_50.dat, where 201807123456 is the date and time stamp, 1234 is the store ID, delta indicates that the file includes only changed records, and 50 is the total number of records in the file. Including the text delta in the file name is informational; regardless of whether it is included, processing the records works the same way.

Similarly, a pricing file name might be REGPC_20180702021616_1234.dat.

Any other files included in the momzip file are not used.

Note:

File names and suffixes are not case-sensitive. For example, either momzip or MOMZIP are acceptable and will not result in an error.

2.      Process records in momzip file and create RI Item Upload records: Once the momzip file is available in the FILE_STORAGE table, the RMSItem Upload periodic function can process the contents of the file and create records in the RI Item Upload Table (RIIUPP). The periodic function includes a parameter defining the store ID assigned in RMFCS, as well as specifying the Company number.

See RMS Item Upload Periodic Function for details on configuring the periodic function.

If there are multiple momzip files, the oldest file is processed.

When this step completes, an RIIUPP record is created for each eligible row in the DAT file, and displayed at the Work with File Upload Screen even though you cannot use this screen to upload import files from RMFCS or RPCS.

This preliminary step of creating the RI Item Upload records does not include all the field mapping that ultimately needs to take place when updating the target tables; instead, the mapping is completed during the next step in the process, when the target tables are updated.

3.Use RI Item Upload records to create or update items, offers, and prices: The RI Item Upload Translation Program and RI Item Upload Edit Program process the records in the RI Item Upload table, and use these records to create or update items, offers, and prices. You can begin these programs by selecting Process File at the Work with Retail Item Upload Screen, or by submitting the RIUPLD Function.

Configuration for RMFCS and RPCS Integrations

Configuration within Order Administration

The configuration required in Order Administration to support importing items from RMFCS and RPCS is described below.

System Control Values

The following system control values must be selected:

• Use Retail Integration (H26)

  Important:

  See Retail Integration (External System into Order Administration) Overview and Setup for background on the additional setup required to support retail item integration. If you do not complete this setup, the import will not be successful.

• Require Long SKU Division with Long SKU Department (E85)

The following system control values must be unselected:

• Require Item Class in Work with Items (F06)

• Require Sort Sequence Number in the SKU File (F23)

• Require Entity in Item File (G44)

Since this information is not provided by RMFCS, the import will not be successful if the information is required.

RMS Item Upload Periodic Function

Use Working with Periodic Functions (WPER) to set up the RMS Item Upload periodic function. If the function needs to run in more than one company, mapping from more than one store in RMFCS, you can name the function RMSZIPN, where N is a unique number. When setting up the function:

• Set the Program name to PFRRMS.

• Set the Parameter to the store ID assigned in RMFCS, and the default offer code in Order Administration, separated by an underscore. For example, if the store ID is 1234 and the default offer is OFR, set the Parameter to 1234_OFR.

  The offer code is required for the import of pricing information from RPCS. If you set the parameter to just the store ID, such as 1234, but do not include the offer code, such as 1234_OFR, the Current Offer (A33) applies.

• Select the Company Parameter flag.

RIUPLD Function

Use Working with Periodic Functions (WPER) to set up the RIUPLD periodic function, if it does not already exist. When setting up the function, set the Program name to PFR0084.

Periodic Process

Use Working with Periodic Processes (WPPR) to assign either or both of the periodic functions described above to a periodic process. The Company parameter is required to indicate the company where the records should be created or updated.

Additional Considerations for RMFCS Integration

Does not support SKUs: Since RMFCS does not support SKU’s, all items imported from RMFCS are non-SKU’d items.

Using RMFCS Item Level and Tran Level to determine whether to create or update an item: RMFCS uses a different hierarchy than Order Administration for multi-level items. The RMFCS hierarchy supports:

• A level 1 item: For example, a picture frame that comes in only one finish and size.

• A level 2 item: For example, an item group that includes a novelty tee shirt in sizes small, medium, and large. Level 1 is the tee shirt, while level 2 includes the sizes.

• A level 3 item: For example, an item group that includes a polo shirt in red, blue, and yellow, and sizes small, medium, and large. Level 1 is the polo shirt, level 2 is the sizes, and level 3 is the colors.

The records in the itemhdr file that map to items in Order Administration are identifiable by the fact that the ItemLevel passed in the file is the same as the TranLevel. If the ItemLevel and the TranLevel are different, the record is not used to update the RIIUPP table in Order Administration.

Troubleshooting Information for the RMFCS Item and Pricing Import

If the process ends without populating the RIIUPP table, possible explanations include:

• The momzip file was not found.

• The number of columns in the DAT file was incorrect.

• The RIIUPP table already contained records that need to be cleared before the process could run again.

When there is an error with the import, it is listed on the Work with File Upload Screen with a File Type of RIIUPP and a status of Error, and you can view the error description by selecting Action > View Error.

If the momzip file did not contain a DAT file containing the itemhdr data, the upload remains at the Work with File Upload Screen in Submitted status. To correct this situation, you need to delete the momzip file from the FILE_STORAGE table.

Mapping Item and Pricing Information into Order Administration

RMFCS to OACS Mapping

The item information that updates the RI Item Upload Table (RIIUPP) and ultimately updates the target tables, including information mapped from RMFCS, is described in the following table. The process creates record type 01 (Item/SKU) records in the table based on the information from RMFCS. See RI Item Upload Table (RIIUPP) for more information on the updated fields.

The file from RMFCS contains no null fields. A blank is passed for an alphanumeric field with no data, and a 0 is passed for a numeric field.

**DFLT ITEM? Certain fields default from the **DFLT ITEM Item/SKU, if one is configured. These fields are indicated below. This information defaults when the RI Item Upload Translation Program and RI Item Upload Edit Program run, using the information in the RI Item Upload table to update the target tables.

**DFTCHG Item? The **DFTCHG Item/SKU controls the update of existing items:

• Any fields that are populated for the **DFTCHG item are not changed for an existing item that is passed from RMFCS.

• And any fields that are not populated for the **DFTCHG item are eligible to be updated for an existing item that is passed from RMFCS.

See the **DFTCHG Item/SKU for more information.

See RPCS to OACS Mapping for information on how pricing information in the RI Item Upload Table (RIIUPP) is updated based on the data received from RTM.

Additional information from RMFCS: Additional information is included in the DAT files from RMFCS; however, only the fields that update the RI Item Upload Table (RIIUPP) are described in the following table.

Sample itemhdr row:

ITEMS|FULLHDR|1234|102900077|||N|N|1|1|Y|||||||||||||2CDQ|2222|5274|2222|5485|A|Item 102900077||Item 102900077||Y|N|1000|EA||||E|N|12.22|USD||USD|||N|N|N|N|N|ITEM|||||N||||N|N|Y|Y||||N|N|N|N||||||||N|N|

Note:

About unmapped item/SKU fields: Any item/SKU in Order Administration fields not listed below are not mapped from RMFCS. They are left blank if alphanumeric, or set to 0 if numeric.

Target Field	Value Used	Description/ Comments
Item Updates
Company	Company number from the periodic process	The periodic process set up for the RMS Item Upload periodic function should be set up to require the Company Parameter.
Record Created Date	Current date when record created
Record Created Time	Current time when record created
Record Type	01	Hard-coded.
Request Type	blank	Since RMFCS does not indicate whether the record is an Add or a Change, Order Administration updates the record for the item if it exists. If no matching item exists, it creates a new item.
Sequence #	Sequential assigned number	Assignment of sequence numbers starts at 1 and continues for the first 999 records in the upload file. After the first 999 records, the Record Created Time increases by 1 second, and sequential assignment begins again and again runs from 1 through 999. This pattern continues for all records in the upload file, so that each has a unique Record Created Time/Sequence # assignment.
Key Type	IT	Hard-coded.
Item	RMFCS item code	Rather than using item SKU fields in the same way as Order Administration, RMFCS uses a hierarchical system to identify the relationships between individual items. An item code in the import table creates or updates an item in Order Administration only if the item’s ItemLevel and TranLevel in RMFCS are the same. See Additional Considerations for RMFCS Integration for a discussion.
SKU	Blank	Not used. See Additional Considerations for RMFCS Integration for a discussion.
Status	U	Unprocessed.
Processed Date	Blank	Populated through the RI Item Upload Process.
Processed Time	Blank	Populated through the RI Item Upload Process.
Allow SKUs	N	Hard-coded. SKUs are not supported through the integration.
Drop Ship	Blank	From the **DFLT ITEM Item/SKU; otherwise, unselected.
Long SKU Style	ItemParent	If no ItemParent is passed, the item code is used as the Long SKU Style.
Retail Style #	Item	The item code from RMFCS is used as the Retail Style #.
Long SKU Vendor	Subclass	The Subclass from RMFCS is used as the Long SKU Vendor.
Non-Inventory	Blank	From the **DFLT ITEM Item/SKU; otherwise, not selected. Note: Non-inventory items from RMFCS, indicated by a setting of N in the MerchandiseInd field, are not imported into Order Administration.
Selling Qty	1
Selling Weight	0	From the **DFLT ITEM Item/SKU; otherwise, 0.
Serial # Tracking	N	Not implemented in Order Administration.
Ship Alone	From ShipAloneInd	When the ShipAloneInd from RMFCS is set to Y, the Ship Alone field is set to S; otherwise, the Ship Alone field is left blank.
Allow % Discount?	Blank	From the **DFLT ITEM Item/SKU; otherwise, not selected.
Oversize	Blank	From the **DFLT ITEM Item/SKU; otherwise, not selected.
Description	ItemDesc	From the ItemDesc in RMFCS.
Exclude From Flex Pay	Blank	From the **DFLT ITEM Item/SKU; otherwise, not selected.
Royalty	N	From the **DFLT ITEM Item/SKU; otherwise, not selected.
Membership	Blank	From the **DFLT ITEM Item/SKU; otherwise, not selected.
Buyer	Blank	From the **DFLT ITEM Item/SKU; otherwise, blank.
Item Class	Blank	From the **DFLT ITEM Item/SKU; otherwise, blank.
Location Class	Blank	From the **DFLT ITEM Item/SKU; otherwise, blank.
Class (Long SKU Class)	Class	The Class from RMFCS is used as the Long SKU Class.
Department (Long SKU Department)	Department	The Department from RMFCS is used as the Long SKU Department.
UOM (Unit of Measure)	StandardUOM from RMFCS	Needs to be a valid unit of measure in Order Administration, set up through Working with Units of Measure (WUOM). Note: Units of measure set up in RMFCS should not exceed 3 positions, since this is the maximum field length supported in Order Administration.
Vendor #	Blank	From the **DFLT ITEM Item/SKU; otherwise, blank.
Ship Via Code	Blank	From the **DFLT ITEM Item/SKU; otherwise, blank.
Manufacturer Vendor	Blank	From the **DFLT ITEM Item/SKU; otherwise, blank.
Entity Number	Blank	From the **DFLT ITEM Item/SKU; otherwise, blank.
Season	Blank	From the **DFLT ITEM Item/SKU; otherwise, blank.
Subscription	Blank	From the **DFLT ITEM Item/SKU; otherwise, not selected.
Height Override	0	From the **DFLT ITEM Item/SKU; otherwise, 0.
Length Override	0	From the **DFLT ITEM Item/SKU; otherwise, 0.
SKU Gift Certificate	N	Hard-coded. Not supported in Order Administration.
Restrict Orders	Blank	From the **DFLT ITEM Item/SKU; otherwise, blank.
VAT Exempt Flag	Blank	From the **DFLT ITEM Item/SKU; otherwise, not selected.
Suppress B/O Card	Blank	From the **DFLT ITEM Item/SKU; otherwise, not selected.
Returnable	Blank	From the **DFLT ITEM Item/SKU; otherwise, not selected.
Whs (Warehouse)		From the **DFLT ITEM Item/SKU; otherwise, from the Default Warehouse (A04); otherwise, set to 0.
Soldout Control Code	Blank	Defaults from the Default Soldout Control Code (D72).
UOM Type	StandardUOM from RMFCS	Needs to match a unit of measure in Order Administration, set up through Working with Units of Measure (WUOM).
OROB Eligible		Selected.

RPCS to OACS Mapping

The offer and pricing information that updates the RI Item Upload Table (RIIUPP) and ultimately updates the target tables, including information mapped from RPCS, is described in the following table. The process creates record type 03 (Item Offer) and 05 (Item Price) records in the table based on the information from RPCS. See RI Item Upload Table (RIIUPP) for more information on the updated fields.

The file from RPCS contains no null fields. A blank is passed for an alphanumeric field with no data, and a 0 is passed for a numeric field.

See RMFCS to OACS Mapping for information on how item information in the Item table and related tables is updated based on the data received from RMFCS.

Additional information from RPCS: Additional information is included in the DAT files from RPCS. The files each include a header record (FHEAD) and a tail record (FTAIL), as well as a detail record (FDETL) for each item offer and price. However, only the fields that update the RI Item Upload Table (RIIUPP) are described in the following table.

Unmapped Item Offer fields: Any Item Offer or Item Price fields not listed in the following tables are not mapped from RMFCS. They are left blank if alphanumeric, or set to 0 if numeric.

Sample REGPC file contents:

FHEAD|1|REGPC|20180627021616|1234|S

FDETL|2|CRE|1001|101000122|20180404000000|1|16.75|EA|USD|0||||

FDETL|3|CRE|1002|101000132|20180405000000|1|16.75|EA|USD|0||||

FDETL|4|CRE|1003|101000123|20180627000000|1|16.75|EA|USD|0||||

FTAIL|5|3

Sample CLRPC file contents:

FHEAD|1|CLRPC|20180404021514|4241|S

FDETL|2|CRE|10002|101000126|20180404000000|6.85|EA|USD|

FDETL|3|CRE|10003|101000136|20180405000000|8.85|EA|USD|

FDETL|4|CRE|10004|101000135|20180404000000|7.85|EA|USD|

FTAIL|5|3

Item Offer Mapping from RPCS

Target Field	Value Used	Description/ Comments
Item Updates
Company	Company number from the periodic process	The periodic process set up for the RMS Item Upload Periodic Function should be set up to require the Company Parameter.
Record Created Date	Current date when record created
Record Created Time	Current time when record created
Record Type	03	Indicates Item Offer. Hard-coded.
Request Type	blank	Since RPCS does not indicate whether the record is an Add or a Change, Order Administration updates the record for the item if it exists. If no matching item exists, it creates a new item.
Sequence #	Sequential assigned number	Assignment of sequence numbers starts at 1 and continues for the first 999 records in the upload file. After the first 999 records, the Record Created Time increases by 1 second, and sequential assignment begins again and again runs from 1 through 999. This pattern continues for all records in the upload file, so that each has a unique Record Created Time/Sequence # assignment.
Key Type	IT	Hard-coded.
Item	RMFCS item code	The item to be updated with the Item Offer information.
SKU	Blank	Not used. See Additional Considerations for RMFCS Integration for a discussion.
Status	U	Unprocessed.
Processed Date	Blank	Populated through the RI Item Upload Process.
Processed Time	Blank	Populated through the RI Item Upload Process.
Offer for Item Offer	Offer from periodic function	The offer code defaults from the Parameter defined for the RMS Item Upload Periodic Function. If no offer code is specified for the periodic function, the Current Offer (A33) applies.

Item Price Mapping from RPCS 

The following mapping applies to both the REGPC (regular price) and CLRPC (clearance price) files from RPCS.

Target Field	Value Used	Description/ Comments
Item Updates
Company	Company number from the periodic process	The periodic process set up for the RMS Item Upload Periodic Function should be set up to require the Company Parameter.
Record Created Date	Current date when record created
Record Created Time	Current time when record created
Record Type	05	Indicates Item Price. Hard-coded.
Request Type	blank	Since RPCS does not indicate whether the record is an Add or a Change, Order Administration updates the record for the item if it exists. If no matching item exists, it creates a new item.
Sequence #	Sequential assigned number	Assignment of sequence numbers starts at 1 and continues for the first 999 records in the upload file. After the first 999 records, the Record Created Time increases by 1 second, and sequential assignment begins again and again runs from 1 through 999. This pattern continues for all records in the upload file, so that each has a unique Record Created Time/Sequence # assignment.
Key Type	IT	Hard-coded.
Item	RMFCS item code	The item to be updated with the Item Offer information.
SKU	Blank	Not used. See Additional Considerations for RMFCS Integration for a discussion.
Status	U	Unprocessed.
Processed Date	Blank	Populated through the RI Item Upload Process.
Processed Time	Blank	Populated through the RI Item Upload Process.
Offer for Item Offer	Offer from periodic function	The offer code defaults from the Parameter defined for the RMS Item Upload Periodic Function. If no offer code is specified for the periodic function, the Current Offer (A33) applies.
Effective Date	RPCS Effective Date	The date when the price becomes effective.
Qty	RPCS: Multi-Units	The quantity required for the price break. In the case of the CLRPC file (clearance price), the quantity is hard-coded to 1.
Price	RPCS Multi-Unit Retail	The item price.

PayPal Direct Connection Integration

Purpose: The PayPal Direct Connection integration enables you to use PayPal as a method of payment on web orders.

• The web storefront sends the PayPal payment on the order directly to PayPal for authorization. The order must receive an approved authorization on the web storefront before it is sent to Order Administration for processing.

• During pick slip generation, Order Administration verifies that the amount required to generate the pick slip is covered by the authorization received for the PayPal payment during web storefront processing. If the amount is not covered, the system places the order on Credit Card Decline hold and the PayPal payment on PayPal Decline hold.

• During deposit processing, Order Administration sends the deposit transaction directly to PayPal for confirmation and settlement.

• When an order is canceled or the PayPal payment method deactivated, Order Administration sends an authorization reversal request to PayPal.

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.

Note:

PayPal is a registered trademark

The Order Administration PayPal Direct Connection integration allows you to use PayPal as a form of payment on web orders and send the deposit transactions directly to PayPal.

Note:

Because the PayPal Direct Connection Integration does not send authorization transactions between Order Administration and PayPal, web orders containing a PayPal payment must receive an approved authorization on the web storefront before being sent to Order Administration for processing. In addition, you can only use PayPal as a form of payment on web orders. The Order Administration PayPal Direct Connection integration does not support PayPal as a form of payment on non-web orders.

In this topic: This topic provides an overview of the PayPal Direct Connection integration and the required setup.

• PayPal Direct Connection Integration Process

• Processing Orders Containing a PayPal Payment

  • Validating a Web Order that Contains a PayPal Payment

  • Maintaining a PayPal Order

  • Applying Refunds Across Multiple Capture Transaction IDs

• Processing Authorizations for a PayPal Order

  • PayPal Authorization Processing

  • Approved PayPal Authorizations

  • Declined PayPal Authorizations

• Processing Deposits for a PayPal Order

  • PayPal Deposit Processing

  • Approved PayPal Deposits

  • Failed PayPal Deposits

• Purchase Deposit Transactions

  • PayPal DoCapture Request

  • PayPal DoCapture Response

• Return Deposit Transactions

  • PayPal RefundTransaction Request

  • PayPal RefundTransaction Response

• PayPal Authorization Reversals

  • PayPal DoVoid Transaction Request

  • PayPal DoVoid Transaction Response

• PayPal Direct Connection Integration Restrictions

• PayPal Direct Connection Integration Troubleshooting

  • PayPal Log

• PayPal Direct Connection Integration Setup

  • Creating the PayPal Decline Order Hold Reason

  • Creating the PPL (PayPal) Service Bureau

  • Creating a PayPal Pay Type

PayPal Direct Connection Integration Process

• Processing Orders Containing a PayPal Payment

  • Validating a Web Order that Contains a PayPal Payment

  • Maintaining a PayPal Order

• Processing Authorizations for a PayPal Order

• Processing Deposits for a PayPal Order

PayPal Direct Connection integration illustration:

Processing Orders Containing a PayPal Payment

When a customer places an order on the web storefront and pays for the order using a PayPal account:

• The web storefront sends an authorization request for the PayPal payment directly to PayPal.

• PayPal validates the PayPal account number that is passed in the authorization request and sends PayPal confirmation information back to the web storefront.

• The web storefront completes the order and sends the order to Order Administration in the Inbound Order XML Message (CWORDERIN).

Web orders containing a PayPal payment that has been authorized by PayPal contain the following information in the Inbound Order XML Message (CWORDERIN). The authorization for the PayPal payment is sent to Order Administration as a manual authorization.

For more information see the Web Services Guide on My Oracle Support (ID 2953017.1).

• Regular order information

• PayPal pay type passed in the payment_type field

• PayPal transaction ID passed in the cc_number field

• Approved PayPal payment:

  • auth_amount

  • auth_number (this is the first 16 positions of the PayPal transaction ID)

  • auth_date (this is the date the PayPal payment was authorized with PayPal)

Validating a Web Order that Contains a PayPal Payment

Because the PayPal Direct Connection Integration does not send authorization transactions between Order Administration and PayPal, web orders containing a PayPal payment must receive an approved authorization on the web storefront before being sent to Order Administration for processing.

If Order Administration receives a web order that contains a PayPal payment that has not yet received an approved authorization, the system will accept the order; however, the PayPal payment will fail batch authorization and you will not be able to generate a pick slip for the order. See Processing Authorizations for a PayPal Order.

Maintaining a PayPal Order

When you advance to an order in order maintenance that contains a pay type with PPL (PayPal) defined as the authorization service and deposit service, the system displays the PayPal Warning Window indicating that you should not make any changes to the order that would increase the order total. When you generate a pick slip for an order that contains a PayPal payment, the system validates that the amount required to generate the pick slip does not exceed 15% or $75.00 of the initial authorization amount that was received from PayPal during web storefront processing.

Examples:

• If the authorization received from PayPal during web storefront processing is $100.00, you can increase the order total up to $115.00 ($100.00 + 15% = $115.00) and still process the order without any problems. However, once you exceed $115.00, the PayPal payment will fail batch authorization and the system will not generate a pick slip or perform drop ship processing for the order.

• If the authorization received from PayPal during web storefront processing is $600.00, you can increase the order total up to $675.00 and still process the order without any problems. However, once you exceed $675.00, the PayPal payment will fail batch authorization and the system will not generate a pick slip or perform drop ship processing for the order. Note: The system does not allow you to increase the order total by 15% ($600.00 + 15% = $690.00) because it would exceed $75.00 of the initial authorization amount that was received from PayPal during web storefront processing.

Reversals? The system submits a reversal to PayPal if:

• The entire order is canceled or sold out, or;

• The payment method is deactivated before any transactions are billed.

The system does not submit a reversal to PayPal for a partial amount, such as when:

• A single item on a multi-line order is canceled or sold out.

• A single unit on an order line is canceled or sold out.

• Any items remaining on the order are canceled after a shipment has taken place.

Also, the reversal is not submitted if any of the order lines have been submitted to Order Orchestration for fulfillment.

For more information: See Stored Value Card Authorization Reversal.

Applying Refunds Across Multiple Capture Transaction IDs

PayPal cannot process a refund that exceeds the amount of the initial deposit. For example, if an order includes two deposits of $25.00, PayPal requires that any single refund processed not exceed $25.00.

In order to be able to reconcile refunds against the initial deposits, Order Administration stores the TRANSACTIONID provided by PayPal for each deposit as the Capture Transaction ID in the Credit Card Deposit History table for each successful deposit with PayPal, so that each refund amount applies to a deposit amount.

Example: You process an order in two shipments:

• Shipment 1: $50.00

• Shipment 2: $40.00

During deposit processing, the capture transaction ID for each shipment is stored in the Credit Card Deposit History table. This ID is not displayed on any screen.

If you then need to process one or more refunds against the order, Order Administration uses the capture transaction IDs to reconcile the refund amounts. It uses the capture transaction ID that matches the refund amount, if any; otherwise, it uses the capture transaction ID for the lowest total shipment that exceeds the refund amount. For example:

• If the refund amount is $40.00: Use the capture transaction ID for shipment 2, because the amount matches this shipment.

• If the refund amount is $50:00: Use the capture transaction ID for shipment 1, because the amount matches this shipment.

• If the refund amount is $45:00: Use the capture transaction ID for shipment 1 (because $45.00 is more than the amount for shipment 2).

• If the refund amount is $25.00: Use the capture transaction ID for shipment 1 (because $25.00 does not match the amount of either deposit).

• If the refund amount is more than $50.00: Split the refund across both capture transaction IDs.

Sometimes multiple capture transaction ID are used for a refund deposit, because no single transaction is large enough to cover the refund. In these cases, the Display Order Payment History Screen indicates the number of deposits used for the total refund amount. For example, if you process a refund totaling $60.00 for an order with the two shipments, one for $50.00 and another for $25.00, the Display Order Payment History screen indicates:

• Partial Deposit confirmed $50.00-

• Partial Deposit confirmed $10.00-

• Deposit split into 2 separate deposits.

• Deposit confirmed $60.00-

Note:

These messages are not displayed at the Payment Method Details panel in Contact Center (Modern View Order Summary), although the purchase and deposit amounts are displayed.

In this situation, there is also an Order Transaction History message written, for example: Refund for inv# 1234 exceeds PayPal limit. Note that the message may be truncated based on the size of the invoice number.

Multiple refunds? Order Administration tracks the total returned amount for PayPal payment methods in order to ensure that subsequent refunds do not result in overusing any individual deposit amounts. For example, if there was a deposit for $50.00 and a deposit of $10.00, and there is already a refund amount of $40.00 applied to the first deposit, leaving $10.00 unrefunded, a subsequent refund of $15.00 would be split across the two deposits.

If the deposit fails: When the deposit is not initially processed successfully and you use Resubmitting Rejected Deposits (SRDP) instead, no capture transaction ID is recorded, so a refund cannot be applied to the deposit.

Note:

Deposits processed before update 20.0 will not have a capture transaction ID, so the process described above does not apply to these deposits.

Processing Authorizations for a PayPal Order

The system calls authorization processing when you generate a pick slip or perform drop ship processing for an order that contains a pay type with PPL (PayPal) defined as the authorization service. During authorization processing for an order that contains a PayPal pay type, the system validates that the required authorization amount is covered by the initial authorization received for the PayPal payment during web storefront processing.

• Approved PayPal Authorizations

  • Example: Approved PayPal Authorization

  • Example: Multiple Approved PayPal Authorizations

  • Example: Approved PayPal Authorization for Amount Within Allowed 15%

  • Example: Approved PayPal Authorization and Credit Card Authorization

• Declined PayPal Authorizations

  • Example: Declined PayPal Authorization for Amount Over 15%

  • Example: Declined PayPal Authorization for Amount Over $75.00

Note:

Orders containing a PayPal payment should have received an authorization from PayPal on the web storefront before the order was received into Order Administration. The system does not send a PayPal payment to PayPal for authorization during pick slip generation or drop ship processing.

PayPal Authorization Processing

The system performs the following steps during PayPal authorization processing.

#	Step
1.	The system determines if a manual authorization exists for the PayPal payment on the order.
	If a manual authorization does not exist for the PayPal payment on the order, the system declines the authorization. See Declined PayPal Authorizations for the updates that the system performs.
	If a manual authorization exists for the PayPal payment on the order, the system determines if this if the first time authorization processing was called for the PayPal payment on the order.
2.	If this is the first time authorization processing was called for the PayPal payment on the order, the system: Creates an order history record indicating the manual authorization was detected. This record indicates: The date when the order history record was created. The first 16 positions of the PayPal transaction ID. The amount that was manually authorized. This is the amount that was authorized by PayPal on the web storefront. Creates an authorization history record for the manual authorization. This record indicates: That the authorization was authorized. The first 16 positions of the PayPal transaction ID in the Authorization # field. The date the PayPal payment was authorized by PayPal on the web storefront. The date the authorization expires. The amount authorized for the PayPal payment. The amount available to apply towards other authorization requests. This amount equals the amount authorized until the system approves an authorization request.

Order history record for manual authorization: The system creates an order history record for the authorization that was received from PayPal on the web storefront. For example:

Date	Type	Transaction Note	Amount	User
7/28/09	AUTH	MANUAL AUTH# DETECTED - O-AUTH_CODE	100.00	AUTH

Authorization history record for manual authorization: The system creates an approved authorization history record for the authorization that was received from PayPal on the web storefront. For example:   

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	100.00

#	Step
3.	The system determines if the initial authorization has expired. The system uses the following calculation to determine the expiration date: authorization date from Authorization History table + Reauthorization days from Pay Type table = authorization expiration date For example, if the initial authorization date is 7/01/09 and the Reauthorization days is 29, the initial authorization expires on 7/29/09 (7/01/09 + 29 = 7/29/09). If the initial authorization has expired, the system declines the authorization. See Declined PayPal Authorizations for the updates that the system performs.
4.	The system determines if the amount of the authorization request exceeds the manual authorization. The system allows the authorization request amount to be 15%, or up to $75.00, over the initial authorization amount. For example: If the manual authorization is for $100.00, the authorization request cannot exceed $115.00 ($100.00 + 15% = $115.00). If the manual authorization is for $600.00, the authorization request cannot exceed $675.00. The system does not allow an increase of 15% to the $600.00 authorization because 15% of $600.00 exceeds $75.00 (600.00 + 15% = 690.00). If the authorization request amount exceeds the initial authorization by 15% or $75.00, the system declines the authorization. See Declined PayPal Authorizations for the updates that the system performs. Orders that Contain a Catch-All Credit Card Pay Type If the order contains a catch-all credit card pay type in addition to the PayPal pay type, instead of declining the PayPal authorization, the system adds the amount that exceeds the manual authorization to the catch-all credit card pay type on the order. In this situation, the system approves the PayPal authorization for the manual authorization amount and applies the amount not covered by the manual authorization to the catch-all credit card. For example, if the manual authorization for the PayPal pay type is $100.00 and the order total is $124.00, the system approves the PayPal authorization request for $100.00 and applies $24.00 towards the catch-all credit card on the order.
5.	If the amount of the authorization request is covered by the manual authorization or exceeds the manual authorization but is within the 15% or $75.00 allowance, the system approves the authorization. If the approved authorization amount exceeds the manual authorization, the system creates a new authorization history record for the extra amount. This record indicates: That the authorization was authorized. The first 16 positions of the PayPal transaction ID in the Authorization # field. The date the PayPal payment was authorized; this is the date the initial authorization was received from PayPal. The date the authorization expires. The extra amount authorized for the PayPal payment. See Approved PayPal Authorizations for the updates that the system performs.

Approved PayPal Authorizations

If the authorization received for the PayPal payment during web storefront processing covers the amount in the authorization request, the system:

• Generates a pick slip or performs drop ship processing for the order.

• Decreases the Amount available for the initial authorization history record by the authorization request amount. For example, if the initial authorization amount received on the web storefront is $100.00, and the authorization request amount is $28.00, the remaining amount available on the initial authorization is $72.00.

• If the authorization request amount exceeds the manual authorization received for the PayPal payment, but is within the 15% or $75.00 allowance, the system creates a new authorization history record for the extra amount.

Updated authorization history record for manual authorization:

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	72.00

New authorization history record for the amount not covered by the manual authorization but within the 15% or $75.00 allowance:

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	7/28/09	8/26/09	12.00	.00

Example: Approved PayPal Authorization

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00 and PayPal authorizes the payment for $100.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-CC_NUMBER (this is the PayPal transaction ID)

• auth_amount = 100.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the authorization date.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $100.00. Because the unused authorization amount of $100.00 covers the amount required to generate a pick slip for the order, the system:

• Generates the pick slip.

• Creates an order history record:

Date	Type	Transaction Note	Amount	User
6/26/09	AUTH	MANUAL AUTH# DETECTED - O-AUTH_CODE	100.00	AUTH

• Creates an authorization history record for the PayPal payment on the order.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	100.00	.00

Example: Multiple Approved PayPal Authorizations

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00 and PayPal approves the payment for $100.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

• auth_amount = 100.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the authorization date.

You generate a pick slip for part of the order. The authorization amount required to generate a pick slip for the order is $42.00. Because the unused authorization amount of $100.00 covers the amount required to generate a pick slip for the order, the system:

• Generates the pick slip.

• Creates an order history record:

Date	Type	Transaction Note	Amount	User
6/26/09	AUTH	MANUAL AUTH# DETECTED - O-AUTH_CODE	100.00	AUTH

Creates an authorization history record.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	100.00	58.00

You generate a pick slip for the remainder of the order. The authorization amount required to generate a pick slip for the order is $58.00. Because the unused authorization amount of $58.00 covers the amount required to generate a pick slip for the order, the system:

• Generates the pick slip.

• Updates the authorization history record.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	58.00	0.00

Example: Approved PayPal Authorization for Amount Within Allowed 15%

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00 and PayPal approves the payment for $100.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

• auth_amount = 100.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the authorization date.

You maintain the order and as a result the order total increases to $110.50.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $110.50. Because the required authorization amount is within 15% of the unused authorization amount of $100.00, the system:

• Generates the pick slip.

• Creates an order history record:

Date	Type	Transaction Note	Amount	User
6/27/09	AUTH	MANUAL AUTH# DETECTED - O-AUTH_CODE	100.00	AUTH

Creates authorization history records:

• One authorization history record for the original authorization amount received from PayPal on the web storefront.

• One authorization history record for the amount that was over the original authorization amount, but within 15% of the original authorization amount.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	100.00	0.00
Authorized	O-AUTH_CODE	6/26/09	7/25/09	10.50	0.00

Example: Approved PayPal Authorization and Credit Card Authorization

Declined PayPal Authorizations

If the authorization received for the PayPal payment during web storefront processing does not cover the authorization request amount, the system places the order on hold and does not generate a pick slip or perform drop ship processing for the order.

The system declines the PayPal authorization for the following reasons:

• A manual authorization does not exist for the PayPal payment, or

• The initial authorization received from PayPal on the web storefront has expired, or

• The authorization request amount exceeds 15% of the initial authorization amount received from PayPal on the web storefront, or

• The authorization request amount exceeds $75.00 of the initial authorization amount received from PayPal on the web storefront.

If the authorization received for the PayPal payment during web storefront processing cannot cover the authorization request amount, or a manual authorization for the PayPal payment does not exist, the system:

• Does not generate a pick slip or perform drop ship processing for the order.

• If the authorization was declined because the initial authorization has expired, the system updates the Amount available for the initial authorization history record to zero. For example:

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09 EXPIRED	100.00	.00

• If the authorization was declined because the initial authorization amount cannot cover the authorization request amount, the system does not update the initial authorization history record. For example:

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	7/27/09	8/25/09	100.00	100.00

• Creates an authorization history record for the declined authorization amount. For example:

Status	Vendor Response	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Declined	PPLDECLINE		7/27/09	8/25/09	39.00	.00

• Places the order on Declined Credit Card (AT) hold and the PayPal payment on the hold reason defined for the PPLDECLINE response code (typically PP PayPal Decline). Note:

• If the PPLDECLINE response code has not been set up for the PPL service bureau, the system places the order on AV hold.

• If the PPLDECLINE response code exists, but a hold reason is not defined for the response code, the system does not place the order on hold, but does not generate a pick slip for the order since the initial authorization for the PayPal payment is not valid.

• Creates order history records indicating the authorization was declined and the order as put on hold. For example:

Date	Type	Transaction Note	Amount	User
7/27/09	PICKGEN	ORDER FLAGGED FOR CREDITCARD CANCELLATIO		USER
7/27/09	HOLD	SYS HLD - DECLINED CREDIT CARD	39.00	USER

Correcting PayPal authorization declines: If Order Administration declines the PayPal authorization request, you will need to correct the error by either:

• Maintaining the order and reducing the order total so that it does not exceed 15% or $75.00 of the initial authorization amount received from PayPal on the web storefront.

• Calling the customer on the order to ask for an additional form of payment to cover the amount that exceeds the initial authorization amount received from PayPal on the web storefront.

• Canceling the order.

Note:

Before you run pick slip generation or perform drop ship processing for the order again, make sure to remove the order from hold.

Example: Declined PayPal Authorization for Amount Over 15%

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00 and PayPal approves the payment for $100.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

• auth_amount = 100.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the current date.

You maintain the order and as a result the order total increases to $122.50.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $122.50. Because the unused authorization amount of $100.00 does not cover the amount required to generate a pick slip for the order, and the amount required exceeds 15% of the unused authorization, the system:

• Does not generate a pick slip.

• Declines the PayPal authorization.

• Places the order on Credit Card Decline (AT) hold and the PayPal payment on the hold reason defined for the PPLDECLINE response code.

• Creates order history records, indicating the PayPal authorization was declined:

Date	Type	Transaction Note	Amount	User
6/26/09	AUTH	MANUAL AUTH# DETECTED - O-42693038SP2401	100.00	AUTH
6/26/09	PICK GEN	ORDER FLAGGED FOR CREDITCARD CANCELLATIO		USER
6/26/09	HOLD	SYS HLD - DECLINED CREDIT CARD	22.50	USER

Creates authorization history records for the PayPal payment on the order, indicating the authorization was declined.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	100.00	100.00
Declined		6/26/09	7/25/09	22.50	0.00

The system allows you to generate a pick slip for the order if:

• You maintain the order and decrease the amount so that it does not exceed 15% of the unused PayPal authorization ($115.00), or

• You maintain the order and apply the amount that exceeds 15% of the unused PayPal authorization towards another form of payment.

Example: Declined PayPal Authorization for Amount Over $75.00

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $600.00 and PayPal approves the payment for $600.00. The web storefront sends the order to Order Administration with a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

• auth_amount = 600.00

• auth_number = O-AUTH_CODE (this is the first 16 positions of the PayPal transaction ID)

• auth_date = 06262009

Order Administration receives and processes the order. Based on the Reauthorization days defined for the PayPal pay type, the PayPal payment does not expire until 29 days from the current date.

You maintain the order and as a result the order total increases to $680.00.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $680.00. While $680.00 is within 15% of the unused PayPal authorization, it is greater than $75.00 of the unused authorization. Because the authorization amount required to generate a pick slip for the order ($680.00) is greater than $75.00 of the unused PayPal authorization ($600.00), the system:

• Does not generate a pick slip.

• Declines the PayPal authorization.

• Places the order on Credit Card Decline (AT) hold and the PayPal payment on the hold reason defined for the PPLDECLINE response code.

• Creates order history records, indicating the PayPal authorization was declined:

Date	Type	Transaction Note	Amount	User
6/26/09	AUTH	MANUAL AUTH# DETECTED - O-42693038SP2401	600.00	AUTH
6/26/09	PICK GEN	ORDER FLAGGED FOR CREDITCARD CANCELLATIO		USER
6/26/09	HOLD	SYS HLD - DECLINED CREDIT CARD	80.00	USER

Creates authorization history records for the PayPal payment on the order, indicating the authorization was declined.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Authorized	O-AUTH_CODE	6/26/09	7/25/09	600.00	600.00
Declined		6/26/09	7/25/09	80.00	0.00

The system allows you to generate a pick slip for the order if:

• You maintain the order and decrease the amount so that it does not exceed $75.00 of the unused PayPal authorization ($675.00), or

• You maintain the order and apply the amount that exceeds $75.00 of the unused PayPal authorization towards another form of payment.

Example: Initial PayPal Authorization Expired

A customer places an order on the web storefront and uses PayPal as the form of payment. The order total is $100.00. Due to communication problems, the web storefront cannot send the PayPal payment to PayPal for approval. The web storefront sends the order to Order Administration without a manual authorization for the PayPal payment:

• cc_name = PAYPAL

• cc_number = O-AUTH_CODE (this is the PayPal transaction ID)

Order Administration receives and processes the order.

You generate a pick slip for the entire order. The authorization amount required to generate a pick slip for the order is $100.00. Because a manual authorization does not exist for the PayPal payment on the order, the system:

• Does not generate a pick slip.

• Declines the PayPal authorization.

• Places the order on Credit Card Decline (AT) hold and the PayPal payment on the hold reason defined for the PPLDECLINE response code.

• Creates order history records, indicating the PayPal authorization was declined:

Date	Type	Transaction Note	Amount	User
6/26/09	PICK GEN	ORDER FLAGGED FOR CREDITCARD CANCELLATIO		USER
6/26/09	HOLD	SYS HLD - DECLINED CREDIT CARD	100.00	USER

Creates an authorization history record for the PayPal payment on the order, indicating the authorization was declined.

Status	Auth #	Auth Date	Auth Expires	Amt Submitted	Amt Available
Declined		6/26/09	7/25/09	100.00	0.00

Processing Deposits for a PayPal Order

When you process deposits for an order that contains a pay type with PPL (PayPal) defined as the deposit service, the system sends the deposit transaction directly to PayPal via PayPal SOAP API architecture.

• PayPal Deposit Processing

  • Approved PayPal Deposits

  • Failed PayPal Deposits

• Purchase Deposit Transactions

  • PayPal DoCapture Request

  • PayPal DoCapture Response

• Return Deposit Transactions

  • PayPal RefundTransaction Request

  • PayPal RefundTransaction Response

PayPal Deposit Processing

The system performs the following steps during PayPal deposit processing.

#	Step
1.	Determines if the deposit is for a debit or credit transaction. If the deposit transaction is for a debit transaction, the system sends the PayPal DoCapture Request to PayPal. If the deposit transaction is for a credit transaction, the system sends the PayPal RefundTransaction Request to PayPal.
2.	PayPal processes the deposit and sends the response back to Order Administration. If the deposit transaction is for a debit transaction, PayPal sends the PayPal DoCapture Response to Order Administration. If the deposit transaction is for a credit transaction, PayPal sends the PayPal RefundTransaction Response to Order Administration.
3.	Order Administration receives the response and processes the deposit. See Approved PayPal Deposits and Failed PayPal Deposits.

Approved PayPal Deposits

If the deposit for the PayPal payment was approved, the system:

• For debit transactions, updates the authorization history record with the deposit amount. For example:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Dep
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	28.00

• Creates a deposit history record for the deposit transaction.

For debit transactions:

Inv#	Type	Date	Amt	Status	Response	Action
467	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit

For credit transactions:

Inv#	Type	Date	Amt	Status	Response	Action
479	*RETURN	7/30/09	20.00-	CONFIRMED	*PROCESSED	Return

• For debit transactions:

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response. However, if a transaction ID is already defined in the Authentication value field, the system replaces the transaction ID only if the deposit amount for the current deposit transaction is equal to or greater than the deposit amount for the previous deposit transaction. For example, If you process two deposit transactions for a PayPal order: the first deposit for $25.00 and the second deposit for $40.00, when you process the second deposit, the system updates the transaction ID defined in the Authentication value field with the transaction ID returned for the second deposit since the second deposit amount ($40.00) is greater than the first deposit amount ($25.00).

• During deposit processing, updates the Credit Card Deposit History table with the transaction ID for each successful deposit, storing it as the capture transaction ID. The system then uses this capture transaction ID to tie refunds, if generated, to individual deposits; see Applying Refunds Across Multiple Capture Transaction IDs for more information. This ID is not displayed on any screen.

Example: Approved PayPal Deposit Across Multiple Authorizations

The PayPal payment on an order has the following authorization history records:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	.00
Authorized	O-AUTH_CODE	7/28/09	8/26/09	12.00	.00	.00

You submit a debit deposit transaction for the PayPal payment for $112.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history records with the deposit amount of $112.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	100.00
Authorized	O-AUTH_CODE	7/28/09	8/26/09	12.00	.00	12.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
469	*PURCH	7/28/09	112.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response.

Example: Approved PayPal Deposit Across Multiple Deposits; Authentication Value Updated

The PayPal payment on an order has the following authorization history record:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	.00

You submit a debit deposit transaction for the PayPal payment for $28.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $28.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	28.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
469	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response.

• You submit a second debit deposit transaction for the PayPal payment for $28.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $28.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	56.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
469	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit
470	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response. The system performs this update because the deposit amount for the current deposit transaction ($28.00) is equal to the deposit amount for the previous deposit transaction.

• You submit a third debit deposit transaction for the PayPal payment for $44.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $44.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	44.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
469	*PURCH	7/28/09	28.00	CONFIRMED	*PROCESSED	Deposit
470	*PURCH	7/29/09	28.00	CONFIRMED	*PROCESSED	Deposit
471	*PURCH	7/30/09	44.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response. The system performs this update because the deposit amount for the current deposit transaction ($44.00) is greater than the deposit amount for the previous deposit transaction ($28.00).

Example: Approved PayPal Deposit Across Multiple Deposits; Authentication Value Not Updated

The PayPal payment on an order has the following authorization history record:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	.00

You submit a debit deposit transaction for the PayPal payment for $56.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $56.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	56.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
472	*PURCH	7/28/09	56.00	CONFIRMED	*PROCESSED	Deposit

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response.

• You submit a second debit deposit transaction for the PayPal payment for $44.00. Order Administration sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history record with the deposit amount of $44.00.

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	44.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
472	*PURCH	7/28/09	56.00	CONFIRMED	*PROCESSED	Deposit
473	*PURCH	7/28/09	44.00	CONFIRMED	*PROCESSED	Deposit

• Does not update the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response. The system does not update this field because the deposit amount for the current deposit transaction ($44.00) is less than the deposit amount for the previous deposit transaction ($56.00).

Example: Approved PayPal Deposit and Catch-All Credit Card Deposit

The PayPal pay type on an order has the following authorization history record:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	.00

The catch-all credit card pay type on the order has the following authorization history record:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	AUTH_#	7/28/09	8/26/09	24.00	.00	.00

You submit a debit deposit transaction for the order for $124.00. Order Administration:

• Sends the deposit transaction for the credit card to the service bureau for deposit processing.

• Sends the deposit transaction to PayPal in the PayPal DoCapture Request and receives the approved response in the PayPal DoCapture Response.

Order Administration:

• Updates the authorization history records with the deposit amount of $124.00.

PayPal pay type:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/28/09	8/26/09	100.00	.00	124.00

Catch-all Credit Card pay type:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	AUTH_#	7/28/09	8/26/09	24.00	.00	24.00

• Creates a deposit history record for the deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action	Ser
475	*PURCH	7/28/09	100.00	CONFIRMED	*PROCESSED	Deposit	PPL
475	*PURCH	7/28/09	24.00	CONFIRMED	100	Deposit	PMT

• Updates the Authentication value field in the Order Payment Method table with the transaction ID returned in the PayPal DoCapture Response.

Example: Approved PayPal Credit Deposit

The PayPal payment on an order has the following authorization history records:

Status	Auth #	Auth Date	Auth Expires	Amt Submit	Amt Avail	Amt Deposit
Authorized	O-AUTH_CODE	7/30/09	8/28/09	100.00	.00	100.00
Authorized	O-AUTH_CODE	7/30/09	8/28/09	14.19	.00	14.19

A debit deposit history record exists for the order:

Inv#	Type	Date	Amt	Status	Response	Action
480	*PURCH	7/30/09	114.20	CONFIRMED	*PROCESSED	Deposit

The customer returns part of the order for a credit of $22.00.

You submit a credit deposit transaction for the PayPal payment for $22.00. Order Administration sends the deposit transaction to PayPal in the PayPal RefundTransaction Request and receives the approved response in the PayPal RefundTransaction Response.

Order Administration creates a deposit history record for the credit deposit transaction.

Inv#	Type	Date	Amt	Status	Response	Action
481	*PURCH	7/30/09	22.00-	CONFIRMED	*PROCESSED	Return

Failed PayPal Deposits

The deposit transaction will be rejected if:

• Communication failures occur between Order Administration and PayPal.

• A duplicate deposit transaction already exists on the PayPal system.

• For debit deposit transactions:

  • The debit amount is greater than the associated authorization amount.

  • The transaction ID defined for the deposit does not match the associated authorization transaction.

• For credit deposit transactions:

  • The transaction ID defined for the deposit does not match the associated debit deposit transaction.

  • The credit amount is greater than the deposit amount.

For example, the PayPal payment on an order receives an authorization for $100.00.

On 6/24, the system ships part of the order for $40.00.

On 6/30, the system ships the rest of the order for $60.00.

On 7/15, the system processes a return for the order for $75.00.

Because the return amount of $75.00 is greater than each deposit amount, PayPal fails the return deposit.

Correcting failed deposits: You can use the Submit Rejected Deposits (SRDP) menu option to cancel or resend failed deposits.

See PayPal Direct Connection Integration Troubleshooting.

Purchase Deposit Transactions

Deposits for a debit (*PURCH) transaction use the PayPal DoCapture method to process the settlement. The system uses the API credentials (API User name, API Password, and API Signature) defined for the PPL service bureau as the credentials used to establish a direct connection to the PayPal system during deposit processing.

PayPal DoCapture Request

Order Administration sends the purchase deposit transaction to PayPal in the PayPal DoCapture Request transaction.

Parameter	Description
METHOD	DoCapture. Transactions sent to PayPal for a purchase deposit use the PayPal DoCapture API.
AUTHORIZATION ID	The transaction ID from the Credit card # field in the Order Payment Method table.
AMT	The amount of the deposit transaction. PayPal will accept an amount that is up to 15% or $75.00 more than the original authorization amount. Note:  This amount cannot exceed $10,000.
CURRENCYCODE	The PayPal currency code, from the ASC Currency code field in the Auth Service Currency table that corresponds to the Currency in the Order Header Extended table. If the Currency in the Order Header Extended table is blank, the system uses the currency code defined in the Local Currency Code (A55) system control value to determine which ASC Currency code in the Auth Service Currency table to use. If a cross reference is not defined in Authorization Service Currency for the selected currency code, the system leaves the CURRENCYCODE in the PayPal DoCapture Request blank; PayPal treats a blank CURRENCYCODE as USD currency. See the Work with Authorization Service Currency Screen to cross-reference the Order Administration currency code to the PayPal currency code.
COMPLETETYPE	NotComplete. This value indicates that there may be additional captures.
INVNUM	The company number and invoice number. Also includes the ecommerce order number if the Append Ecommerce Order # to PayPal Invoice ID (M40) system control value is selected. The company number and invoice number include leading zeros. Example:  006-0000467-EC12345, where 006 is the company number, 0000467 is the invoice number, and EC12345 is the ecommerce order number.
NOTE	The charge description from the Charge description field in the Authorization Service table, followed by the order number. A plus sign (+) displays for each space. Example:  PAYPAL+DIRECT+COMMUNICATION+1845, where PAYPAL DIRECT COMMUNICATION is the charge description and 1845 is the order number.

PayPal DoCapture Response

Order Administration receives the purchase deposit response transaction from PayPal in the PayPal DoCapture Response transaction.

Parameter	Description
AUTHORIZATION ID	The transaction ID from the card number field in the Order Payment Method table.
TRANSACTIONID	The unique transaction ID assigned by PayPal to the deposit confirmation. Updates the Authentication value field in the Order Payment Method table. However, if a transaction ID is already defined in the Authentication value field, the system replaces the transaction ID only if the deposit amount for the current deposit transaction is equal to or greater than the deposit amount for the previous deposit transaction. Example:  If you process two deposit transactions for a PayPal order: the first deposit for $25.00 and the second deposit for $40.00, when you process the second deposit, the system updates the transaction ID defined in the Authentication value field with the transaction ID returned for the second deposit since the second deposit amount ($40.00) is greater than the first deposit amount ($25.00). Capture transaction ID: During deposit processing, the system updates the Credit Card Deposit History table with this transaction ID for each successful deposit, storing it as the capture transaction ID. The system then uses this capture transaction ID to tie refunds, if generated, to individual deposits; see Applying Refunds Across Multiple Capture Transaction IDs for more information. This ID is not displayed on any screen.
PARENT TRANSACTIONID
PAYMENTTYPE	Indicates whether the payment is instant or delayed.
ORDERTIME	The date and time when the payment was processed by PayPal. Example:  2009-07-24T17:23:15Z
AMT	The final amount charged, including any shipping and taxes from the Merchant Profile.
FEEAMT	The PayPal fee amount charged for the transaction.
SETTLEAMT	The amount deposited in the merchant’s PayPal account if there is a currency conversion.
EXCHANGERATE	The exchange rate if a currency conversion occurred.
PAYMENTSTATUS	Order Administration considers a deposit successful if the following status is received: Completed = The payment was completed, and the funds were added successfully to the merchant’s account balance. Refunded = The merchant refunded the payment. Processed = A payment was accepted. The system considers any other response a rejected deposit. Updates the Response field in the Deposit History table.

Return Deposit Transactions

Deposits for a credit (*RETURN) transaction use the PayPal RefundTransaction method to process the settlement. The system uses the API credentials (API User name, API Password, and API Signature) defined for the PPL service bureau as the credentials used to establish a direct connection to the PayPal system during deposit processing.

PayPal RefundTransaction Request

Order Administration sends the return deposit request transaction to PayPal in the PayPal RefundTransaction Request transaction.

Parameter	Description
METHOD	RefundTransaction. Transactions sent to PayPal for a return deposit use the PayPal RefundTransaction API.
TRANSACTIONID	The transaction ID from the Authentication value field in the Order Payment Method table for the record associated with the first non-deactivated PayPal pay type. This ID is also stored in the Credit Card Deposit History table as the capture transaction ID. The system uses this value to match a purchase deposit to the return deposit. When a refund is applied across multiple transactions, the system uses the capture transaction IDs to reconcile the refund amounts and submits each refund amount separately based on the originating capture transaction ID. See Applying Refunds Across Multiple Capture Transaction IDs for a discussion. If a transaction ID does not exist in the Authentication value, the system sends a blank Authorization ID field to PayPal. Because PayPal cannot match a purchase deposit to the return deposit, the system places the return deposit in a failed status.
REFUNDTYPE	The type of refund to make. Set to Partial.
AMT	The amount of the deposit (refund) transaction. Return Amount PayPal does not accept returns for an amount that is greater than the original deposit amount. For example, the PayPal payment on an order receives an authorization for $100.00. On 6/24, the system ships part of the order for $40.00. On 6/30, the system ships the rest of the order for $60.00. On 7/15, the system processes a return for the order for $75.00. Because the return amount of $75.00 is greater than each deposit amount, PayPal fails the return deposit.
NOTE	The charge description from the Charge description field in the Authorization Service table, followed by the order number. A plus sign (+) displays for each space. Example:  PAYPAL+DIRECT+COMMUNICATION+1845, where PAYPAL DIRECT COMMUNICATION is the charge description and 1845 is the order number.

PayPal RefundTransaction Response

Order Administration receives the return deposit response transaction from PayPal in the PayPal RefundTransaction Response transaction.

Parameter	Description
REFUND TRANSACTIONID	The unique transaction ID assigned by PayPal to the deposit confirmation.
NETREFUNDAMT	The amount subtracted from the PayPal balance of the original recipient of payment to make this refund.
FEEREFUNDAMT	The transaction fee refunded to the original recipient of payment.
GROSSREFUND AMT	The amount of money refunded to the original payer.

PayPal Authorization Reversals

Authorization reversals use the PayPal DoVoid method to request the reversal. The system uses the API credentials (API User name, API Password, and API Signature) defined for the PPL service bureau as the credentials used to establish a direct connection to the PayPal system when processing a stored value card authorization trigger record (File/Key = AHR).

Sent when? The system creates authorization reversal triggers only if the Send reversal flag is selected for PayPal in Defining Authorization Services (WASV). Also, the system sends a DoVoid request for a reversal only if:

• The entire order is canceled or sold out, or;

• The payment method is deactivated before any transactions are billed.

The system does not submit a reversal to PayPal for a partial amount, such as when:

• A single item on a multi-line order is canceled or sold out.

• A single unit on an order line is canceled or sold out.

• Any items remaining on the order are canceled after a shipment has taken place.

For more information: See:

• Stored Value Card Authorization Reversal for background.

• Working with Outbound Interface Transactions (WOIT) for information on creating and processing outbound interface triggers.

• Defining Authorization Services (WASV) for information on setting up PayPal as an authorization service.

PayPal DoVoid Transaction Request

Order Administration sends the DoVoid request to PayPal to request an authorization reversal.

The DoVoid request specifies the stored value card number for the Order Payment Method as the AUTHORIZATIONID.

PayPal DoVoid Transaction Response

The DoVoid response confirms that the DoVoid request was successful and echoes the AUTHORIZATIONID.

PayPal Direct Connection Integration Restrictions

The Order Administration PayPal Direct Connection does not support the following.

• Online or batch authorization processing in Order Administration. Web orders containing a PayPal payment must receive an approved authorization from PayPal on the web storefront before being sent to Order Administration for processing.

• Additions to orders that contain a PayPal pay type in Order Maintenance that would exceed 15% or $75.00 of the initial authorization received for the PayPal payment. For example, if the authorization received for the PayPal payment is $100.00, you can apply up to $115.00 towards the PayPal authorization ($100.00 + 15% = $115.00).

• Orders that contain multiple ship to customers.

• Gift card payments.

• Alias items.

• Promotions applied to web orders in Order Administration. Final order amounts must be passed from the web storefront.

• Authorization reversals are supported only for the full amount of the authorization when the entire order is canceled or sold out, when the payment method is deactivated.

• Exchanges and returns performed through order entry are not recommended when the pay type on the order is PayPal; however, the system does not prevent either activity.

• Exchanges are not supported if there is a charge on the exchanged item. In this scenario, you must create a separate order for the new charge with a different customer payment.

• Returns/Refunds using the PayPal payment cannot be greater than the original deposit amount.

PayPal Direct Connection Integration Troubleshooting

If you have problems connecting to PayPal during deposit processing, use the following steps to help troubleshoot the issue.

PayPal service set up correctly? Verify that you have performed the required setup for the PayPal Direct Connection integration; see PayPal Direct Connection Integration Setup.

PayPal Log

When you process deposits for an order containing a PayPal pay type, the system sends the deposit transaction directly to PayPal and logs the transactional information in the PayPal log.

Information in log: The PayPal log includes a copy of the deposit information sent between Order Administration and PayPal. In addition, any errors that may occur during deposit transaction processing are captured in the log.

You can use this log to confirm that communication between Order Administration and PayPal is working correctly, to isolate communication problems, or the recover information.

Sample log information:

Successful deposit process generates IFO level messages, such as the following:

11:56:55,831 INFO PAYPAL - [Settlement] Transmitted deposit(*PURCH) Processed : AMT=20.94&INVNUM=I23-1754&NOTE=PAYPAL+1754&AUTHORIZATIONID=AUTH_ID&COMPLETETYPE=NotComplete&METHOD=DoCapture

Failure deposit process and errors during processing generates ERROR level messages, such as the following:

11:56:55,831 ERROR PAYPAL - [Settlement] Transmitted deposit(*PURCH) Failure : AMT=20.94=123-1234=PAYPAL+1754=AUTH_ID=NotComplete=DoCapture
11:57:06,581 ERROR PAYPAL - [Settlement] Timestamp      : 2009-05-08T15:52:55Z
11:57:08,737 ERROR PAYPAL - [Settlement] CorrelationId  : CORR_ID
11:57:10,284 ERROR PAYPAL - [Settlement] Error code     : 10002
11:57:11,972 ERROR PAYPAL - [Settlement] Short message  : Security error
11:57:15,018 ERROR PAYPAL - [Settlement] Long message   : Security header is not valid
11:57:17,300 ERROR PAYPAL - [Settlement] Severity code  : Error
11:57:20,297 INFO  PAYPAL - [Settlement] Transmitted deposit(*RETURN)Failure : AMT=68.00=123-123456=PAYPALID+7042982=AUTH_ID=NotComplete=RefundTransaction

The time elapsed to receive a response is indicated in a DEBUG level message, such as the following:

12:19:13,481 DEBUG PAYPAL - message: [Settlement] Got response, elapsed time = 2 seconds

Errors reading the authorization service or authorization service extended generates ERROR level messages, such as the following:

11:31:04,471 ERROR PAYPAL - [Settlement] Defaults set. Do not process in PayPal 'live' environment

11:31:31,841 ERROR PAYPAL - [Settlement] Exception(s) encountered during Initialization. No Deposit processing performed.

PayPal Direct Connection Integration Setup

Purpose: Before you can use the PayPal - Direct Connection integration, you must perform the necessary setup.

• Creating the PayPal Decline Order Hold Reason

• Creating the PPL (PayPal) Service Bureau

• Creating a PayPal Pay Type

If you are upgrading from 5.0: In 5.0, the PayPal credentials are stored in the System Properties (PPOP) menu option. When you upgrade from version 5.0, the PayPal credentials are stored in the Work with Authentication Services (WASV) menu option in the API user name, API password, and API signature fields. You will need to redefine your PayPal credentials as part of the upgrade process.

Type of PayPal integration: The PayPal Direct Connection integration uses PayPal’s Express Checkout to send deposit transactions between PayPal and Order Administration. Communication protocol is provided through the PayPal SOAP API Architecture, which uses a signed SOAP request over HTTPS. The PayPal API jar file, provided by PayPal and included with Order Administration, handles communication between PayPal and Order Administration.

In order to use the PayPal Direct Connection integration, your web storefront must support a direct connection to PayPal to perform authorizations.

Related system control value: In addition to the setup described below, you can use the Append Ecommerce Order # to PayPal Invoice ID (M40) to define whether to include the ecommerce order number in the INVNUM set to PayPal.

Creating the PayPal Decline Order Hold Reason

Use the Establishing Order Hold Reason Codes (WOHR) menu option to create the PP (PayPal Decline) order hold reason code. The system assigns this reason to the PayPal pay type on the order when it is declined during PayPal authorization processing at pick slip generation time.

At the Create Order Hold Reason Screen, enter the following information:

Field	Description
Reason	Enter PP.
Description	Enter PAYPAL DECLINE.

Creating the PPL (PayPal) Service Bureau

Use the Defining Authorization Services (WASV) menu option to create the PPL service bureau.

Multiple PayPal accounts: If you use multiple PayPal accounts, for example, each of your entities uses an individual PayPal account, you can:

• Use the Work with Merchant ID Overrides Screen to set up overrides for the different entities in your company. In this situation, you can define unique API credentials to establish a connection to the PayPal system for each of your PayPal accounts at the Create Merchant ID by Entity Screen. You can create one PayPal pay type for all of your accounts; see Creating a PayPal Pay Type.

• Use the Work with Authorization Service Currency Screen to set up a cross-reference between the Order Administration currency code and the PayPal currency code. When sending the PayPal DoCapture Request to PayPal, the system populates the CURRENCYCODE in the request with the ASC Currency code in the Auth Service Currency table that corresponds to the Currency in the Order Header Extended table.

  • If the Currency in the Order Header Extended table is blank, the system uses the currency code defined in the Local Currency Code (A55) system control value to determine which ASC Currency code in the Auth Service Currency table to use.

  • If a cross reference is not defined in Authorization Service Currency for the selected currency code, the system leaves the CURRENCYCODE in the PayPal DoCapture Request blank; PayPal treats a blank CURRENCYCODE as USD currency.

At the First Create Authorization Services Screen, enter the following information:

Field	Description
Service code	Enter the name of the PayPal account; for example PPL.
Application	Select Auth/Deposit.
Charge description	Enter PAYPAL DIRECT CONNECTION.

At the Second Create Authorization Service Screen, enter the following information:

Field	Description
Media type	Select Communication.
Batch/Online	Select Batch.
Active production system?	Select this field to send transactions to PayPal.
Primary authorization service	Enter PPL.
Test mode?	Select this field if you are sending transactions to PayPal’s test “sandbox” environment. Deselect this field if you are sending transactions to PayPal’s production “live” environment.
	The following fields are used to establish a connection to the PayPal system when using the PayPal Direct Connection Integration. You can also define API credential information at the entity level using the Create Merchant ID by Entity Screen.
API User name	Enter the user name, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing.
API Password	Enter the password, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing.
API Signature	Enter the encrypted signature, provided by PayPal, used to establish a direct connection to the PayPal system during deposit processing.

At the Create Vendor Response Screen, enter the following information:

Field	Description
Response code	Enter PPLDECLINE.
Description 1	Enter PAYPAL DECLINE.
Hold reason	Enter PP. If you do not enter PP as the hold reason, the system places the PayPal payment on AV hold.

Creating a PayPal Pay Type

Use the Work with Pay Types (WPAY) menu option to create the PayPal pay type, making sure to define the following information.

Field	Description
Pay category	Enter Credit Card (pay category 2).
Card type	Enter Credit (card type C).
Authorization service	Enter the name of the PayPal Direct Connection service bureau, for example, PPL.
Deposit service	Enter the name of the PayPal Direct Connection service bureau, for example, PPL.
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. Typically, PayPal payments are good for 29 days.
Send reversal	Select this field to enable sending reversals to PayPal when the value of the entire authorization amount is canceled or deactivated. See Stored Value Card Authorization Reversal for background.