If you’ve been on social media lately, you’ve probably encountered the Ice Bucket Challenge, a viral awareness and fundraising campaign started by Boston College athlete Pete Frates aimed at fighting Amyotrophic Lateral Sclerosis (ALS), better known as Lou Gehrig’s disease.
The rules are simple: once the challenge is received, you have 24 hours to either post a video of yourself dumping a bucket of ice water on your head or to donate to ALS research, and then once that’s done, you challenge someone else to do the same. Everyone from pro athletes to movie stars to prominent political families is taking the challenge.
And now, there’s at least one tech company. Here’s WePay accepting the challenge:
In addition to braving the bucket, we’re making a $500 donation to the Pete Frates fund, and a separate $500 donation to the ALS Association, a national non-profit organization that conducts research, care services, public education, and public policy aimed at putting an end to ALS.
We’ve challenged David Hornik at August Capital, Paul Purcell at Continental Investors, Chris Howard at Ignition Partners and our partners at GoFundMe to take the challenge themselves. ALS research is an eminently worthy cause, and it would be great to see the tech community step up and help put a stop to this terrible disease.
You have 24 hours to respond!
Once a company decides that it needs to have payment processing as a part of its product offerings, there are a number of ways to go about doing that. One of the easiest ways is to work with a payments services provider (PSP) like WePay. That lets you harness a payments infrastructure that’s already been built out instead of recreating the wheel by building your own, and depending on which PSP you go with, you might also get help with things like regulatory compliance and customer support.
But PSPs aren’t the only game in town. We’re a fairly recent innovation in an industry that in some regards hasn’t changed much since the 1970s, and as you might well imagine, there’s a lot of different legacy players offering a range of different services.
It goes without saying that we here at WePay have built the best possible payments solution for specific types of businesses — online platforms like crowdfunding sites, small business software providers and marketplaces that provide value by linking payers with payees without controlling one side of the transaction the way a traditional merchant might. Nobody else in the industry offers the same blend of flexibility, regulatory compliance and 100 percent safety from losses due to fraud.
Yet payments is an area where there really doesn’t exist a one size fits all solution, despite what PayPal might like you to think. Depending on the nature of your business and what your goals are, a different type of payments processor might be right for you. Here’s some of the different types of payments partners along with their pros and cons.
Gateway companies are the OGs of the payments world, providing a technology layer that enables a company to interface with an acquiring bank to process transactions. If you are looking to build your own payment solution from scratch, then you will probably need to work with a gateway. Gateways are not interoperable — every acquiring bank has different gateways that they work with. Some, particularly those that are wholly owned subsidiaries of an acquirer like Vantiv, only work with a single bank. Gateways offer flexibility and a lower per-transaction fee at the expense of significant upfront and ongoing costs associated with creating and running a payments system.
Examples: Chase Paymentech, First Data, Cybersource
Independent Sales Organizations, or ISOs, are the value added retailers of the payments world. Their primary purpose is to market and sell merchant accounts to businesses on behalf of an acquiring bank. Most ISOs have a single acquirer they work with, but some of the larger ones work with several. It’s hard to generalize too much about ISOs, as it is a diverse industry — on the small end they may be little more than a sales office peddling merchant accounts to local brick-and-mortar businesses, while larger ISOs often offer a greater degree of technology, service, and support to their customers. ISOs are generally unsuited for platform payments, as their primary use case is providing merchant accounts for an end retailer.
Examples: Too many to list. Here’s Visa’s list of registered ISOs.
Payment Service Providers, also called PSPs and payment facilitators are a newer class of payments companies that bundle an acquirer, processor, gateway and support for alternate payment methods into a complete payments solution. PSPs are very developer-focused, providing modern tools like APIs and SDKs as well as a complete technology stack for payments processing. The downside is that the most regulatory compliant of them will impose their own checkout flow on a transaction, which can hurt brand building and the user experience, while some that are more flexible offer less in the way of fraud mitigation and regulatory compliance.
Examples: WePay, Braintree, Stripe, Balanced, PayPal
There are a lot of players in the payments space, all of them with slightly different product offerings geared to different types of businesses. A large multinational company is going to want to work with different partners than a mom-and-pop retailer, and a platform company is going to have different needs than a company that’s an end merchant. The key is finding the right kind of payments provider that meet your specific needs. If you’re a platform looking for an easy and simple payment API, WePay can help. Contact our API team at API@WePay.com to hear about how we make processing payments simple, safe, and profitable.
Monday, we at WePay had the pleasure of attending Rackspace Solve in San Francisco, the first of several major conferences by Rackspace aimed at showing how various companies are using the cloud to solve tough business problems.
Our CEO Bill Clerico gave one of the first talks of the morning on a problem that every startup eventually runs into: scaling up to meet massive user demand without falling flat on your face.
Anybody who’s not gone through it would probably put that in the “good problems to have” category, but make no mistake: scaling is one of the toughest challenges in the technology business, something that takes a robust DevOps strategy to tackle. We would know, since WePay has faced some unique scaling challenges. Put it this way — the payment volume we process is set to more than double this year, and it will double again next year if we have anything to say about it. To keep up with demand, we’ve hired about 20 people in the last month, mostly in engineering, at a company that’s only about 60 people strong.
In other words, getting to scale is a major initiative here at WePay, one on which we’ve worked closely with Rackspace. We were one of the first customers for Rackspace’s DevOps Automation Services, which helped us to keep our service running at a time when we were facing unprecedented demand, and has continued to help us as we look to take on even more volume.
You can watch Bill’s full talk at the video above, but here’s some takeaways in the meantime:
The time to think about DevOps is now: Bill said that if he had one do-over at WePay, it would be to have started thinking about building great infrastructure earlier in the process, because it’s something that sets a company up for success at every stage. In the early days, the understandable temptation is to focus technical talent exclusively on product, but if you don’t also spend time building out great infrastructure, it’s easy to get stuck with early mistakes that will hurt you down the road, Bill said.
“As a technical founder, you think you can just go on Stack Overflow and find what you need solve any problem, but that’s really not the case,” he said. “You can’t have great DevOps just by reading some blog.”
DevOps isn’t just a technical problem: Because DevOps is a problem with a technical solution, it’s tempting to think of it as just a problem for the technical side of the business. But a poor or non-existent DevOps strategy hurts every part of a company. It’s a customer service problem, because especially in the enterprise zero downtime is the one of the No. 1 demands that your customers make of you. It’s a product problem, because bad infrastructure limits how fast product teams can work and how well they can innovate. (With due respect to Mark Zuckerberg, you need to move fast, but if you break things every time you do, that’s a problem.) DevOps even affects recruiting, Bill said.
“I’ve certainly found it to be the case that the best engineers, the ones you really want to hire, won’t want to work on crappy infrastructure,” he said.
Just because DevOps is important doesn’t mean it needs to be entirely in-house: At the same time, DevOps is often a problem with peaks and valleys — sometimes your servers are getting hammered and you need a full team working around the clock, and sometimes nothing is happening and you’ll struggle to find work for just one person. That being the case, don’t be afraid of working with an outside team, Bill said. In WePay’s case, working with Rackspace enabled the company to be very agile, scaling up to meet demands and get support when it was needed and then scaling down when things were more stable. Outsourcing can be an important tool in the arsenal.
One of the common questions we often get here at WePay is about offering escrow — understandable, since many of our platform partners are services uniting a buyer and a seller who don’t know each other, and escrow offers a way for both sides to be comfortable with a transaction even with that unknown.
Yet like a lot of things in the payment industry, escrow is something that seems like it should be simple but is actually surprisingly complex when you really look at it. Given that, we thought a little primer might be useful.
Here’s the first bit of hidden complexity, because when people ask about “escrow,” that’s not always what they mean. Oftentimes, what they’re really talking about is the ability to delay payments.
There are any number of situations where a platform might need to do this. An obvious one is where a payer is buying something from a seller that can’t be readily evaluated for quality. Take a marketplace for concert tickets, for example. In this instance, the product could ship immediately, but until the buyer actually brings the ticket to the venue and is actually let into the concert, it would be very hard to say whether they got what they paid for.
The ticket platform therefore might charge the buyer but only release the funds to the seller after the show, and only if they don’t get an angry message from the buyer saying the tickets were bogus. That cuts down on fraud, because unscrupulous types know they won’t get any money from just printing out and selling fake tickets. It also might increase conversion rates for the platform, because buyers might be more comfortable using the service if they’re getting some guarantee that the things they buy will be genuine.
This might look like an escrow. Or, it might look like a money-back refund policy that the platform helps to enforce.
And that’s an important distinction, because escrow agents are actually something that is regulated at the state level, meaning anyone who wants to offer escrow services needs a license from the states they’re accepting funds in. There’s good reason for this regulation. Since the escrow agent is holding other people’s money, there’s a lot of potential for wrongdoing. Licensing requirements help prevent the escrow agent from just disappearing into the night with the buyer’s money, or from saying they are holding something in escrow when they’re really using it to play the stock market, or any other potential abuses you can think of.
Here’s how California law sees escrow with regard to Internet companies:
"With regard to Internet escrow companies, ‘escrow’ also includes any transaction in which one person, for the purpose of effecting the sale or transfer of personal property or services to another person, delivers money, or its Internet-authorized equivalent, to a third person to be held by that third person until the happening of a specified event or the performance of a prescribed condition, when it is then to be delivered by that third person to a grantee, grantor, promisee, promisor, obligee, obligor, bailee, bailor, or any agent or employee of any of the latter.” — California Financial Code 17003(b).
The short answer? Probably not, but maybe.
You’ve probably noticed that definition looks very close to what our hypothetical ticket platform was doing in the earlier example — it was a 3rd party that was holding on to funds until a transaction could be verified to have occurred satisfactorily. But there are a couple of differences that might be relevant, legally speaking. For one thing, the escrow it’s providing here is not its primary service — rather, it’s the technology that lets ticket sellers find ticket buyers and vice versa. It’s also not the buyer or the seller that’s choosing to put the funds into escrow, but rather the platform itself that’s choosing to hold onto funds as a part of its normal efforts to fight fraud and keep everyone using its service honest.
That might make the ticket platform materially different enough that it can essentially hold funds in escrow without actually being an escrow agent. Or it might not. Like a lot of legal issues, once you get outside what’s clearly spelled out in the law it becomes more a matter of probability and risk assessment than hard and fast rules.
What is clear is that, if the platform is holding the money, regulatory compliance is a burden that would fall on the platform. If the ticket platform were found to infringe, the regulators would be sending angry letters to them, not the company processing their payments. That could be true even if the platform holds the money in a bank account “For the Benefit Of” (FBO) its customers, or if the platform uses a third party payment processor to hold customers’ money for the platform. If the customers’ money appears on the platform’s balance sheet, the platform is exposed to regulations that apply to that money, such as the California internet escrow law.
At WePay, we hate legal ambiguity. Our promise to our partners is that they will never have to concern themselves with the regulatory risk and compliance, because we will cover that all for them. They expect us to keep everything on the up and up, so that any potential downside is minimized. Consequentially, we’re very cautious about anything that introduces additional risks.
That being said, we offer our partners a way that they can do delayed payments and ensure that they don’t have to worry about hard legal questions about escrow.
It starts with the way we process our payments: our platform partners never hold customers’ funds. WePay assures that those funds go straight from the buyer to a special bank account, then to the seller, without ever being held by the platform or appearing on the platform’s balance sheet. That means that WePay, and not the platform, is on the hook if the states ever do decide that marketplaces (or other types of platforms) need to be licensed escrow agents to provide delayed payments.
We also offer two options that act like escrow, but which we think are compliant:
If you’d like to learn more about how our delayed payouts work, contact our API team at API@wepay.com