Payment integration

[gfarrell]

Let's go with Braintree as discussed. Look into integrating this with our user management.

Perhaps payments should just be attached to offers, not users? (well, implicit link to users via User hasMany Offer).

[neil-s]

I'm thinking on each sell offer, the moment a potential buyer clicks 'Accept' and then makes a payment, we set the field paidForBy = buyerUsername. Any sell offers with that field set are not shown on the listings page. If the deal doesn't go through in the end, we can refund the 5 pounds to that username and unset the field, which will result in the listing being shown again.

[gfarrell]

I disagree for two reasons.

• when people discover that if they say a deal fell through, it refunds the money, they'll all just say the deal fell through because it doesn't hinder them in procuring a ticket (they are already in private communication with the seller). This is the point that @raph-s and I were making on Saturday.
• Ticket belongsTo Seller whereas payment is a Buyer specific process. I would say that structurally it makes more sense for "offers" to be a data-type whereby a buyer makes an offer on a listing, rendering the listing hidden until either it is successful or fails. We can record "success" or "failure" for our own metrics, but materially success -> listing permanently hidden, failure -> listing back online.

On Monday, 24 February 2014 at 16:36, Neil Satra wrote:

I'm thinking on each sell offer, the moment a potential buyer clicks 'Accept' and then makes a payment, we set the field paidForBy = buyerUsername. Any sell offers with that field set are not shown on the listings page. If the deal doesn't go through in the end, we can refund the 5 pounds to that username and unset the field, which will result in the listing being shown again.

— Reply to this email directly or view it on GitHub (https://github.com/neil-s/mayballmarketplace/issues/6#issuecomment-35905329).