JSR 187: Payment API for the Java Platform (JPay) Submitted

Discussions

News: JSR 187: Payment API for the Java Platform (JPay) Submitted

  1. JSR 187 requests the creation of the Payment API for the Java Platform (JPay) specification. The JPay API will support payments in an open, Web-like environment targeted for J2SE and J2EE. In particular, a JPay connector shall support HTTP servlets as the typical implementation technology for Web applications.

    Check out JSR 187: JPay.

    What do you guys think, do we need such a JSR?
  2. I do think this is a little short sighted:

    2.9 Are there any internationalization or localization issues?

    No.

    Um...are we all going to Euros? International payments, currency conversions, Taxes, Tarrifs, and Tolls? Import export requirementes. Pesos ? From what country. Time of exchange rate? These things may be covered by the JSR, but I think they definietly need to be covered.

    Make sure that you use BigInteger/BigDecimal for currency...otherwise things get messy when dealing with devalued currencies (The Lira used to be my favorite example, but I am sure something else will come up. Damned Euro again:)


  3. What do you guys think, do we need such a JSR?


    Absolutely. The ability to charge for intellectual content on the web is key to its long term success. At the moment the business models all revolve around selling existing (real-world) products. Intellectual content requires either subscription (and I know that even people like the online encyclopedia companies have trouble making that work) or giving it way for free.

    The key to useful intellectual content on the web revolves (IMHO) around very small, highly automated payments. Whether JPay can do that remains another issue.

    /david
  4. I am tasked with creating a system (web site) where each page may charge for access using a different merchant account, payment processor, etc. This would make my job much easier. Right now I only support payflow, but as soon as we get a client which wants to use their own payment processor, I have to program for a whole new card proccessing API.

    I say while we don't NEED a standard api, it would be greatly benefitial.

    -Pete
  5. Absolutely this is needed. We've coded our app to payflow and are now, in some ways, their hostage. And it's very hard to do Euro's or other "exotic" currencies with Payflow. (Payflow supports it, but no merchant banks that work with VeriSign's payflow product will do anything but dollars without a very large committment.)

    We need this in a very big way.