migrate from samurai to stripe and/or braintree #58

Closed
whit537 opened this Issue Jun 15, 2012 · 25 comments

Projects

None yet

1 participant

@whit537
Member
whit537 commented Jun 15, 2012

Our credit card processing vendor is dead in the water (see also #47 and now this blog post) after being acquired by GroupOn in March. Sigh. Time to migrate! Can we migrate cards from Samurai's vault to Stripe's and/or Braintree's? If we can't we'll have to beg people to re-enter their card info. Derp.

@whit537
Member
whit537 commented Jun 15, 2012

Talked to both. Stripe has a new Platform product in beta that is quite interesting but won't work for us because of the small per-transaction amount. It basically would decentralize us, which would be awesome. Everyone would have to sign up for a Stripe account as part of Gittip sign-up, but then money would go straight from tippers into each tippees bank account. I actually really, really want that.

Anyway, I activated the Stripe account I signed up for a couple months ago and made a live payment. Will look into their API. 2.9% + $0.30 per transaction, no monthly charge. Really does look well-executed.

Also talked to Braintree. We can bring our existing merchant account, and would pay $0.10 per transaction on top of that + $49 per month (waived for first three). Braintree has done away with vaulting charges although their website doesn't reflect this. It would take a call to First Data to have them transfer from FD Nashville to FD Cardnet, and then communicating a VAR sheet from FD to Braintree. Our price with Samurai was supposedly $0.30 + 2.3% (though see #47). If we can really keep that or maybe even have a lower price after moving to Braintree then even with a $0.10 transaction fee we may come out ahead. It depends on the average transaction amount whether the 0.6% of volume compares to the flat per-transaction component, and of course on what the flat part would be for FD+Braintree. The $49 monthly would be overwhelmed quickly.

Ideally though we would use both for redundancy.

@whit537
Member
whit537 commented Jun 15, 2012

Also, Rob at Braintree did confirm that Samurai's support staff were let go during the acquisition. They kept one dev and Sean. Milking it. For shame.

@whit537
Member
whit537 commented Jun 19, 2012

The biggest problem here is the 25 credit cards we already have. I don't see an option besides asking everyone to re-enter their credit card details. :-(

So first we get accounts set up on Stripe and Braintree, and then upgrade the site to use both Stripe and Braintree. Once that's deployed we beg everyone to re-enter their credit card details. Need to write a blog post explaining the whole thing in detail and why re-entering cc details is the only safe thing to do. Need to kill payment method tokens in Samurai so people know we made our best effort not to leave their cc details with a dying company. Probably apologize for picking the wrong vendor. :-/

@whit537
Member
whit537 commented Jun 19, 2012

On Stripe Platform, compare Dwolla (#65).

@whit537
Member
whit537 commented Jun 19, 2012

It looks like with Stripe we can't authorize and settle separately. Currently we perform an authorize when the participant first enters their cc details in order to catch problems with the card while we have their attention. Braintree does have separate authorize and settle steps. With stripe we could simply charge the user $1.00 or something when they first add the card. This would go into their balance and we would use that on Friday. Since we don't want the user to have to think about what payment processor they're using, we would have to do this initial charge regardless of processor.

Update: Looks like Stripe customer objects do what we want. Phew.

@whit537
Member
whit537 commented Jun 19, 2012

When the user enters their credit card details we want to vault them at both Stripe and Braintree. How are we going to decide which one to use for the charge?

It would be safest from a systems redundancy point of view to use both with equal distribution. We want to depend equally on both in the normal case and automatically fail over on connection errors.

I mean, for that matter, should we even bother ditching Samurai? Sure leaves a bad taste in my mouth, I'll say that. Yeah, we're not using Samurai. It's dead. Samurai didn't fail with a connection error, it failed with a bug that we wouldn't to program for.

@whit537
Member
whit537 commented Jun 19, 2012

We want one fee to cover pulling money in via credit card. We know Stripe's pricing is 2.9% + $0.30. Our fee is currently $0.30 + 3.9%. If the per-transaction cost is going to be an issue maybe we should raise our fee to $0.39 + 3.9% to give ourselves some wiggle room. We don't want to have to change our fee every time we have to make a change in our payment providers. We don't know yet exactly what the cost is going to be with Braintree, because we don't know what our rates are with FirstData and how that's going to survive the move to Braintree.

@whit537
Member
whit537 commented Jun 19, 2012

Call and email in to FirstData to transfer the merchant account to Braintree.

@whit537
Member
whit537 commented Jun 19, 2012

Hrm, Braintree coming back with pretty complex pricing. Actually, wait ... that was the wrong price sheet. :-)

Standing by ...

@whit537
Member
whit537 commented Jun 19, 2012

Okay, that's better. $49/mo + $0.10, as quoted verbally. Need to hear back from FirstData.

@whit537
Member
whit537 commented Jun 19, 2012

Now I'm thinking we might as well attempt billing via Samurai for anyone who doesn't resubmit credit card details by Friday. Why not?

@whit537
Member
whit537 commented Jun 19, 2012

BTW, authorizations/validations are $0.10 each for Braintree. So that's on authorizations as well as full purchases.

@whit537
Member
whit537 commented Jun 20, 2012

Gah. I am so gun-shy now! I really want to give our user's credit card data to a third party? That's, like, lifeblood. Can PCI compliance be that bad?

@whit537
Member
whit537 commented Jun 20, 2012

PCI compliance is that bad. PCI compliance is that bad. PCI compliance is that bad.

/me shuts eyes tight

@whit537
Member
whit537 commented Jun 20, 2012

It really makes the codebase a fair bit more complex to support N credit card processors. I'm considering just using Stripe.

@whit537 whit537 added a commit that referenced this issue Jun 20, 2012
@whit537 whit537 Turn off credit card page for now
I've redacted all credit cards we had stored with Samurai. This commit
turns off the credit card page so that we don't collect more credit
cards until we can funnel those to a new vendor (#58).
0aa09e9
@whit537
Member
whit537 commented Jun 20, 2012

I've reached out to Sean Harper and Sheel Mohnot on Twitter. I've also emailed Sheel (his hn profile lists an address).

But at this point it's too late to migrate data: I've redacted all payment_method_tokens with Samurai. We have 0 working credit cards on file at the moment. I guess I'm looking for their side of the story for when I write the blog post about this.

@whit537
Member
whit537 commented Jun 20, 2012

P.S. I did snapshot the list of participants who had entered a credit card, so that I can contact them privately and ask them if they would re-enter their info.

@whit537 whit537 added a commit that referenced this issue Jun 20, 2012
@whit537 whit537 Drop payment_method_token column from user object
I'm removing payment_method_token from the user object so I can rename
rename this column in the database to stripe_customer_id. #58
67ffa5b
@whit537
Member
whit537 commented Jun 20, 2012

I renamed the payment_method_token column to stripe_customer_id in the production database.

@whit537 whit537 added a commit that referenced this issue Jun 20, 2012
@whit537 whit537 Add stripe_customer_id to user object
Now that this is renamed in the production db let's bring it back in the
user object. Perhaps a bit over-careful for this stage in the game (we
could have just done this in one release and then altered the table
quickly; no-one would have noticed), but there you have it. #58
d08793c
@whit537
Member
whit537 commented Jun 21, 2012

Remaining:

Go! Go! Go!

@whit537 whit537 added a commit that referenced this issue Jun 21, 2012
@whit537 whit537 s/samurai/stripe/g
Here's a big commit replacing Samurai with Stripe. This is the bulk of
the work for #58. Phew!
dd71544
@whit537 whit537 added a commit that referenced this issue Jun 21, 2012
@whit537 whit537 Show login instead of 404 on credit-card for anon
I'd like to link directly to the /credit-card.html page when publicizing
that we're back w/ credit card acceptance, but I don't want folks who
are unauthenticated to get a gnarly 404. #58
828f8a5
@whit537
Member
whit537 commented Jun 21, 2012

Damn, alright. That's done. Rolling out Stripe, that is. Now the fun part! :D

@whit537
Member
whit537 commented Jun 21, 2012

I don't see that I can privately message people on GitHub. I don't want to publically announce who the people are who set up a credit card. I may try reaching out to people privately through Twitter or email as I'm able to resolve their identities based on their GitHub logins. I don't believe our oauth permission from people allows us to message them that way.

@whit537
Member
whit537 commented Jun 21, 2012

I (1) contacted 10 people privately on Twitter, 2 on IRC and 1 on email = 14 out of 29. Hopefully that's enough to get us back up to eight or ten, and then I'll float the blog post on HN and let it go from there.

@whit537 whit537 added a commit that referenced this issue Jun 21, 2012
@whit537 whit537 Fix regression in payment prompt
I didn't update the payment_method_token to stripe_customer_id in the
template where we prompt the user to back their tip with a credit card
if they haven't done so yet. #58
51d3bed
@whit537
Member
whit537 commented Jun 21, 2012

Closing this out. The blog post charted at #5 on HN (that I saw). Had a call with Sean. Hoping they can figure out their customer support.

@whit537 whit537 closed this Jun 21, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment