El2CrCrdService.asmx

This web service replaces EliCrCrdService.  It provides the methods to add, change, and delete eContact credit cards. It also provides a list function to display the available credit card for the eContact.

In addition, this web service provides the following methods to process credit cards:

• ValidateCreditCard
• SalesTrx
• Peauthorize
• Force (Complete)
• Void
• Refund
• AVSOnly

This is temporary documentation on changes done on 2/13/15 in which we support parameters regarding whether to update A/R or not for the following methods:

• SalesTrx
• Force (Complete)
• Void
• Refund

For these four methods, the user can pass the following parameters in the ExtraInput field:

      UpdateAR=N,CRAcctNo=000012340000123400001234

You do not have to pass this parameter. If you do not, then the UpdateAR is assumed to be “Y.”

If you should pass the UpdateAR parameter, the value must be “Y” or “N.” Under normal circumstances, most users would want a credit card charge to reflect the cash receipt with credit card charges in the accounts receivable for the customer. In some situations, we may charge credit cards not related to AR purposes. If that is the case, you can set UpdateAR=N.

The CRAcctNo parameter is used when UpdateAR=”N.” The value you provide for this parameter must be a 24-digit account number. In Elliott, even though the display chart of an account may not be 24 digits, internally it is always 3 segments with an 8-digit max for each segment. Please pass the internal 24 chart for account numbers. The system will use this account to write A/R Distribution to G/L as follows:

      Dr.  Cash

      Cr.  CrAcctNo

If UpdateAR=”Y,” then the normal A/R Distribution is as follows:

      Dr.  Cash

      Cr.  AR Account (as specified in the customer)

Force (Complete)

A Force method can be used to process either forced or complete transactions. When you use this method, if you pass the Transaction ID (Payware TroutD), after which it is automatically converted to a complete transaction.

Charging Credit Card from the Web

The two most commonly used web methods for online processing are the SalesTrx and PreAuthorize. They are used into the two common scenarios below:

Method 1: Charge on the Web:

Use SalesTrx web service method

Pros: The credit card is charged the full amount. You don't need to go into Elliott again later to finish the charge.

Cons: The credit card is charged the full amount. If you need to adjust the order (when some items aren't available, for example), the account is now charged the wrong amount and you need to adjust it.

Method 2: PreAuthorize on the Web, Charge in Elliott

Use the PreAuthorize web service method.

To PreAuthorize on the web: You would use the PreAuthorize method. The Input is actually the same SalesTrxInput that's used in SalesTrx method.

Pros: More flexible. The card went through PreAuth, so you have the correct card information. You can adjust the amount when you charge.

Cons: You have to go in Elliott in order to charge and finish the transaction.

Note on Preventing Card Charged/Order Not Created, or Vice Versa.

Most likely you will do credit card  processing and create orders together online. Since both actions have side effects, if one succeeds while the other fails, the data will be in a bad state. To help lower that risk:

The EliOrder service has a method called TrialAllocation. This method has no side effects. It will go through most of the actions of CreateOrder (e.g.,  ensure it can open the files needed). You should call this method to verify that you can get a successful response before calling CreateOrder. This can reduce the likelihood of running into problems in the CreateOrder method.

Example of creating order / process credit card:

DO EliorderService.TrialAllocation

  IF OK: DO  El2crcrd.PreAuthroize or El2crcrd.SalesTrx

    IF OK: DO EliorderService.CreateOrder

El2CrCrdService Return Code

0 = OK – Payment Gateway accepted the credit card. But, you might want to do additional checking. The response has an "AVSStatus" field. See explanation below. It provides additional information on the address match.

26 = The Transaction is Declined by gateway.

Note: one of the reasons a gateway would reject a transaction is if it detected duplicate transactions for that user on that same day. If you want to detect this and present a different message, you can check

Response.ReturnCode is 26 AND Response.StatusMessage2 contains the string"duplicate"

Code: Anything Else - There were errors.

These are errors that your website would not be able to recover / handle. You can have one generic error message for all of them, or present different error messages. Below are some error codes that we have special messages for:

else if (response.ReturnCode == 36) {

      message = "Due to high volume, we are unable to process your request at this time.  Please try again later. ";

}

else if (response.ReturnCode == 37) {

      // time out error/connection dropped

      message = "There was a temporary service interruption while processing your request.  Please try again later. ";

}

else if (response.ReturnCode == 38) {

      message = "We are sorry that we are unable to process credit cards at this time. Please try again later and contact us if you continue to encounter problems. ";

}

AVSStatus

It can be one of the following values. 

/// <summary>

//' A: Address matches, Zip code does not

//' B: Address matches, postal code does not

//' C: No match on address or postal code

//' D: Street address and postal code match

//' E: AVS error

//' G: Service not supported by non-US issuer

//' I: Address not verified for international transaction

//' M: Street address and postal code match

//' N: No match on address or Zip code

//' P: Postal code matches, address does not

//' R: Retry, system is unavailable or timed out

//' S: Service not supported by issuer (card type does not support AVS)

//' U: Address information is unavailable

//' W: 9-digit Zip code matches, address does not

//' X: Exact match

//' Y: Address and 5-digit Zip code match

//' Z: 5-digit Zip code matches, address does not

//' 0: No response sent

/// </summary>

The way you can do it is to pick a list of codes that's acceptable, (we suggest you use ABDMPWXYZ), and make sure the AVSStatus is one of these codes. Otherwise we reject the credit card. 

Choosing a high AVSStatus standard to decline a customer’s credit card can be problematic.  Keep in mind, the gateway has accepted this PreAuth (or sales) transaction already. The fund has been reserved from your customer credit card.  If you choose to decline this transaction on your end, it does not immediately release the customer’s credit card fund allocation.  It usually takes between 7 to 30 days for the abandoned allocation to disappear from your customer’s credit card.  If your customer tries a few times to authorize this credit card, it could potentially hold up funds from your customer's credit card and cause a problem.