COM object help

[LMan]

Help anyone know anything about ?

I am lost .....

 

-- SecurePay.Com Documentation ---- Version 2.5 07/11/2001

 

This file provides an overview for integration with the SecurePay.Com credit card gateway. The interface described in this document is designed for variables to be passed to the Gateway in the background via an ?https? call through a COM object, processed at SecurePay.Com and then sending a response to the request object with a the return variable set.

 

The Process:

 

1. The requestor interface makes a ?https? call to a COM object on their servers which contacts the SecurePay.Com gateway servers.

 

2. The Securepay.Com system initiates a transaction based on the data sent by the requestor.

 

3. The Securepay.Com system responds to the requestor object with the results of the submitted transaction.

 

4. The merchant interface interprets the response from SecurePay.Com based on the business rules the Merchant has defined.

 

 

Accessing the Securepay.Com Gateway:

 

The interface residing on the SecurePay.Com server will be in a pre-defined directory below is the directory for this process:

 

https://www.securepay.com/secure1/index.asp

 

This is the normal value for the URL variable used by the COM object.

 

Install the SecurePay.Com (See installation below) components on your web server. Then, in your scripts instantiate and set the required properties. The component has limited logic and error correction; most logic is left up to the developer. This is because of the different cases associated with processing transactions. Once the properties have been set, execute the send method. The component will then contact the script on the SecurePay.Com server, process the transaction and then return the response values back to the COM object.

 

For the scripts to function properly the following variables must be passed to SecurePay.Com via the COM object. Setting the variables is done by setting their values when creating an instance of the COM object. See the provided ?secure.asp? for an example of how the values are set.

 

The Following variables are mandatory for all transactions:

 

URL = ?The url of the cgi script to process the credit cards. This is always an ?https? value and the COM object will error if a non secure URL request is passed to it. The default value is:

 

https://www.securepay.com/secure1/index.asp

 

Amount = "The amount of the charge to be processed. This number should be the following format xxxx.xx, the dollar amount as a number followed with 2 decimal places. No dollar sign or other symbols are permitted. If the Amount formatting is not complied with it will generate and error."

 

Email = "The email of the customer making the purchase."

 

Merch_ID = "A unique Merchant identifier assigned to the Merchant by SecurePay.Com."

 

Tr_Type = "The type of transaction being processed. This variable can have two values.

 

SALE - Indicates a charge to be placed against a credit card account.

 

CREDIT ? Indicates a refund or ?credit? to be placed against a credit card account.

 

PREAUTH ? Indicates a pre-authorization on a Credit Card. This is a temporary block on

 

an Amount submitted by the Merchant. This is not a qualified transaction and if not

 

closed with a FORCE transaction it will release the block after 5-7 days depending on the

 

card issuer. This can have a negative impact on the funds availability of the card holder

 

and should be used appropriately.

 

FORCE ? Indicates a closure of a previously PREAUTH (pre-authorized) transaction. A

 

FORCE requires all data fields submitted with the original pre-authorization plus the

 

additional variable named APPROVNUMBER. The value of this field is the original

 

transaction Approval Number returned as the value of Approv_Num.

 

VOID ? Indicates a reversal of a transaction conducted on the same business day.

 

An additional variable must be passed with a VOID transaction. That variable

 

is the original record number assigned to the transaction. This number is passed with each successful transaction as the ?VoidRecNum?.

 

 

CC_Method = "The type of transaction being presented. Either ?DataEntry? or ?Swiped?.

 

Note: Swiped transactions require a Magnetic Stripe Reader to read the card. Only transaction with the MSR being read are processed as ?Swiped? all other transactions are ?DataEntry?.

 

____________________________________________________________________________

 

The Following variables are mandatory for ?DataEntry? transactions:

 

Note: See CC_Method above.

 

NameOnCard = "The name on the credit card."

 

CreditCardNumber = "The account number of the credit card. No dashes or spaces."

 

Month = "The 2 digit designation for the month of expiration on the card.

 

Example: 01 is January, 12 is December."

 

Year = "The 2 digit designation for the year of expiration on the card.

 

Example: 00 is 2000, 01 is 2001, 02 is 2002."

 

Street = "The street address in the billing address for the credit card."

 

City = "The City in the billing address for the credit card."

 

State = "The State in the billing address for the credit card."

 

Zip = "The Zip code in the billing address for the credit card."

 

AVSREQ = "The AVS type being requested. (See the AVS information below.)"

 

____________________________________________________________________________

 

 

 

The Following variables are mandatory for ?Swiped? transactions:

 

Note: See CC_Method above.

 

SwipeData =?SwipeData is the Magnetic Stripe Data from Track 1 on the Credit Card.?

 

Note: The Merchant Account must setup properly for Swiped transactions to be properly processed. To present swiped transactions without proper account settings could result in problems with a given processors security policies.

 

 

____________________________________________________________________________

 

The Following variables are optional for all transactions:

 

OPTIONAL VARIABLES = There are several optional variables that can be passed to provide specific information for special transaction types or data to be stored with each transaction.

 

"Two optional variables can be used that are stored with the transaction information in the SecurePay.Com database. These two variables correlate with the Comment1 and Comment2 fields used in the manual web terminal process. These fields can be passed to help manage and audit transactions using the reporting functions at SecurePay.Com.

 

On the Process Card page of the SecurePay.Com web terminal there are 2 comment fields, by default they are named Comment1 and Comment2. The descriptive names of these fields are configurable at SecurePay.Com in the Merchant Configuration database. Each Merchant can request to have these Comment fields uniquely named as required. For example the Comment1 field can be configured to be named ?Order ID? or ?Reference Number? or any other descriptive term. The Configured name will appear as such on the web terminal pages.

 

These custom named Comment fields also appear in the CSV file as the field names of that column in the file. The CSV report can be generated as part of the transaction reporting output.

 

Since these fields can be output in a transaction report the contents of the field can also propagated remotely through the use of the COM or Scripting interfaces used at SecurePay.Com.

 

When passing data in these fields the data passed in the Comment1 field will be output in a column with the name of Comment1 in the Merchant database. If the Merchant has this field named ?Order_ID? it will appear as the column heading in the CVS file with the Comment1 data stored as its record values. The same would apply to Comment2.

 

The Optional Variable names:

 

Comment1 = "An optional field used by the Merchant to aid in managing transactions.

 

Comment2 = "An second optional field used by the Merchant to aid in managing transactions.

 

VoidRecNum = The VoidRecNum is passed back with the Approval Code and other return variables on each approved transaction. If the transaction is to be reversed on the same business day as the original transaction a VOID transaction type may be initiated provided the original Record Number is passed to SecurePay with all other original transaction data. The value of the Record Number to be passed to SecurePay is the value of the ?VoidRecNum? assigned to the original transaction. The name of both the receiving variable and send variable is the same.

 

ApprovNumber = ApprovNumber is passed as a required variable when conducting a FORCE transaction. The value of the variable ApprovNumber is the original Approval Code from the pre-authorization. It is passed back in the response string from the transaction request sent to the COM object.

 

____________________________________________________________________________

 

 

The Following describes the results of a processed transaction:

 

After passing these variables to the interface on the SecurePay.Com server a transaction with the merchant's credit card processor will be made. The response of that transaction is returned to the script, interpreted for ease of use and the results are returned to the calling system as the following comma delimited string:

 

Return_Code, Approv_Num, Card_Response, and AVS_Response, VoidRecNum

 

Below are the output results of that call. Based on the return values of Return_Code, Approv_Num, Card_Response, AVS_Response, and VoidRecNum the merchant can personalize these results into a custom format for presentation to the customer.

 

The following 5 variables are returned:

 

Return_Code, Approv_Num, Card_Response, and AVS_Response.VoidRecNum

 

There are 3 possible responses from the Gateway with the Return_Code variable.

 

Return_Code: Y= approved, N= host decline

 

Approv_Num = The Approv_Num can have 2 possible responses.

 

1. "XXXXXX", the Approval number of the transaction.

 

2. "NONE", When a transaction is declined.

 

Card_Response= Verbose text from processor: APPROVED, INVALID CARD NUMBER.

 

The Card_Response can have many possible values. These are usually verbose descriptions of why a card was declined or the word "Approved" when transactions are accepted for processing.

 

AVS_Response = The output of the address comparison.

 

*If the AVSREQ property was not set this response will be ignored.

 

 

VoidRecNum = The Record Number of the Approved Transaction. The value is ?000? for Non-Approved Transactions. The VoidRecNum is required to conduct a Void or reversal of a transaction that was processed on the same business day. Transactions requiring reversal after the current business day are required to use the Credit transaction type.

 

____________________________________________________________________________

 

 

The AVSREQ variable is only required in DataEntry transactions.

 

Note: CC_Method above.

 

When making a transaction request the AVSREQ value must be set to one of

 

the following depending on the business rules you are implementing.

 

Note: The AVS system used by SecurePay.Com supports the United States. All AVS requests for Card Accounts issued outside the US may or may not return an AVS match. It is dependent on the card issuing bank and whether that card issuing bank subscribes and participates with the AVS system. AVS requests for cards issued outside the US where the bank does not participate in the AVS process will contain a specific AVS_Response of "G".

 

See below for other AVS responses.

 

Values for the AVSREQ variable:

 

AVSREQ = 0 Set the AVSREQ to "0" when you do not want to do an AVS Check.

 

AVSREQ = 1 Set the AVSREQ to "1" when you want a transaction authorization and a Full AVS (both street address and zip code).

 

AVSREQ = 2 Set the AVSREQ to "2" when you want an AVS only, Full AVS but do not authorize the Credit Card.

 

AVSREQ = 3 Set the AVSREQ to "3" when you want Credit Card Authorization and Zip Code AVS Only.

 

AVSREQ = 4 Set the AVSREQ to "4" when you want AVS with Zip Code only, do

 

not authorize the Credit Card.

 

 

Values for the AVS_Response:

 

The AVS_Response variable provides a method to develop a business rule set

 

to work in conjunction with the AVSREQ variable to limit merchant liability

 

in credit card acceptance. The AVS system involves presenting 2 pieces of data

 

to the processor as an comparative check against information the processor

 

has on file. The data used in this comparison are the "Billing Street Address"

 

and the "Billing Zip Code" of the credit card holder.

 

Dependent on the success of the comparative match on this information the

 

value of the AVS_Response variable will be one of the following:

 

AVS_Response =

 

A = Address (Street) matches, Zip does not.

 

E = AVS Error

 

G = Issuing bank does not subscribe to the AVS system.

 

N = no match on Address or Zip Code.

 

R = Retry, system unavailable or timed out.

 

S = Service not supported by issuer.

 

U = Address information unavailable.

 

W = 9 digit Zip matches, Address does not.

 

X = Exact AVS match.

 

Y = Address and 5 digit zip code match.

 

Z = 5 digit Zip Code matches, Address does not.

 

 

____________________________________________________________________________

 

Interpreting the Response:

 

In normal processing you can trap for "Return_Code" being "Y" for a successful authorization.

 

The "Approv_Num" will be the authorization approval number.

 

The "Card_Response" will be "Approval" or "Accepted".

 

The "AVS_Response" will contain the return value for the AVS comparative match as discussed earlier.

 

 

If "Return_Code" is "N" then the "Approv_Num" will equal "Not-Approved", the "Card_Response" field will contain more verbose information that may not be appropriate for the customer to see.

 

Terms like "CALL AUTH CENTER","PICK UP CARD" or other wording that explains why the transaction resulted in a Decline. This information is informative and should be captured but may better be suited for the merchant and not the customer. If the "Return_Code" is "N" you may want to give the customer an opportunity to pay with another card or by another method.

 

When requesting a transaction for "AVS check" the transaction is treated exactly as a "SALE" except the AVSREQ flag is set at "2" or "4".

 

The AVS_Response will equal the return output value based on the results of the comparative match as described above.

 

After an AVS check is completed and based on the Business Rules defined by the Merchant a second transaction request is made passing the same data set again. This time the AVSREQ flag should be set to "0", "1" or "3". An AVSREQ flag setting of "1" is the normal transaction mode.

 

The 4 variables (Return_Code, Approv_Num, Card_Response, and AVS_Response) are returned to the requesting object as comma delimited string.

 

Return_Code,Approv_Num,Card_Response,AVS_Response

 

 

____________________________________________________________________________

 

 

Installation

 

This DLLs provided in this version are accompanied by a installation program and will need to be installed for use. Run the install program in the SPCom.zip file.

 

To install the Securepay.Com COM object:

 

From the Start button select Run.

 

Browse to the directory your files were extracted to.

 

In the "COM_Files" directory is the installable COM object.

 

Select SPCOM.msi file for Installation.

 

Select OK on the run menu.

 

The SecurePay.Com COM object will be installed.

 

 

***A sample script has been included with the SecurePay component.

 

The samples provided are Active Server Pages with VBScript. It is assumed that the web server where the DLL are registered support ASP and VBScript. Other scripting languages may work and SecurePay will assist the developers in integration if needed.

 

The files in the example are named test.asp and secure.asp both files are formatted with simplicity for ease of understanding. If you have questions about the use or methodology used by the components please contact SecurePay.Com.

 

All code is developed by SecurePay.Com is protected by Copyright.

 

Copyright 2001, SecurePay.Com, Inc., All rights Reserved.

 

Distribution rights are held by SecurePay.Com. This file is not to be published or distributed within written permission from SecurePay.Com.

 

Questions and inquiries should be directed to:

 

Tony Reynolds

 

SecurePay.Com

 

13339 North Central Expressway, Suite 100

 

Richardson, TX 75243

 

469-330-9551

 

1-866-GOHTTPS

 

[email protected]

 

Thanks

LMan

[LMan]

Anyone know how to do this??? :blink: