CUSTOMER INTEGRATION
Customer Integration is used to pass customer information (name, physical address, e-mail address, etc.) from an independent source directly into the customer database used in the Online Store and Order Management System.
Popular uses include:
METHODOLOGY
Customer Integration is achieved via an HTTP POST (the Request POST) from the client's web site to the default page of the client's Online Store via the secure https protocol. The exact URL depends on which Online Store (BtoC or BtoB) is targeted.
Customer Integration may be used to identify existing customers, to create new customers, or both. If integration is used to identify existing customers, one or more "Match" fields (starting with Match1) are required. These "Match" fields are then used to identify the customer, while any other fields specified are used to update the customer's information. If new customers are being created, all fields listed as Required for New Customers are required. If the integration fields provided are not sufficient to uniquely determine the existing customer, or to create a new customer, then the integration fails. (Any error in the data provided likewise causes the integration to fail.)
MODES
Customer Integration may be operated in any of seven possible modes:
Reply-Only: Following the Request POST, an HTTP POST (the Reply POST) is sent back to a URL specified in the Request POST (the ReplyURL). The Reply POST contains the all of the data included in the Request POST, as well as the status of the integration attempt and reason for failure, if applicable. The ReplyURL must be a file that can accept an HTTP POST, and thus may not be a .htm (or .html) file. In this mode, it is inconsequential whether the Request POST is directed to the BtoC Store or the BtoB Store. Reply-Only is appropriate if you wish to keep the customer on your site regardless of the success or failure of the integration, and have the ability to read in the values of the Reply POST and take corresponding action.
Redirect-Only: Similar to the Reply-Only mode, the customer is redirected to a URL specified in the Request POST (the ReplyURL). In this mode, no data is sent to the ReplyURL, and thus a .htm (or .html) file is permitted. It is inconsequential whether the Request POST is directed to the BtoC Store or the BtoB Store. Redirect-Only is appropriate if you wish to keep the customer on your site regardless of the success or failure of the integration, but lack the ability to read in the values of the Reply POST and take corresponding action.
Proceed-Only: This is the default mode. Following the Request POST, the customer proceeds to the Online Store (either BtoC or BtoB, as appropriate). If the integration attempt is successful, the customer enters the store already logged in and never sees the store's login screen. If the integration attempt is unsuccessful, the customer must log in as usual. There is never a Reply POST in this mode. Proceed-Only is appropriate if you wish to send the customer into the Online Store regardless of the success or failure of the integration.
Display-Only: Following a successful integration attempt (via the Request POST), the word "Success" is displayed on screen. Following an unsuccessful integration attempt, the Failure Reason is displayed on screen. Display-Only is appropriate for debugging purposes when developing your integration, if you lack the ability to read in the values of the Reply POST used in the Reply-Failure mode.
Reply-Failure: Following a successful integration attempt (via the Request POST), the customer proceeds to the Online Store as in the Proceed-Only mode, and no Reply POST is sent. Following an unsuccessful integration attempt, a Reply POST is sent as in the Reply-Only mode. Reply-Failure is appropriate if you wish to send the customer into the Online Store only if the integration is successful, and have the ability to read in the values of the Reply POST and take corresponding action for an unsuccessful integration. Reply-Failure is also useful for debugging purposes when developing your integration.
Redirect-Failure: Following a successful integration attempt (via the Request POST), the customer proceeds to the Online Store as in the Proceed-Only mode. Following an unsuccessful integration attempt, the customer is redirected to the ReplyURL as in the Redirect-Only mode. Redirect-Failure is appropriate if you wish to send the customer into the Online Store only if the integration is successful, but lack the ability to read in the values of the Reply POST and take corresponding action for an unsuccessful integration.
Display-Failure: Following a successful integration attempt (via the Request POST), the customer proceeds to the Online Store as in the Proceed-Only mode. Following an unsuccessful integration attempt, the Failure Reason is displayed on screen as in the Display-Only mode. Display-Failure is appropriate for debugging purposes when developing your integration, if you lack the ability to read in the values of the Reply POST used in the Reply-Failure mode. Using Display-Failure in a live integration is not recommended.
Note: If the customer lands on a page within the Online Store following an integration attempt, the body tag of that page includes the css class nextIntegrationSuccess or nextIntegrationFailure, as appropriate.
REQUEST POST FIELDS
Customer Fields
Field Name | Description | Notes | Data Type (Max Length) | Required for New Customers |
LAST_NAME | Customer's Last Name | Text (50) | Yes | |
FIRST_NAME | Customer's First Name | Text (30) | Yes | |
Customer's E-Mail Address | Text (50) | Yes | ||
ADDRESS_LABEL | Customer's Contact Address Label | Text (25) | No | |
COMPANY_NAME | Customer's Company Name | Text (100) | Conditional1 | |
ADDRESS1 | Customer's Street Address, Line 1 | Text (100) | Yes | |
ADDRESS2 | Customer's Street Address, Line 2 | Text (100) | No | |
CITY | Customer's City | Text (50) | Yes | |
STATE | Customer's State/Province |
|
Text (2) | Conditional2 |
POSTAL_CODE | Customer's Postal (Zip) Code | Text (20) | Yes | |
COUNTRY | Customer's Country |
|
Text (2) | Yes |
ADDRESS_TYPE | Contact Address Type |
|
Boolean | No |
PHONE_NUM | Customer's Phone Number | Subject to a minimum number of digits if the Minimum Phone Digits feature is in use (Settings/Site Options in the Order Management System) | Text (30) | Yes |
PHONE_EXT | Customer's Phone Extension | Text (30) | No | |
PRIMARY_SHIP | Primary Ship To Address |
|
Boolean | No |
PRIMARY_BILL | Primary Bill To Address |
|
Boolean | No |
DISCOUNT | Customer Discount |
|
Float | No |
ACTIVE | Active Status |
|
Boolean | No |
MAILING_LIST | Mailing List Status |
|
Boolean | No |
CUST_TYPE | Customer Type |
|
Text (20) | No |
PASSWORD | Customer's Password | Text (50) | Conditional3 | |
PASSWORD_REMINDER | Customer's Password Reminder (Hint) | Text (100) | No | |
CUSTOM_FIELD1 | Custom Field #1 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD2 | Custom Field #2 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD3 | Custom Field #3 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD4 | Custom Field #4 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD5 | Custom Field #5 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD6 | Custom Field #6 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD7 | Custom Field #7 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD8 | Custom Field #8 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD9 | Custom Field #9 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD10 | Custom Field #10 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD11 | Custom Field #11 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD12 | Custom Field #12 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD13 | Custom Field #13 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD14 | Custom Field #14 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD15 | Custom Field #15 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD16 | Custom Field #16 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD17 | Custom Field #17 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD18 | Custom Field #18 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD19 | Custom Field #19 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOM_FIELD20 | Custom Field #20 | For type Yes/No, use 1 for Yes and 0 for No | Conditional (50) | Conditional4 |
CUSTOMER_NO | Customer Number | May be used for matching purposes only (will be ignored otherwise) | Integer | No |
Field Name | Description | Notes |
Matchn | nth field to be used for customer matching |
|
Mode | Integration Mode |
|
ReplyURL | URL to which the Reply POST is directed for Reply-Only and Reply-Failure modes; or to which the customer is redirected for Redirect-Only and Redirect-Failure modes |
|
REPLY POST FIELDS (Reply-Only and Reply-Failure modes only)
Field Name | Description | Notes |
(Same as Request POST) | (Same as Request POST) | Every field included in the Request POST is also included in the Reply POST, even if that field is not needed for Customer Integration |
Status | Integration Status | Value is either Success or Failure |
Action | Action Taken |
|
FailureReason | Reason for Failed Integration |
|