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

Get bid side quote of market depth from mtgox, and then calculate how many bitcoins you would need to sell to get X amount of USD.

Ok I wanted to pose a quick question to everyone interested in the development of OpenPay.

One of the most important components of OpenPay from the perspective of a merchant will be the exchange connector.
The exchange connector's job is to receive quotes from an exchange (default is mtgox), and convert local fiat prices into btc amounts so the transaction can be priced appropriately.

Up until now I had been using the "last price", but the recent volatility makes me question the wisdom of that decision.

I'm considering using the Volume Weighted Average Price instead.  I say this because I don't expect a merchant to sweep each transaction, but simply to run a single sweep at end of business day.  I have a hunch this would provide a more stable & predictable sweep at the end of the day.

Thoughts?

I want to take a moment and thank everyone who has been helping with this project so far.
Even without the sources on github those of you who have been requesting a zip via email or irc, or IM have been a tremendous help.
Thanks!

So I think I've found the problem with git merge, it appears to be related to credentials.  I changed them at github after my last laptop burned up, then restored the project directory from a backup and I think it had the old credentials.
Has anyone experienced a similar issue in the past?

following.

Great idea, thanks!  I'm in as Isis, realname is someip.slkc.qwest.net

IRC chat for this project on irc.freenode.net, hashtag

#openpay

webchat link
https://webchat.freenode.net/?channels=openpay&uio=d4

@Isis,

My gitfu is not great, so I have a little cheatsheet for when I am committing into bitcoinj. I thought it might be useful to you in your merging:


UPDATE
Ensure local repo up-to-date with remote bitcoinj target:

git remote add bitcoinj-upstream https://code.google.com/p/bitcoinj/
git pull bitcoinj-upstream master


REBASE
You can rebase onto master like this:

    git checkout -b new-branch-1           <<< You will probably already have a branch you are trying to merge so won't need this.
    git fetch bitcoinj-upstream               <<< Fetch upstream bitcoinj to local repo.
    git rebase bitcoinj-upstream/master  <<< Work out differences of local to target upstream

Then you can squash commits with:

  git rebase -i bitcoinj-upstream/master

which will allow you to interactively choose commits to squash. Handy to squash multiple commits into one so that you can see them all together.


WHITESPACE
git show

or just :

git show

for the current commit. Gives very useful list of all additions and deletions.


COLOR
Very useful to see adds/ deletes/ whitespace in color in a console:

git config --global color.ui true

First time back to the forums in months, happen upon this thread! Exciting things, I haven't looked at the code (or lack thereof, given your recent hiccups), but I'm cautiously optimistic about this thing.

I'm having some problems with getting the code up on github.  I think it's a failed merge, I get the feeling I'm missing something simple and stupid.  Anyways the code is ready to drop.  If you can't wait to get it from github shoot me an IM and I'll send you a zip.  In the meantime I just need to figure out what I'm doing wrong with this commit.

Sincerely,
Isis

p.s. Thanks for all the props to all the supporters out there.  It keeps me motivated to keep working on the code.

p.p.s.  I'm setting up a test gateway on AWS, will post a link to it as soon as it's up.  The test gateway will allow you to perform real transactions without all the headache of setting up the entire system locally.  Since no information is actually stored at the gateway I don't see any sort of security issue putting it on AWS, but if anyone finds something let me know and I'll either fix it or take it down.

it just doesn't look good when you set a date and you don't make any post that date, usually two things, either it wasn't good news and he didn't want to tell us, or he abandoned that project.

Likely, though you would have to do a lot of the leg work yourself to get the cheapest rate (running your own bitcoin transaction server, setting up your card...).

More than likely there will be services out there that set things up for you and it will be close to the rate of a prepaid card.

I should stfu? maybe you should stfu, you have no idea. I have no problem doing little things if i see a bug, but I am not taking on a dead project. Which hasn't been committed to in over a month. Also while I agreed with the vision I don't agree with the code. It is kinda a mess, which the maintainer agreed with me.

DING DONG THE PROJECT IS DEAD! Now a real coder, and not me should take over and I have no problem committing where I see fit. I actually have a life and other projects to give my attention too and can't dedicate to play Dr. Frankenstein and bring this project back from the dead .

If successful will this be cheaper than buying a prepaid VISA with Bitcoins?

Great work Isis !

Look forward to perusing your code.

What hardware will a developer need to get started ?

If you could recommend a card supplier and card reader that you know is reliable and usable on all of Win/ Mac / Linux that would be very useful. I am thinking EMV.

I imagine until we get an IIN it will have to be a testnet but I would like to get familiar with the kit.

Great. For me, this is probably the next most important project than bitcoin itself. Terminal whingers aside, any code that can do what you are proposing would be huge step forward, the enemy of function is perfection ... or something like that.

Big kudos to you "isis" for trucking along with OpenPay against the adversities. Too bad management couldn't get their heads out of the old ways of thinking to fathom the potential.

I'm doing a little investigation to see if I can bring some resources to bear on OpenPay.

I don't work for free pay me and I will work on it.

Yes there will be support for Radiant Systems.

Nah I just had to wrap up some legal stuff and wait for an NDA to expire so I could start disclosing and discussing again.
All of that wrapped up yesterday.  Initial code drop of the new stuff is happening tonight. 
Sorry for the delay.

So for those of you who have been waiting for further updates here's what's going on...
OpenPay was commissioned by a company that has been a client of mine for a couple of years.  At first they were all for it, but when we started talking about setting up a new payment network and opening the source etc there was heavy opposition from upper management.  Mostly they were frightened that secret sauce recipes might accidentally be disclosed.

Eventually it was decided to just rescind the project and take it private.  This means I had to re-imburse the company for the time I billed them developing it.  Effectively I bought it out.  In the meantime certain sections of the code were determined to be touching on trade-secrets and those had to be re-implemented.

Finally what I ended up doing is doing a from scratch re-write of the initial re-write.
I apologize for being so tight lipped, it won't happen again.

Tonight you will see the merchant gateway module drop.  This will include a MtGox exchange connector, a balance check module, a module to connect the merchant to the OpenPay network and fallback signing module.
Tomorrow you will see an enrollment module and some pieces intended for service providers to connect an online wallet to OpenPay.

In the next couple of days you will start seeing modules for QuickBooks POS and other POS systems that will add OpenPay as a tender type.

Thanks again for your patience!
 

The dude hasn't ben active on the forums since August 1st so I doubt we will hear anything