What Happens - Transmission Methods

The lTransmitMethod / Transmission Method Parameter is the Key

a. Name and address information of the purchaser
b. Credit card number and expiration date
c. Credit card start date or issue number
d. Amount of sale

MERCH_METHOD1 - Routing Transactions Through Holonet IAT.

1. The order information is packaged with your Merchant name and password by your application into the appropriate structure and passed to the Merchant/400 API.

2. The Merchant/400 API formats the authorization requests and connects to the SSL transaction provider, Holonet IAT. The request is then encrypted and transmitted to Holonet IAT.

3. Based on the Service Name and Merchant name that were passed to the API in the input structure and transmitted with the request, Holonet IAT forwards the request to the appropriate processing partner. The current partner processing choices are:

   a. Credit Card Network
   b. Anacom Communications
   c. Holonet Holopay
   

4. Since a connection to Anacom Communications will be discussed below (and is fairly similar to the methods Holonet IAT uses to communicate with them, we will continue this example using Credit Card Network. At this point in the process, Holonet IAT unencrypts the request and re-packages it into the PGP (Pretty Good Privacy) mail encryption format. Once this is done, the request is transmitted via e-mail to Credit Card Network. Card processor information and currency denomination are also determined by the Merchant name.

5. Credit Card Network unencrypts the request and submits the information to the card processor for authorization. This is done with the ICVerify electronic payment program.

6. A reply is returned from the card processor in seconds and the entire process is reversed. Credit Card Network packages the response, using PGP, and sends it to Holonet IAT.

7. When received by Holonet IAT, the response is unencrypted and re-encrypted (into SSL) and sent on to the waiting Merchant/400 API.

8. The Merchant/400 API unencrypts the response and determines if the transaction was accepted or denied. Result information is formatted in the appropriate structure and returned to your application for further processing and storage.

9. Complete transaction reports including credit card numbers and expiration dates are provided by Credit Card Network in a password protected, secure directory. These reports are produced daily and are html files. They are available to review and download and contain each transaction and daily totals.

10. Credit Card Network performs an automatic settlement each evening whereby all the transactions for the day are settled and funds are transferred by the processor into the merchant's checking account within 48 hours.

Credit Card Network also provides a manual data entry screen in your Merchant password protected directory. This data entry screen can be used to enter transactions that are outside the normal order process.

MERCH_METHOD2 - Routing Transactions to Anacom Communications.

1. The order information is packaged with your Merchant name and password by your application into the appropriate structure and passed to the Merchant/400 API. Transaction type information is also provided.

2. The Merchant/400 API formats the authorization requests, which are encrypted and transmitted to Anacom Communications.

3. Anacom unencrypts the request and submits the information to the card processor for authorization. This is done with the ICVerify electronic payment program.

4. A reply is returned from the card processor in seconds and the process is reversed. Anacom packages the response, using SSL, and sends it to the waiting Merchant/400 API.

5. The Merchant/400 API unencrypts the response and determines if the transaction was accepted or denied. Result information is formatted in the appropriate structure and returned to your application for further processing and storage.

6. Complete transaction reports are provided in a date search format by Anacom Communications in a password protected, secure directory. They are available to review and download and contain each transaction and transaction count totals.

Anacom Communications also provides a manual data entry screen in your Merchant password protected directory. This data entry screen can be used to enter credit transactions.

MERCH_METHOD3 - Routing Transactions to DataCash Ltd.

1. The order information is packaged with your Merchant name and password by your application into the appropriate structure and passed to the Merchant/400 API. Transaction type information is also provided.

2. The Merchant/400 API formats the authorization requests, which are encrypted and transmitted to DataCash.

3. DataCash unencrypts the request and checks the data sent for validity. This is done with the DataCash Transaction.raw proprietary electronic payment clearing system interface. Initially, a Luhn check is done on the card, and a check that they support that particular card and currency combination. Then they check the card details for validity - whether the expiration date is reasonable, whether the start date and/or issue number look reasonable and are what are expected. The transaction information is then submitted via a dedicated X.25 link to the card processor or acquiring bank for authorization.

4. A reply is returned from the card processor in seconds and the process is reversed. DataCash packages the response, using SSL, and sends it to the waiting Merchant/400 API.

5. The Merchant/400 API unencrypts the response and determines if the transaction was accepted or denied. Result information is formatted in the appropriate structure and returned to your application for further processing and storage.

6. Complete transaction reports are provided in a date search format by DataCash in a password protected, secure directory. They are available to review and download and contain each transaction and transaction count totals.

DataCash also provides an online service that provides a variety of functions, including a private, manual, data entry screen which can be used to enter credit transactions.

MERCH_METHOD999 - Routing Free-Format Transactions.

1. The form information (following standard HTTP GET, POST, etc. URI request formats) is packaged by your application into the WWWMERCH_INPUT999 structure and passed to the Merchant/400 API. Examples of this data stream look something like the following two samples:
   • POST /path/programname.cgi HTTP/1.0\x0D\x25
Content-type: Application/x-www-form-urlencoded\x0D\x25
Content-length: 28 \x0D\x25\x0D\x25
&field1=value1&field2=value2\x0D\x25\x0D\x25

   • GET /path/programname.cgi?field1=value1&field2=value2 HTTP/1.0\x0D\x25\x0D\x25

   It is important to note that the inclusion of the \x0D\x25 string is indicative of a set of carriage return (hexadecimal code 0D) and line feed (hexadecimal code 25) characters included in the buffer. These CRLF characters serve to separate the various HTTP heading data elements, to separate the <HEAD> information from the <BODY> information (by way of double CRLF strings), and to complete the transmission stream (also with the use of double CRLF strings).

2. The Merchant/400 API searches for the characters that separate the HTTP <HEAD> information from the <BODY> information. The <HEAD> information is converted to CCSID 819 (the standard for HTTP <HEAD> information over the Internet) and the <BODY> information is converted to ASCII according to the value of the Input Body CCSID. Once this is complete, the buffer is transmitted to the upline host.

3. The upline host unencrypts the request and processes the information transmitted.

4. A reply is packaged, using SSL, and returned from the upline host to the waiting Merchant/400 API.

5. The Merchant/400 API unencrypts the response, then finds the <HEAD> and <BODY> information. The <HEAD> information is converted from CCSID 819 and the <BODY> information is converted from ASCII according to the value of theResults Body CCSID. Result information is formatted in the WWWMERCH_RESULT999 structure and returned to your application for further processing and storage.

It is important to note that, while the MERCH_METHOD999 free format method is very flexible, information passed in the WWWMERCH_INPUT999 and WWWMERCH_RESULT999 structures must conform to the HTTP request URI form structure standards. More information about HTTP may be obtained at the World Wide Web Consortium. The topics that discuss Script Inputs and Script Outputs may also be of assistance.

For questions or comments about Credit Card Network, write to ccnetwork@creditnet.com

For questions or comments about Holonet IAT, write to support@holonet.net

For questions or comments about Anacom Communicatioins, write to support@anacom.com

For questions or comments about DataCash, write to info@datacash.com