Stripe adds multiple account support(stripe.com)
stripe.com
Stripe adds multiple account support
https://stripe.com/blog/manage-multiple-accounts
20 comments
While I really appreciate this feature, I'd love it even more if I could get multi-account reporting (from Stripe or anybody using the API). I have 3 Stripe accounts and don't have a problem with password management, due to having LastPass, but answering simple questions like "How much money should I expect to receive in transfers in the next week?" requires me to do three context switches and then math. (Also, mentioned this to support years ago, but even on a single account there's no "sum of scheduled transfers" on the transfer page, which has always struck me like a number likely to be of interest to many people.)
This is a priority for me which is annoying enough to mention and to have bought various Stripe reporting apps speculatively, hoping one would implement it, but below the cusp of "Screw it, I'll figure out how to use the reporting API then do summary stats on a cron job and dump them onto one of my dashboards."
This is a priority for me which is annoying enough to mention and to have bought various Stripe reporting apps speculatively, hoping one would implement it, but below the cusp of "Screw it, I'll figure out how to use the reporting API then do summary stats on a cron job and dump them onto one of my dashboards."
I recently released my first self-published browser game (http://scarletsword.com) and used Stripe for the microtransactions. It's wonderful, and easy, and updates like this one make me excited for its future development. You know, as if it's not good enough already.
Wait. Stripe has micro transaction support? I can't find it on their pricing page where is it? How does it compare to Paypal's micropayments pricing (5% + 5¢ instead of the standard 2.9% + 30¢).
This is great, I have been considering switching to Stripe and this has almost sealed the deal.
One question if a Stripe employee happens to come in here: The horror stories I have read make me nervous about switching. I have read about massive delays in getting paid with only vague explanations, and in more than one case Stripe actually reversing all charges made by a merchant after allowing a new account to exist for several days. Merchants performed services/shipped products based upon Stripe charges, then Stripe reversed the charges with essentially no explanation. These reversals were supposedly not at the request of cardholders.
What percentage of accounts suffer these types of issues?
One question if a Stripe employee happens to come in here: The horror stories I have read make me nervous about switching. I have read about massive delays in getting paid with only vague explanations, and in more than one case Stripe actually reversing all charges made by a merchant after allowing a new account to exist for several days. Merchants performed services/shipped products based upon Stripe charges, then Stripe reversed the charges with essentially no explanation. These reversals were supposedly not at the request of cardholders.
What percentage of accounts suffer these types of issues?
I'd love to hear from anyone who feels poorly treated or has encountered problems like this: I'm [email protected]. (I'm one of Stripe's founders.)
The way we look at it is: legitimate businesses are always fine and -- furthermore -- we know that our reputation rests on not screwing anyone over. We can afford to lose money on an account; we cannot afford to damage our reputation. Our internal philosophy document states: "In evaluating businesses, we should first be careful never to do harm." Luckily, we've had almost no issues to date.
One unfortunate case that we do often run in to, however, is that a fraudulent user will start loudly posting purported horror stories on various forums in an effort to get us to release money. It's a decent strategy: these stories are bad for Stripe. It's obviously very hard for someone else to distinguish this case from a "real" case of Stripe acting malevolently. But, no matter what happened, we obviously can't rebut them and post sensitive details about their account. So their stories stand.
Even if we were omniscient and had neither any false positives nor any false negatives, these stories would exist. It just comes with scale. And, in reality, we're of course far from omniscient. We just try to turn the dial all the way towards false negatives -- we never want to hurt a legitimate business.
It's a tough dynamic. It exists to some extent with many online services (most of whom have terms of services that prohibit certain businesses); Stripe is more acutely subject to it since you can fairly readily use Stripe for financial gain. I'd love to hear from anyone who thinks we should handle it differently or better.
(Downandout, to address your question directly, we'd be happy to chat with you (and anyone else) directly before you make the switch to reassure you that your business doesn't contravene our ToS. Feel free to drop me a line.)
Lastly, I mean it about actively wanting to hear from anyone who thinks we've handled a situation badly -- if there are any mistakes, we need to take action. [email protected] -- I'd be happy to chat by email, phone, or IM.
The way we look at it is: legitimate businesses are always fine and -- furthermore -- we know that our reputation rests on not screwing anyone over. We can afford to lose money on an account; we cannot afford to damage our reputation. Our internal philosophy document states: "In evaluating businesses, we should first be careful never to do harm." Luckily, we've had almost no issues to date.
One unfortunate case that we do often run in to, however, is that a fraudulent user will start loudly posting purported horror stories on various forums in an effort to get us to release money. It's a decent strategy: these stories are bad for Stripe. It's obviously very hard for someone else to distinguish this case from a "real" case of Stripe acting malevolently. But, no matter what happened, we obviously can't rebut them and post sensitive details about their account. So their stories stand.
Even if we were omniscient and had neither any false positives nor any false negatives, these stories would exist. It just comes with scale. And, in reality, we're of course far from omniscient. We just try to turn the dial all the way towards false negatives -- we never want to hurt a legitimate business.
It's a tough dynamic. It exists to some extent with many online services (most of whom have terms of services that prohibit certain businesses); Stripe is more acutely subject to it since you can fairly readily use Stripe for financial gain. I'd love to hear from anyone who thinks we should handle it differently or better.
(Downandout, to address your question directly, we'd be happy to chat with you (and anyone else) directly before you make the switch to reassure you that your business doesn't contravene our ToS. Feel free to drop me a line.)
Lastly, I mean it about actively wanting to hear from anyone who thinks we've handled a situation badly -- if there are any mistakes, we need to take action. [email protected] -- I'd be happy to chat by email, phone, or IM.
Thanks Patrick, I didn't mean to imply that you don't have legitimate reasons to freeze accounts when you do. I was just wondering what the odds of having problems were for a legitimate business that at times has significant spikes in volume. In light of your response, I for one actually think I will take the leap and switch.
They've been really good to me, and to some friends of my mind, who have the problem described by "legitimate business which at times has significant spikes in volume." The first time I knew it was going to happen I gave them a heads up in advance, and got back something to the effect of "Oh, don't worry, we know you're on the level Patrick." I've subsequently had e.g. one-day spikes in the $X0k range (where the account's steady state would be $1k a month) and never had a problem.
I never had an issue with Paypal that calling them didn't resolve, but that sort of spikiness made me worried about their future actions, and relatedly that of my actual banks.
As long as I'm here, I'll recount an anecdote from Bank of America, which I wanted to apprise "You're going to see a bunch of wire transfer coincidentally happening at the same time in the next few days, which will be FAR above the norms for this account, and I'd like you to know what is happening so you don't go doing anything rash like filing a Suspicious Activity Report."
Two things I learned during this process:
1) Knowing what a Suspicious Activity Report is and why one would want to avoid having them filed is is considered by some employees to be suspicious.
2) After getting the run around from telephone support, I decided to do a branch visit, at the Bank of America branch on Wall Street (since I was in Manhattan to visit Fog Creek at the time). The banker I was talking to listened attentively and then asked for clarification: exactly how much money was I talking? I gave him an estimate, whereupon he replied "Sir, this is Wall Street. We have entirely different standards for what constitutes 'a large amount of money.'"
I never had an issue with Paypal that calling them didn't resolve, but that sort of spikiness made me worried about their future actions, and relatedly that of my actual banks.
As long as I'm here, I'll recount an anecdote from Bank of America, which I wanted to apprise "You're going to see a bunch of wire transfer coincidentally happening at the same time in the next few days, which will be FAR above the norms for this account, and I'd like you to know what is happening so you don't go doing anything rash like filing a Suspicious Activity Report."
Two things I learned during this process:
1) Knowing what a Suspicious Activity Report is and why one would want to avoid having them filed is is considered by some employees to be suspicious.
2) After getting the run around from telephone support, I decided to do a branch visit, at the Bank of America branch on Wall Street (since I was in Manhattan to visit Fog Creek at the time). The banker I was talking to listened attentively and then asked for clarification: exactly how much money was I talking? I gave him an estimate, whereupon he replied "Sir, this is Wall Street. We have entirely different standards for what constitutes 'a large amount of money.'"
I'd recommend Stripe unequivocally. I've been using it in the UK since it was in beta with no issues at all. The whole experience has been joyous, which is very unusual in the payments arena IME.
Another mostly-happy UK Stripe user here. We launched around the time they came out of beta and only have a few transactions going through so far, but we’ve had no major problems.
In the interests of balance, I should say that Stripe does still have some pain points for us. Two are serious enough that we’d probably jump to any competitor that handled them better.
But the fact is that right now, I don’t know of any competitors available to us in the UK that do those things better. Moreover, we anticipated much worse pain points with various other card payment systems we considered.
Stripe certainly isn’t a perfect solution, but there is a lot to like about it, and it remains our favourite choice for card payments by some considerable margin.
In the interests of balance, I should say that Stripe does still have some pain points for us. Two are serious enough that we’d probably jump to any competitor that handled them better.
But the fact is that right now, I don’t know of any competitors available to us in the UK that do those things better. Moreover, we anticipated much worse pain points with various other card payment systems we considered.
Stripe certainly isn’t a perfect solution, but there is a lot to like about it, and it remains our favourite choice for card payments by some considerable margin.
Chris - I too would love to hear your payments wishlist. [email protected] if you'd like to share.
Please see my reply to Patrick’s sibling comment: https://news.ycombinator.com/item?id=7030013
I'd of course love to hear the complaints :-). [email protected].
I probably should have been more specific rather than expressing vague concerns in a public forum like that. Apologies.
Basically, for any payment service I’m looking for three things:
1. Can I integrate with it and collect money in the ways I want to?
2. Can I maintain proper records of those transactions for tax/audit/compliance purposes?
3. Can I test all of this thoroughly?
The new generation of payment services is great at fixing #1. Stripe and the like have made integration a much more pleasant and efficient experience.
Almost every payment service we’ve considered sucks at #2 to some degree. I do understand the desire to keep things simple and market with nonsense about five-minute integrations, but in the real world we still have to produce proper accounts and file things like VAT (sales tax) returns, so we do need the data to do those things available as easily as possible.
An almost universal failing in payment APIs we’ve looked at is having a data/API model built around mutable entities. I don’t want the details for a charge I already knew about to change if something like a refund or chargeback happens. I want a separate transaction recorded for that, with its own unique ID and date and records of things like fees and taxes, and of course a cross-reference to the original. This is easy to audit, and it’s easy to detect things like duplicate notifications while integrating.
An example more specific to Stripe is not applying a unique ID to the transfers it makes to our bank account, which of course occur close together and for similar amounts of money since we’re using it for B2C subscription charges. Unfortunately, different VAT criteria might apply to the underlying charges to our customers, depending on whether they’re in Europe or not. This leads to crazy things like manually reconciling records using spreadsheets, dashboards and the Mk I human eyeball, instead of writing a script that takes our downloaded bank statement and our Stripe API key and just works everything out quickly and accurately. It has also resulted in more in accountancy fees to prepare a tax return than the total amount of tax on the return! (If we must have this, please consider allowing us to have a single transfer weekly or monthly. In our case, a few days of drifting cash flow is no big deal, and the effort it would save every time we have to file a tax return would be well worth it.)
Also, slightly related, VAT invoices. Please, for the love of all that is holy, sort this out. It’s the law, a tiny amount of money is actually involved, but not keeping proper business records is not acceptable. We aren’t likely to get in a lot of trouble over 20p of misplaced tax. We are likely to get in trouble if we are picked for a Business Records Check and can’t show we’re following good practices, and right now that again means we waste crazy amounts of time fussing over literally pence on each transaction to make sure everything is squared away if anyone asks. Again, this stuff should just work, and our total effort required for compliance should be on the order of ten seconds to download a one-page PDF from the web site every month.
For #3, Stripe’s test facilities are a worthy effort. There’s a separate version of the system that can be used to check integrations without making real charges, and you can simulate a reasonable amount of real world behaviour with it. That is already better than a lot of payment services offer.
What you can’t do, unfortunately, is build an automated integration test suite that will fire off all the API calls we will ever want to make and receive all the incoming webhooks we might ever see in rapid succession. Some plausible things can’t be simulated as far as I know (e.g., what happens when someone’s card works for some subscription payments but then expires, or if someone raises a chargeback). Also, webhook notifications sometimes take a considerable time to arrive after whatever would have triggered them, which isn’t very test-friendly.
Despite our efforts to test our integration thoroughly, the lack of ability to run an automated suite quickly after we’ve made a change means again we’re talking about spending a lot of time manually testing all the key integration points every time we touch that part of our code.
I hope this is of interest to those in this discussion who work on payment services. Also, this has been a long post and obviously its purpose is mostly criticism, so I want to finish by reiterating that our experience with Stripe has been very positive overall. Even where I’m picking on them above, I don’t know of anyone else who’s actually doing things any better in most cases, and many other payment services seem to suffer from the same problems today.
Edit: And just to be clear, the two potentially loyalty-defeating issues I alluded to before are:
1. being able to automate the preparation of our accounts/tax records, matching up all transactions with our customers with the deposits that ultimately hit our bank account, and
2. being able to run a comprehensive, automated integration test suite.
Basically, for any payment service I’m looking for three things:
1. Can I integrate with it and collect money in the ways I want to?
2. Can I maintain proper records of those transactions for tax/audit/compliance purposes?
3. Can I test all of this thoroughly?
The new generation of payment services is great at fixing #1. Stripe and the like have made integration a much more pleasant and efficient experience.
Almost every payment service we’ve considered sucks at #2 to some degree. I do understand the desire to keep things simple and market with nonsense about five-minute integrations, but in the real world we still have to produce proper accounts and file things like VAT (sales tax) returns, so we do need the data to do those things available as easily as possible.
An almost universal failing in payment APIs we’ve looked at is having a data/API model built around mutable entities. I don’t want the details for a charge I already knew about to change if something like a refund or chargeback happens. I want a separate transaction recorded for that, with its own unique ID and date and records of things like fees and taxes, and of course a cross-reference to the original. This is easy to audit, and it’s easy to detect things like duplicate notifications while integrating.
An example more specific to Stripe is not applying a unique ID to the transfers it makes to our bank account, which of course occur close together and for similar amounts of money since we’re using it for B2C subscription charges. Unfortunately, different VAT criteria might apply to the underlying charges to our customers, depending on whether they’re in Europe or not. This leads to crazy things like manually reconciling records using spreadsheets, dashboards and the Mk I human eyeball, instead of writing a script that takes our downloaded bank statement and our Stripe API key and just works everything out quickly and accurately. It has also resulted in more in accountancy fees to prepare a tax return than the total amount of tax on the return! (If we must have this, please consider allowing us to have a single transfer weekly or monthly. In our case, a few days of drifting cash flow is no big deal, and the effort it would save every time we have to file a tax return would be well worth it.)
Also, slightly related, VAT invoices. Please, for the love of all that is holy, sort this out. It’s the law, a tiny amount of money is actually involved, but not keeping proper business records is not acceptable. We aren’t likely to get in a lot of trouble over 20p of misplaced tax. We are likely to get in trouble if we are picked for a Business Records Check and can’t show we’re following good practices, and right now that again means we waste crazy amounts of time fussing over literally pence on each transaction to make sure everything is squared away if anyone asks. Again, this stuff should just work, and our total effort required for compliance should be on the order of ten seconds to download a one-page PDF from the web site every month.
For #3, Stripe’s test facilities are a worthy effort. There’s a separate version of the system that can be used to check integrations without making real charges, and you can simulate a reasonable amount of real world behaviour with it. That is already better than a lot of payment services offer.
What you can’t do, unfortunately, is build an automated integration test suite that will fire off all the API calls we will ever want to make and receive all the incoming webhooks we might ever see in rapid succession. Some plausible things can’t be simulated as far as I know (e.g., what happens when someone’s card works for some subscription payments but then expires, or if someone raises a chargeback). Also, webhook notifications sometimes take a considerable time to arrive after whatever would have triggered them, which isn’t very test-friendly.
Despite our efforts to test our integration thoroughly, the lack of ability to run an automated suite quickly after we’ve made a change means again we’re talking about spending a lot of time manually testing all the key integration points every time we touch that part of our code.
I hope this is of interest to those in this discussion who work on payment services. Also, this has been a long post and obviously its purpose is mostly criticism, so I want to finish by reiterating that our experience with Stripe has been very positive overall. Even where I’m picking on them above, I don’t know of anyone else who’s actually doing things any better in most cases, and many other payment services seem to suffer from the same problems today.
Edit: And just to be clear, the two potentially loyalty-defeating issues I alluded to before are:
1. being able to automate the preparation of our accounts/tax records, matching up all transactions with our customers with the deposits that ultimately hit our bank account, and
2. being able to run a comprehensive, automated integration test suite.
I would love for you to try our API/webhook automated testing product and let me know how it does or doesn't work for you: https://www.runscope.com
I have no affiliation with Stripe aside from developing on their API. One of the explanations I've heard in regards to this is a scenario something like the following:
1. Merchant sets up Stripe account.
2. Merchant begins processing credit cards.
3. Stripe's vetting process kicks in and takes a look at Merchant, finding that Merchant is operating a business type that is prohibited by Stripe's TOS.
4. Stripe cancels all transactions and locks the account.
From what I can tell Stripe allows you to start charging immediately and only some time later does the vetting process kick in where a human takes a look at the merchant. When the merchant is operating a business that is prohibited[0], this happens.
[0]: https://stripe.com/prohibited_businesses
1. Merchant sets up Stripe account.
2. Merchant begins processing credit cards.
3. Stripe's vetting process kicks in and takes a look at Merchant, finding that Merchant is operating a business type that is prohibited by Stripe's TOS.
4. Stripe cancels all transactions and locks the account.
From what I can tell Stripe allows you to start charging immediately and only some time later does the vetting process kick in where a human takes a look at the merchant. When the merchant is operating a business that is prohibited[0], this happens.
[0]: https://stripe.com/prohibited_businesses
Thanks for bringing this up. A couple of clarifications (I work on risk at Stripe):
1. This failure mode existed up until a few months ago, but has since been fixed. In order to avoid anyone wasting time, we have systems that alert us to potential ToS violations as soon as someone sets up their account. We review these alerts right away, and reach out to users well before they've started accepting payments.
2. We never cancel or refund transactions that have even a remote chance of being legitimate. For cases where we have to stop accepting payments for a website because of ToS issues, we're always happy to give users as much time as they need to transition off of Stripe if they've already started accepting payments through us.
If you're aware of recent cases where we haven't done this, I'd really appreciate knowing about them. You can reach me at [email protected].
1. This failure mode existed up until a few months ago, but has since been fixed. In order to avoid anyone wasting time, we have systems that alert us to potential ToS violations as soon as someone sets up their account. We review these alerts right away, and reach out to users well before they've started accepting payments.
2. We never cancel or refund transactions that have even a remote chance of being legitimate. For cases where we have to stop accepting payments for a website because of ToS issues, we're always happy to give users as much time as they need to transition off of Stripe if they've already started accepting payments through us.
If you're aware of recent cases where we haven't done this, I'd really appreciate knowing about them. You can reach me at [email protected].
Good to know. Thanks for an official answer.
I can see that happening. My business is allowed (custom app development) but I'm not sure I want to take the gamble on possibly not getting paid for a week of work. One of the scenarios I read stated that Stripe said the reversals were because their automated system believed that the person behind the account was the same as one that had already been canceled, but that the detection system wasn't 100% accurate and they were awful sorry if the decision had been made in error. It offered no appeals process. That story made me particularly nervous since ISP's recycle IPs etc.
I've been using Stripe for just over a year now to take payments for a 6-figure-a-year business. We've had no reversals whatsoever. The only time Stripe has removed payments have been in the case of the occasional chargeback, which we typically win; payments seem to get docked the moment you file your response to the dispute, and get credited back the moment you're notified the dispute has been won.
I was a little nervous when first setting up with Stripe too, so we enabled it for a few hours and let a few sales go through, then switched back to our old merchant account and payment gateway while we waited to make absolutely sure the sales went through with Stripe. 7 days later, the payments hit our bank account, and we switched everything over to them - been happy ever since. They have a great dashboard, and everything's far easier to deal with and manage than it was with our old merchant account. Only downside is the pay delay - merchant account deposited most funds in our accounts within 2 days; Stripe takes 7. But if you're doing pretty consistent numbers, this isn't too much of a burden to cash flow, since you've got the funds from a week ago coming in every day.
I was a little nervous when first setting up with Stripe too, so we enabled it for a few hours and let a few sales go through, then switched back to our old merchant account and payment gateway while we waited to make absolutely sure the sales went through with Stripe. 7 days later, the payments hit our bank account, and we switched everything over to them - been happy ever since. They have a great dashboard, and everything's far easier to deal with and manage than it was with our old merchant account. Only downside is the pay delay - merchant account deposited most funds in our accounts within 2 days; Stripe takes 7. But if you're doing pretty consistent numbers, this isn't too much of a burden to cash flow, since you've got the funds from a week ago coming in every day.
I've run 30-40K through Stripe over the last several months for a couple consulting clients with no issues whatsoever.
Stripe does what it says on the tin.
These guys are a dream to deal with versus my old set up (Authorize.net and First Data). Those guys are thieves who nickel and dime you to death with cryptically-named mystery fees.
I'm in the US FWIW.....
Stripe does what it says on the tin.
These guys are a dream to deal with versus my old set up (Authorize.net and First Data). Those guys are thieves who nickel and dime you to death with cryptically-named mystery fees.
I'm in the US FWIW.....
I'm not familiar with the details here (feel free to email me -- [email protected]), but I can say with confidence that you should never have to worry about not being paid for a week of work with Stripe. If there was a bug like this, we'd do everything possible to make things right, including (of course) transferring funds to your account to cover any reversals that were made in error.
I'm wondering which of these came from the card networks and, most importantly, what's the actual rationale for including them?
* Virtual currency that can be monetized, re-sold or converted to physical or
* digital products or services or otherwise exit the virtual world
* Sexually-oriented or pornographic products or services
* Airlines
* Cruise lines
* Flea markets
* Drug paraphernalia
* Psychic services
* Prepaid phone cards, phone services or cell phones
* Telecommunications equipment and telephone sales
* Personal computer technical support
* Virtual currency that can be monetized, re-sold or converted to physical or
* digital products or services or otherwise exit the virtual world
* Sexually-oriented or pornographic products or services
* Airlines
* Cruise lines
* Flea markets
* Drug paraphernalia
* Psychic services
* Prepaid phone cards, phone services or cell phones
* Telecommunications equipment and telephone sales
* Personal computer technical support
As it happens, I posted a comment that tries to explain some of this a few months ago: https://news.ycombinator.com/item?id=6188987.
4. Sexually-oriented or pornographic products or services
Would you constitute software development for the adult industry as one of those? I'm a freelance software developer.. Most of my clients are in the adult realm. I build sites for them, and software they buy from me. I'd love to use Stripe for processing their invoices (currently use PayPal) but that worries me that I'm gonna get canned because I wrote a CMS that is used on a porn site.
Would you constitute software development for the adult industry as one of those? I'm a freelance software developer.. Most of my clients are in the adult realm. I build sites for them, and software they buy from me. I'd love to use Stripe for processing their invoices (currently use PayPal) but that worries me that I'm gonna get canned because I wrote a CMS that is used on a porn site.
I'm not from Stripe, but I think I can answer: you're fine. Porn businesses are avoided mainly due to high fraud rates (including friendly fraud, when the cardholder buys the website services and later falsely claims their card number was stolen). It's not out of morality. After all, many brick-and-mortar shops have no problem accepting card payments for porn magazines. Your business isn't porn, and you're unlikely to get chargebacks, so you're good.
Judging from previous companies I've talked to, it doesn't matter. Porn is porn. They want no association with it period. Even if it's just code.
Can you explain the telecommunications equipment one? We're an electronic design company setting up Stripe (Australian Beta), and while we don't have any products in this category currently, we've been thinking of doing some networking/telecoms products...
It'd be good to hear more specifically what's not allowed.
It'd be good to hear more specifically what's not allowed.
You should probably reach out to them directly.
Wow I hadn't heard any of this. If its at all true, it would make me reconsider ever using Stripe again
Hipchat needs to do this.
There are about five hundred services that need to do this, to be honest. The separation between a user and an account is one that's largely not valued when people are originally modeling applications, but it probably should be. (Speaking for myself as well here.)
The way I work around this is launching a separate chrome for each account.
For example, I have a work-trello and a personal-trello command in ~/bin, but you can use shortcuts in Windows or whatever the equivalent is in OS X.
chromium-browser --app=https://trello.com --user-data-dir=/home/jewel/.profiles/personal-trello
They can run concurrently and are completely isolated. I don't think this is possible with firefox yet. I use app mode since I don't need the normal navigation when using it this way.
For example, I have a work-trello and a personal-trello command in ~/bin, but you can use shortcuts in Windows or whatever the equivalent is in OS X.
chromium-browser --app=https://trello.com --user-data-dir=/home/jewel/.profiles/personal-trello
They can run concurrently and are completely isolated. I don't think this is possible with firefox yet. I use app mode since I don't need the normal navigation when using it this way.
Firefox has done this for a very long time: its called profiles and you can read up on it at https://support.mozilla.org/en-US/kb/profiles-where-firefox-.... You can simply run
firefox.exe -p
and pull up the profile manager (you have to make sure all instances of Firefox are closed first) and you can create as many profiles as you want. Once you have a profile (for example, "worktrello") you can launch it with
firefox -P "worktrello" -no-remote
and it will be a completely separate process, with its own cache and cookies and all.
firefox.exe -p
and pull up the profile manager (you have to make sure all instances of Firefox are closed first) and you can create as many profiles as you want. Once you have a profile (for example, "worktrello") you can launch it with
firefox -P "worktrello" -no-remote
and it will be a completely separate process, with its own cache and cookies and all.
Same with Chrome, only it has a UI. Click the person icon at the top left.
I know you probably don't want to move, but slack.com has done multi-account management for team chat really well.
seriously
This is exactly the feature I was hoping would show up, Stripe you continue to be one step ahead.
Was literally looking for this yesterday, Stripe is always reading my mind :)
Same here, have a part of an app that I'd like a separate account for so this matches up perfectly.
Interesting, Im in Australia and I have had this feature in Stripe for a few days already from when I signed up. The only issue I have had is that I cant find where to delete accounts. Otherwise, congrats to the Stripe team!
You can delete your account here: https://manage.stripe.com/account/data ("Close this account...")
Thanks Mr G
This is great! This is one of the things we looked at when choosing a credit card provider. (We did not end up choosing Stripe, but this certainly sweetens the deal. Always looking for a better rate!)
Does this mean that we could have multiple accounts, with different soft descriptors, merged together? Would we also be able to see, in a single report, the transactions for all of the accounts (rather than having to log in separately to download sales data?)
Can't wait to see more of your de-annoying features!
Does this mean that we could have multiple accounts, with different soft descriptors, merged together? Would we also be able to see, in a single report, the transactions for all of the accounts (rather than having to log in separately to download sales data?)
Can't wait to see more of your de-annoying features!
I'd love to hear why you didn't choose Stripe -- feel free to drop me a line. I'm [email protected].
I'm not the OP, but I opted for Balanced over Stripe due to the delay in getting paid. Aside from that I prefer Stripe's API and overall experience more.
Balanced employee here: if anyone's wondering, we do next day deposits for all accounts and same-day deposits for Wells Fargo accounts. Some people even just use is solely for payouts.
And rbritton, as the guy in charge of the API these days, I'd love to hear how I can make it better.
And rbritton, as the guy in charge of the API these days, I'd love to hear how I can make it better.
I use Balanced for a non-marketplace ordering system as well as in an in-person ordering app. The Balanced dashboard is used for any account management and refunds.
I found the process of actually taking and charging a card to be a bit cumbersome with having to tokenize the card (wait for response), create the customer record (wait for response), associate the card token (wait for response), and finally create the debit (wait for response).
The tokenizing I'm absolutely fine with since it offloads the bulk of PCI compliance to Balanced, but the last three steps seemed a bit much when all I wanted to do was debit the card. I don't have any need to save a permanent customer and card record. This is a process Stripe doesn't have as far as I can tell, but I was ultimately willing to deal with it for the faster payouts.
I also like Stripe's two-factor authentication support.
And, on another note, I was a bit disappointed with both Balanced and Stripe's iOS libraries. They only support tokenizing a card. Though this is likely going to be the bulk of use by many people it meant creating everything else from scratch.
I found the process of actually taking and charging a card to be a bit cumbersome with having to tokenize the card (wait for response), create the customer record (wait for response), associate the card token (wait for response), and finally create the debit (wait for response).
The tokenizing I'm absolutely fine with since it offloads the bulk of PCI compliance to Balanced, but the last three steps seemed a bit much when all I wanted to do was debit the card. I don't have any need to save a permanent customer and card record. This is a process Stripe doesn't have as far as I can tell, but I was ultimately willing to deal with it for the faster payouts.
I also like Stripe's two-factor authentication support.
And, on another note, I was a bit disappointed with both Balanced and Stripe's iOS libraries. They only support tokenizing a card. Though this is likely going to be the bulk of use by many people it meant creating everything else from scratch.
Hi rbitton,
Balanced employee here.
>> I found the process of actually taking and charging a card to be a bit cumbersome with having to tokenize the card (wait for response), create the customer record (wait for response), associate the card token (wait for response), and finally create the debit (wait for response).
Couldn't agree more. Tracking this issue here: https://github.com/balanced/balanced-api/issues/472. We will have news very shortly on some changes that you might be interested in.
>> I also like Stripe's two-factor authentication support.
This is already done AFAIK. Email me directly -- [email protected]
>> And, on another note, I was a bit disappointed with both Balanced and Stripe's iOS libraries. They only support tokenizing a card. Though this is likely going to be the bulk of use by many people it meant creating everything else from scratch.
May I ask that you open a github issue on https://github.com/balanced/balanced-ios with exactly what you're looking for?
Thank you very much.
Balanced employee here.
>> I found the process of actually taking and charging a card to be a bit cumbersome with having to tokenize the card (wait for response), create the customer record (wait for response), associate the card token (wait for response), and finally create the debit (wait for response).
Couldn't agree more. Tracking this issue here: https://github.com/balanced/balanced-api/issues/472. We will have news very shortly on some changes that you might be interested in.
>> I also like Stripe's two-factor authentication support.
This is already done AFAIK. Email me directly -- [email protected]
>> And, on another note, I was a bit disappointed with both Balanced and Stripe's iOS libraries. They only support tokenizing a card. Though this is likely going to be the bulk of use by many people it meant creating everything else from scratch.
May I ask that you open a github issue on https://github.com/balanced/balanced-ios with exactly what you're looking for?
Thank you very much.
I just looked at the balanced tutorials here:
https://docs.balancedpayments.com/current/overview.html?lang...
and while the code for "Collecting Credit Card Information" makes a lot of sense I find the steps under "Charge a credit card" unclear. Why does one need to create a customer to charge a card that has been tokenized ? I would also suggest making it more clear in this tutorial what the different numbers mean. For example where did CUXj7DWHSxlMvGDLGSYRI3o come from in step 2 ? As for the card_uri I'm guessing that is the uri that was obtained in the prior tutorial, but guessing makes me a little uncomfortable so it would be nice if that were made more explicit.
I'm also wondering why the balancedpayments documentation emphasizes marketplaces over simple e-commerce sites. Does this mean that balanced is a less appropriate solution for simpler sites (ie. where payments are made directly from a site's users to the site itself) ?
https://docs.balancedpayments.com/current/overview.html?lang...
and while the code for "Collecting Credit Card Information" makes a lot of sense I find the steps under "Charge a credit card" unclear. Why does one need to create a customer to charge a card that has been tokenized ? I would also suggest making it more clear in this tutorial what the different numbers mean. For example where did CUXj7DWHSxlMvGDLGSYRI3o come from in step 2 ? As for the card_uri I'm guessing that is the uri that was obtained in the prior tutorial, but guessing makes me a little uncomfortable so it would be nice if that were made more explicit.
I'm also wondering why the balancedpayments documentation emphasizes marketplaces over simple e-commerce sites. Does this mean that balanced is a less appropriate solution for simpler sites (ie. where payments are made directly from a site's users to the site itself) ?
Hi there!
Balanced employee here.
You're right. That tutorial could be made much more clear. In fact, this guide and others are being extensively rewritten. The example itself is specific to charging a Card. Therefore, the guide assumes you have an existing Customer since Customer creation is a separate topic. You are correct that the card_uri is an example of one that would be obtained from the previous example. Let me clear up how to charge a credit card.
First, the card needs to be tokenized (information sent to Balanced and securely vaulted), https://docs.balancedpayments.com/current/api.html?language=....
Next, either find an existing Customer or create a new one, https://docs.balancedpayments.com/current/api.html?language=....
Now add the Card to the Customer, https://docs.balancedpayments.com/current/api.html?language=....
Lastly, go ahead and create a new debit, https://docs.balancedpayments.com/current/api.html?language=....
A requirement of the current API is that a Card or BankAccount must first be associated to a Customer before it can be used. This is mainly due to the fact that v1.0 of the API is very Customer resource centric, something that's changing in the upcoming 1.1 release. A Customer resource will no longer be required to charge Cards.
If you have any other questions feel free to hop in #balanced on freenode IRC. We love questions!
Balanced employee here.
You're right. That tutorial could be made much more clear. In fact, this guide and others are being extensively rewritten. The example itself is specific to charging a Card. Therefore, the guide assumes you have an existing Customer since Customer creation is a separate topic. You are correct that the card_uri is an example of one that would be obtained from the previous example. Let me clear up how to charge a credit card.
First, the card needs to be tokenized (information sent to Balanced and securely vaulted), https://docs.balancedpayments.com/current/api.html?language=....
Next, either find an existing Customer or create a new one, https://docs.balancedpayments.com/current/api.html?language=....
Now add the Card to the Customer, https://docs.balancedpayments.com/current/api.html?language=....
Lastly, go ahead and create a new debit, https://docs.balancedpayments.com/current/api.html?language=....
A requirement of the current API is that a Card or BankAccount must first be associated to a Customer before it can be used. This is mainly due to the fact that v1.0 of the API is very Customer resource centric, something that's changing in the upcoming 1.1 release. A Customer resource will no longer be required to charge Cards.
If you have any other questions feel free to hop in #balanced on freenode IRC. We love questions!
(ceo of Balanced)
This is great feedback!
Is this essentially what you're looking for?
This is great feedback!
Is this essentially what you're looking for?
require 'balanced'
Balanced.configure('ak-test-2ficCWmYvpRBBSzC7Me62ZTX0Y2DPGjgt')
card = Balanced::Card.find('/cards/CC4TsBYO9E4IRQqg0jvrEg9i')
card.debit(
:amount => 5000,
:appears_on_statement_as => 'Statement text',
:description => 'Some descriptive text for the debit in the dashboard'
)Yes, exactly that. I like having the option to save customers and cards, but I prefer not to be required to for circumstances that don't need it.
Thanks! That makes sense. This process only needs to fully happen the first time, but I bet we can make that a bit easier.
I've made an issue to track this on GitHub, let's talk more over there: https://github.com/balanced/balanced-api/issues/472
I've made an issue to track this on GitHub, let's talk more over there: https://github.com/balanced/balanced-api/issues/472
If you don't have any need to save the customer and card for subsequent charges, then I believe (on Stripe) you can simply pass the token to the payment object API, eliminating 2 of your 4 steps.
Next day deposits? Does this mean Balanced has no reserve policy?
Yup, we don't mandate reserves. Marketplaces are liable for things like chargebacks, so many people do keep reserves and use our escrow functionality.
Is Stripe planning on offering next-day/same-day deposits anytime soon (for all accounts)? This is becoming a big problem for us and we're considering switching to Balanced because of it.
Yes. Could you drop me a line? [email protected].
Balanced employee here.
Axsuul, thanks for checking out Balanced! Let me know if I can answer any questions.
Axsuul, thanks for checking out Balanced! Let me know if I can answer any questions.
I have to say that not only do you have a very good product/service, but I am constantly impressed by your engagement in it and apparent commitment to your customer base.
thanks!
@memset who did you end up using for payments?
Oh, I just noticed that you are a co-founder of Balanced!
I will say this - and I mean this in the most respectful way possible: it is unlikely I would encourage us to switch to you folks until (frustratingly!) you all are more established!
[Also, I don't mean to single you out specifically: I'm talking about any company who wants to be an integral part of our infrastructure, but the topic at hand happens to be payments.]
I have personally been burned by choosing a neato new startup for critical parts of our infrastructure. Burned in the sense that these startups change their model and pivot quickly, and since we have made them an integral part of our infrastructure, it is frustrating and difficult to change. (Dotcloud, for example, got rid of their free sandboxed tier this past year. This was a great move on their part, but also left a sour taste in my mouth and unexpectedly increased our expenses.) We also get burned when a new company has bugs - because while I personally might understand, our customers are the ones who are affected. It also called into question my ability to evaluate different solutions, and forced me to realize that, for non-personal projects, it is important to use something established.
This is somewhat ironic, since we ourselves are a startup - so I feel the pain of finding customers (or even developers!) every day!
I will say this - and I mean this in the most respectful way possible: it is unlikely I would encourage us to switch to you folks until (frustratingly!) you all are more established!
[Also, I don't mean to single you out specifically: I'm talking about any company who wants to be an integral part of our infrastructure, but the topic at hand happens to be payments.]
I have personally been burned by choosing a neato new startup for critical parts of our infrastructure. Burned in the sense that these startups change their model and pivot quickly, and since we have made them an integral part of our infrastructure, it is frustrating and difficult to change. (Dotcloud, for example, got rid of their free sandboxed tier this past year. This was a great move on their part, but also left a sour taste in my mouth and unexpectedly increased our expenses.) We also get burned when a new company has bugs - because while I personally might understand, our customers are the ones who are affected. It also called into question my ability to evaluate different solutions, and forced me to realize that, for non-personal projects, it is important to use something established.
This is somewhat ironic, since we ourselves are a startup - so I feel the pain of finding customers (or even developers!) every day!
Sorry I didn't disclose that I'm a Balanced co-founder. HN won't allow me to go back and edit now.
Thanks for taking the time to respond, Jay, and I appreciate the honest feedback. I'd be concerned if you didn't take seriously your choices about core pieces of your infrastructure, especially ones that are so closely related to your revenue.
I will say that Balanced has been processing live transactions for over 3 years, works with hundreds of marketplaces and crowdfunding platforms, and has been growing as fast as we can (~780% y-o-y). Unfortunately, there's not much we can do to become more established besides exist longer and continue growing. We're not planning on going anywhere, so we'll keep improving in that dept. as well. :-)
Thanks again!
Thanks for taking the time to respond, Jay, and I appreciate the honest feedback. I'd be concerned if you didn't take seriously your choices about core pieces of your infrastructure, especially ones that are so closely related to your revenue.
I will say that Balanced has been processing live transactions for over 3 years, works with hundreds of marketplaces and crowdfunding platforms, and has been growing as fast as we can (~780% y-o-y). Unfortunately, there's not much we can do to become more established besides exist longer and continue growing. We're not planning on going anywhere, so we'll keep improving in that dept. as well. :-)
Thanks again!
I think you'll enjoy one of the announcements we're making soon. I bet we're more established than you think.
Braintree. Being able to change soft descriptors was useful to us, because we sell merchandise (eyewear) on behalf of different brands. I believe they gave us a better rate. (interchange + basis points, rather than percentage + basis points.)
Because we have these different brands for which we do eyewewar, we found that they had slightly better dashboard and reporting tools. There were also differences in being able to do do "authorizations" separately from "settlements" but I think both now support that process fairly well.
It was also nice that Braintree was able to boast of many established companies, which we already use and trust, for payments. One thing I've learned is to always ask for references!
Between the two, both have a great API. Things have probably changed with Stripe in the intervening year too. Stripe was certainly hungrier - they did a better job returning our calls, understanding our business, etc - but the former ended up having a better rate and the feature set we needed at the time.
But I'm always re-evaluating (fortunately - or maybe unfortunately - if another processor is better for some reason, then given our volume, it is usually worth it for us to switch.) So this is why these kinds of features are exciting to me!
Because we have these different brands for which we do eyewewar, we found that they had slightly better dashboard and reporting tools. There were also differences in being able to do do "authorizations" separately from "settlements" but I think both now support that process fairly well.
It was also nice that Braintree was able to boast of many established companies, which we already use and trust, for payments. One thing I've learned is to always ask for references!
Between the two, both have a great API. Things have probably changed with Stripe in the intervening year too. Stripe was certainly hungrier - they did a better job returning our calls, understanding our business, etc - but the former ended up having a better rate and the feature set we needed at the time.
But I'm always re-evaluating (fortunately - or maybe unfortunately - if another processor is better for some reason, then given our volume, it is usually worth it for us to switch.) So this is why these kinds of features are exciting to me!
As nice as new features are, I do wish you'd work on bringing all of your existing features to non-US customers first!
Your international support is definitely better than most payment processors (Balanced I'm looking at you), but it's been over six months since you introduced Transfers to US customers. I'd love to know if there is a technical/legal reason behind this? The US has a number marketplace payment solutions but I've yet to come across any European ones.
Your international support is definitely better than most payment processors (Balanced I'm looking at you), but it's been over six months since you introduced Transfers to US customers. I'd love to know if there is a technical/legal reason behind this? The US has a number marketplace payment solutions but I've yet to come across any European ones.
Well, it's a tough balance, and much of it can't be expedited just by applying more manpower -- beyond mythical man month considerations, there's also the fact that we're often waiting on other partners. Given that, working on new features doesn't necessarily slow our international expansion.
But I hear you. Hope to have more to report before too long.
But I hear you. Hope to have more to report before too long.
Balanced employee here.
Thanks for calling us out, robotfelix (honestly). We're working on expanding internationally, but until then checkout mangopay.com for European marketplace payments.
Thanks for calling us out, robotfelix (honestly). We're working on expanding internationally, but until then checkout mangopay.com for European marketplace payments.
Awesome. We have US, UK and AU Stripe accounts and this is exactly what I was wishing for a few weeks back. Thank you :)
Hello stripe people, any plans to add some kind of facility for micro-payments anytime soon?
pc probably has the authoritative answer, but this Quora answer by Vish Shastry might shed some light: http://www.quora.com/Online-and-Mobile-Payments/When-will-St...
Excerpt:
>I have no particular insight into Stripe's product roadmap, but my guess is that they probably won't put 5% + $0.05 pricing into the market anytime soon. That pricing would put them underwater on individual transactions, since it costs more than that to process a charge to a credit / debit card.
>Amazon and PayPal can only do it because a) PayPal can sometimes process payments to a user's bank account (instead of their credit / debit card) or pull funds from a user's existing PayPal balance, which costs them next to nothing and b) Amazon also sometimes routes payments through a bank account, but they also don't have high margins and can live with some 'loss leader' transactions.
Excerpt:
>I have no particular insight into Stripe's product roadmap, but my guess is that they probably won't put 5% + $0.05 pricing into the market anytime soon. That pricing would put them underwater on individual transactions, since it costs more than that to process a charge to a credit / debit card.
>Amazon and PayPal can only do it because a) PayPal can sometimes process payments to a user's bank account (instead of their credit / debit card) or pull funds from a user's existing PayPal balance, which costs them next to nothing and b) Amazon also sometimes routes payments through a bank account, but they also don't have high margins and can live with some 'loss leader' transactions.
[deleted](1)
This is awesome. Glad they introduced this feature sooner than later.
Cool! Just the other day I was wondering if Stripe supported this, because otherwise it would've been a pain in the ass to have multiple projects on Stripe. Thanks!
@pc: You guys should allow authorizations to last much longer than 7 days. PayPal allows up to 30 days before expiration.
Love it. I haven't had a need for this yet but I could definitely see how this would be beneficial.
When will Stripe Integrate with 1ShoppingCart? Tired of Merchant account and Gateway fees.
You should probably ask 1ShoppingCart...
Great, any news on multiple subscription support?
It's coming! Happy to give you beta access -- [email protected].
\o/
Super easy to set up and switch between the instances. You can even set an icon for the user that is always shown at the top right corner. Saves lifetimes if you have multiple twitter, FB etc accounts to manage and don't need a special marketing SaaS.