First off, congrats on taking the initiative. It's one thing to complain about how much a situation sucks, and another entirely to take it upon yourself to actually do something about it.
You're partially right. The biggest issue medium to long-term would be getting a bank to back you. That doesn't have to be a show stopper from day 1 though (assuming you're willing to assume some personal liability, as you will be in violation of the ToS of any service provider you use).
It all comes down to your risk appetite. Essentially, you could run your own API that would wrap Stripe/Braintree's API and kickstart your business that way. This would require a US entity, but with Stripe's Atlas this is a non-issue.
This is fine if you're processing $10k or even $100k/mo. It gets icky when you try to get past that. As volume grows, there's increasing pressure to make sure that your setup is air-tight, something you can only get by setting up locally (Visa/Mastercard regulations prohibit cross-border processing so it's the only 100% legit way forward).
Herein lies the challenge. Banks in the Middle East (which I presume is where you are targeting) vary greatly in terms of what volume actually deserves their attention. For some that's $10M/mo. For others it might be less. Once you've got $100k, and have a strong upward trend, you can start having these discussions.
In short, you want to start it like you would any other business: by focus on making something people want. The bank issues can be delayed until after you've got a decent customer base. Historically, there's a 95% chance that your company would not survive (startup stats still apply). If you get past that, hit me up and I can provide more specific advice.
I actually requested him to comment on Twitter (https://twitter.com/yazinsai). He founded White Payments, a Stripe-inspired payment processor in the Middle East. It was acquired by Payfort last year [1].
Essentially, you could run your own API that would wrap Stripe/Braintree's API and kickstart your business that way. This would require a US entity, but with Stripe's Atlas this is a non-issue.
Disclaimer: I work at Stripe, on Atlas, and I'm writing here because this is professionally interesting to me.
We probably wouldn't be able to support that business, due to it being an "aggregator." (It aggregates the charges of other merchants and holds onto the funds for some period.)
These are strongly discouraged by banking partners, largely for risk reasons. For example, hypothetically suppose an undercapitalized aggregator was hit by $10k in credit losses by a fraudulent merchant. (Merchant signs up; runs $10k in charges; whoops they're all stolen cards; you ask their bank to pull $10k back but that account has been closed and whomever opened it is out in the wind.)
That $10k has to come from somewhere. Historically, what ends up happening distressingly frequently is this causes the aggregator to fail to deliver money to other merchants. Some of them fail. Their customers charge back their purchases. This increases financial strain on the aggregator. Eventually, the aggregator fails; all of their merchants are greatly inconvenienced; some of them fail; thousands upon thousands of customers are adversely affected. One or more interested parties look for the nearest deep pockets and say "Hey, you should have seen this coming. You're the big, sophisticated company here. Make this long, long line of people whole."
This is why the industry largely doesn't offer credit card processing services to aggregators and, when it does, wants them to be huge, well-capitalized, and very sophisticated. The same issue makes it anomalously hard to get processing capabilities for businesses that you'd assume wouldn't cause problems, like e.g. travel agents. (One cruise company folds while holding onto customer funds; dominoes start falling as above; boom there's an $N million credit loss attributable to a company with revenues in the $100k per year range.)
There are some things which look similar if you squint but are distinguishable because the business doesn't end up holding funds they're not already entitled to. For example, Stripe Connect lets a platform split a transaction into the majority for the merchant and a fee for the platform, without the platform needing to physically have custody of the merchant's money at any point. That probably won't work for your use-case, though, since the merchant would have to be in a country we support.
We're working as fast as we can on bringing the rest of the world online. Stripe wants to be everywhere. Atlas is one initiative we're working on to make good on that (and has brought Stripe up to somewhere north of 110 countries with customers in them); we're constantly at work on other approaches, too.
If any HNer ever has a question about this sort of topic, feel free to email me -- my HN username @ stripe.com will work. I'm happy to explain things, find the right person to do so, or see what we can do regarding businesses that are at the margins. We spend a lot of time on me team and elsewhere in the company zealously advocating on behalf of our users to banking partners to get their businesses accepted.
I'm curious: FastSpring supports sellers from all over the world as their customers, despite having no local presence. It's not difficult. Why can't Stripe? I was waiting for years to be allowed to use it, until MOSS happened in EU and I no longer care - FastSpring's higher fee is well worth the VAT offloading they do for me (and Stripe wouldn't because of the different setup).
Thanks @patio11 -- curious to know if Stripe has ever approved an aggregator outside the regions where Connect exists? Seems to me this limitation is set upstream from Stripe
The issue is that my country, Tunisia, doesn't allow local banks to make foreign purchases. In other words, if you have a Tunisian credit card, you are not able to buy anything online. The primary cause of this is that the currency is strictly controlled, but I believe that the government is trying to work on relaxing these restrictions over time. So that removes the possibility of using Stripe/Braintree/etc. as an intermediary for processing payments.
Because of this, the only way to setup a payment processor in Tunisia is to do it the old-fashioned way. I guess my only course of action is to talk with a number of local banks and see if they'd be willing to back a local payment processor.
You're partially right. The biggest issue medium to long-term would be getting a bank to back you. That doesn't have to be a show stopper from day 1 though (assuming you're willing to assume some personal liability, as you will be in violation of the ToS of any service provider you use).
It all comes down to your risk appetite. Essentially, you could run your own API that would wrap Stripe/Braintree's API and kickstart your business that way. This would require a US entity, but with Stripe's Atlas this is a non-issue.
This is fine if you're processing $10k or even $100k/mo. It gets icky when you try to get past that. As volume grows, there's increasing pressure to make sure that your setup is air-tight, something you can only get by setting up locally (Visa/Mastercard regulations prohibit cross-border processing so it's the only 100% legit way forward).
Herein lies the challenge. Banks in the Middle East (which I presume is where you are targeting) vary greatly in terms of what volume actually deserves their attention. For some that's $10M/mo. For others it might be less. Once you've got $100k, and have a strong upward trend, you can start having these discussions.
In short, you want to start it like you would any other business: by focus on making something people want. The bank issues can be delayed until after you've got a decent customer base. Historically, there's a 95% chance that your company would not survive (startup stats still apply). If you get past that, hit me up and I can provide more specific advice.