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:


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. ";




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.

Developer Documentations

  1. Received Code 9999 with Web Services Call
  2. Received Return Status Code 3 When Using Elilogin Login Method
  3. Elliott Web Service Requirements
  4. Elliott eStore Checklist
  5. LN API
  6. FN API
  7. RN API
  8. IN and DF API Change (V9.0)
  9. FA API Changes (V9.0)
  10. VA API Changes (V9.0)
  11. CartService
  12. EliarachService
  13. ElicshtxService
  14. EliattrbService
  15. ElisyscdService
  16. EliNoteService
  17. El2rstimService
  18. EliOrderService
  19. ItemInquiry
  20. EliitmiqService
  21. EliShiptoService
  22. El2getfrService
  23. Steps Required to Test ReportWriter in V8.2
  24. Installation of ElliottService, NETcellent’s Web Services for Elliott
  25. ResellerFinder
  26. EliaptrxService
  27. VendorInquiry
  28. EliloginService
  29. ElislsmnService
  30. EliserhsService
  31. EliatpobService
  32. ElievprcService
  33. ElihdtrxService
  34. ElicuswlService
  35. QueryTurnaround
  36. InvoiceInquiry
  37. ElicustmService
  38. EligetcdService
  39. OrderInquiry
  40. EliordiqService
  41. EliecontService
  42. EliautdpService
  43. El2CrCrdService
  44. Log-Timer / ElliottTimer.Ini Support
  45. Alpha Document Number Support (V8.5/V9.0)
  46. ElliottService System.TypeInitializationException
  47. Feature - Printing API to Dynamically Set Number of Copies
  48. The Values and Meanings of Distribution Types - ARDISFIL, APDISFIL, IMDISFIL, BMDISFIL
  49. DD API Changes (V9.0)
  50. PA API (8.5)
  51. Validate License API
  52. AP API
  53. TP API: Temporary Path
  54. Data Structures for Report Desk Defaults and Enforcements
  55. COBOL to VB Interface Programs
  56. IN API: Option to Support Files and Folders Validation
  57. FF API: File Functions
  58. ID API
  59. LK: Links API
  60. FFLNearYou
  61. Report Desk: Registry Settings
  62. Developing a New Elliott V8.6 Report Desk User Defined Report (UDR)
  63. CustomerInquiry
  64. Elliott API (JSON Web Service)
  65. Animating COBOL Code in Elliott V8.5
  66. Preliminary Programming Changes for Elliott 8.6
  67. CV API
  68. System Lock File Requirements
  69. How to Write Test Codes for C# ESS Projects
  70. Solving the Inability to Debug Elliott on a New Server
  71. Report Desk: Developing Custom Reports
  72. Report Desk Tables
  73. Report Desk Database Delivery Strategy
  74. Logging I-O Logic Errors
  75. Report Desk: Developer Documentation Roadmap
  76. Report Desk: Resolution of Pervasive.Data.SqlClient.dll
  77. TB API
  78. Creating HTML Emails for Professional Presentation
  79. EM API - Create and Send an Email
  80. DN API (Document Number Handling)

Feedback and Knowledge Base