AUTOMATED CREDIT CARD PROCESSING

SendSafe accepts Visa, MasterCard, American Express, and Discover cards (support for additional cards or custom store cards can be added for a nominal fee). SendSafe also supports COD as a credit card alternative. Enabling various cards or COD is done in the Storefront Admin Page.

Credit card processing is setup individually for each store front. This s a very flexible arrangement. You can use ICZ Internal Gateway Support, PayPal PayFlowPro, or IC Verify of each store front. You can mix processor support. One store front may use VeriSign and another store front managed by the same SendSafe robot can run IC Verify. 

The server computer runs the web and database server software.

The business website is constructed from database driven webpages.

Sendsafe, CPrompt's e-commerce software, is running the e-store on a server. Sendsafe takes the information entered into a webpage and processes it until a completed customer order results.

The payment gateway is a middle-man company that aggregates and sends credit card transactions to a credit card "Processor. Your business will need to set up an account with a payment gateway like VeriSign or a direct connection to a Processor for very high volume accounts. CPrompt can assist you in making these decisions and setting up these services."

The (credit card) Processor is a large clearing house for credit card charges that your merchant bank uses.

The Merchant Bank is the bank where your business establishes a merchant credit card account, which enables your e-business to deposit the money from credit card transactions. CPrompt can assist you in setting up this service.

The business back-end programs are your existing accounting, inventory control or shipping programs used to manage the business daily operations. The e-commerce software or the back-end software can be modified to exchange information with each other to allow, for example, an e-commerce order to be automatically entered into your accounting program.

There are two basic ways credit card transactions are handled:

Your payment gateway should be setup to perform automated end of day settlements. If it is not setup in this way then you will need to perform a manual settlement directly using your payment gateway's interface at the end of the business day.

 


TEST CREDIT CARD NUMBERS:

These international credit card numbers can be used to test the entire system. They are numbers that banks will reject as invalid without problem and are intended for system testing. 

Credit Card  Sample Number 
Visa  4111 1111 1111 1111 (best test cc to use)
4007 0000 0002 7
4242 4242 4242 4242 (often will decline even in test mode)
MasterCard  5500 0000 0000 0004
5424 0000 0000 0015 
American Express  3782 8224 6310 005
3400 0000 0000 009
3700 0000 0000 002 
Diner's Club  3000 0000 0000 04 
Carte Blanche  3000 0000 0000 04 
Discover  6011 0000 0000 0004
6011 0000 0000 0012
6011 1111 1111 1117 (this one will cause errors on some gateways
en Route  2014 0000 0000 009 
JCB  3088 0000 0000 0009 
Special SendSafe Test Visa number 0111-1111-1111-1111


ICZ INTERNAL GATEWAY SUPPORT

SendSafe's ICZ Internal Gateway processor includes support for 45 of the most popular online processors. This is the credit card processing setup that is the easiest to use; unless you have indepth technical knowledge of a gateway, you should not use the plugin interfaces discussed elsewhere in this document (i.e. PayflowPro, IC Verify, or custom plugins). In most cases ICZ Integrated gateway support will provide the highest processing speed compared to other SendSafe options.

Below is a list of the currently supported gateway processors:

3DSI EC-Linx www.3dsi.com
ACH Payments www.ach-payments.com
Authorize.Net www.authorize.net
Bank Of America www.bankofamerica.com
Concord EFSNET www.concordefsnet.com
CyberCash www.cybercash.net
DPI Link www.dpicorp.com
ECHOnline www.echo-inc.com
ECX QuickCommerce www.ecx.com
eProcessing www.eProcessingNetwork.com
Fast Transact www.fasttransact.com
FirstData / CardService Int. www.cardservice.com
FirstData / Cardservice Int. www.firstdata.com
GoRealTime (Full-pass) www.gorealtime.com 
IBill Processing Plus www.ibill.com
Innovative Gateway www.innovativegateway.com
Intellipay ExpertLink www.intellipay.com
Iongate www.iongate.com
iTransact RediCharge HTML www.itransact.com
LinkPoint www.linkpoint.com
Merchant Anywhere www.merchantanywhere.com
Merchant Partners www.merchantpartners.com
Moneris www.moneris.com
MPCS Weblink www.merchantcommerce.net
NetBilling www.netbilling.com
Network Merchants www.networkmerchants.com
NOVA's Viaklix www.viaklix.com
OGONE www.ogone.be
Optimal Payments www.optimalpayments.com
PayFlowLink - Verisign www.verisign.com
PayFuse - First National MS www.firstnationalmerchants.com
Paymentech - Orbital www.paymentech.com
Payments Gateway www.paymentsgateway.com 
Payready Link www.payready.net
Planet Payment www.planetpayment.com
Plug 'n Pay www.plugnpay.com
PRIGate www.paymentresource.com
Protx www.protx.com
PSIGate www.psigate.com
RTWare WebLink www.rtware.net
SkipJack www.skipjack.com
SurePay / YourPay www.surepay.com
TrustCommerce www.trustcommerce.com
USA ePay www.usaepay.com
uSight gateway.usight.com 
Verisign PayFlow Pro www.verisign.com
YourPay www.yourpay.com

Support for each gateway is configured in the storefront.config file. The following parameters must be set for the individual gateway. Not all of the parameters are required for every gateway and some gateways need addtional information or setup (some of the special setup requirements are listed below).

VeriSign PayFlowPro

This PayFlowPro connection uses the 4.x SDK. It should not be used for PayFlowPro gateway. Instead use the native SendSafe SDK free PayPal PayFlowPro Integration.

Sample configuration:
ICZ INTEGRATED = YES
ICZ TIMEOUT = 30

ICZ AUTH MODE = mauthcapture
ICZ HASH = <none>
; Set your partner code into ICZ PGATEWAYVALUE and Set ICZ PGATEWAYPARAM = PARTNER
; Partner code is optional if PARTNER = VeriSign
ICZ PGATEWAYPARAM = PARTNER
ICZ PGATEWAYVALUE = VeriSign
; Vendor code is optional and will default to VENDOR = USERID
ICZ PGATEWAY2NDPARAM = VENDOR
ICZ PGATEWAY2NDVALUE = myvenor

ICZ GATEWAY = 10
; PRODUCTION ICZ URLGATEWAY = payflow.verisign.com
; TEST MODE  ICZ URLGATEWAY = test-payflow.verisign.com
ICZ URLGATEWAY = payflow.verisign.com
ICZ USERID = myid
ICZ PASSWORD = shhhh

ICZ P12CERTPASSWORD = <none>
ICZ P12CERTIFICATE LOCATION = <none>
ICZ TRANSX RETRY CODES = 8;11;25;26;100;101;102;103;104;106;109;115;116;1000
ICZ IGNORECERTAUTH = NO

LinkPoint

Sample configuration:
ICZ INTEGRATED = YES
ICZ TIMEOUT = 30

ICZ AUTH MODE = mauthonly

ICZ HASH = <none>
ICZ PGATEWAYPARAM = <none>
ICZ PGATEWAYVALUE = <none>

ICZ GATEWAY = 30
ICZ URLGATEWAY = secure.linkpt.net:1129
ICZ USERID = 00000
ICZ PASSWORD = 000000

ICZ P12CERTPASSWORD = shhhhh
ICZ P12CERTIFICATE LOCATION = C:\PROJECT\JSOF SSL\jsof\WholesaleDirect.store\CyberCash\wholesalediscbrakes.p12
ICZ TRANSX RETRY CODES = <none>
ICZ IGNORECERTAUTH = NO

AUTHORIZE.NET

Sample configuration:
ICZ INTEGRATED = YES
ICZ TIMEOUT = 30

ICZ AUTH MODE = mauthonly

ICZ HASH = <none>
ICZ PGATEWAYPARAM = Authorize.Net
ICZ PGATEWAYVALUE = AIM

ICZ PGATEWAY2NDVALUE = <none>
ICZ PGATEWAY2NDPARAM = <none>

ICZ GATEWAY = 1
ICZ URLGATEWAY = <none>
ICZ USERID = API Login ID
ICZ PASSWORD = Transaction Key

ICZ P12CERTPASSWORD = <none>
ICZ P12CERTIFICATE LOCATION = <none>
ICZ TRANSX RETRY CODES = <none>
ICZ IGNORECERTAUTH = NO

If you get the following error message:

"This account has not been given the permission(s) required for this request."
You have not configured Authorize.net with an API Login ID and Transaction Key. You acquire your API Login and your Transaction Key from the authorize.net web admin. Replace the login and password with your API Login and Transaction Key.

 

FILE = "..\SendSafe\<your store name>.store.config" or jsof.config (default) ON-LINE PROCESSOR INTEGRATION SETTINGS FOR ICZ GATEWAY SUPPORT.
Before modifying any configuration file always make a backup copy of the file.

Note: All keywords that control on-line credit card processing begin with the word CyberCash. These key words are used for any on-line processor (CyberCash, VeriSign, NetAuthorize, etc).

Keyword Default value Explanation
ICZ INTEGRATED NO YES/NO Should the robot process credit card transactions using ICZ internal gateway processor
ICZ GATEWAY 10 Set to the numeric code for the gateway. The default is 10 - PayFlowPro

No Gateway (0) n/a
Authorize.Net (1) http://www.authorize.net
DPI Link (2) http://www.dpicorp.com
eProcessing (3) http://www.eProcessingNetwork.com
GoRealTime (Full-pass) (4) http://www.gorealtime.com
IBill Processing Plus (5) http://www.ibill.com
Intellipay ExpertLink (6) http://www.intellipay.com
Iongate (7) http://www.iongate.com
iTransact RediCharge HTML (8) http://www.itransact.com
NetBilling (9) http://www.netbilling.com
Verisign PayFlow Pro (10) http://www.verisign.com
Payready Link (11) https://www.payready.net
NOVA's Viaklix (12) http://www.viaklix.com
USA ePay (13) http://www.usaepay.com
Plug 'n Pay (14) http://www.plugnpay.com
Planet Payment (15) http://planetpayment.com/
MPCS (16) http://merchantcommerce.net/
RTWare (17) http://www.rtware.net/
ECX (18) http://www.ecx.com
Bank of America (19) http://bankofamerica.com/merchantservices
Innovative Gateway (20) http://www.innovativegateway.com
Merchant Anywhere (Transaction Central) (21) http://www.merchantanywhere.com/
SkipJack (22) http://www.skipjack.com
ECHOnline (23) http://www.echo-inc.com
3DSI EC-Linx(24) http://www.3dsi.com
TrustCommerce (25) http://www.trustcommerce.com
PSIGate (26) http://www.psigate.com
PayFuse XML(27) http://www.firstnationalmerchants.com/
PayFlowLink (28) http://www.verisign.com
Paymentech Orbital Gateway (29) http://www.paymentech.com
LinkPoint (30) http://www.linkpoint.com
Moneris eSelect Plus (31) http://www.moneris.com
uSight Gateway (32) http://gateway.usight.com
Fast Transact (33) http://www.fasttransact.com/
NetworkMerchants (34) http://www.networkmerchants.com/
Ogone DirectLink(35) http://www.ogone.be
Concord EFSNet (36) http://www.concordefsnet.com/
Payment Resources International PRIGate (37) http://www.paymentresource.com/TransactionCentral.asp
Protx (38) http://www.protx.com
Optimal Payments / FirePay (39) http://www.optimalpayments.com/
Merchant Partners (40) http://www.merchantpartners.com/
CyberCash (41) http://www.cybercash.net/
FirstData / CardService International (42) http://www.firstdata.com
YourPay (43) http://www.yourpay.com
ACH Payments (44) http://www.ach-payments.com
Payments Gateway (45) https://www.paymentsgateway.net/
ICZ AUTH MODE mauthcapture

Authorize Only ('mauthonly') or Authorize and capture ('mauthcapture').

This entry can also contain two mode strings seperated by commas (where the 1st mode string equals the mode to use for orders which contain shippable items AND the 2nd mode string equals the mode to use if the entire order is fulfilled immediately) i.e. ICZ AUTH MODE = mauthonly,mauthcapture.

Note: To mark an item as immediately fulfilled (i.e. non shipping) you need to set the defaultshipmode for that item to null.

ICZ TIMEOUT 30 This is a transaction timeout (in seconds) value used by gateways.
ICZ USERID userid This is the merchant, store, or User ID Assigned to you by the on-line credit card processor.
ICZ PASSWORD   This key or password is provided by on-line credit card processor. If you do not have a password enter <none>

This value should be entered via the Primary Setup Dialog box; if you enter this value manually then it will not be encrypted. Using the Primary Setup dialog will encrypt this password. The clear text password cannot begin with a '#'.

ICZ URL GATEWAY test-payflow.verisign.com

This is the URL for the on-line credit card processor host that SendSafe will contact to process credit card authorizations. To use the default URL for a gateway enter <none>

Please note that the proper "http://" or "https://" formatting must be used where needed. For example: https://secure.authorize.net/gateway/transact.dll would be the correct URL for authorize.net WHILE payflow.verisign.com wold be the correct URL for VeriSign PayFlowPro.

ICZ PGATEWAYPARAM <none> This is an optional gateway parameter which may be needed for some gateways. This value translates directly into a keyword which a specific gateway required.
ICZ PGATEWAYVALUE <none> This is the value for the optional gateway parameter ICZ PGATEWAYPARAM which may be needed for some gateways.
ICZ HASH <none> This optional hash code is provided by some gateways such as Authorize.net.
ICZ TRANSX RETRY CODES 8;11;25;26;

These are processor (gateway) specific error codes which should be retried. Codes like timeout are included. This list will be different for every processor. An exact match including case is required for retry.

Set to <none> for no retry codes.

ICZ P12CERTIFICATE LOCATION <none> The location and name of a P12 (*.pfx / *.p12) client certificate which is used for identification. For example: C:\pathto\cert.pfx
ICZ P12CERTPASSWORD <none> The password for the P12 (*.pfx / *.p12) client certificate.
ICZ IGNORECERTAUTH NO Setting this value YES will cause the system to ignore validation failures of the client certificate. This setting is useful if you do not have a CA certificate loaded on the server for the issuer of the client certificate.
ICZ CHARGESLIP COMMENT Online order placed with %s. Order#%s

This is the comment line that is included in the charge slip. This message will be seen by the customer in thier monthy credit card statement. This comment will also appear in most charge records shown by gateways which support a comment.

If your gateway does not support comments then this field will be ignored.

The first %s will be replaced with your company's e-mail address (i.e. sales@youbiz.com)

The second %s will be replaced with the transaction number

Both the first and the second %s are optional. Values assigned will be in the fixed order shown above.

Example of resulting string: "Online order placed with sales@yourcompany.com. Order#%1273645"

ICZ SUPPRESS EMAIL NO Setting this value YES cause the email address to NOT be set to the gateway. This is useful to suppress unwanted email from being sent directly from the gateway to the customer.

 

Partial List of Gateway Error Codes

Authorize.Net:

Code Description
1 Approved.
2 Declined.
3 Error.

 

DPI:

Code ResponseText Description
00 APPROVAL Approved and completed.
01 CALL Refer to issuer.
02 CALL Refer to issuer - Special condition.
03 TERM ID ERROR Invalid merchant ID.
04 HOLD-CALL Pick up card.
05 DECLINE Do not honor.
06 ERROR xx General error.
06 ERROR xxxx General error.
07 HOLD-CALL Pick up card - Special condition.
13 AMOUNT ERROR Invalid amount.
14 CARD NO. ERROR Invalid card number.
15 NO SUCH ISSUER No such issuer.
19 RE ENTER Re-enter transaction.
21 NO ACTION TAKEN Unable to back out transaction.
28 NO REPLY File is temporarily unavailable.
39 NO CREDIT ACCOUNT No credit account.
41 HOLD-CALL Pickup card - Lost.
43 HOLD-CALL Pickup card - Stolen.
51 DECLINE Insufficient funds.
54 EXPIRED CARD Expired card.
57 SERV NOT ALLOWED Transaction not permitted - Card.
61 DECLINE Exceeds withdrawal limit.
62 DECLINE Invalid service code, restricted.
65 DECLINE Activity limit exceeded.
76 NO ACTION TAKEN Unable to locate, no match.
77 NO ACTION TAKEN Inconsistent data, rev. or repeat.
78 NO ACCOUNT No account.
80 DATE ERROR Invalid date.
85 CARD OK No reason to decline.
91 NO REPLY Issuer or switch is unavailable.
93 DECLINE Violation, cannot complete.
96 SYSTEM ERROR System malfunction.
98 VOID ERROR No matching transaction to void.
L2 PASSWORD INVALID Password is missing or invalid.
L3 EXPIRATION DATE INVALID Expiration Date is not formatted correctly.
L6 ORDER NUMBER MISSING The Order Number is required but missing.
L7 WRONG TRANSACTION CODE Transaction Code must be either a 30 for Authorize Only, 32 for Authorize and Settle.
L8 NETWORK The Network Connection timed out due to a communications error.

 

eProcessing:

Code Description
0 Approved.
1 Declined.
2 Error.

 

GoRealTime:

Code Description
0 Approved.
1 Declined or error condition.

 

IBill:

Code Description
0 Approved.
1 Declined or error condition.

 

Intellipay:

Code Description
A Approved. The purchase has been authorized by the issuer.
S Same. The DTS has detected a possible duplicate transaction.
D Declined. The authorizer has declined the purchase request.
X Expired. The card has expired.
E Error. A data entry error of some kind has occurred.
U Unknown. An unknown processor or issuer error has occurred.
F Failure. A system failure of some kind has occurred.

 

 

IOnGate:

Code ResponseText Description
AA APPROVAL Approved.
NC PICK UP CARD Pick up card.
ND NOT ON FILE Cardholder not found.
ND EXPIRED CARD Expired card.
ND REQ. EXCEEDS BAL. Request exceeds balance.
ND DECLINED Do not honor.
ND AMOUNT ERROR Transaction amount error.
ND DECLINED CVV2 Credit Verification Value error.
NR CALL AUTH. CENTER Refer to issuer.

 

ITransact:

Code Description
0 Approved.
1 Declined or error condition.

 

NetBilling:

Code Description
I (letter I) = Incomplete These are transactions that are successful, but may fail at a later date, ie: An ACH transaction is approved, but then is later denied due to NSF.
1 (number 1) = Approved, Good This is a transaction that is approved and charged.
R = Refunded This transaction has been refunded. It is extremely unlikely you will ever see this return code in this context, although you may see it when browsing old transactions in the NetBilling database (via the Admin tools).
T = Ticket This is returned when an Authorize-Only or AVS-Only transaction is good.
F or 0 = Failure The number zero "0" or the letter "F" indicates that the transaction failed.
Other Code Any other non-zero, non-null codes should be interpreted as success for compatibility with future response codes.

 

PayFlow Pro:

Code Description
0 Approved.
1 User authentication failed.
2 Invalid tender type. Your merchant bank account does not support the following credit card type that was submitted.
3 Invalid transaction type. Transaction type is not appropriate for this transaction. For example, you cannot credit an authorization-only transaction.
4 Invalid amount format.
5 Invalid merchant information. Processor does not recognize your merchant account information. Contact your bank account acquirer to resolve this problem.
7 Field format error. Invalid information entered.
8 Not a transaction server.
9 Too many parameters or invalid stream.
10 Too many line items.
11 Client timeout waiting for response.
12 Declined. Please check the credit card number and transaction information to make sure they were entered correctly. If this does not resolve the problem, have the customer call the credit card issuer to resolve.
13 Referral. Transaction was declined but could be approved with a verbal authorization from the bank that issued the card. Submit a manual Voice Authorization transaction and enter the verbal auth code.
19 Original transaction ID (PNRef) not found. The transaction ID you entered for this transaction is not valid.
20 Cannot find the customer reference number.
22 Invalid ABA number.
23 Invalid account number. Please check credit card number and re-submit.
24 Invalid expiration date. Please check and re-submit.
25 Transaction type not mapped to this host.
26 Invalid vendor account.
27 Insufficient partner permissions.
28 Insufficient user permissions.
29 Invalid XML document. This could be caused by an unrecognized XML tag or a bad XML format that cannot be parsed by the system.
30 Duplicate transaction.
31 Error in adding the recurring profile.
32 Error in modifying the recurring profile.
33 Error in canceling the recurring profile.
34 Error in forcing the recurring profile.
35 Error in reactivating the recurring profile.
36 OLTP Transaction failed.
50 Insufficient funds available.
99 General error.
100 Transaction type not supported by host.
101 Timeout value too small.
102 Processor not available.
103 Error reading response from host.
104 Timeout waiting for processor response. Try your transaction again.
105 Credit Error. Please make sure you have not already credited this transaction, or that this transaction ID is for a creditable transaction. (For example, you cannot credit an authorization.)
106 Host not availible.
107 Duplicate suppression timeout.
108 Void error. Please make sure the transaction ID entered has not already been voided. If not, then look at the Transaction Detail screen for this transaction to see if it has settled. (The Batch field will be set to a number greater than zero if the transaction has been settled.) If the transaction has already settled your only recourse is a reversal (credit a payment or submit a payment for a credit).
109 Timeout waiting for host response.
111 Capture error. Only authorization transactions can be captured.
112 Failed AVS check. Address and zip code do not match.
113 Cannot exceed sales cap. For ACH transactions only. (Not supported.)
114 CVV2 Mismatch. An authorization may still exist on the cardholder's account.
115 System is busy, try again later.
116 VPS Internal error - Failed to lock terminal number.
117 Failed merchant rule check. An attempt was made to submit a transaction that failed to meet the security settings specified on the VeriSign Manager Security Settings page. See VeriSign Manager User's Guide.
118 Invalid keywords found in string fields.
1000 Generic host error. This is a generic message returned by your credit card processor. The message itself will contain more information describing the error.

 

PayReady:

Code Description
0 Authorized.
1 Declined.
2 Not Authorized.
3 Error Occurred.
4 Missing Information.
5 Unavailable Card Type.

 

VIAKLIX:

Code ResponseText Description
0 APPROVED Transaction approved.
1 (Custom server response) Declined or error condition. See Processor message for addtional information.

USAePay:

Code Description
Approved Transaction approved.
Declined Transaction declined.
Error There is an error in the data received.

PlugNPay:

A Approved.
C Call Auth Center.
D Declined.
P Pick up card.
X Expired.
E Other Error.

Bank Of America:

-1 Communication issue with authorization system.
0 Order authorized successfully.
1 Communication or Routing error requiring resubmission of authorization request.
2 Card issuing company declined to authorize transaction.
3 No response from, or error communicating with, card issuing company.
4 Card issuing company declined to authorize transaction, or card type not accepted by merchant.
6 Card issuing company declined to authorize transaction as credit card has expired.
7 Card issuing company declined to authorize transaction in full.
8 Communication error requiring resubmission of authorization request.
9 Duplicate Merchant Order Number.
10 Other issue.
11 Invalid Encrypted Order Information provided.

Innovative:

0 Transaction Approved
* All other codes should be considered as declined.

Merchant Anywhere:

0 Approved
1 Declined

Skipjack:

0 Transaction is not approved.
1 Transaction is approved.
-1 Error in transaction.

ECHOnline:

G Approved
D Declined
C Cancelled
T Timeout waiting for host response
R Received

3DSI EC-Linx:

A Approved
V Voided
C Partial Credit
M Force Accepted
D Declined
F Failed
E Exists

Trust Commerce:

approved Transaction was successful.
accepted Transaction was successful (for offline transactions such as Credits)
declined Transaction declined.
baddata Improperly formatted or missing data.

PSIGate:

Approved Transaction Approved.
Declined Transaction Declined.
Error Error condition.

PayFuse:

1 Approved.
2 Referral (General).
3 Referral - Call bank for manual approval.
4 AVS request accepted.
50 Declined (General).
51 Connection timed-out.
52 Error connecting to processor or sending data.
53 Error during Payment Commit phase.
54 Timed out waiting for response.
100 Transaction failed to settle due to Soft Error.
101 Transaction failed to settle due to Hard Error.
102 Transaction failed to settle because the transaction is marked as Locked.
500 Declined - Transaction considered fraudulent by Fraud component.
501 "The transaction was Approved by the processor. However, it failed a postprocessing fraud rule and has been voided."
502 "The transaction was Approved by the processor. However, it failed a fraud rule and has been marked for review."

PayFlowLink:

0 Approved
- Anything other than an approved transaction will return no code. However, the processor error message will contain an error string.

LinkPoint/YourPay/FirstData

APPROVED The transaction was approved.
DECLINED the transaction was declined.
FRAUD Fraudulant transaction detected.

 

 


 ADDRESS VERIFICATION SYSTEM (AVS) MODE: 

The following only applies to systems that have AVS checking enabled. To enable and configure AVS operation use the Setup for your specific payment gatewaye.

When using AVS mode you need to be aware that transactions will be approved while AVS fails unless you configure your gateway to specifically reject certain AVS scenerios.

When AVS is enabled, all transactions will be tagged with one of the codes listed below. For approved charges, this tag will be inserted after the Authorization code i.e. Approved: ET07 (AVSC=X). In this example the AVSC=X indicates an AVS code of 'X' (which means exact match - see table below).

If a transaction fails AVS but the charge was approved by the bank, then an additional line of explanation is included in all output (e-receipt, html reports, database, etc.). This line will explain why the AVS failed. In addition to this extra line of information each line will contain an AVS failed tag of: (AVSC1A). This tag can be searched for to find orders that may need human attention. This extra line of information in the e-receipt may be useful to the customer since they may have entered an incorrect zipcode or street number.

You may want to manually decline an order that has failed AVS. You should consult your merchant bank for information on their policies regarding AVS.

Note: To generate AVS failure reports from the database search for (AVSC1A) in the CCTxStatus column. i.e. Select * from Orders WHERE CCTxStatus LIKE '%(AVSC1A)%'

List of Raw AVS Codes returned by PayPal.
These raw codes can be found in the appropriate SendSafe audit file, e-receipt, database, html reports, etc.

Return Code Description
A Address matches, ZIP does not.

The first five numerical characters contained in the address match with those stored at the VIC or issuer's center. However, the zip code does not match.

E Ineligible transaction.
N Neither address nor ZIP matches.

Neither the first five numerical characters contained in the address match with those stored at the VIC or issuer's center nor the zip code match.

G Foreign address, non-global participant in AVS system.
R Retry (system unavailable or timed out). Warning! Some banks may incorrectly return a 'R' retry code while at the same time capturing the money. There is no way to retry AVS without running the entire charge.
S Card type not supported.

The card type for this transaction is not supported by AVS. AVS can verify addresses for Visa cards, Mastercard, proprietary cards, and private label transactions.

U Address information unavailable.

The address information was not available at the VIC or issuer's center.

W Nine-digit zip match, address does not.

The nine-digit postal zip code matches that stored at the VIC or card issuer's center. However, the first five numerical characters contained in the address do not match.

X Exact match (nine-digit zip and address).

Both the nine-digit postal zip code as well as the first five numerical characters contained in the address match.

Y Address and five-digit zip match.

Both the five-digit postal zip code as well as the first five numerical characters contained in the address match.

Z Five-digit zip matches, address does not.

The five-digit postal zip code matches that stored at the VIC or card issuer's center. However, the first five numerical characters contained in the address do not match.

P AVS is not supported for this transaction.

 


PAYPAL PAYFLOW PRO INTEGRATION

SendSafe does not use a PayPal SDK for connection (i.e. SDK Free). SendSafe connects directly to the gateway using an HTTPS link. This eliminates any concern of mismatch between PayPal SDK and the gateway.

SendSafe can be customized by C Prompt to provide custom automated credit, void, and other credit card transactions.

Selecting the Host:

The following information is needed to setup SendSafe to work with PayPal PayFlowPro. This information is stored in the file "..\SendSafe\<your store name>.store.config"

To setup this information open the SendSafe robot's menu Setup --> On-Line Credit Card Processing Integration.

Description configuration file keyword and dialog entries.
Host Domain Name For Production: payflow.verisign.com
For Test: test-payflow.verisign.com
Vendor ID Your case-sensitive login that you defined at registration (typically the same as UserId)
Partner ID Your partner ID is provided to you by the authorized VeriSign Reseller who signed you up for the Payflow Pro service. If you signed up yourself, use VeriSign.
Customer ID (UserId) For now you must use your VENDOR login for this parameter. In future releases you will be able to use this parameter to create multiple users for a single account.
Secret Hash No used for VeriSign
Password or Merchant Key

The case-sensitive password defined atregistration withVeriSign.

This value should be entered via the Primary Setup Dialog box; if you enter this value manually then it will not be encrypted. Using the Primary Setup dialog will encrypt this password. The clear text password cannot begin with a '#'.

 

This information and settings are decisions you will make about how your business will handle credit card transactions.

Transaction type (or method)  i.e. Credit Card Processor Service Capture Mode Authorize Only ('mauthonly') or Authorize and capture ('mauthcapture') (see also Advance Config)

This entry can also contain two mode strings seperated by commans (where the 1st mode string equals the mode to use for orders which contain shippable items AND the 2nd mode string equals the mode to use if the entire order is fulfilled immediately)..
Credit card Address Verification (AVS) setting Enter a string of pass codes: A, Y, Z, U, etc.
Note: "U" should always be present for processing AVS transactions when AVS processing is not available. The string "UXY" is the typical setting used for AVS. (See AVS Codes for a complete list)

Testing and Trouble shooting:

  1. The PayFlowProModule can be run stand-alone at a command prompt. A batch file with all the needed parameters can be found in the same directory and the module (testpayflow.bat). You will need to change the MerchantId, VendorId, Partner, & password parameters before running.
  2. See Advance Config for more settings.
FILE = "..\SendSafe\<your store name>.store.config" or jsof.config (default) part 5 - ON-LINE PROCESSOR INTEGRATION SETTINGS FOR VeriSign, PayPal, and custom Credit Card Processor support.
Before modifying any configuration file always make a backup copy of the file.

Note: All keywords that control on-line credit card processing begin with the word PayPal. These key words are used for any on-line processor (PayPal, VeriSign, NetAuthorize, etc).

Keyword Default value Explanation
CYBERCASH INTEGRATED NO YES/NO Should the robot process credit card transactions using on-line credit card processor
CYBERCASH ADDRESS VERIFICATION NO no longer used
CYBERCASH MODULE LOC ServerSideCode\PayPal no longer used

CYBERCASH MODULE NAME 

 

PayPalmodule.exe no longer used
CYBERCASH CONFIGFILE NAME merchant_conf no longer used
CYBERCASH AVS MODE UXY no longer used
CYBERCASH MERCHANT ID userid This is the API merchant or User ID Assigned to you by the on-line credit card processor. ( see also CCID)
CYBERCASH MERCHANT KEY   This key or password is provided by on-line credit card processor ( see also Merchant Key)

This value should be entered via the Primary Setup Dialog box; if you enter this value manually then it will not be encrypted. Using the Primary Setup dialog will encrypt this password.

CYBERCASH SECRET HASH  secret-test-mck no longer used
CYBERCASH HOST URL Domain Name = pilot-payflowpro.paypal.com
or
URL = payflowpro.paypal.com
This is the Domain Name for the on-line credit card processor host that SendSafe will contact to process credit card authorizations. (see also PayPal Payment Service (CCPS))
CYBERCASH AUTH MODE mauthcapture

Authorize Only ('mauthonly') or Authorize and capture ('mauthcapture'). (See Transaction type)

This entry can also contain two mode strings seperated by commans (where the 1st mode string equals the mode to use for orders which contain shippable items AND the 2nd mode string equals the mode to use if the entire order is fulfilled immediately).

Note: To mark an item as immediately fulfilled (i.e. non shipping) you need to set the defaulshipmode for that item to null.

CYBERCASH TIMEOUT 45 This is a transaction timeout (in seconds) value used by some on-line processing services.
CYBERCASH PORT 443 This is a port number that is used by some on-line credit card processoring services
CYBERCASH VENDOR ID userid This is the VendorId which is currently the same as the UserId i.e. CYBERCASH MERCHANT ID (PayPal may change this in the future).
CYBERCASH PARTNER Verisign This is the Partner code you were assgined when you signed up with PayPal.
CYBERCASH DEBUG NO If set to YES then all output files from the plug-in will be archived in the archive directory

 


IC VERIFY INSTALLATION

To run SendSafe using IC Verify to authorize credit card orders you have to do the following:

  1. Call up your bank to setup an account that will work through IC Verify
  2. Install IC Verify Active-X Component
  3. Install IC Verify
  4. Register IC Verify with http://www.icverify.com
  5. Configure SendSafe to use IC Verify
  6. Test the system
  7. Go live.

Installation Steps:

1. Install the IC Verify Active-X Component. Locate the subdirectory "IC Verify Active-X Component". This subdirectory can be found under the SendSafe directory i.e. "..\SendSafe JSOF\IC Verify Active-X Component".

  1. From the "IC Verify Active-X Component" directory run the setup.exe program.
  2. It is okay if IC Verify generates an Install error that "Msvcrt20.dll" is in use and cannot be installed. Press the [Ignore] button to proceed with the installation leaving the existing "Msvcrt20.dll" in place and running. DO NOT PRESS the [Abort] button.
  3. Close the "Start Menu Addition" Window which may have been left open. This window is listing: ICVPay, Readme, License, Examples, and docs Startup menu entries.
  4. When the setup dialog asks you to Finish the install. Press [Finish] and then [Okay].
  5. This setup program will install and register the IC Verify Active-X component "ICVPay.dll".

2. Install IC Verify (after installation is complete follow the instructions that came with the IC Verify disks to setup IC Verify for your Merchant Account Processor or setup IC Verify in test - training mode). To begin the installation run the program "install.exe" from the IC Verify disks. IC Verify must be run in Multi-User mode in order for SendSafe to be able to submit credit card authorization jobs to IC Verify.

  1. Insert the 1st IC Verify disk and execute the "install.exe" program.
  2. It is okay if IC Verify generates an Install error that "Msvcrt20.dll" is in use and cannot be installed. Press the [Ignore] button to proceed with the installation leaving the existing "Msvcrt20.dll" in place and running. DO NOT PRESS the [Abort] button.
  3. From the Start Menu, run the "IC Verify Multi-User" program.
  4. Create a "Request Directory" suggested "c:\ICVWIN20\ReqDir".
  5. Enter the path  "c:\ICVWIN20\ReqDir" that you just created into the "Request Directory" entry.
  6. Enabling "Evaluated Response" mode. Execute the IC Verify Setup Program, select the "Merchant Information tab", in the "Evaluate Rsp Y/N/B/L/D/S" entry field enter "Y" for yes.
  7. Setting up "Search Matching" for IC Verify 2.20 Interactive. Execute the IC Verify Setup Program, select the "Options tab", in the "Match 1st, 2nd Fields" entry field enter "N" for no. If you do not set this value to NO then when processing voids/ships the IC Verify GUI will generate "TRANSACTION NOT FOUND" error messages.

To run IC Verify in test - training mode:

(This is useful to test out the system without running actual credit card transactions)

  1. Copy one of the "demoxx.set" files from the demoset subdirectory to the root IC Verify directory.
  2. Rename the file "demoxx.set" to "icverify.set" replacing the existing file.
  3. From the Start Menu, run the "IC Verify Multi-User" program.
  4. Enter "/DD" in the Initialization String entry (do not enter the quotes "" only the /DD).
  5. Create a "Request Directory" suggested "c:\ICVWIN20\ReqDir".
  6. Enter the path  "c:\ICVWIN20\ReqDir" that you just created into the "Request Directory" entry.
  7. Enabling "Evaluated Response" mode. Execute the IC Verify Setup Program, select the "Merchant Information tab", in the "Evaluate Rsp Y/N/B/L/D/S" entry field enter "Y" for yes.

3. Setup SendSafe to use IC Verify (click for details). This involves entering 7 item in SendSafe's "IC Verify Integration" menu (a sub menu of Setup).

4. Test the entire SendSafe + IC Verify system using test credit card numbers, then put through a real order and then void the transaction in IC Verify.


IC VERIFY INTEGRATION OF OFF-LINE PROCESSING SYSTEM

IC Verify is the industry leading credit card authorization system. C Prompt is an integration development partner with IC Verify. SendSafe and IC verify can be purchased separately or as a bundle. If you already own IC Verify, SendSafe can be seamlessly integrated with your existing IC Verify system.

SendSafe has the capability to perform integrated operations with IC Verify. SendSafe makes requests to  IC Verify to authorize credit card transaction. The entire process is fully automated. The authorization code is amended to the SendSafe i-commerce transaction record. Automated customer confirmation messages of approval or charge denied are generated and e-mailed.

IC Verify Multi-User Mode

SendSafe runs with IC Verify in multi-user mode. The IC Verify DLL operation used by SendSafe is hardwired to operate as substation 1. Currently this setting cannot be changed. Other substations configured for your IC Verify installation can be set to the substation numbers 2...n.

Configuring SendSafe and IC Verify

Set up IC Verify as you would for a standard installation (see IC verify documentation for detailed instruction).

If you are planning on using IC Verify you must install the IC Verify Active-X component. This component is not used as an Active-X Webpage object. It is run internally on the computer and is functionally a special case DLL provided by IC Verify. The IC Verify Active-X Component can be found a sub directory under where you installed SendSafe. To install this component run the setup.exe program by double clicking on it.

There are a few SendSafe specific configuration items:

  1. IC Verify must be run in mutli user mode and the multi-user IC verify server program must be running.
  2. IC Verify Active-X component must be installed.
  3. A Request/Response directory needs to be created. This directory is not created during IC Verify installation. The recommend default is "d:\Icvwin20\ReqDir". This directory must be entered into both the IC Verify Multi-User GUI and the SendSafe Robot's "IC Verify Integration" setup dialog. 
  4. Set the "Process Files Every N Seconds" entry in the IC Verify Multi-User GUI to 3 seconds.
  5. In the IC Verify Setup the "Evaluated Response" field (under the Merchant Info tab of Advanced Setup) must be set to Y (yes).
  6. In the Multi-User GUI the "Initialization String" entry should be empty, unless you are running in training mode; in which case the initialization string should be set to "/DD".
  7. (Optional) If Modem Sharing is planned THEN IC Verify may need to be configured to quickly disconnect the phone when a verification task is complete. These settings can be found in the IC Verify Setup under the "hardware" tab. The entry that controls disconnection is labeled "Wait Hold". Three separate values can be entered into this field, each separated by a space. The first value determines the polling speed that ICVERIFY checks for transaction requests. The second value determines how long ICVERIFY will hold the line open once a connection is established with the processing network. The third value which can be entered is the name of the directory which will be used to process request and answer files. A typical SendSafe entry would be "3 1 d:\Icvwin20\ReqDir". This tells IC Verify to check for requests every 3 seconds,   to hold the line open for 1 second, and to use the request/response directory "d:\Icvwin20\ReqDir". Some tuning of these values may be required to get IC Verify to efficiently perform modem sharing. 

If IC Verify will also be used to manually process transactions, then a separate phone line is strongly recommended. This means that if you will be running the IC Verify GUI to manually enter transactions (in addition to SendSafe automatic transaction processing) THEN to avoid modem conflicts you should use a different line for Internet Access and IC Verify Credit Card Processing.

The SendSafe configuration options are located in the "IC Verify Integration" drop down menu (located under the Setup menu). In the "IC Verify Integration" dialog you will need to enter a few pieces of information. Optional Advanced IC Verify configuration is accomplished by modifying the jsof.config file. Please refer to the "IC Verify Quick Setup Guide" and "Windows User Manual" for additional information about these configuration parameters and installing IC Verify on your computer. Specific information about setting up IC Verify in Multiple User mode can be found on page 56 of the "Windows User Manual". 

FILE = "..\SendSafe\<your store name>.store.config" or jsof.config (default) part 5 - ON-LINE PROCESSOR INTEGRATION SETTINGS FOR VeriSign, CyberCash, and custom Credit Card Processor support.
Before modifying any configuration file always make a backup copy of the file.

Note: All keywords that control on-line credit card processing begin with the word CyberCash. These key words are used for any on-line processor (CyberCash, VeriSign, NetAuthorize, etc).

Dialog Entry Typical Value Description
Request Directory d:\Icvwin20\ReqDir The Request/Response directory that the Multi-user Version of IC Verify is running using to process transactions. This directory must be "shared" and r/w accessible by the robot.
Max ICV Users 0008 The value of Max_Users should be equivalent to the number of users that have been licensed to use the copy of ICVERIFY (or NetVERIFY) that is functioning as the master station. If more than one instance of the control is being utilized
Address Verification Mode 0 Enter one of these number values (0 through 4):

(0) Do not perform AVS checking. AVS information is transmitted but the response is not evaluated and is not returned as part of the approval code.
(1) Transmit AVS information but do not evaluate response. The AVS code is returned as part of the approval code.
(2) Transmit AVS information and fail if both zip code and street address fail to match.
(3) Transmit AVS information and fail if either zip code or street address fail to match.
(4) Transmit AVS information and fail if either the 9-digit zip code or street address fail to match.

Address Verification NO YES/NO: Is Address verification enabled with merchant bank processor? This is the master on/off switch and overrides anything in the "Address Verification Mode" entry.
Modem Sharing NO Set to YES if IC Verify will be sharing the modem ALSO USED for Internet connections.
IC Verify Operation enabled NO YES/NO Should the robot process credit card transactions using IC verify. Note: You must have a licensed version of IC verify running in the Multi-user mode.
Credit Card Transaction Type BOOK Identifies the transation as: BOOK, SELL, or AUTHONLY. Enter one of these strings: "BOOK", "SELL", or "AUTHONLY".

It is recommended that you test IC Verify Integration with IC Verify set in Training Mode. This is accomplished by setting the Multi-User Initialization string to include "/DD". This will allow you to simulate IC Verify processing credit card transactions. See IC Verify documentation for more details.

Common IC Verify Configuration and Operation mistakes:

  1. A very common error is running SendSafe without running the IC Verify server. If this happens SendSafe may appear to hang-up while processing a customer order. If you wait long enough, SendSafe will timeout after a several minutes and report an IC Verify error. Always run both SendSafe and IC Verify Multi-user server. You may want to place these programs in your startup folder or run them as NT Services using Microsoft's srvany.exe tool (provided in the NT Resource Kit).
  2. If you get an "ICV-1020 Unrecognized IC Verify response error" then the most likely cause is that IC Verify is not configured for "Evaluated Response". Open the IC Verify Setup Program, select the "Merchant Information tab", in the "Evaluate Rsp Y/N/B/L/D/S" entry field enter "Y" for yes.

 

FILE = "..\SendSafe\<your store name>.store.config" or jsof.config (default) part 5 - IC VERIFY INTEGRATION SETTINGS
Before modifying any configuration file always make a backup copy of the file.
Keyword Default value Explanation
ICVERIFY INTEGRATED NO YES/NO Should the robot process credit card transactions using IC verify. Note: You must have a licensed version of IC verify running in the Multi-user mode.
ICVERIFY REQ DIRECTORY d:\Icvwin20\ReqDir The Request/Response directory that the Multi-user Version of IC Verify is running using to process transactions. This directory must be "shared" and r/w accessible by the robot.
ICVERIFY MERCHANT NUMBER 001 Three digit merchant number used by IC verify.
ICVERIFY MERCHANT CODE RIFY Corresponds to the last four characters of the setup file name of the merchant that the transaction is being processed for. ( "RIFY" is almost always the file name).
ICVERIFY SHARED MODEM NO Set to YES if IC Verify will be sharing the modem ALSO USED for Internet connections.
ICVERIFY MODEM DELAY 10 This is the time in seconds that SendSafe will wait after an IC Verify transaction is completed. This value is used to force the IC Verify modem connection to remain open for this period of time (giving IC Verify enough time to hang up the modem). This value has no effect unless modem sharing is enabled. This value is limited to 99 seconds.
ICVERIFY ADDRESS VERIFICATION NO YES/NO: Is Address verification enabled with merchant bank processor?
ICVERIFY MAX USERS 008 The value of Max_Users should be equivalent to the number of users that have been licensed to use the copy of ICVERIFY (or NetVERIFY) that is functioning as the master station. If more than one instance of the control is being utilized
ICVERIFY LICENCE TIMEOUT 10000 The length of time in milliseconds that a transaction will wait for a license for processing before it times out. The default value is 10000.
ICVERIFY TRANSACTION BOOK Identifies the transaction as: BOOK, SELL, or AUTHONLY. Enter one of these strings: "BOOK", "SELL", or "AUTHONLY".
ICVERIFY AVS MODE 0 Enter one of these number values (0 through 4):

(0) Do not perform AVS checking. AVS information is transmitted but the response is not evaluated and is not returned as part of the approval code.
(1) Transmit AVS information but do not evaluate response. The AVS code is returned as part of the approval code.
(2) Transmit AVS information and fail if both zip code and street address fail to match.
(3) Transmit AVS information and fail if either zip code or street address fail to match.
(4) Transmit AVS information and fail if either the 9-digit zip code or street address fail to match.

 


CUSTOM INTEGRATION AND OPERATION OF THE ON-LINE CREDIT CARD PROCESSING MODULE

All on-line processing services (i.e. VeriSign, CyberCash, etc.) will use this interface to a plug-in module. Plug-in modules are provided for CyberCash and VeriSign. Source Code for these modules is available so that you can create support for other on-line processors.

If you do not want to use CyberCash, VeriSign, or IC Verify, you can integrate any Credit Card Processing system you want. This does require programming experience. C Prompt can do this custom programming for you (cost about $2000), or you can do it yourself. C Prompt will also provide free of charge the c++ source for the CyberCash or VeriSign module so that you can modify it to work with your processor (the source code is provided on condition of a reciprocal agreement where you will provide to C Prompt royalty free any and all modification made to the module).

This custom integration is accomplished by replacing the CyberCash module with support for any Credit Card Processing system. The CyberCash module is a stand alone C++ program that processes credit card transactions. The program is a plug in module with a defined interface. It takes a set of command line parameters and returns the results in a file (or to stdout). The program must be a command line runnable object (C++, VB, Perl, etc.).

You must program your replacement module to take the following input and generate the specified output file. 

See Configuration file for manual configuration of CyberCash module and customization. 

Sample command line input for Cybercash Module:

cybercashmodule /ORDERID="CPROMPT00000005" /NAME="Bob Haveson" /AMOUNT="usd 10.00" /CCNUM="4111111111111111" /EXPDATE="02/02" /ADDRESS="1 Mocking Bird Lane" /CITY="Dallas" /STATE="TX" /ZIP="75230" /COUNTRY="USA" /CONFIGFILE="..\conf\merchant_conf" /OPERATIONCODE="mauthcapture" /FILEOUT="CPROMPT00000004.txt" 

/OPERATIONCODE "mauthonly" or "mauthcapture" Ascii string controls CpatureOnly or CaptureAuth operating modes.
/CONFIGFILE Path to config file for module (used only by CyberCash).
/ORDERID Unique order id number which will be <Name of Store><SendSafe Order Number>
/AMOUNT "usd 34.95"usd<space>dollar amount note: Must include currency code i.e. USD for U.S. Dollars
/CCNUM "5555444455554442" Credit card number
/EXPDATE "12/99" MM/YY Expiration date on credit card
/NAME Name of the credit card holder
/ADDRESS "1600 Pennsylvania Avenue" Address of credit card holder
/CITY "Washington" City part of address of credit card holder
/STATE "DC" Two letter avreviation for state part of address of credit card holder
/ZIP "20500" Five digit zip code part of address of credit card holder
/COUNTRY "USA" Country part of address of credit card holder
/FILEOUT Name and path of the results output file that the module will generate.
/HOST The full tcp/ip host address of the service provider (i.e. test-payflow.verisign.com).
/PORT The tcp/ip port to access the provider (i.e. port 433).
/TIMEOUT The transaction timeout value used for communicating with the host.
/VENDORTID The vendor id for the processor account.
/MERCHANTID The merchant or user id for the processor account.
/PASSWORD

The password for the processor account.

This value should be entered via the Primary Setup Dialog box; if you enter this value manually then it will not be encrypted. Using the Primary Setup dialog will encrypt this password.

/PARTNER The partner code (currenly used only by VeriSign).

Note:

Results returned to SendSafe in a file:

The name of this file is passed to the module as the command line parameter "/FILEOUT"

SAMPLE OKAY TRANSACTION FILE:

[[RUNNING TRANSACTION]]=
ConfigFile = >> ..\conf\merchant_conf
OperationCode = >> mauthcapture
OrderID = >> CPROMPT00000005
Amount = >> usd 10.00
CCNumber = >> 4111111111111111
ExpDate = >> 02/02
Name = >> Bob Haveson
Address = >> 1 Mocking Bird Lane
City = >> Dallas
State = >> TX
Zip = >> 75230
Country = >> USA
[[END TRANSACTION]]
 
[[RESULTS]]=
0 card-exp => 01/04
1 aux-msg => Financial Institution Response: authorization approved.
2 cust-txn => 416750268
3 avs-code => X
4 paid-amount => usd 2625.06
5 card-number => 411111
6 card-type => vs
7 order-id => CPROMPT28380847
8 MStatus => success
9 ref-code => 00015612
10 auth-code => NV68
11 merch-txn => 416750268
12 action-code => 000
[[END RESULTS]]

Notes:

  1. merch-txn will return a unique code identifying this transaction. In VeriSign this code is the PNREF code.

SAMPLE FAILED TRANSACTION FILE:

[[RUNNING TRANSACTION]]=
ConfigFile = >> ..\conf\merchant_conf
OperationCode = >> mauthcapture
OrderID = >> CPROMPT00000005
Amount = >> usd 10.00
CCNumber = >> 4111111111111111
ExpDate = >> 02/02
Name = >> Bob Haveson
Address = >> 1 Mocking Bird Lane
City = >> Dallas
State = >> TX
Zip = >> 75230
Country = >> USA
[[END TRANSACTION]]

[[RESULTS]]=
0 MErrMsg = > Duplicate: Order ID 'CPROMPT00000005' has been completed already
1 MStatus = > failure-hard
2 MErrCode = > CR-0045
[[END RESULTS]]

 


PROCESSING CREDIT CARD RETRIES:

(re-running orders, retrying orders)

Your bank or on-line processor can experience network outages. These outages will result in SendSafe not being able to authorize one or more transactions. These outages can result in some very odd status results coming back from your merchant bank or on-line processor (PayFlowPro, Authorize.net, etc).

The SendSafe robot handles these outages by identifying that an outage is occuring and then retrying the authorization. All orders that go into retry will be fulfilled once the gateway comes back on line unless the outage lasts for 66 hours. The retry interval is not linear but exponential and slightly randomized. This helps to prevent overloading a gateway with orders once it comes back online and crushing it. Below is a table which shows the approximate retry intervals i.e. 10 min, 40 min, 90 min, etc.

So you can use the admin orders page to search for orders with “retry” in the orders.status column. If an order failed retry then it will be marked as failed retry. If the order has something like this: “{COMPLETED};RetryStatus=15” it means the order was completed and it was retries 5 times (i.e. 20 – 15 = 5).

On the order receipt / status page, the customer sees a message which tells them their charge cannot be approved right now due to problems with the payment gateway and that their order will be completed later once the gateway starts working again. They are told they will be email confirmation at that time. They are told that they should not place a new order or a duplicate order will result.

If all reties fail then SendSafe will issue an e-receipt to the customer indicating that the order was not completed. SendSafe will also send admin e-mail and issue SMTP pager alerts when the outage occurs and if any orders fail to complete in retry.

If you have access to the physcial server, you can manually force a retry for an order than will no longer be automatically retried. This can be done by following these steps:

1. Locate a backup copy of the original EMSG file in the Output directory and copy it to a temp directory

a. Example: 85631.1542.ASPSRC.EMSG.backup.1027237289.PresvBackup
Where 85631 = transactionId

b. Copy and Rename the EMSG backup file to: 85631.1542.ASPSRC.EMSG

2. Change status of the Order

a. Open the order in the AdminOrder page.

b. The status entry for the order record will look something like this: {RETRYCCFAILED};QBORDER;RetryStatus=0

c. Change {RETRYCCFAILED} to: {RETRYCC}

d. Change RetryStatus=0 to: RetryStatus=1

3. Move the file 85631.1542.ASPSRC.EMSG into the “Input” directory (SendSafe input queue).

 


SUPPORT FOR IN-HOUSE CREDIT CARDS

In-House credit card acceptance is enabled by setting "Enable Charge Card Alterative IHC" to true in the storefront config. Accepting credit card security codes must also be enabled. IHC charges are automatically detected and processed by the robot; therefore enable/disable is controlled by enabling selection of IHC from storefront config admin page.

If your orders are being processed through the credit card processor instead of IHC, check to make sure you have set CSV CODE = YES.

IHC can operate in one of two ways: (a) To connect to an outside system for charge approval OR (b) Integration with the SendSafe e-coupon system.

Charge approval requests are submitted using an HTTPS GET to a defined URL on a remote system. Responses come back as text values in an HTML page. The SendSafe will follow page redirects so the response can be the result of an HTTP redirect.

Transaction timeouts and system level errors will be retried.

To enable IHC, set the IHC entry in the storeconfig to true. On older systems there may not be an IHC entry (DB row in the storeconfig table). If this is the case then use the SQL Script "add IHC to storeconfig.sql" to add the DB row.

FILE = "..\SendSafe\<your store name>.store.config"
Before modifying any configuration file always make a backup copy of the file.
To find a specific storefronts configuration file: see Location of Configuration files
KeywordDefault valueExplanation
IHC GATEWAY URL IHC GATEWAY URL=<none>

For in-house charge processing this parameter is set to the URL which is used for charge approval. The URL is everything up to the "?" parameter delimited i.e. "https://www.youweb.com/verify.asp"

To use SendSafe's built in e-coupon/e-credit line system for charge authorization set this field to: "ECOUPON"

IHC URL PSTRING IHC URL PSTRING=<none>

This parameter sets an sprinf() like string which defines the URL-parameter portion of the URL. i.e. transactionid=%s&ihc=%s&accountnum=%s&dollars=%d&cents=%d"

The sprintf()-like URL parameters will be assigned the following values in this order:

  • The transactionid for this order
  • The (optional) CSV security code (labeled an IHC code). This code does not include the automatic "IHC" prefix found in the trigger file.
  • The account (credit card) number
  • The dollars being charges
  • The cents being charges
The tokens for each of these value can be anything defined in the parameter string.

IHC ORDERNUM TOKENDELIM IHC ORDERNUM TOKENDELIM=Order No:

This delimiter which marks the beginning of an order number in the HTTP response.

IHC RESPONSE TOKENDELIM IHC RESPONSE TOKENDELIM=Response:

This delimiter which marks the beggining of an approval response in the HTTP response. Value response codes are:

    100 - charge approved
    101 - invalid account number
    102 - wrong number of digits in account number
    103 - credit exceeded
    104 - charge declined
    

IHC EOE TOKENDELIM IHC EOE TOKENDELIM=<

This delimiter which marks the end of an order number or aproval response in the HTTP response. this is often also EOL.

IHC TIMEOUT IHC TIMEOUT=60

Transaction completion timeout in seconds. Timeouts will be retried.

CSV CODE YES CSV must be enabled for IHC. This keyword enables and disables the processing of CSV codes which include (Visa/MC/Amx cards and IHC passwords).

 

Application("NameForIHCCard" ) = "IHC Card"

Sets the name of the IHC charge card displayed in the GUI.

Application("IHCEntryLabel" ) = "IHC Code"

Sets the entry field label for IHC security code entry.

Application("CVSCardHelp" ) = "<font color=gray size=2>CVV2,CVC2,CID Code on the back of the card.</font>"

Sets the entry field help text for IHC security code entry. Keep it short and use a hyperlink.

Application("IHCCardNumLen" ) = 10

Sets the length that the IHC card number must be.

 


CREDIT CARD SECURITY CODES

SendSafe accepts and processes credit card security codes. These are the 3 or 4 digit codes used by MC/Visa/Amx. To properly handle theses codes you must configure SendSafe for them. These codes are handled in ICZ and IHC processing subsystems (other subsystems require customization).

To maintain compliance with industry security regulation SendSafe does not store security codes. Security codes are checked the first time a credit card is submitted or updated. QuickBuy transactions do not submit security codes because they cannot be retained in the secure offline database and still be in compliance with security regulations.

The recommend setup is to configure your payment gateway to:

  1. Reject if CCV Code = N - Rejects a charge if the CCV code does not match
  2. Accept if CCV Code = P - Accept a NOT PROCESSED status i.e. no CCV code was submitted
  3. Accept if CCV Code = S - Accept an ON CARD BUT NOT SUBMITTED status i.e. no CCV code was submitted
  4. Accept if CCV Code = U - Accept when an issuer is not certified or has not provided encryption key
The above settings will validate the CCV code when entered by the customer WHILE accepting a charge that does not include a CCV code. This setup is required if QuickBuy is enabled or Subscriptions with automated charges are enabled. Since it is against CISP regulations to store a CCV code, the QuickBuy and Subscription functions do not have access to CCV codes and therefore can only process a charge without the code.

Some older systems may not already have a CSV column in the secure DB. You can use the "Add SecureCC CSV Column.sql" script to setup this column.

FILE = "..\SendSafe\<your store name>.store.config"
Before modifying any configuration file always make a backup copy of the file.
To find a specific storefronts configuration file: see Location of Configuration files
KeywordDefault valueExplanation
CSV CODE NO This keyword enables and disables the processing of CSV codes which include (Visa/MC/Amx cards and IHC passwords).

By default the enty of CSV codes by a customer is optional. The CSV entry field is displayed and a require red asterisk is present *. However, the system will accept a blank entry field. This mode is called a soft requirement i.e. a requirement which is not enforced. The system can be configured for an enforced requirement that the CSV code be entered; in this mode an error message is displayed if the field is left blank and the customer cannot proceed without entering a CSV code. This configuration is in the the global.inc.asa file as shown below:

Application("CSVRequired" ) = true

if true, the customer must enter a CSV code during checkout along with their credit card number. This flag does not affect QuickBuy.

 


TRIGGER FILE FORMAT

From: 
	Sub UploadCCNumber()
Handled by: 
	bool BPOrderObject::importAndParseASPSRCOrder()
	
fObjOrderRecordDebugDump.WriteLine( "SendSafeOrder=DBV1.00" )
fObjOrderRecordDebugDump.WriteLine( "StoreFrontID: " & storeFrontId )
fObjOrderRecordDebugDump.WriteLine( "Time Stamp: " & Now )
fObjOrderRecordDebugDump.WriteLine( "Account: " & ccNumber )
fObjOrderRecordDebugDump.WriteLine( "Expiration Date: " & expDate )
fObjOrderRecordDebugDump.WriteLine( "CSV: " & csvCode )
fObjOrderRecordDebugDump.WriteLine( "[<END OF RECORD>]" )

Notes:

  1. The name of the trigger file contains the transactionId.
    example: 633508467.414629437.ASPSRC.EMSG the transactionid = 633508467
  2. When an order first comes in and the triger files causes its loading; QuickBuy state is determind from the order status field Status
  3. Since an In-House Credit card (IHC) can be any numeric string, it cannot be identified by the standard credit card prefix codes. IHC mode is therefore identified by the CSV code prefix of: IHC. This automatically assigned prefix is saved as part of the CSV code in the DB.
  4. CSV codes (CSC, CVV2, CIS, and IHC) are processed if present and ignored if not present (this is determinded on a transaction by transactioni basis).

Example of a normal Trigger file

SendSafeOrder=DBV1.00
StoreFrontID: CPROMPT
Time Stamp: 7/11/2005 8:32:14 PM
Account: 4111-1111-1111-1111
Expiration Date: 12/17
CSV: 123
[<END OF RECORD>]

Notes:

  1. State Status = {SUBMITTED PENDING}
  2. The CSV field is optional

Example of a QuickBuy Trigger file

SendSafeOrder=DBV1.00
StoreFrontID: CPROMPT
Time Stamp: 7/11/2005 8:08:26 PM
Account: 736846355
Expiration Date: /
CSV:
[<END OF RECORD>]

Notes:

  1. The Account number is the customerId
  2. QuickBuy state Status = {QB SUBMITTED PENDING}
  3. The Expiration date must be blank
  4. The CSV must be blank
  5. The CSV field is optional