[November 30, 2000] "To help Internet merchants process a broad range of Web-based payment types (including credit debit card, purchase card, and Automated Clearinghouse, or ACH payments) for B2B and B2C e-commerce, VeriSign, Ariba, and other vendors have created the XMLPay specification for sending payment requests and responses through financial networks. XML simplifies client-side processing in payment service applications, allowing applications to be easily linked to larger XML workflow environments. XMLPay is also a live 'payment gateway' service that provides connectivity to most major bank processors and financial networks, and comes pre-integrated in many e-commerce applications. Instead of having to use point-to-point, difficult-to-integrate payment solutions, merchants can simply communicate payment requests to the XMLPay gateway and VeriSign switches these requests to the appropriate financial institution, returning results back to the merchant. XMLPay also helps businesses gain information from transactions, and supports certificate-based identification and authentication, digital signatures, and the generation and archiving of digital receipts."
"The XMLPay Specification consists of three parts. (1) XMLPay: Core -- the heart of XMLPay. It defines the basic XML datatypes needed to unify B2C and B2B payment processing applications. (2) XMLPay: Registration -- captures automation of payment-related enrollment functions, such as merchant registration and configuration. (3) XMLPay: Reports -- specifies mechanisms for automating merchant transaction reporting functions in the payments back office. The first of these specifications, XMLPay Core, is available now (November 2000). Teams working on XMLPay are planning to extend the functionality to registration and reporting. The driving goal is to provide a public specification for Web payment interoperability, from merchant service sign-up, to payment execution, to reporting functions after payments have taken place."
From the core specification: "This document, the XMLPay 1.0 Core Specification, defines an XML syntax for payment transaction requests, responses, and receipts in a payment processing network. The typical user of XMLPay is an Internet merchant or merchant aggregator who wants to dispatch credit card, corporate purchase card, Automated Clearing House (ACH), or other payment requests to a financial processing network. Using the data type definitions specified by XMLPay, a user creates a client payment request and dispatches it -- using a mechanism left unspecified by XMLPay -- to an associated XMLPay-compliant server component. Responses are also formatted in XML and convey the results of the payment requests to the client. XMLPay includes support for digitally-signed XML objects. Digital signatures are used both for the purpose of authenticating requests and responses and as a foundation for a higher-level digital receipt architecture based on an X.509 Public Key Infrastructure. XMLPay uses the digital signature format being specified by the joint IETF/W3C XML Digital Signature Working Group." Appendix A, "XMLPay Schemas," provides standard W3C schemas for XMLPay and XMLPay Types; Appendix B, "XMLPay DTD," presents the Document Type Definition for XMLPay... XMLPay supports payment processing using the following payment instruments: (1) Retail credit and debit cards; (2) Corporate purchase cards: Levels 1, 2 and 3; (3) Internet checks; (4) ACH. Typical XMLPay operations include: (1) Funds authorization and capture; (2) Sales and repeat sales; (3) Voiding of transactions. XMLPay is intended for use in both Business-to-Consumer (B2C) and Business-to-Business (B2B) payment processing applications. In a B2C transaction, the Buyer presents a payment instrument (e.g., credit card number) to a Seller in order move money from the Buyer to the Seller (or vice-versa in the case of a credit or refund). Use of XMLPay comes into play when the Seller needs to forward the Buyer's payment information on to a Payment Processor. The Seller formats a XMLPayRequest and submits it either directly to an XMLPay-compliant payment processor or, as pictured, indirectly via a XMLPay-compliant Payment Gateway. Responses have type XMLPayResponse. The Buyer-to-Seller and Payment Gateway-to-Payment Processor channels are typically left unaffected by use of XMLPay. For example, XMLPay is typically not used in direct communications between the buyer and the seller. Instead, conventional HTML form submission or other Internet communication methods are typically used. Similarly, because Payment Processors often differ considerably in the formats they specify for payment requests, it is often desired to localize XMLPay server logic at the Payment Gateway, leaving the legacy connections between gateways and processors unchanged. When used in support of B2B transactions, the Seller does not typically initiate XMLPay requests. Instead, an aggregator or trading exchange uses XMLPay to communicate business-focused purchasing information (such as level 3 corporate purchase card data) to a payment gateway. In this way, the trading exchange links payment execution to other XML-based communications between Buyers and Sellers such as Advance Shipping Notice delivery, Purchase Order communication, or other B2B communication functions..."
About the XML Trust Center (XTC): "XTC represents a new approach to the development of emerging technologies for next-generation Public Key Infrastructure (PKI). Built to support developers implementing emerging specifications for XML-based trust services, the XTC provides resources that encourage developer adoption and ensure solution interoperability. Though sponsored by VeriSign, the XTC strives to be vendor-neutral and invites the participation of other vendors implementing XML-based trust services."
From the Verisign XML Trust Services Overview: "XML complements Public Key Infrastructure (PKI) and digital certificates, the standard method for securing Internet transactions.And now,VeriSign XML Trust Services -- a four-component suite of open specifications for application developers -- makes it easier than ever to integrate a broad range of trust services into B2B and B2C applications. (1) With XKMS, trust functions reside in servers accessible via easily programmed XML transactions. Developers can allow applications to delegate all or part of the processing of XML digital signatures and encrypted elements to VeriSign, minimizing the complexity of the underlying PKI. (2) The Security Assertion Markup Language (SAML) developed by VeriSign and other vendors, solves this problem. SAML combines two prior protocols, S2ML and AuthXML, and offers a vendor-neutral, open XML standard for enabling secure e-commerce transactions by describing authentication, authorization, and profile information. Businesses can then exchange this data between customers, partners, and suppliers, regardless of the security system they use or the e-commerce platform on which they operate. (3) The XMLPay specification was created for for sending payment requests and responses through financial networks. XML simplifies client-side processing in payment service applications, allowing applications to be easily linked to larger XML workflow environments. XMLPay is also a live 'payment gateway' service that provides connectivity to most major bank processors and financial networks, and comes pre-integrated in many e-commerce applications. Instead of having to use pointto- point, difficult-to-integrate payment solutions, merchants can simply communicate payment requests to the XMLPay gateway, and VeriSign switches these requests to the appropriate financial institution, returning results back to the merchant. (4) To enable Internet registrars that sell online identity services to access central domain name registry data more efficiently,VeriSign has developed the Extensible Provisioning Protocol (EPP) to support an XML-based domain name management utility. EPP enables VeriSign Global Registry Services' accredited registrar partners to sell domain names, telephone numbers, and other identity assets via EPP, which permits greater information sharing and flexibility and new identification technologies gain acceptance."
References:
XMLPay 1.0 Core Specification. By VeriSign, Inc. [Fall] 2000. Release Date: 11/20/00. 69 pages. [cache]
XMLPay DTD [from the specification]
"XMLPay. XML Trust Services." White paper. "The typical user of XMLPay is an Internet merchant or merchant aggregator who wants to dispatch consumer credit (or debit) card, corporate purchase card, Automated Clearinghouse (ACH), or other payment requests to a financial processing network. Using the data type definitions specified by XMLPay, such a user creates an XMLPay client payment request and dispatches it....using a transport mechanism intentionally left unspecified by XMLPay....to an associated XMLPay-compliant server component. Responses are also formatted in XML and convey the results of the payment requests to the client. The use of XML simplifies client-side processing in payment service applications, allowing payment service applications to be easily linked larger XML-workflow environments. This paper describes the capabilities that XMLPay brings to payment services in a variety of application scenarios. The intended audience of this paper is anyone who is thinking about adding the ability to payment capabilities to their merchant Web site, B2B trading exchange, or other online transaction system. We describe what XMLPay is, who uses it, and how the VeriSign XMLPay payment gateway implementation makes it possible to use XML simply and easily in payment service applications." [cache]
XML Trust Services. "A four-component suite of open specifications for application developers developed in partnership with industry leaders including Microsoft, Ariba, webMethods, and Netegrity. [The specifications] make it easier than ever to integrate a broad range of trust services into B2B and B2C applications."
XML Trust Services. "A four-component suite of open specifications for application developers developed in partnership with industry leaders including Microsoft, Ariba, webMethods, and Netegrity. [The specifications] make it easier than ever to integrate a broad range of trust services into B2B and B2C applications."
