The network architecture of the system is based on TCP/IP. Where the environment is hostile and sensitive information is being transmitted between entities, encryption is always used. From the customer’s perspective, sensitive information includes cardholder information such as card numbers, cardholder names and expiry information. It also includes order fulfillment information such as shipping address, shipping date or method, or other delivery instructions. For merchants, sensitive information includes MAC generation keys, viewing on-line reports, and managing their account configuration.
For this reason, almost all Internet originated traffic to the acquirer system would be considered sensitive. Consequently, extensive use of SSL-enabled HTTP would be used by the acquirer system.
When sensitive information is sent over dedicated or secure channels, the option exists to allow the underlying network management to provide the requisite security. For this reason, if the acquirer has a dedicated connection to the Banknet system, then the transmission is done in the clear. The option exists to use VPN between the acquiring system and backend host system. Other options can be easily constructed.
The architecture specified above is very scalable.
Normally, the database would be on a separate server networked with one or more Payment Gateways in a cluster. This allows for load balancing, high availability clustering, and fault tolerance.
The database management system (DMS) needs to support transactional integrity, but can be any JDBC compliant product such as Oracle, DB2, MS-SQL or MySQL. For extremely high load systems, additional scalability in the DMS may be called for, but many vendors can support this requirement.
A firewall in front of the Payment Gateway is an essential feature of any network architecture. However, the firewall, possibly in conjunction with a round-robin DNS can provide some levels of load balancing between multiple Payment Gateway servers. It also insulates the Database server from any attempted connection by external entities.
The specifications for servers involved in the Payment Gateway function are quite generic. Any server grade hardware including Intel, RS/6000, Sparc, HP-UX, or other hardware platforms would be sufficient. Operating systems such as Linux, Solaris, AIX, or Windows would be acceptable. This generality allows for wide latitude in scalability and functionality.
The Payment Gateway function would normally be met by a Web Server/Application Server capable of supporting Java Servlets. Other configurations are certainly acceptable. Mod-perl and fast-CGI enabled Apache servers should have very good performance.
Since most of the work of the Payment Gateways will be done using SSL, the CPU load created by SSL encryption may be significant. This load can be minimized with dedicated SSL-encryption co-processors installed in the server.
The nature of transmissions between the cardholder, the merchant and the acquirer depends on whether the transaction is a Shopping Cart Order or a Cardholder Order. In the latter case, the cardholder is completely insulated from the acquirer. The merchant controls the entire transaction with the cardholder.
Shopping Cart Orders are more complicated. Because the merchant redirects the cardholder to the acquirer for checkout processing, additional issues surface in managing the shopping experience for the cardholder. In particular, after checkout, the cardholder should be redirected to the merchant site. To this end, the merchant can specify the redirection URLs to be used by the acquirer following processing of a transaction. These three URLs include where to send the customer following a successfully captured transaction, an unsuccessfully captured transaction, and an unspecified error (such as the backend host system does not respond within a timeout period).
Should the merchant require more texture in redirections than this, the option exists for the merchant to set a cookie on the cardholder’s browser prior to the redirection to the acquirer payment gateway. Upon redirection back to the merchant site, the merchant can then retrieve this cookie and based on its value, redirect the cardholder to the specific page on the merchant site.
Links
[1] https://niedermayer.ca/user/login?destination=node/163%23comment-form
[2] https://niedermayer.ca/user/login?destination=node/165%23comment-form
[3] https://niedermayer.ca/user/login?destination=node/167%23comment-form
[4] https://niedermayer.ca/user/login?destination=node/164%23comment-form
[5] https://niedermayer.ca/user/login?destination=node/166%23comment-form
[6] https://niedermayer.ca/user/login?destination=node/168%23comment-form