eCharge resend txt

Craig Noreen craign at eCHARGE.Com
Tue Jan 26 15:38:02 PST 1999


Ivan,

I have converted the word docs to txt format. Let me know if you have any problems or questions regarding eCharge.

Best Regards,

Criag Noreen
Business Development Manager
(206) 708-1225
-------------- next part --------------


 Technical Overview of the 
 eCHARGE(tm) 900 Billing System

There are four major components to the eCHARGE system. A custom Web eCHARGE radio button generator will be provided over the Net free of charge to Web hosting sites (or suppliers) that choose to allow users to acquire their goods or service(s) using the eCHARGE system. This software will hot link all users depressing the eCHARGE radio button directly to the eCHARGE application server. At this point the application server takes over and invokes a JAVA applet that looks at the users' browser, and determines if the user has the eCHARGE plug-in already installed. 

If the user does not, then a program is called to install the necessary plug-in. This program informs the user that he does not have the needed plug-in installed and prompts the user to download it to his PC. By saying yes, the eCHARGE plug-in is downloaded to the users PC. The plug-in is designed to be called by depressing the eCHARGE icon on a Web site that facilitates the entire transaction. 

Once the eCHARGE plug-in has been installed, the 900 number and product information specific to the eCHARGE radio button that was depressed is transparently inserted into the eCHARGE plug-in. The user is also at the same time connected to the eCHARGE Merchant Transaction Server (MTS). 

Once connected to the MTS, the user is delivered the item they wish to obtain in encrypted form using RSA encryption methodology. Following the down loading of the desired item, the user is prompted with confirmation of the down load. At this time the plug-in disconnects the user and configures the modem to place the 900 call. The call is placed and the 900 Transaction Server delivers the de-encryption key to the user. The 900 call is terminated and the data is de-encrypted. The user is then displayed a THANK YOU message with a choice to EXIT or RECONNECT to the Net. 

Utilities & New Features

eCHARGE will be adding many features to the system over the next few months in an effort to make the product as user friendly as possible. It is the goal of management to give the consumer as much control over the purchasing process as is technically possible. These features include: 

* A blocking utility 
* A budgeting feature 
* A multiple transaction feature (shopping cart) 
* Scheduling features 

A blocking feature will be added as a priority. Management realizes that there are several different groups who may wish to totally block access to the eCHARGE billing system. These would include parents, libraries, Internet cafes, dormitories etc. Along with this feature will be a password protect utility where approved individuals will still have access to the system when a block has been initiated. 

                     
A budgeting feature will be introduced where a blocking mechanism will be activated based on certain user defined criteria. For instance, parents wishing allow a teenager to be
able to charge on-line game playing to the phone bill for the sake of convenience, but wishing to limit the amount that can be charged over a specific period of time. 

This feature will allow blocking of purchases based on price limits as well, allowing for increased management of usage by parents and business users. 

An eCHARGE shopping cart will be introduced where users will be able to "tag" multiple items and have the aggregate amount charged as a single 900 call. 

Scheduling purchases and fulfillment is an important feature of the eCHARGE system. A scheduling feature will allow for management of the disconnect required in the first generation of the software -making the process less intrusive to the user. It will also allow for control over lengthy downloads of large products. The user will be able to move the purchase and/or fulfillment process to off peak times or to the end of an Internet "surf". Management believes that giving control of the purchase process to the user will increase the over all acceptance of the system. 
                                                                   
                 


eCHARGE Corporation
500 Union Street, Suite 745
Seattle, WA. 98101
(206) 729-9900 - Voice
(206) 729-9800 - Fax
www.eCHARGE.com
-------------- next part --------------




















This document contains information proprietary to eCHARGETM Corporation.
It shall not be copied or reproduced, or duplicated in whole or part
without the expressed or written permission of eCHARGETM Corporation.

Copyright (c) 1998, eCHARGETM Corporation


TABLE OF CONTENTS
1	INTRODUCTION	3
1.1	Purpose	3
1.2	Audience	3
1.3	Overview	3
2	FUNCTIONALITY	4
2.1	Store merchant data for forwarding	4
2.2	Transaction status inquiries	4
2.3	Post recurrent transactions	4
3	MESSAGE PROTOCOL	5
3.1	Message format	5
3.2	Example message	5
4	API SPECIFICATION	6
4.1	Format	6
4.2	Error codes	6
4.3	SetMerchantData	6
4.4	SetMerchantDataResponse	7
4.5	TransactionStatus	7
4.6	TransactionStatusResponse	7
4.7	PostRecurrentTransaction	7
4.8	PostRecurrentTransactionResponse	8
5	EXAMPLES	9
5.1	Store and forward, Redirect	9
5.2	Post recurrent transaction	10

1 Introduction
1.1 Purpose
This document describes the capabilities of the eCHARGE Merchant API, describes each of its messages, and provides an example integration.  This interface is stabilizing, but should still be considered "subject to change".
1.2 Audience
This document will be useful to anyone designing or implementing merchant-side functionality.
1.3 Overview
The Merchant API is used to integrate the eCHARGE payment system with existing eCommerce systems, and in general to provide a way for merchant systems to initiate communications with the eCHARGE server.  
2 Functionality
This section summarizes the responsibilities of the Merchant API in point form.
2.1 Store merchant data for forwarding
Commerce servers can use this message to store information on the eCHARGE server that will be associated with a merchant ID and a merchant transaction ID and downloaded to the purchaser over the secure 900 line.  For example, merchant data might be interpreted as decryption keys, a payment URL, a digital receipt, or a PIN number.
Covered by: SetMerchantData, SetMerchantDataResponse
2.2 Transaction status inquiries
Merchant systems can ask whether a particular transaction has gone through or not.  This will allow them to verify payment before providing a product or service.
Covered by: TransactionStatus, TransactionStatusResponse
2.3 Post recurrent transactions
Once a recurrent transaction has been established in the eCHARGE database, a merchant can periodically cause that transaction to be repeated, as in a monthly charge for a subscription.
Covered by: PostRecurrentTransaction, PostRecurrentTransactionResponse

3 Message protocol
eCHARGE servers listen for merchant communications on a configurable port (usually 4006).  The messages are exchanged over normal TCP/IP sockets, and follow a variable-length tag/value format.  The exact format is outlined here.
3.1 Message format
<length><FramingProtocolVersion><MessageName><Tag=<len><value>>*
The length is the number of bytes in the whole message, formatted as a five-digit, zero-padded decimal number, like "00158".
The framing protocol version is a two-digit, zero-padded decimal number, like "01".  The current framing protocol is currently "01".
The message name is a left-justified sequence of ascii characters, padded to a width of 28 with spaces.  For example, "SetMerchantData             ".
The rest of the message consists of a sequence of tag/value pairs, formatted with a tag name followed by a equals sign, followed by a length specifier (five-digit, zero-padded decimal number) and a value string of the specified length.  An example tag/value pair might be: "MerchantID=000041008".
3.2 Example message
A sample message might look like the following:
0006701SetMerchantData           Version=00009000000001MerchantID=000041008
except of course that the real SetMerchantData message has more tag/value pairs than the above.
4 API Specification
This section outlines the API exported by the eCHARGE server to the merchant side, in the form of several messages.  These messages are sufficient to implement a wide variety of merchant integrations.
4.1 Format
All the messages follow the same protocol, as described in the previous section, and therefore need to have "LinkType" and "Version" fields, in addition to the fields described below.  "LinkType" will normally be "00010Storefront" and "Version" will be "00009000000006".
4.2 Error codes
All the response messages will have non-zero status codes for reporting failure.  The codes are as follows:
Code
Meaning
Code
Meaning
0
Successful
1001
Unknown merchant ID
1
DataNotFound
1003
Database unavailable
2
BadPurchaseID
1004
Bad message
3
ProtocolError
1005
General server failure
4
CorruptedMessage
1006
Inactive merchant
5
NoPayPurchaseID
1007
Invalid merchant IP address
6
NoSuchPurchaseID
1008
Merchant data not inserted
7
NoPayNumber
1009
Non unique merchant key
8
NoSuchNumber
1010
Unknown merchant key
10
NotAvailable
2001
Network error
11
PriceMismatch
2010
Transaction not recurrent
12
NoFinalPage


13
IncorrectVersion



4.3 SetMerchantData
This message allows the merchant to store arbitrary data on the eCHARGE server, associate it with a merchant and transaction, and give it a type.
Fieldname
Type
Contents
Req
MerchantID
String
The merchant id
Y
MerchantKey
String
Unique merchant-generated key
N
MerchantSignonID
Long
Used for security at the IP-address level
Y
Type
String
URL, zert, etc.
Y
MerchantData
Binary
Opaque merchant data
Y

4.4 SetMerchantDataResponse
This message is sent from the server to the merchant, in response to the SetMerchantData message, to indicate success or failure.
Fieldname
Type
Contents
Req
Status
Int
Zero for success, or a number indicating the failure that occurred.
Y
MerchantKey
String
The MerchantKey passed-in, or a newly generated one if one was not passed-in.
Y

*Note: The combination of a merchant ID and a merchant key can also be used to retrieve the value, so if the commerce server integration passed-in a unique value, they can ignore this field.
4.5 TransactionStatus
This message requests status information about a given transaction.  The response indicates whether the transaction has gone through or not.
Fieldname
Type
Contents
Req
Merchant ID
String
The merchant id
Y
MerchantKey
String
Unique merchant-generated key
Y
MerchantSignonID
Long
Used for security at the IP-address level
Y

4.6 TransactionStatusResponse
This message is sent from the server to the merchant, in response to the TransactionStatus message, to indicate the state of the transaction.
Fieldname
Type
Contents
Req
Status
Int
Zero for success, or a number indicating the exact failure.
Y
State
String
PAID or NOT_PAID.
Y

Note: if the status is non-zero, the value of "State" will be undefined.
4.7 PostRecurrentTransaction
A PostRecurrentTransaction message is sent by the merchant to the eCHARGE server to initiate a recurring transaction.  It must include the following fields:
Fieldname
Type
Contents
Req
Merchant ID
Int
The merchant id
Y
MerchantTransactionID
String
See merchant gateway protocol
Y
MerchantAccountID
Int
Used for security at the IP-address level
Y
BillingAmount
Double
The amount of the recurrent billing
Y
Data
Int
Opaque merchant data
N

4.8 PostRecurrentTransactionResponse
The eCHARGE server sends A PostRecurrentTransactionResponse message to the merchant, to indicate success or failure:
Fieldname
Type
Contents
Req
Status
Int
Zero for success, or a number indicating the failure that occurred. See Error Codes.
Y
MerchantTransactionID
String
The MerchantTransactionID passed-in
Y
5 Examples
5.1 Store and forward, Redirect
This is a sequence that shows how a general merchant integration might work, with a merchant side store-and-forward (SetMerchantData, GetMerchantData), a client-side redirect (type = "URL") and a merchant-side transaction verification (TransactionStatus, TransactionStatusResponse)
5.2 
Post recurrent transaction
This is an example of how a merchant system would notify the eCHARGE server that a recurrent transaction needs to be repeated.
Note: a "CDR" is a call detail record, used to inform the phone company what number will be billed.

Merchant API






January 26, 1999- CONFIDENTIAL- DO NOT DISTRIBUTE	II





Merchant API		01/26/99

Copyright (c) 1998, eCHARGE Corporation	Page 10 of 1	
COMPANY CONFIDENTIAL	01/26/99

-------------- next part --------------

eCHARGE(tm) Corporation presents a new 
billing system that is ideal for an ISP.

The Concept:
Charge monthly ISP access fees to the local phone bill.

eCHARGE(tm) Corporation is offering a new and unique transaction system that is a logical solution for an Internet Service Provider.  The innovative eCHARGE ISP application allows subscribers to sign-up for monthly service and directly charge regular ISP access fees to the local telephone bill.  eCHARGE is an ideal payment option for your customers who prefer to be invoiced, and will help you reduce the associated invoice processing costs.

Consumer Benefit
* Ideal payment option for customers who don't want to use or don't have a credit card.
* Monthly recurring billing makes it easy to automatically pay on time.
* Simple to use point and click technology assists novice customer.
* Convenient billing to the monthly phone bill consolidates Internet & telephone related expenses.
* Completely secure payment option.
* Interest free account.
* No account to open or additional paperwork.


ISP Benefit-  Grow/Maintain your customer base: 
* Easy to use for online registration.
* Offer more payment options to suit customer needs.
* Increase customer loyalty.
* Increases your competitive advantage against Telco ISP's who are offering a similar payment option now.
* Offer an automated payment method for a customer whose credit card account is either at the maximum limit or no longer valid.

ISP Benefit-  Cut Costs:
* Reduce the cost of invoice processing by switching existing invoice customers to an automated system like eCHARGE.
* Faster and more accurate payment method than checks.  No NSF Checks.
* Automated recurring billing option.
* Improve cash flow.
* By putting your charges on the phone bill you insure prompt payment.  *

*the phone bill is the most likely to be paid first and on time.


-------------- next part --------------
eCHARGE(tm) Corporation was established for the purpose of bringing the "eCHARGE" purchase transaction system to the Internet market. The company's management has extensive experience in technology based organizations, public companies, the Internet and the telephone and communications business. 

The eCHARGE transaction system is unlike anything currently available on the Internet. Proprietary software allows the buyer to safely and conveniently charge their Internet purchases to their monthly telephone bill. No credit checks, no application forms to fill out, pre-payments or passwords are needed. 

Though the system is virtually fraud proof and therefore attractive to online users because it is safer to use than credit cards and other methods, the most outstanding benefit to consumers and merchants alike is the simplicity and ease-of-use of the eCHARGE system. The system is fully automatic and quick. And, transactions are anonymous with "click and buy" simplicity. 

We recognize that one of the biggest challenges on the Internet is the conversion of 'HITS' to 'SALES'.  The eCHARGE billing system easily overcomes this challenge with it's  simple 'CLICK and BUY' feature.

The management of eCHARGE Corporation is confident that online customers and merchants will quickly adopt and use the eCHARGE  payment  option because it is a safe way to conduct Internet transactions but more importantly it's much more convenient than any other method. 




eCHARGE Corporation
500 Union Street, Suite 745
Seattle, WA. 98101
(206) 749-9900 - Voice
(206) 749-9800 - Fax
www.eCHARGE.com 



More information about the freeside-users mailing list