The design of a robust, flexible e-Commerce model is predicated on the following goals and objectives:

1. The system will be able to securely accept transactions from two types of merchants:
   1. Those without SSL encryption at the merchant storefront site. These merchants might use a simple buy button to allow a consumer to purchase a single item. Alternatively, they may use a shopping cart application but the actual exchange of cardholder and order fulfillment information is consummated by redirecting the consumer to an SSL encrypted web site hosted by the Payment Acquirer. The terminal status of each transaction sent by the acquirer for approval is communicated back to the merchant. Because cardholder information is not shared with the merchant storefront server, there is no need for encrypting any connections between the merchant and the acquirer. Only the consumer-payment acquirer connection needs encryption. These transactions will be known as “shopping cart transactions”.
   2. Those with SSL encryption at the merchant storefront site. These merchants would typically use a shopping cart application and collect the cardholder and order fulfillment information. The necessary information is then transmitted to the acquirer. The terminal status of each transaction sent by the acquirer for approval is communicated back to the merchant. Because cardholder information is shared with the merchant storefront, both the connections between the cardholder and the merchant and the connections between the merchant and the acquirer must be encrypted. These transactions will be known as “cardholder transactions”.
2. All communications between the merchants and the acquirer use Message Authentication Codes (MACs). MACs are used to verify the source of the transmission and verify that the message has not been modified enroute.
   1. Because the concept of a MAC is a security option not currently offered in the marketplace, the model allows the option to not include a MAC entity with messages. Such an option should only be made available if: the Merchant understands and agrees to accept the risks inherent in not using a MAC, and the acquiring system understands that this is the preferred option of this merchant.
3. Merchants will construct MACs using a MAC key generated by a certificate authority controlled by the acquirer. These keys will have a finite, predetermined life span. Merchants or their agents will use a Web interface to replace keys about to expire. The system will have to manage key chaining so that a merchant can have a transaction in transit using an old key while a newer key is still being enabled or installed.
4. All merchant authentication schemes will flow from a merchant id and merchant password. To request a new MAC key, a merchant will not only need this id and password but also some knowledge of the previous MAC key.
5. All valid message formats between the merchant and the acquirer will be explicitly specified.
6. Merchants can view transaction details, aggregate reports, and manage specific system configuration settings specific to their accounts using a web interface on a system controlled by the acquirer.
7. Where a message between a merchant and an acquirer does not contain an optional piece of information, the missing information will be retrieved from the merchant settings and configurations stored by the acquirer.
8. The acquirer system must be flexible and modular enough in design so that it can be modified to connect and communicate with multiple hosts, each with different transaction messaging formats.
9. Merchants can be notified of the terminal status of a transaction using a number of different methods: e-mail, secure web interface, or real-time HTTP communication.
10. XML will be used whenever possible to communicate data between independent systems.