Topic: [ANNOUNCE] OpenPay - Entering Burn In, Shake Down & Alpha Test phase. - page 4. (Read 19448 times)

This is one of those times I really wish I wasn't bound by NDAs.  Square is known to my client, they have worked closely in the past.  They aren't competitors and I believe they are aware of OpenPay already, that's all I can say about that topic right now.
The business side of things such as bringing on Hypercom, Ingenico, Square etc is being handled outside the scope of what I'm doing here, but yes it is being handled.

As far as charging a percentage fee, the fee is paid for by the consumer not the merchant.  Hence the fixed fee, however I have considered the implications of 1% fee with a max of 0.01BTC, this is basically the opposite of what you're talking about and the problem with it is that it doesn't provide enough resources to back the insurance program.  Charging a 2% or whatever merchant gateway fee like Square, PayPal or Authorize.net is a real possibility and would probably be an important source of income for those service providers, not having to pay any of that fee to the network is a real deal sweetener for them I imagine.  Don't forget though, that anyone can be their own service provider.  They just need to put up the infrastructure that they want to run and find someone else to fill the gaps.

For instance the reference implementation will include 2 service provider deployments, one targeted at merchants and one targeted at consumers. 

The consumer side will essentially turn their MtGOX account into a bank account.  They will have their BTC balance and their local currency balance.  As the need arises, bitcoins will be purchased to fulfill transactions.  This handled through an exchange connector I'm working on, MtGOX really has no part in it.  The connector is just automation service that works with their existing API.

The merchant side will feature a gateway application with another exchange connector which is also tied to MtGOX, this is used for clearing BTC balances back to local currency.  All a merchant would need is a MtGox account and the gateway app which includes, the messaging component and the exchange connector.  No other infrastructure would be needed for them.

Hope that helps!

Yes you understand correctly.

As to the question about where funds for the exchange process are stored that would be at the customer's service provider.  Just like how your current visa card might tap your savings if you don't have enough in checking, the goal is for places such as MtGOX or whomever else wishes to participate to have an integration pathway between the local currency denominated account and the BTC denominated account.

Thanks!

You completely misunderstood anything I have said in this thread. I think his idea is on point. The execution of the idea is very wrong and lining up to be a mess, where if he went and found a project leader who has experience leading open source projects it could be done greatly. I just am sad that this project is going in a direction that is very wrong and the code is a mess. XMAPP for communicating the commands, is a disaster and needs a real programmer to handle. Just like when bitcoins used to use IRC to find peers, that is asking to be hacked. Thank god they fixed that.

Second I am not the programmer or have any involvement of http://cam4btc.com other than another idea that I thought was a good idea, so get your facts straight. Right now I am working on 2-3 projects that would be more important then some kids trying to make a good idea that is over their heads. I think this project needs a real coder. BTW streblo go look thru my post, they pretty smart, and usually right about these things just saying.

So,  do I understand the following correctly?

1. OpenPay is a system which merchants will have to have a specific setup to be able to take advantage of, although you are working with a large company to make it default for a large number of merchants.
2. It allows you to "enroll" a standard card (eg. gift card) which you can then use to send money to a merchant without paying the 3% (or whatever) fee.
3. It does so by having the card swipe perform a credit card system-style authentication and then creates a Bitcoin transaction from you to the merchant.
4. The merchant can choose to keep the money as bitcoins (in which case there's a deposit insurance program) or have it immediately converted into local currency (into their bank?), so the whole thing is essentially a BitPay equivalent for meatspace.

One question: where do the funds for the consumer to pay for the Bitcoin transaction come from? I understand that you can have a Bitcoin balance, and if you don't have enough you can automatically buy it from an exchange, but where is the value to do that stored, and how do you fill it up?

Thanks for the clarification. Not sure if you think this is something that should be built into OpenPay but, just thinking as an end user, it would be good to see a network managed escrow feature that tied in with courier tracking systems. E.g. Funds from purchaser held centrally in escrow which are then either automatically released to the vendor once the recipient has signed for their delivery or returned to purchaser if delivery fails. One trusted escrow service on a trusted payment network might do a world of good for Bitcoin's "trust" issues. Just a thought.

I realize the size of this project that why this cool idea has to have an amazing programmer behind to make it work.
So then he should just write some RFC documents then using code.



I can't contribute I have my own projects, if only there was more time in the day I would LOL, I am not insulting anyone, I just telling him and I can see he is not a strong Java programmer, and I am trying to point him in the right direction.

So anyone with a jabber client, can easily DDOS or fake flood a server with fake request that the server would see as valid commands.
P2P and client/server can be the same thing
Java has process builder and can spawn other processes.

I am still disappointed that a non higher caliber programmer is project leader, maybe he should start looking for a better project leader.

Yes, yes, we all wish we were all better at the things we do. Lack of programming ability or not, isis is making a best effort attempt at bringing something great -- disruptive, even -- to merchants and consumers. And he's making it open source. And he has backed by large POS companies which will help overcome rather large hurdles. So whether we want to work on systems that allow for widespread, rapid adoption of ubiquitous multi-currency transactions or camming sites, is our own decision (with it's own, respective thread). I am truly sorry to hear other projects are taking your time.

Has OpenPay considered a percentage transaction fee (with a minimum of 0.01BTC, perhaps)? In my anecdotal experience, merchants abhor per-transaction fees. Just look at the success of Square. By the way, partnering with square would be an enormous boon to OpenPay. Does your business partner compete directly with them? Square has (easily-modifiable) software and magstripe readers at many locations. I'm sure they would love to take their 2.75% without having to pay any of it to Visa, etc.

Sadly, I wish I had more to offer this project. Hopefully I can send a donation here in a month or two.

EDIT: VVVV  Okay, fair enough. I apologize if I was brash.

You do realise the size of the task the OP is trying to achieve ?

The whole point of having a clearly defined set of services in a reference implementation is that each service can be engineered, or re-engineered, as required.

A reference implementation that successfully bridges the 'consumer payments' networks and the Bitcoin network would be incredibly useful.

Maybe you could contribute or come up with reasons that your suggestions are better, instead of tossing around insults?

You do know you can run each of those things isolated yet in the same application.

XMAPP is very wrong for this type of application, sockets with self signed SSL would be the best.

P2P and client/server models can do the same thing just like bitcoin is P2P yet it has a server and client model, with nodes.

I am disappointed that this cool project doesn't have a higher caliber of programmer running it.

I just noticed that I failed to address a significant part of your comment in my last post.

I already explained the reason for running stand alone.  And being able to use the "chat" but not the rest is precisely one reason for running everything as a series of standalone services.
As far as a client & a server version, this is a network protocol stack, client or server is a matter of how you bundle it, but strictly speaking there is no client or server it's all P2P with onion routing.

The product is currently built from the standpoint of multiple service providers all working to try and process a payment.

It starts with the merchant gateway application which talks to the PIN pad and Messaging.

Messaging then forwards the message to everyone it (or the service provider) knows about.  At this point you are no longer under the control of the service provider, but it is assumed that the customer has an account with some service provider somewhere (even if it's just an app on their phone) who is looking for a payment request message.

So at this time we've sent a message and it's "in the cloud" (my term for we really have no clue where it's at).  Eventually it get's picked up by the customer's service provider, i.e. their bank, their cellphone, whatever.  Some authentication takes place and then a standard bitcoin transaction is built, signed and passed back along the XMPP network.

Where it eventually lands in the lap of the merchant service provider, who notifies the merchant that the funds are good and then submits the bitcoin transaction to the normal bitcoin network.

So you see it's really more of a P2P model rather than a client/server model.
I hope that makes things a bit clearer!

You are correct payment terminals must remain PCI compliant and that does generally mean it is locked down to some degree. 
There will be merchants who will need to invest in new hardware/software to process OpenPay transactions, and we have a plan to deal with that by working one on one with merchants & their service providers to minimize the impact as much as possible.

The piece of the puzzle you are missing here is that PCI compliance for a payment terminal means that it is running a locked down and signed firmware from the merchant service provider or the manufacturer. 
Switching providers allows the merchant to load (or have loaded) new firmware from their new service provider.  Fortunately we are working with one of the largest makers of POS terminals, to ship their new products with OpenPay EMV & AnyCard enabled by default, so I doubt it will be much of an issue.

Also I'm not sure about PCI compliance requirements in Europe but I assume they are universal.  I do know for certain that state side merchants who own their equipment are allowed to run apps on their terminals to support any payment type they wish.  The apps just need to be blessed or signed by either the manufacturer of the terminal or the merchant service provider.  Most terminal manufacturers make software development kits available and will either provide a signing key, or sign off on the app with very little hassle.

Either way, the change to method of payment isn't really an app in the strictest sense of the word, depending on your configuration, the capabilities of your terminal/gateway and whatever agreements you may have in place with your merchant service provider, the "app" simply routes the payment flow through a different network for processing.  Ideally this would be completely seamless for the merchant because most of the heavy lifting is actually done by the service provider.
Think about it this way, you can generally use Discover or American Express on the same terminal as you would use a Visa or Mastercard.  The only difference between swiping a Visa and swiping a Discover or AMEX is what network the transaction is run over.  Same deal with OpenPay.

Now back to the point about POS systems, i.e. the software running on the cash register, not the software running on the terminal.  The client who gave me the initial idea to pursue this, is one of the largest producers of this type of software in the industry.  While I can't disclose the client's name nor can I disclose who runs their software, I can safely say that at launch we will have 4 nationwide retailers on board and you will be able to use OpenPay to buy auto parts in the US, Canada, Mexico and get automotive services such as oil changes, break jobs etc.  We're actively looking for general merchandise retailers to sign up to accept OpenPay once the whole thing launches, each one will have unique needs and challenges. and OPA will actively support that effort by providing whatever support the merchant may need to get going,

I hope that's helpful!
 

Each module should stand alone because they will be running on their own server, in their own memory space, isolated from the rest of the system.  
This breaks a whole bunch of attack vectors, you can't just compromise 1 machine or 1 service and have anything of value.
Furthermore, the reference implementation is just that, a reference for building your own.  We want people to take what we have, slap their business logic onto it and get going, but the fact is most service providers will probably want some serious customization for their own offerings.  Having each module stand on it's own allows a company (or person), to replace a small chunk of functionality at a time, test it out and ensure it works they way they want it to before moving onto another chunk.

As for XMPP...
XMPP is only used for network communications between deployments.  XMPP was chosen because it's clean, simple, extensible and fast.  With XMPP, multiple deployments can receive and process the same messages without a bunch of excess configuration.  For instance if I am running a service provider I only have to publish one address, [email protected] and payment requests will automatically be broadcast to all of my deployments.

Also securing jabberd is a known quantity, whereas handrolling a messaging protocol along with a model client/server implementation has the potential to introduce new vulnerabilities.

Inter-module communication is handled using SSL and sockets.

In regards to comments, you're correct the code needs more of them. In the modules I'm committing tonight I've tried to be much more explicit.  I'll get a tidy pass in before we start burn-in and shake down to go through and clean it up.
You'll also notice I'm missing unit tests, I'm probably going to end up paying for that in the end.  Frankly I hate writing JUnit tests but it does need to be done.  I'm considering adding JML as well.  

Again this will be done during the tidy pass, but it's exactly the type of reason we have open sourced it.

@OP

I am skeptical about the EMV part.
In Europe, a POS terminal must be PCI PED compliant, meaning neither Visa/Mastercard nor any bank will allow the POS to install a new module, specially a bitcoin module.

The implication is that the merchant needs to get a separate, openpay-enabled POS terminal and hook it up to her checkout system (expensive proposition) OR ask a value add reseller to install the OpenPay module in the existing POS (also an expensive proposition).

Therefore I fail to see where this scenario improves on the merchant simply integrating a bitcoin acceptance feature (essentially currency, conversion, QR code display) on said checkout system.

What I do see is the user experience of a customer carrying the card you describe: if the merchant is equipped with the openpay-enabled POS (that the big if) the customer can make a partial redemption of his bitcoin balance to settle his purchase transaction, then reload his card as needed.

In a nutshell, the card makes sense only if you can get "free" access to the POS terminal.
A project that entails having merchants putting money in yet another POS terminal or another POS software is doomed to wait a long a time before gaining a large acceptance.

I don't understand why each module should be able to stand alone? That makes no sense, I am going to use the chat but not the rest. Also it makes more sense to do one version that is a client version, and one that is a server. Everything is together kinda makes no sense. Also you need more comments, also you need to tell people to org.jivesoftware.smack library in the readmd. Why you using XMPP, why not just use sockets to send around the information?

Source code is being released daily and is nearly complete.  Each module should be able to stand-alone.  I need to document each service, but if you can read Java code you should be able to mostly get a deployment going now.

The sources can be downloaded from github...
https://github.com/openpay/OpenPay

Anyone with Java experience is welcome to start giving more eyeballs to the code.  I should have a running deployment for burn in & shakedown by the end of the week.

Enjoy!

That's exactly correct. 
Every transaction originated from the reference software, has a small fee of 0.01 BTC, half of the fee goes to the Open Payment Alliance to cover operating expenses, the other half of the fee goes to the deposit insurance program.

The purpose of the deposit insurance program is to allow people to get their money back should their service provider encounter some unforseen difficulty. 
If you are running your own provider dealing with your own funds, there is no need to contribute to this fund (it's pointless, why would you rob yourself) so you can just disable it. 

However for providers that wish to carry the OpenPay logo and show the "Deposits Insured by" logo, it's mandatory. It's basically a free value add for the provider and gives them a new no-cost tool they can use to market to their target audience. 

The fee goes to a completely offline address that can only be accessed by a committee comprised of members of the Open Payment Alliance and these committee members would be elected annually by the member body. (Which reminds me we need to start having nominations for committee members soon).

If there is an event, a provider would file a claim (or if they were shutdown the individuals affected could file their own claims), the validity of the claim would be vetted by the committee and funds dispersed to the effected parties.

To some extent this program does run on the honor system, but it's assumed that if you go through the steps to join OPA, then you'll abide by the terms and conditions of it.

The deposit insurance program came about from discussions we had in the beginning with several merchants that were interested in accepting Bitcoin for payment. 
This was after the linode issue and right before the first bitcoinica break in, about this time Tradehill and their problems were mentioned as well.
The consensus was basically that for merchants and consumers to really feel comfortable with bitcoin there would need to be some sort of deposit insurance that was completely separate and independent from the service providers.
Thus we came up with the idea of making deposit insurance a feature of the network and to have the insurance program managed by the operators of the network instead of the service providers.

Mostly you're correct Clipse.  Depends on if you're talking about EMV or AnyCard.

With the EMV option it's completely compatible with the EMV standard and any place that takes NFC or Chip & Pin based EMV payments.  However we will need to acquire an IIN from ISO first and that's going to take some time.
Also EMV isn't a popular option in the US and there are lots of merchants that are magstripe only, hence the need for the "AnyCard" payment option.  With AnyCard, the merchant will need to have their payment terminal re-configured to allow OpenPay as a method of payment.  This is why the offer of free custom programming for merchants that want to begin accepting OpenPay.

That's not quite correct. 
OpenPay's primary purpose is to allow the spending of bitcoins in meatspace. 
Most merchants probably don't want to be stuck with large quantities of bitcoins, similar to how a US merchant wouldn't want a bunch of Euros sitting in the til, nor a European merchant want to be saddled with a bunch of USD.

Therefore bitcoins in this scenario are being used as a common interchange currency.
The merchant would have an exchange rate of BTC/Local, this exchange service would be provided by whomever setup their merchant services account.
If the customer has an account with funds denominated in local currency, then his/her provider would also provide an exchange service for the local currency amounts in excess of their BTC balance.
Multi-denominated accounts are also a real possibility, but it's just up to the implementer's and service providers.
So in a nutshell at least 1 and possibly 2 or 3 conversions are going on.
First the merchant needs to convert his local currency based transaction amount into BTC.
Next the customer may not have sufficient BTC in his/her account to cover the transaction and may wish to buy some BTC so they can complete the transaction.
Finally the merchant will probably wish to have the BTCs they have earned throughout the day converted into local currency, that would be conversion 3.
All of these conversions would be handled by exchanges that wished to join the OpenPay network and offer these services to their customers.
I'm working on a gateway (released separately), that will work with MtGox, but it's unofficial.

Back to the card thing.
For the magstripe option you can use any card you wish that has track2 data encoded on it.  It doesn't need to be a mastercard, visa, it can be an old expired gift card or just about anything else with a stripe on it.
The card just serves as an enrollment identifier and is used to identify you to your service provider (bank, credit union, eWallet service, even an app on your phone). 
By definition you would need to know about bitcoins to enroll right now, but it is possible that service providers may come online that never actually mention bitcoins, and never denominate accounts in BTC.  I don't like that idea, but how the service providers run their business is up to them.

The way I interpret the OP, you would be able to swipe a bitcoin card? at any merchant that allows visa/mastercard paypoints and online gateways, please correct me if Im wrong Isis.

This all sounds great to get bitcoin moving into the "real world".