Integrate StoreFront 5.0 (classic ASP) with BluePay gateway

Options are seen here. Probably asp post will be used from an existing shopping cart. Credit card number and cvv2 must be entered directly into the BluePay form. See options here: <[login to view URL]> ## Deliverables Required fields posted from the shopping cart form. Below is an example of post required fields and optional fields. Bluepay 2.0 POST Method For automated integration. This interface is NOT for POSTing directly from a web form! The URL of this interface is currently: [login to view URL] PLEASE NOTE: This URL may change in the future. In integrating your system, please remember to make the URL a parameter you can easily change. If you are coding a shopping cart, please make the URL a parameter the merchant can easily set. REQUEST FORMAT: Expected input format is that of a standard HTTPS POST. All parameters are uri-encoded in the body of the request. For example: ### BEGIN REQUEST EXAMPLE ### POST [login to view URL] Content-Type: application/x-www-form-urlencoded ACCOUNT_ID=123412341234&NAME1=Chris%20J.&NAME2=Jansen ### END REQUEST EXAMPLE ### Of course, there are more parameters than that required for a successful transaction. RESPONSE FORMAT: Expected output is that of a standard HTTPS response. All response parameters are uri-encoded in the body of the response. See below under "Output format" for more details. For example: ### BEGIN RESPONSE EXAMPLE ### HTTP/1.1 200 OK Cache-Control: max-age=0 Connection: close Date: Tue, 07 Dec 2004 17:31:12 GMT Server: Apache Content-Type: text/html; charset=ISO-8859-1 Expires: Tue, 07 Dec 2004 17:31:12 GMT TRANS_ID=100000000150&STATUS=0&AVS=0&CVV2=7&MESSAGE=Declined&REBID= ### END RESPONSE EXAMPLE ### Input Parameters are: ACCOUNT_ID = Your 12-digit Bluepay 2.0 Account ID USER_ID = Optional. Your 12-digit Bluepay 2.0 User ID TAMPER_PROOF_SEAL = An MD5 hash of your Secret Key and a few transaction parameters, as below. TPS_DEF = Definition of which fields are included in the MD5 above. See below for details. TRANS_TYPE = Optional. AUTH, SALE, REFUND, CAPTURE (defaults to SALE) PAYMENT_TYPE = Optional. CREDIT or ACH or DEBIT (Defaults to CREDIT) MODE = Optional. TEST or LIVE (Defaults to TEST) MASTER_ID = Optional. The TRANS_ID of a previous transaction; any parameters not sent will be filled out from the previous transaction. This allows you to run a "manual" rebilling. REQUIRED for CAPTURE or REFUND; contains the TRANS_ID of the transaction to CAPTURE or REFUND. The following fields are required for credit card transactions unless MASTER_ID is set or sending swipe data: PAYMENT_ACCOUNT = The customer's credit card number. (eg: '4111111111111111') CARD_CVV2 = The customer's Card Validation Code. This is the three-digit code printed on the back of most credit cards. CARD_EXPIRE = The customer's Credit Card Expiration Date, in MMYY format. We also accept swipe data in two formats, one of these is required to get swipe charge rates: SWIPE = The full swiped track data, just the way it comes to you from the card reader, including both Track1 and Track2. TRACK2 = Only Track2 of the swiped data. The following field is required for ACH transactions unless MASTER_ID is set: PAYMENT_ACCOUNT = This is set to three colon-seperated fields. First, the account type must be 'C' for checking, or 'S' for savings. Second, the bank's routing number, and finally the customer's account number. (eg: 'C:123456789:1234123412341234') DOC_TYPE = The documentation for the ACH transaction. May be 'PPD', 'CCD', 'TEL', 'WEB', or 'ARC'. Defaults to 'WEB' if not set. ACH also has some additional requirements noted below. The following fields are optional: IS_CORPORATE = Set to '1' if this is a corporate transaction, rather than personal. COMPANY_NAME = The name of the company on the check or credit card. (64 characters) AMOUNT = The FULL amount of the transaction, including tax and tip. ([login to view URL] format) NAME1 = The customer's first name (16 characters) NAME2 = The customer's last name (16 characters) ADDR1 = The customer's street address, necessary for AVS. (64 Characters) ADDR2 = The customer's second address line, if any (64 Characters) CITY = The customer's city (32 Characters) STATE = The customers' state, province, or equivalent. (16 Characters max; 2-letter abbrev preferred) ZIP = The customer's zipcode or equivalent. (16 Characters) COUNTRY = The customer's country (64 Characters) EMAIL = The customer's email address. Required for ACH. PHONE = The cusotmer's phone number. Required for ACH. MEMO = 128-character descriptor field. CUSTOM_ID = 64 characters of merchant-specified data, searchable and reportable CUSTOM_ID2 = 64 characters of merchant-specified data, searchable and reportable The following fields are optional but may be required for the best rates from your merchant account: ORDER_ID = Optional Purchase Order ID (16 Chracters) INVOICE_ID = Optional Invoice ID (16 Characters) AMOUNT_TIP = The tip amount, if any. AMOUNT_TAX = The tax amount, if any. AMOUNT_FOOD = The amount of the total that was spent on food, for restaurants AMOUNT_MISC = The amount of the total that was spent on beverages and other. The following fields are to add rebilling to a SALE or AUTH: DO_REBILL = 1 for rebilling, not set or 0 for no rebilling. REB_FIRST_DATE = Date and time of first rebilling to run, in ISO format (YYYY-MM-DD HH:MM:SS) Required for rebilling Time portion is optional; will default to midnight on the date specified. REB_EXPR = How often to run rebilling, in date expression format ("3 DAY" to run every three days, "1 MONTH" to run monthly, "1 YEAR" to run yearly, "2 WEEK" to run bi-weekly, etc) Required for rebilling. REB_CYCLES = Optional. How many times to rebill. Not set to rebill until cancelled. REB_AMOUNT = Optional. How much to charge when rebillings are run. Defaults to amount of transaction being run. The following fields are available only when PAYMENT_TYPE is set to DEBIT SMID_ID = Required, this is the encryption key information PIN_BLOCK = Required, this is the encrypted PIN AMOUNT_CASHBACK = Optional, amount of cash given to customer AMOUNT_SURCHARGE = Optional, surcharge for performing cash back Note that DEBIT also requires you to send either SWIPE or TRACK2. The following fields are available but not currently required for any application: SSN = The customer's SSN or TAXID, all digits (no dashes) (9 Characters). BIRTHDATE = The customer's birthdate in ISO format (YYYY-MM-DD) CUST_ID = The customer's state ID or driver's license. (25 Characters) CUST_ID_STATE = The state of issuance of the customer's ID. (16 Characters) The following fields are DEPRECATED and should not be used: DO_AUTOCAP = '1' or '0'. '1' will cause Bluepay2.0 to automatically CAPTURE an AUTH if it is approved. This is equivalent to running a SALE, and running a SALE would probably be preferred, unless you are using oneof the following two options: AVS_ALLOWED = A string containing all the acceptable AVS responses. Any other AVS response will cause the AUTH to DECLINE. '#' or not sent indicates all are allowed. For example, if you sent 'XYZ' and the AVS response is 'W' then the AUTH will be declined. CVV2_ALLOWED = A string containing all the acceptable CVV2 responses. Any other CVV2 response will cause the AUTH to DECLINE. '#' or not sent indicates all are allowed. ## Notes on the TAMPER_PROOF_SEAL: The TAMPER_PROOF_SEAL is an MD5 checksum of your SECRET KEY and a few transaction parameters. We use an MD5 simply to avoid sending the SECRET KEY over the wire, and we include some of the transaction parameters simply as a convenient source of "random" padding. The TAMPER_PROOF_SEAL is currently calculated as follows: md5(SECRET KEY + ACCOUNT_ID + TRANS_TYPE + AMOUNT + MASTER_ID + NAME1 + PAYMENT_ACCOUNT) where '+' indicates string concantenation and undefined fields are concantenated as '' (null string) Your md5 function must return a hex-encoded md5 checksum. If you do not know your SECRET KEY, please contact Bluepay support. TPS_DEF (NEW) ** NOTICE: THE USE OF THIS FIELD CAN POSSIBLY WEAKEN YOUR SECURITY. PLEASE BE SURE YOU UNDERSTAND HOW THE TAMPER_PROOF_SEAL WORKS BEFORE YOU CONSIDER USING THIS OPTION. ** This option allows a merchant to determine which fields are included in the TAMPER_PROOF_SEAL. If set blank or not sent, it will default to the fields as described under TAMPER_PROOF_SEAL, above. If set to a space-seperated list of field names, then the TPS will be calculated using the fields listed, in order. The secret key is always the first field, and should not be listed. Imagine your account ID were 123412341234 and you wanted to run a $10.00 TEST transaction. Your secret key is abcdabcdabcdabcd: You might set TPS_DEF to: "ACCOUNT_ID AMOUNT MODE" In which case, the system would expect the TAMPER_PROOF_SEAL to be an MD5 of the following string: "abcdabcdabcdabcd12341234123410.00TEST" Some of the Bluepay Sample Code (such as the Ruby library) illustrates a use of the TPS_DEF to essentially remove everything but the SECRET_KEY from the calculation. ########################################################## # # Output Parameters are: TRANS_ID = The ID of the just-run transaction, if successful. STATUS = '1' for APPROVED, '0' for DECLINE, 'E' and all other responses are ERROR. AVS = The AVS response from the processing network CVV2 = The CVV2 response from the processing network AUTH_CODE = The auth code for successful AUTH MESSAGE = A human-readable description of the transaction status. REBID = The ID of the newly-created rebilling sequence, if any. Output HTTP status code is 200 for a successfully processed transaction, whether it was declined or approved. Output HTTP status code is 400 for an error transaction. Keep in mind the number and ordering of output fields may change. Do not rely on either to be the same or your code may break in a future update.