This repository has been archived by the owner. It is now read-only.

migrate from samurai to stripe and/or braintree #58

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

Comments

Projects
None yet
1 participant
@chadwhitacre
Contributor

chadwhitacre 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.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 15, 2012

Contributor

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.

Contributor

chadwhitacre 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.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 15, 2012

Contributor

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.

Contributor

chadwhitacre 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.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 19, 2012

Contributor

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. :-/

Contributor

chadwhitacre 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. :-/

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 19, 2012

Contributor

On Stripe Platform, compare Dwolla (#65).

Contributor

chadwhitacre commented Jun 19, 2012

On Stripe Platform, compare Dwolla (#65).

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 19, 2012

Contributor

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.

Contributor

chadwhitacre 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.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 19, 2012

Contributor

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.

Contributor

chadwhitacre 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.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 19, 2012

Contributor

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.

Contributor

chadwhitacre 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.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 19, 2012

Contributor

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

Contributor

chadwhitacre commented Jun 19, 2012

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

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 19, 2012

Contributor

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

Standing by ...

Contributor

chadwhitacre commented Jun 19, 2012

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

Standing by ...

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 19, 2012

Contributor

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

Contributor

chadwhitacre commented Jun 19, 2012

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

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 19, 2012

Contributor

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?

Contributor

chadwhitacre 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?

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 19, 2012

Contributor

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

Contributor

chadwhitacre commented Jun 19, 2012

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

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 20, 2012

Contributor

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?

Contributor

chadwhitacre 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?

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 20, 2012

Contributor

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

/me shuts eyes tight

Contributor

chadwhitacre commented Jun 20, 2012

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

/me shuts eyes tight

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 20, 2012

Contributor

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

Contributor

chadwhitacre 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.

chadwhitacre added a commit that referenced this issue Jun 20, 2012

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).
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 20, 2012

Contributor

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.

Contributor

chadwhitacre 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.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 20, 2012

Contributor

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.

Contributor

chadwhitacre 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.

chadwhitacre added a commit that referenced this issue Jun 20, 2012

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
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 20, 2012

Contributor

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

Contributor

chadwhitacre commented Jun 20, 2012

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

chadwhitacre added a commit that referenced this issue Jun 20, 2012

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
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 21, 2012

Contributor

Remaining:

Go! Go! Go!

Contributor

chadwhitacre commented Jun 21, 2012

Remaining:

Go! Go! Go!

chadwhitacre added a commit that referenced this issue Jun 21, 2012

s/samurai/stripe/g
Here's a big commit replacing Samurai with Stripe. This is the bulk of
the work for #58. Phew!

chadwhitacre added a commit that referenced this issue Jun 21, 2012

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
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 21, 2012

Contributor

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

Contributor

chadwhitacre commented Jun 21, 2012

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

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre
Contributor

chadwhitacre commented Jun 21, 2012

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 21, 2012

Contributor

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.

Contributor

chadwhitacre 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.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 21, 2012

Contributor

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.

Contributor

chadwhitacre 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.

chadwhitacre added a commit that referenced this issue Jun 21, 2012

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
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jun 21, 2012

Contributor

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.

Contributor

chadwhitacre 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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.