Electronic Credit Card Processing Orbital (Paymentech) Interface
______
ResponseDocumentation Supplement

Contents

Introduction to Electronic Credit Card Processing......

System Requirements......

Data considerations before implementation......

Response Setup......

System Operation......

Order Entry / Instant Authorization......

Authorize/Send New Orders (batch)......

Create/Send Deposits......

Authorize/Send Back Orders......

View CC Transactions......

Enter Credit/Debit Records......

Address Verification for Orbital (AVS)......

Overview......

Turning on the Address Verification System (AVS)......

ONE PASS versus Standard......

Duplicate Credit Card Transmissions......

APPENDIX A : Response Codes......

APPENDIX B : CVV2 Response Codes......

Glossary......

Questions and Answers......

NOTE: All Orbital installations and conversions must be scheduled in advance with CoLinear Support BEFORE you go live!

Introduction to Electronic Credit Card Processing

The Electronic Credit Card Interface is designed to allow you to process credit card orders in batches via modem or internet. You can authorize orders, send deposits and send credits in transaction files created in this module.

Instructions for using the Orbital Interface are provided in the sections that follow.

System Requirements

  • Response 9.x Build 4018 or greater
  • An internet connection for every workstation that will process credits either in real-time or batch mode. Internet Explorer 6.0 or higher (no other software or hardware is required).
  • Merchant information from Paymentech (Merchant ID)
  • Windows Service Packs Must Be Current!
    Make sure you have the latest service pack installed. A client running Win2000/SP2 had transmission problems that were remedied by installing SP4. So be sure you have the latest service pack for whatever version of Win32 you may be using.
  • Paymentech requires the IP address(es) of the production machines be listed with Paymentech, otherwise they get the error message listed in a file we create called testrecv.xml. For more information on how to "list" the IP addresses with Paymentech, Orbital Support Desk can be reached via the following telephone number or email address.
  • OrbitalGatewaySupportCenter
  • Phone: 1-866-645-1314
  • Email:

User Tip June 2005: because we use a NAT on our Firewall, we gave them the address of the firewall and the router and the range of in-house IP addresses and they were happy

Remember, if you’re using a NAT, all the outside world sees is the address of the gateway, in our case although we have 64 IP addresses, the only one the world sees for internet traffic is the gateway (router) address itself, 00.000.140.65

Firewall note: Response accesses the Orbital URL orbital1.paymentech.net/authorize on port 443.


Data considerations before implementation

Response users who are setting up ECC for the first time OR switching from a different Processor to Orbital need to do the following before changing the option to Orbital in the Response menu option for “Credit Card System file”:

  1. Important! Be sure you don’t have any printed/authorized orders (i.e. status W or Q orders). You must ship and confirm or unpick prior to the changeover to Orbital.
  2. SETTLE ALL CONFIRMED orders with your present (prior) processor. If you are using manual CC processing in Response, settle via the Response “Manual CC Processing procedures”.
  1. Print your Undeposited Shipped Credit Card Orders report with a starting date from 01/01/90 thru the present. You must make sure NOTHING shows on this report but headings. Doing so ensures that #1 is done.
  2. Authorization codes received from your present (prior) processor must be cleared so new codes can be received from Orbital. Orbital will not accept your old processors codes. You should use “enter voice authorizations” to blank out the current authorization code and authorization date in orders that were authorized via your prior processor. If you have a large qty we have a SQL script to help you clear the old auths. Request that from (clear_cc_auth&date.sql)
  3. When steps 1 thru 4 above are complete you can select Orbital as your processor in Credit Card System file and complete the new information on that screen.
Response Setup

STOP! YouMUSTdownloadandextract cc_Orbital.zip. Use this link, save the file to your \CoLinear\r4w\ folder:

Next, extract all files (5) to \r4w\data, the files are 4 XML files refund.xml, capture.xml, request.xml, void.xml. 2 .dtd files, Request_PTI26.dtd and Response_PTI26.dtd Orbital will not work without this. (Multi-company users also extract to \r4w\data\ not to the dataset directories). You will get errors if you don’t have these files

Run the Credit Card System Setup program before running any of the other Orbital Interface programs.

  • To run the Credit Card System File program:
  1. From the Response Main Menu, choose
  • Orders
  1. From the Orders menu, choose
  • Authorize/Deposit Orders
  1. From the Authorize/Deposit Orders menu, choose
  • Auto Credit Card Processing
  1. From the Auto Credit Card Processing menu, choose
  • Configure Setup File (to open Credit Card System File view)

Select Orbital from the combo box. The Credit Card System File menu displays the following.

Enter the following information:

  • Merchant ID (GROUP#) – Refer to the Merchant Information provided by Orbital/Paymentech. (Paymentech form shows this as the GROUP # see below)
  • If you are set up for Address Verification (AVS), check Use Address Verification (highly recommended that you do this!).
  • Mode: Choose LIVE for real transactions. Chosing TEST MODEmeans send the transactions to a test server, phony auth codes will be returned. Be aware that Response will NOT know the auth codes are phony. Response behaves as it would with a real authorization.
  • The URL for Orbital Gateway certification system (TEST MODE) is ‘orbitalvar1.paymentech.net/authorize’ on port 443(we don't hard-code the port, so it uses the default secure port 443.)
  • The URL for Orbital Gateway production system (LIVE) is orbital1.paymentech.net/authorize’ on port 443
  • User tip: we had to open port 443 but even then authorize generated a new error; status 9717 Security Information - agent/chain/merchant is missing. Also, The Orbital Gateway Virtual Terminal Security Code Matrix has the Merchant Number and a Group Number. In Response USE The Group Number is the Paymentech Mechant ID number. After putting the group number into this field I was able to authorize an order.

NOTE: If you checked Use Address Verification, refer to the Appendix section on AVS for instructions.

The Appendix appears at the end of this document.

Multi-division users may need to enter merchant info in their division setup record, see info here

Multiple Merchant IDS without multi division module

MEMO: If you have multiple merchant ID’s(Group#’s) and you need to assign the merchant ID based on the customer type the ctypemerch.fil works for Orbital in 9.x in build 4018 and greater. The Merchant/Group ID used above is overridden by any customer types you enter in CTYPEMERCH.FIL Any valid Customer Types that do NOT exist in that file will use the Merchant/Group# from Credit Card Setup.
ctypemerch.fil is an ascii text file comma delimited containing the format as follows:

CustTypeID,merchantID,password,phone# for cust service(although password and phone can be stored in the file as well, orbital doesn't use it)
CNSMR0011,111111333,password1,8005551212
CTYPE2,111111334,password2,8005551234
If the customer type is CNSMR001, the merchant ID 111111333 is used, etc.
Create the CTYPEMERCH.FIL in the \r4w\data directory (or data\00x in the case of multi company)

User tip: If authorize generates this error; status 9717 Security Information - agent/chain/merchant is missing. Have Paymentech verify they have tied your multiple Group numbers together on their side. Sometimes they forget this step.

4/12/2006 MULTIPLE MERCHANT ID’s per INVENTORY ITEM: Merchant IDs can optionally be setup per item in the Charges tab, Merchant IDs button.

Do not use ccdescriptor.fil with Orbital, it is for TransFirst ONLY

10/10/2011: User tip: If you have multiple accounts, they all need to be tied together by your processor (agent/chain/merchant).

· Response sends only one code at this higher level.

· Response can handle multiple Group Numbers to differentiate the companies/websites. Each Group Number need to be attached to a merchant ID and has to have your IP address associated with it.

System Operation

Authorization Life

Credit card authorization codes have a finite life. In some cases, authorization codes can be valid for up to 30 days after they have been obtained. For Orbital, ask Paymentech for the life of the authorization for EACH CC Type. Enter those values in Response, using the Payment Codes menu option under the File menu by finding each credit card type (M/C, VISA, etc.) and saving the appropriate value to the # days Authorization Valid field.

Order Entry / Instant Authorization

Instant Authorizations are done in Order Entry. In the Totals screen, after you have entered the credit card information, expiration, CVV(optional) and tabbed through the Shipping and Tax fields, press Alt+Z to authorize the current order (or click the Authorize! Button).

You can see the authorization code is received along with the authorization date, it will be saved with the order. If Paymentech returns a DECLINE , the messageon your screen will indicate the reason.

In the eventPaymentech returns an AVS codethat matches one of the codes you have setup for AVS decline, before we populate the auth code field, we’ll ask you:

Answering “Yes” declines the authorization. Behind the scenes, we’ll reverse the authorization that we just received.

Answering “No” will accept the authorization and you can continue on to save the order.

(see more on AVS and how it works in the appendix of this document)

TECH NOTE: AUTHORIZATION button while in Order Entrywe create testsent.xml and testrecv.xmlinstead of the Auth_inquiry file. The .xml files are in \data\00x\ and are not needed by Orbital, they are more of a debugging tool. They are continuously overwritten by the next transaction

Authorize/Send New Orders (batch)

In addition to authorizing at order entry you should authorize by batch at least once EACH DAY.

Select the Authorize/Send New Orders option from the C/Card Processing menu. This option will search all orders that require authorization for the specified date (and earlier dates, as appropriate). This procedure will NOT re-authorize orders that were authorized in Order Entry using the Alt+Z option. This authorize/send new orders will authorize orders that do not have an authorization code, and also orders whose authorizations have expired per your setup.

All credit card orders should be authorized before the merchandise is picked and shipped. By Default Response will NOT print an order without a valid authorization. In the event you want to print orders prior to authorizing them (not recommended!), you can do so by setting the checkbox on the Picking Tickets subtab on the System Options tab in Company Setup.
When AUTHORIZING ORDERS you have the following options:

  • You can limit authorization to specific credit card types (MC, VI, AX, etc.).
  • You can authorize all orders, regardless of credit card type
  • You can limit to orders with only designated % of items shippable or X dollar amount shippable

New orders are selected for authorization when the “requested ship date” is on or before the date specified here, provided the orders also satisfy the criteria outlined below:

  • The authorization code must be blank.
    NOTE: The program will check previously authorized orders to ensure that the code has not expired. If expired, the old code is blanked out so the order can be resubmitted for a fresh one.
  • The balance due on the order must be greater than zero.
    NOTE: If the balance due on the order is zero, the order will be assigned an authorization code of “N/A”.
    When the program has completed processing orders the Authorize New Order Inquiry Totals window will display. You may print out the totals for future reference.

After closing this window you will be notified that the file was created and is ready for transfer via Orbital.

(tech note: the file is named AUTH_INQUIRY without and extension in the …\r4w\data directory. Meaning you can run authorizations and deposits at the same time now. All transactions are appended to INQUIRY.LST before being deleted)

Click “OK” to send the data via Orbital.

When the file is sent to Orbital, a file is sent back to Response (file name: AUTH_RESPONSE, no file extension. . All transactions are appended to RESPONSE.LST before being deleted). This triggers the Receive/Process

procedure.

When this file is read in, you’ll see a summary screen as follows:

Orders that are declined will be updated with a status of ‘D’. Others will be updated with the authorization code returned by your bank.

You may be presented with a window like this showing orders that declinded

Window title: errors encountered during authorize new orders

Error text (example): Processing error 05 - "Do not Honor" encountered for order 100471.

NOTE: For those orders that are declined, the authorization code will be “DECL-?”, where ‘?’ is the status of the order at the time the auth was declined. (true 4018). Declined orders will show on the Declined Orders report.

Declined orders should be resolved promptly since they will continue to commit inventory and be reflected as sales (under the presumption that the declined status is only temporary). You should:

  • Print the Declined Credit Cards report (from the Other Order Reports menu).
  • Decide on the most appropriate strategy for your company to deal with declined orders. This may include calling the customers to request an alternate payment method, or trying to re-authorize it at a later date. To reset the order, just change the status from D to E (or P or B) in Order entry. Be sure the auth code and date fields become blank, then the order will be sent again the next to you authorize orders.
  • You MUST have Response acquire the authorization. Because Response updates other internal records with the authorizations information, Voice or “manual” authorizations obtained outside of Response cannot be entered into an order.
  • For information on establishing reauthorization rules go here:
  • Cancel the order if the customer is unable or unwilling to make payment.

Once authorized, picking tickets (i.e. fulfillment) for credit card orders can proceed.

After picking tickets have been printed, and the orders have been picked, packed, shipped, and confirmed, you can create a transaction file to send for deposit.

Authorize/Send Back Orders

Authorizing backorders is similar to authorizing new orders, with the following exceptions:

  • The requested ship date is no longer relevant. The fact that the order has been through the process once already (that is, it has been authorized, printed, and confirmed) means that the requested ship date has come and gone. The orders must now be filled as soon as stock becomes available to fill them.
  • Each order (including backorders) retains two values for percent shippable at all times. These are “% items shippable” and “% dollars shippable”. These figures fluctuate with your inventory levels (as inventory is received and/or adjusted). See View Unshipped Orders Info. (on the Print Orders menu) for more details.
  • Backorders are authorized if they meet the following criteria:
  • The order status is either ‘B’, ‘P’, or ‘Q’.
  • The order has a credit card number.
  • The authorization code must be blank.
    NOTE: The program will check previously authorized orders to ensure that the code is still valid. If the authorization code is stale (old), the program will clear the code and make the order available to be sent for authorization.
  • The order satisfies the percent shippable criteria (if any) that you have specified.

When the program has completed processing orders, you will be prompted to process the file. At this point, the file AUTH_INQUIRY has been created. To send this file via modem to be authorized, press a key.


After the request for authorization file (AUTH_INQUIRY) has been sent.

Create/Send Deposits

While authorization codes are based on the total balance due on an order, the deposit amount is based on the value of what actually shipped.

When an order is confirmed the system generates a unique shipment record. If it requires four separate shipments to complete an order (i.e. backorders) there will be four separate shipment records describing what was shipped each time. This shipment record contains the value of the shipment for which tax and shipping charges are typically pro-rated, though you may configure to bill both in full, up-front if you prefer. We advise against charging tax and shipping in full up-front, however. If the customer cancels a backorder and you have pro-rated tax and shipping charges, you potentially don’t owe them a refund.
You can view shipment records in Customer Service (Order Look-up). Find an order that is either fully shipped (status ‘S’) or partially shipped (status ‘P’). Then, from the options at the bottom of the screen, choose Shipments. For each shipment record, the value of the shipment is displayed in the Amount column. The date in the Confirm field is the date this shipment was confirmed.