Standards Watch : PayCircle Opening Up Content Services

Payment service providers (PSPs) will become the bridge in the electronic world for procuring payments from consumers and delivering them to content and service providers. Portals, retailers and increasingly, network operators, all have plans to take on the role of merchant or PSP. As they turn their eyes to the possibilities of downloadable applications—such as video streams or digital downloads of MP3 files or video clips, online magazines, tickets or services—charging for these services efficiently through micropayments becomes a top priority.

To foster an environment of specifications on which sophisticated business and payment models can be built, PayCircle (www.paycircle.org) was formed last year as a vendor-independent, non-profit consortium whose main focus would be “payment technology improvement,” according to Richard Dawson, lead business systems analyst at CSG Systems—one of the founding members. Other members of PayCircle include Hewlett-Packard, Oracle, Siemens, Sun Microsystems, Amdocs, as well as a host of online gaming vendors, mobile application service providers, content providers and other electronic merchants. “We are basing our specifications on IN prepaid solutions that focus on business enablement and definition of use cases, as well as technical specs in XML and Java,” says Dawson.

The Evolution of a Payment Interface

PayCircle members Siemens and Hewlett-Packard had developed a payment methodology for mobile e-services through their e-speak initiative. It was incorporated into a Mobile Payment group in PayCircle that is concentrating on payment interfaces for mobile payment applications. PayCircle Payment Web Service Specification 1.0 and a reference implementation for this specification contain WSDL (Web services description language) sources and XML schema that should enable actual mobile payment applications and services for MP3 files, video clips, subscription-based online magazines, streaming video/radio channels or on-demand gaming, as well as for interaction with point-of-sale terminals or vending and ticketing machines.

“The payment API supports prepaid and postpay and enables charging for volumes of time and data sessions, as well as currency.” That, Dawson says, enables providers to charge by the actual amount of sessions or for pre-rated sessions. “We believe this API guarantees network independence and portability of the applications, which will help network operators create specialized applications from third parties,” says Dawson, noting that both the Parlay Group and PayCircle wanted to consolidate the fragmented work going on in the industry.

Because it is a co-branded specification, parts of the PayCircle mobile payment APIs have now been integrated into the Parlay X 1.0 specification, which is available at www.parlay.org/specs/index.asp.

With Parlay X 1.0, pricing methods for B2B, B2C or person-to-person transactions have been clarified according to whether pricing is “continuous or event-based,” says Dawson, noting that the former is based on duration of mobile data sessions or volumes of data downloads; the latter on itemized events, such as ring tone downloads, gambling, m-ticketing, MP3s, and so on.

In general PayCircle members will investigate enhancements that could be added to the next version of the PayCircle Payment Web Service.

The goal of the PayCircle Payment Interface, which has been incorporated into Parlay X 1.0, is to “open up access to the maximum number of back-end financial systems without unnecessary restriction,” says Dawson. “The Payment Interface also reflects the differing roles among m-service providers and PSPs.”

The interface environment is based on W3C standards for Web-based services. SOAP (simple object access protocol) is proposed as the mechanism for encoding and formatting m-service to payment service communication. In addition, another proposal would involve registration and discovery of mobile payment services, which use specifications such as UDDI (universal description, discovery and integration).

PayCircle working groups also use underlying standard formats and protocols such as XML and HTTP, as well as security mechanisms such as XML-DSIG (Digital Signature) and XKMS (XML-Key Management System) document structures. “Currently, security mechanisms and protocols are outside the remit of PayCircle, as we are very much focused on just the payment interface,” says Dawson, citing authentication as a factor on which PayCircle also will focus. “We want to motivate the industry to use more sophisticated techniques, such as verifying certificates, digital signatures or SIM cards of mobile devices,” says Dawson. Additionally, fraud reduction is an ongoing mission. “In addition to secure channels, our members are looking at fraud management systems and standards for secure m-commerce,” he says, noting that secure PayCircle APIs focus on exposure to fraud on two levels—the enablement of real-time authentication and charge and usage authorization, and second, the rapid feedback of transaction events for immediate review by customers.