 |
|
iCharge™ xSERV Web Service  |
|
Transaction services on demandIn the video game The Incredible Machine the player is able to take simple components and connect them together in ingenious ways to perform some amazing feats. Web Services are something like that, but instead of connecting with ropes, pulleys, levers and gears, applications are loosely coupled together over the Internet using a standard protocol called SOAP (Simple Object Access Protocol). There are two participants in a Web Service interaction, the Publisher and the Consumer. The Publisher provides the Web Service which is used by the Consumer. The interaction takes place between two servers across the Internet. A program can consume multiple Web Services provided by different Publishers to perform a task. A program can be both a Web Service Publisher to downstream Consumers, and a Web Service Consumer to upstream Publishers. Web Services allow us to create Supply Chains of information services consisting of interconnected aggregators and distributors on the global scale at very low cost. xSERV at your service The iCharge™ xSERV Web Service connects directly to your e-commerce application, allowing you to programatically request transaction services (Methods) using SOAP. xSERV returns a response to the calling application within a few seconds to indicate the status and outcome of the requested transaction. The Methods provided include: • ProcessPayment to process a customer's credit card payment • ProcessRefund to process a refund on a previous payment • TransactionStatus to query the status of a previous payment • AccountStatus to query the status of your Client Account* • ReloadAccount to deposit to your Client Account* using your own card * Your Client Account is the prepaid account from which all iCharge™ fees are deducted. Using these Methods, you can completely automate all the financial processes required by your application. xSERV Applications xSERV is the ideal solution in situations where you need to exercise full control of your application and its user interface (if any). As xSERV operates under the covers inside your application, it is completely invisible to your users. Your application can integrate the basic payment services provided by xSERV with other functions provided by yourself or third parties to deliver a value-added end product to your customers. xSERV may be used in any application, and is not restricted only to Web-based transactions. Possible applications include: • Integration to existing software to add payment functions • Cash register or Point of Sale applications • Call centre payment services • Integration to IVR (Interactive Voice Response) systems • Bill payment applications • Processing recurring charges in batch mode • Any automated process where there is no human interface • Embedded applications in devices and appliances What you need... • Web Services Support If your application server supports Web Services, it is very easy to invoke xSERV and parse the XML response returned. Most modern application servers including ColdFusion MX, ASP.NET, Tomcat, WebSphere, Sun One, PHP and Perl provide support for XML, SOAP and WSDL - the basic protocols and languages of Web Services. If your application server does not support Web Services, xSERV supports an alternative interface based on HTTP POST. You can use the HTTP POST interface as long as your application can programatically submit a form to a URL using SSL (HTTPS). The response returned is an XML file and is exactly the same whether SOAP or POST is used to request the transaction. If your application server does not provide native support for processing XML data, you will need to write code to parse the response to extract the key fields which indicate the status of each transaction. • Secure Server If your customers enter credit card information through a browser to your application over the Internet, you will need to purchase an SSL certificate and install it on your web server. Note that a secure server is not required for the upstream connection between your server and xSERV, only for the downstream connection between your server and your customers' browsers. • Server Protection If your application stores customer credit card details, passwords and other confidential information, you will need to establish systems and processes to protect your database. At any given moment, there are hundreds of "bots" probing the Internet seeking out unsecured systems as potential targets. A properly-configured firewall will be your first line of defence against unauthorized intrusions. You'll also need to configure your server to minimize its surface area that's open to potential attacks. In addition, you'll have to establish procedures to keep abreast of the latest security bulletins published by your software suppliers and keep your system up to date with the latest security patches. Server protection is by far the most costly part of your service provision. The good news is that it is possible to reduce much of this cost if your application doesn't actually store any customer credit card information in your database. For example, if you are designing a web-based e-commerce application, you can pass credit card information directly from the customer's browser to xSERV for processing without storing it. You'll only need to store OrderRef - a transaction reference number that is either assigned by you or assigned automatically by xSERV. With the OrderRef field, your application can always invoke the TransactionStatus Method to retrieve details about the transaction, or use the ProcessRefund Method to make a refund if needed. xSERV has been designed to allow you to outsource the most costly aspect of server security. How it works 
xSERV Security Features • 128-bit SSL between xSERV and your server • 1024-bit RSA VPN between xSERV and Payment Gateway • Secured server environment • All xSERV calls require a password • xSERV can only be called from pre-registered servers • System continuously monitored for unauthorized entry attempts |
|