This week, Integration Developer News www.idevnews.com interviews Karsten Lüttge, a key Siemens exec driving JPay to learn more about how it works -- and what opportunities JPay presents for Java enterprise architects and developers.

Read more: http://www.idevnews.com/IntegrationNews.asp?ID=147

"The proposal is being back by some of the leading names in transaction-driven Java, including Oracle, IBM, Sun, HP and Siemens"

Where are the main players, MasterCard, Visa etc(the primary networks) who really drive the whole process and the real domain experts. Some times I am amazed how much we got into technology without knowing the business... and why we poke our nose every where..

i don't see why visa/mc would be involved in this. do they provide online payment systems? my understanding is that most businesses submit payment through a clearing house to make a credit card payment. this lets them handle mc/visa/disc/amex, etc, etc.

at my current gig, we're using authorize.net to handle these payment transactions. i'd imagine it'll take some time before these companies will start to adhere to the standard. this java payment api hasn't even been drafted yet. and it's being pushed by the api vendors and not the transaction providers. which makes sense because the api vendors are trying to sell a value added product in a market that is constantly being diluted with FOSS (not that that's a bad thing IMO). it's part of the api vendor's bread and butter to provide easy to use api's. it's part of the transaction provider's bread and butter to provide _some_ api and to be really good about providing transactions. since they've all got some existing api, change takes time and money. money that'll probably only be spent with some leveraging on the part of the api vendors.

i don't see why visa/mc would be involved in this. do they provide online payment systems? my understanding is that most businesses submit payment through a clearing house to make a credit card payment. this lets them handle mc/visa/disc/amex, etc, etc.

You better check with them, as THEY will ultimately process the requests. Think of it like an effort to build a common interface to an O/R mapping tool, without ever knowing how the DB works. I think it is possible, but you might be missing something at the end.. Not mentioning that those "key players" have their own plans for the future of e-payment systems and if they decide to enforce them, your api may become ... simply outdated.

The biggest advantage of including Visa and Mastercard is their political weight. When Visa and Mastercard mandate something, all member banks and processors have to follow.

I'd be more interested in hearing how any of the top realtime payment gateway vendors like Paymentech and Verisign are going to support this/if they are going to support this.

We use Paymentech's Orbital gateway Java SDK on all our eCommerce sites and I'd like to know if they plan on using JPay as an abstraction wrapper around their existing API or in place of their existing API.

I haven't had a chance to have a detailed look at the spec yet, but from what I can see from a cursory examination, this seems to be aimed at J2ME-type applications. In which case it may be suitable to have a common (simple) API for these types of transactions, but convincing the providers themselves to adhere to what amounts to a lowest-common-denominator API may be tough.

I haven't had a chance to have a detailed look at the spec yet, but from what I can see from a cursory examination, this seems to be aimed at J2ME-type applications.

No, they support it for J2SE and J2EE platforms see the link http://www.jcp.org/en/jsr/detail?id=182.

Seeing expert group of this JSR I guarantee it will become a show piece on the JCP website without ever providing a real value to the real world applications (what the heck they know about payement processing). I hope I am wrong in my assessment..

Payment processors follow their own techniques for authentication of the merchant and the "adaptor" on the merchant.
It would be interesting to know how the Specification addresses that issue.

-- Ashutosh

The article on http://www.idevnews.com/IntegrationNews.asp?ID=147 mentions "Collecting many transactions with multiple merchants over a billing period solves this problem and provides a new business opportunity for so-called payment service providers".

I wonder if the API is targetted towards micro-payments (probably in a batch mode) rather than actual online transactions.

Regards,
Ashutosh

I haven't had a chance to have a detailed look at the spec yet, but from what I can see from a cursory examination, this seems to be aimed at J2ME-type applications.

No, they support it for J2SE and J2EE platforms see the link http://www.jcp.org/en/jsr/detail?id=182. Seeing expert group of this JSR I guarantee it will become a show piece on the JCP website without ever providing a real value to the real world applications (what the heck they know about payement processing). I hope I am wrong in my assessment..

I think you're exactly right. This API is not suitable for real-world payment applications. I don;t know how many payment service providers will wish to be saddled with such an anaemic API.

Hi there, I think as the spec lead of JSR 182 and the person that has been interviewed I should respond here. Sorry it took me some time to get aware of the discussion here and finally decide to subscribe and respond. BTW the tone here seems a bit harsh!? I suggest one should at least visit the JSR 182 homepage, or better review the API, before ultimately assessing on it.

I have to admit that some of the (mostly negative) comments posted here are indeed correct. However, many are not or are at least questionable. Let me comment on some of the statements made.

The key players, such as Visa or MasterCard, are missing in action (Rashid Jilani)

I agree that support from these companies would have been good. However, with JPOS we have an open source project involved that has quite some interesting references in working in credit card environments. IBM is also in the expert group. They clearly have a stake in such transaction processing systems.

Credit card networks will normally not see the transactions since they are assumed to be aggregated and result in a single transaction to pay the bill. This bill payment is not in the scope of the API. Also, you should understand that the API will sit in the Point Of Sale (physical or virtual) and separate the POS application from the underlying payment Acquirer protocol. A resource adapter providing the API would wrap this protocol and expose it in a unique way to the application. The POS application could run in different environments without being changed. All integration lies in picking the right resource adapter. So again, I don't see why banks or credit card networks are absolutely necessary here, although I admit their knowledge would have been useful. The criterion is if the API can map on the appropriate Acquirere protocols.

Seems to be aimed at J2ME-type Application (Rory Winston)

As somebody had responded already, and as the interview and the JSR clearly state, the API addresses mainly J2EE as this is a technology suitable to create POS applications. BTW there is JSR 229 defining an payment API for applications running on J2ME, such as a smartphone.

The API has not been drafted yet (Rashid Jilani)

The API is in early draft review and can be downloaded from here the JSR 182 homepage:
http://www.jcp.org/en/jsr/detail?id=182

What the heck they know about payment processing (Rashid Jilani)

Siemens is a leading vendor for wireless and wirelinie telephony networks and prepaid (calling card) solutions for telephony. Their calling card solution can deal with huge amounts of online transactions from different applications, such as ringtone download, SMS-Centers, and of course telephony exchanges. So I consider them (or us, since I'm a Siemens employee) experts in realtime processing for micropayments.

Payment processors follow their own techniques for authentication of the merchant and the "adaptor" on the merchant. (Ashutosh Shinde)

The idea is that authentication is handled by the resource adapter and not exposed to the application. This makes the application independent of a particular authentication mechanism. Credentials shall be configured within the resource adapter.

Cheers. - K.