Difference between revisions of "Template:CreditLine Programming Rules"

From Payment Processing Software Library
Jump to: navigation, search
Line 1: Line 1:
 +
→ PLEASE, read every point below as those are the common points of failure in the integrations.  Reviewing these pointers may save you significant amount of time in debugging.
 +
 
1. Each API object instance needs to call the initialization function (such as '''clcInit''' or '''Init''') themselves and get a unique handle to themselves. This handle '''can not be shared''' across objects. However, SEE IMPORTANT WARNING BELOW about multiple object creation!  
 
1. Each API object instance needs to call the initialization function (such as '''clcInit''' or '''Init''') themselves and get a unique handle to themselves. This handle '''can not be shared''' across objects. However, SEE IMPORTANT WARNING BELOW about multiple object creation!  
  
Line 16: Line 18:
  
 
8. Avoid '''redundant''' and '''inefficient''' code.  Obscure and hard to debug errors may hide in such code.  
 
8. Avoid '''redundant''' and '''inefficient''' code.  Obscure and hard to debug errors may hide in such code.  
 +
 +
9. Do take a look at our '''[http://911software.com/files/samples/ sample code]'''.
  
  

Revision as of 19:13, 20 April 2011

→ PLEASE, read every point below as those are the common points of failure in the integrations. Reviewing these pointers may save you significant amount of time in debugging.

1. Each API object instance needs to call the initialization function (such as clcInit or Init) themselves and get a unique handle to themselves. This handle can not be shared across objects. However, SEE IMPORTANT WARNING BELOW about multiple object creation!

2. Do NOT create a new object every time you call our API. This will create resource issues. The API object is meant to be created and shared by your application, unless you need to make multiple requests in parallel or creating multiple terminals to do the same - see below.

2. Each instance can only make one request at a time, but one process can have multiple instances to make multiple requests.

3. Each instance needs to have a unique client name or terminal name. For example, instance 1 gets TERM001, and instance 2 gets TERM002. The best way to configure this is by device. The length limit is 7. The server monitors the names for duplication and will do it's own name resolution in case of duplicate client names.

4. The server name should match what's showing on the title bar of the credit server program.

5. If using the CreditLine Multiple Merchant Account Setup, you must call clcSetMerchantIndex before every Auth, Edit, Sale, Batch and other transaction related calls. The merchant index is reset to 0 on every call completion.

6. Some environments, such as VB.NET may lose the automation reference if the same API is called twice too quickly. Avoid calling the same API in tight loops - add a reasonable delay if needed.

7. The dollar amounts have an implied decimal point. e.g. $2.00 should be submitted to our API as 200, not 2.00

8. Avoid redundant and inefficient code. Obscure and hard to debug errors may hide in such code.

9. Do take a look at our sample code.


The server name should match what's showing on the title bar of the credit server program. We had a NETBIOS interface before, so they must match. However, the file API is not that strict. However, it is a good practice to match them, in case we implement multi-servers that monitor the same message directory.