migrate from samurai to stripe and/or braintree #58
Comments
|
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. |
|
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. |
|
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. :-/ |
|
On Stripe Platform, compare Dwolla (#65). |
|
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. |
|
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. |
|
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. |
|
Call and email in to FirstData to transfer the merchant account to Braintree. |
|
Hrm, Braintree coming back with pretty complex pricing. Actually, wait ... that was the wrong price sheet. :-) Standing by ... |
|
Okay, that's better. $49/mo + $0.10, as quoted verbally. Need to hear back from FirstData. |
|
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? |
|
BTW, authorizations/validations are $0.10 each for Braintree. So that's on authorizations as well as full purchases. |
|
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? |
|
PCI compliance is that bad. PCI compliance is that bad. PCI compliance is that bad. /me shuts eyes tight |
|
It really makes the codebase a fair bit more complex to support N credit card processors. I'm considering just using Stripe. |
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).
|
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. |
|
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. |
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
|
I renamed the payment_method_token column to stripe_customer_id in the production database. |
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
|
Remaining:
Go! Go! Go! |
Here's a big commit replacing Samurai with Stripe. This is the bulk of the work for #58. Phew!
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
|
Damn, alright. That's done. Rolling out Stripe, that is. Now the fun part! :D |
|
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. |
|
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. |
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
|
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. |
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.
The text was updated successfully, but these errors were encountered: