Charges

[jcap49]

Overview

This feature handles the actual Coinbase API integration.

Tools

Coinbase API Docs Coinbase Ruby Gem

Acceptance Criteria

-charges are associated with product pages, sellers, and buyers -charges successfully completed via a given product page, seller is paid, appropriate amount deducted from buyer account

[jcap49]

@deoates can you walk me through what you envisioned for this user flow? When users check out, they can authorize access to their Coinbase account which is then used to transfer the appropriate BTC? If that's the case, I'm wondering if it also makes sense for users to sign in/create account w/ their Coinbase accounts instead of Twitter.

[zachferland]

I can help with this part, I have fooled around quite a bit with the coinbase api and bitpay api. @jcap49 so it would actually make sense for a seller to sign in with coinbase. A buyer does not have to login at all with coinbase or twitter, unless we have some reason. Checkout out this - https://coinbase.com/docs/merchant_tools/payment_iframes - allows coinbase and non coinbase users to easily make a payment right inline. I also noticed on the mockups there were two choices to pay with coinbase or a wallet, I see no reason why there should not just be a single purchase button because coinbase handles this quite nicely (I should probably bring this up in the UX section, but I just started checking this stuff out), Unless of course we have imagined a better way to implement this. It is possible that having those two buttons is a better user experience because you will ultimately have to click pay within coinbase if you want to make a purchase this way. Also it may have to be implemented this way if we want to offer a simple way to collect further information from a buyer(email, address, etc)

[jcap49]

perfect -- let's discuss tonight

On Tue, Mar 4, 2014 at 11:06 PM, zachferland notifications@github.comwrote:

I can help with this part, I have fooled around quite a bit with the coinbase api and bitpay api. @jcap49 https://github.com/jcap49 so it would actually make sense for a seller to sign in with coinbase. A buyer does not have to login at all with coinbase or twitter, unless we have some reason. Checkout out this - https://coinbase.com/docs/merchant_tools/payment_iframes - allows coinbase and non coinbase users to easily make a payment right inline. I also noticed on the mockups there were two choices to pay with coinbase or a wallet, I see no reason why there should not just be a single purchase button because coinbase handles this quite nicely (I should probably bring this up in the UX section, but I just started checking this stuff out), Unless of course we have imagined a better way to implement this. It is possible that having those two buttons is a better user ex perience because you will ultimately have to click pay within coinbase if you want to make a purchase this way. Also it may have to be implemented this way if we want to offer a simple way to collect further information from a buyer(email, address, etc)

Reply to this email directly or view it on GitHubhttps://github.com/jcap49/coinery/issues/4#issuecomment-36708360 .

John Capecelatro 315-749-8433 @jcap49 http://www.twitter.com/jcap49 www.johncapecelatro.com

[jcap49]

Coinbase API Integration

After looking through the payment iframe, it became apparent that this method wouldn't fit the constraints of this app. For one-off purchases (i.e. static site with a few items for sale) this makes sense, but as we'll be dynamically allowing users to create product pages, there's no way to autogenerate the iframe (or edit an existing iframe) to match the description for a given product. That said, below is an outline of how I'm thinking about actually implementing this all.

Login & App Authorization

There are two different ways to go about implementing the below login/authentication. The barebones way is to use OAuth2 as outlined in the docs. The more straightforward way (perhaps) is to use Omniauth (which we'll already have sorted for Twitter login). Either way, the below should give us a good starting point for getting login/auth/user creation working:

Option 1: OAuth2

App Authorization -- API Reference OAuth 2

Option 2: Omniauth

Coinbase Omniauth Omniauth

Transfers

Outside of user auth, the only other touch point we'll be having with this API is around transactions. There are two distinct scenarios for transfers to happen:

1. buyer purchases an item and btc is withdrawn from his account.
2. seller is paid for a purchase and btc is deposited into his account

Transactions -- API Reference

[zachferland]

The iframe is dynamically generated with the "code" value returned from requests in the Buttons API

Once you get a code parameter returned from the API, you can use it to construct a payment iFrame with its src attribute set to https://coinbase.com/inline_payments/CODE.

Also additional parameters can be passed/collected, such as email, address, and some custom inputs. (not in iframe but page though)

Have you started with the implementation you mentioned above yet?

The only way I could think that the proposed implementation above would be easier, is if you wanted to directly make a transaction from buyer to seller, it may also offer some flexibility that I am not aware of yet. (i have not looked through all parts of the api extensively yet)

[jcap49]

Ah gotcha. Looks like I didn't read closely enough :) Glad you're onboard to help!

Haven't started any of the implementation yet so we can easily move in the Buttons API direction. Just to clarify -- this method will allow us to direct payment from the seller to buyer? (i.e. not from buyer to our merchant acct)

On Wed, Mar 5, 2014 at 10:35 PM, zachferland notifications@github.comwrote:

The iframe is dynamically generated with the "code" value returned from requests in the Buttons APIhttps://coinbase.com/api/doc/1.0/buttons/create.html

Once you get a code parameter returned from the API, you can use it to construct a payment iFrame with its src attribute set to https://coinbase.com/inline_payments/CODE.

Also additional parameters can be passed/collected, such as email, address, and some custom inputs. (not in iframe but page though)

Have you started with the implementation you mentioned above yet?

The only way I could think that the proposed implementation above would be easier, is if you wanted to directly make a transaction from buyer to seller, it may also offer some flexibility that I am not aware of yet. (i have not looked through all parts of the api extensively yet)

Reply to this email directly or view it on GitHubhttps://github.com/jcap49/coinery/issues/4#issuecomment-36821925 .

John Capecelatro 315-749-8433 @jcap49 http://www.twitter.com/jcap49 www.johncapecelatro.com