Since March 2013, I've been working on building a payment system to sell products for my business. It started out as a modified version of Stripe Checkout. And, from there, I bolted on a full-featured back-end to manage the checkout and collected payments.
I named my payment system "Snappy Checkout". Here's an example of how I use it on one of my websites:
After adding a few lines of JavaScript, the checkout can also be launched directly from any website that uses HTTPS.
Here are some differences from other checkouts I've used:
- Both Stripe and PayPal payments can be accepted. I prefer Stripe over PayPal (API-wise), but I didn't want to switch soley to Stripe because a lot of people still like paying with PayPal.
- When a payment is received, a number of checks are run to determine if it's possibly fraudulent. I'm using the term "possibly" because it's hard to programatically determine a payment is fraudulent at 100% accuracy. So far though, I've found Snappy Checkout's detection to be accurate when scanning payments that I've received.
- If selling digital products, files are stored in your own Dropbox account. I suppose there could be pluses and minuses here. But, I prefer to allow people to control their own files.
- Snappy Checkout offers a variety of payments -- including one-time payments, discounted payments, subscriptions, subscriptions with a trial period prior to the first payment, and the option to split a payment over several months.
- Both Stripe and PayPal payments can be viewed, searched, and refunded from the Snappy Checkout dashboard.
- The cost is 2.9% + 80¢ per sale. Most people are charging a percentage of the sale price on top of the credit card processing fee.
I think others will find this can work for their business too. What do you think?
Whoa, this looks pretty fantastic to me. Have you thought about integrating with Shopify? It has a lot of trouble with recurring payments, and Chargify is a pain to use and adds an additional $60/month charge on top of the Shopify fees (it is still worth it, but Shopify having simpler recurring payments would be amazing). This looks like exactly what I was looking for about a year ago when I add recurring payments to my store.
EDIT: After signing up, I see integrating with Shopify isn't even necessary. Do you plan to compete with them? Or potentially be a feature to work with them?
It's targeting people who want to be able to put together a store very simply and quickly (at least that is why I used it). It definitely has a weakness on recurring payments (pretty much the only thing Volusion does better, in my opinion), but other than that it is pretty fantastic in terms of connectability and ease.
For digital products, a download link is included in the emailed receipt. I use the Dropbox API to create a temporary download link that is active for 4 hours. I don't expose the Dropbox link though. Instead, the customer clicks a Snappy Checkout link and I redirect them to the Dropbox link.
That extra step is in there because I check the customer's IP address to ensure it's the same on every download attempt. If the IP address changes, I send the customer a new download link via email.
I know it's not possible to stop sharing files across the Internet. I think this process does a good job of preventing it -- without adding too much grief.
When purchasing a product that is shipped, shipping fields will appear below the credit card information fields.
> That extra step is in there because I check the customer's IP address to ensure it's the same on every download attempt. If the IP address changes, I send the customer a new download link via email.
That is a very clever solution to a very difficult problem. I love it!
Really nice to see some innovation in this space. I have used a particular provider since 2006 and eventually ripped out 98.5% of their system to replace with my own, but am familiar with the offerings you're competing with. Most are godawful. They're largely bubblegummed-together, the reporting is atrocious, they're virtually unusable by the (surprisingly) non-technical people who have to work with them, they have UXes which actively discourage customers' customers from spending money (!), etc etc.
I would not be surprised if the market eventually pushed you into handling fulfillment, by the way. For many of the early adopters in this space that's as simple as "proxy a download link and send two emails" but it's a really important part of the puzzle for them.
Snappy Checkout does have an API (just some basic calls right now) & webhooks that can help with digital fulfillment. For my own business, a webhook notifies me of a new sale and I use the Snappy Checkout API to verify that the sale is legit -- which basically allows me to verify that the paid price matches the expected product price.
If you meant non digital fulfillment, I don't know much about that. I'm interested in improving Snappy Checkout to help in that area if at all possible.
If you're going to start adding features, you might want to add a feature request page to help prioritize them. I sell desktop software and the most requested features in that space would probably be license key fulfillment, discount codes, product bundling, and interfacing with CD fulfillment services.
License key fulfillment can be done now using the Snappy Checkout API & webhooks. This process is undocumented right now... but, I'm working on it. In the meantime, I can help anyone get it going via email.
Recurring payments is just a huge pain. Stripe built the easiest solution, but it still wasn't perfect (although knowing those guys, it will continue to improve). Totally second patio11's excitement over innovation in the space.
Funny to see patio11's comment percolate up, after watching this thread today. Wondered why it took so long. Just waiting for the "OMG...security hole found in snappy checkout" comments to take over. :)
BTW, OP this looks awesome and I'm hoping to try it out soon. didn't mean to snark.
I'm not sold on this product yet, for other reasons, but the transaction fees are very compelling to me.
For the typical $5/mo SaaS subscription
This is the problem. Typical Saas subscriptions are significantly more than $5/month, at least if you want to stay in business. $50/month (as a starting tier) is more normal and could actually be sustainable.
If you're charging only $5/month for your SaaS, then you will be unlikely to have enough margins to pay for any external services (and possibly your rent).
For reference, Gumroad charges .30 + 5%. So on a $50/month subscription that's going to be $2.80, whereas with Snappy Checkout its only going to be $1.95. More importantly, as you charge more (e.g., $200/month), the gap would widen even further.
We currently process about $3k/month through Gumroad and e-Junkie, so we're just about at the point where it makes sense to look at other options. If we can move to something like this as opposed to rolling our own, I'm very interested.
We could argue about what's a "typical" SaaS monthly fee, but I'm pretty sure your $50/mo is for the SMB/Enterprise space where my $5/mo is for consumer.
As you say, I see SaaS as primarily a B2B product. I have trouble naming successful B2C SaaS products, outside of perhaps Dropbox (although I still think Dropbox is primarily B2B, at least in terms of revenue).
But we probably agree on this: if you charge $5/month, this product is not for you. If you charge $50/month, the fees are negligible.
- hosted downloads (not my Dropbox)
- hosted checkout pages (not lightbox)
- what the dunning emails look like, and if I can edit them
- the docs for the API
- more information in general (the site is only 1 page, hard to trust)
- I have no plans to host downloads. Dropbox, S3, etc. live and breathe that stuff. I think Dropbox is easier for the average person to setup, so I chose to go with them.
- Hosted checkout pages -- like a form directly in your website?
- The dunning emails cannot be edited right now. It's on my to-do list. I'd be happy to email anyone a sample of the format I'm using right now.
- There are no API docs right now. I'm working on it. If anyone is interested, please let me know and I will send you a full list of calls available.
- Snappy Checkout is surely new, but I've been writing software on the Internet for quite some time now. If you want to stalk me, try Googling things like "Singer's Creations", "Weather Watcher", or "Mike Singer".
On the second thought, yes it's a lot and I'd prefer flat per month fee like E-junkie does with the secure downloads hosted on the provider server/S3 not my personal Dropbox.
It's great, the functionality is good and the price is fair.
I could only see USD hardcoded as the currency, though, and there is the old euro VAT problem -- businesses in Europe need to be able to charge customers VAT depending on where the goods will be delivered and what type of goods they are. It's all pretty complicated stuff, but without it a checkout system is useless to most Europeans :(
It has always seemed to me that anyone who can build a checkout that handles VAT properly would have the whole of Europe beating a path to their door.
"It has always seemed to me that anyone who can build a checkout that handles VAT properly would have the whole of Europe beating a path to their door."
This looks really nice. We are looking for something to integrate into http://Clara.io (our online 3D modeling + rendering tool) so we can start accepting payments. We are looking at Stripe of course, but things on top of stripe that make life easier are always welcome.
Q: Can I migrate from this to something else (stripe.com directly) if it proves to be insufficient or it doesn't have longevity? How much of the customer information is locked in this versus stripe?
Q2: On a separate question, how easily can I move my subscribers away from Stripe.com for whatever reason? Will I need them to re-enter in their payment data? That would be killer for us.
Q3: How do other websites handle this these types of issues of potentially switching payment systems?
Let me know if there is anything preventing you from using Snappy Checkout. It does a lot right now, but I'm willing to make it better if it won't work for your business is-is.
A: When accepting Stripe payments via Snappy Checkout, all of your customer data is still available in Stripe. If you left Snappy Checkout to use something else, the only thing that would not work is subscriptions. I don't use Stripe's system for subscriptions -- that is all handled in Snappy Checkout. And, if it really proves to be insufficient, I'd like to make it work for you if possible.
A2: Snappy Checkout creates customers in Stripe's system. So, you could still charge existing customers if you found another 3rd party system that allowed that. I don't think it's possible to charge existing customers from Stripe's admin right now.
A3: Good question. I'm not sure though -- a possible import process maybe? I suppose that would be tough since Stripe/PayPal hold all of the credit card data. My goal is certainly not to push people away when a roadblock is encountered. I'd like to make Snappy Checkout work for anyone.
Correction: For existing Stripe customers, you can create new charges/subscriptions from the Stripe admin.
> I don't think it's possible to charge existing customers from Stripe's admin right now.
I don't think this is correct. Stripe (and the Stripe Admin UI) gives you enormous power to charge/upgrade/downgrade/enroll existing customers.
I'm curious, why did you choose to implement your own subscriptions, instead of utilizing Stripe's? This is a much more appealing option if its a clean integration that simply leverages all of Stripe's features (MoonClerk does this well).
Hmm. I really like this, and I'm definitely going to use it when I finish my service. However, I have two small problems and one large problem with it:
- It's impossible to go back and select another payment option once you click one of them.
- You can't style your payment dialog. (This may be a good thing [consistency], but I think it'd be nice to be able to add custom CSS to the pricing dialog.)
My large problem is that the price is crazy; your 50 cent per transaction fee means that for all transactions under $7 you collect more in fees than Stripe does. With a $5 payment - very common for services such as the one I'll release soon - I'm paying 20% to you. With a $1 payment, I pay a prohibitive 83% in fees. That's a really large cut compared to using the Stripe API directly, and I think that for anyone looking to increase their profits it's a no-brainer to cut Snappy Checkout out of the equation.
To give a personal example, my service will be primarily receiving $5 payments. For the first 1000 payments or so, I'll probably stick with Snappy - the $500 I give up isn't worth the time I would've spent rolling my own solution. However, as soon as I can see that there's a clear market for my product, I'll roll my own with Stripe - I clearly wouldn't want to give up 20% to payment processing alone.
Meanwhile, Frank is selling antique vases on Facebook for $1.5k each, and he pays 50 cents a transaction to you.
However, if you were to switch to a flat fee + a percentage (say 1.5% and 15 cents), as Stripe does, you would probably retain my business for a lot longer. Suddenly, I pay a 4.5% cut to you as opposed to a 10% cut, which is quite reasonable. At the same time, Frank the antique vase seller doesn't really care about a 1.5% fee: a win-win situation.
tl;dr I recommend that you change to a percentage of the total sales: sellers of cheap items will use your service and sellers of expensive items won't care. There's a reason why Stripe, Visa, and every other payment processor everywhere ever does this.
It seems someone loses either way. Charge a flat fee and small transactions are more expensive. Charge a percentage and large transactions are more expensive. I suppose you could do some combination of both, but that would make the pricing more complicated to understand.
I don't know about everyone else, but I would care if I was being charged X% to sell a $200 item -- even more so if there were options to pay a flat fee.
There's a reason why every other payment processor I can name and probably hundreds I can't name charge a percentage - it strikes a balance between fairness for large and small payments. Almost no company I can think of would blink at a 0.25% fee - a sign your fees are too low. Meanwhile, nobody would want to pay 80% of a $1 purchase in fees. I really encourage you to rethink your fee model. Visa, Stripe, Mastercard, etc. all use a percentage. There's a reason why almost every payment fee in the last 50 years has used a percentage - because it works.
Personally, I just discovered Gumroad and I'll probably be using that instead. With them I pay 10% of a $5 transaction in fees. With Snappy I pay 20%. It's a no-brainer.
Finally, I don't think a flat fee plus a percent is too hard to understand. Stripe and Gumroad use it, and probably many more but I can't think of them.
[edit] I just found out I can't use recurring subscriptions with PayPal. I'm going with Gumroad. That said, you have a really nice looking product and I'd love to use it, but 20% in fees is ridiculous.
Every other payment processor charges a percentage -- agreed. So, it seems people have no choice right now. They are going to pay a percentage no matter where they go.
I'm open to pricing suggestions. I was just trying to do what I thought was reasonable.
If you (or anyone else) want to work out some kind of X% for less expensive transactions, then send me an email and we can work something out. I'm willing to discuss matching whatever Gumroad or anyone offering similar checkout products is charging.
This is one of the better looking implementations of "checkout on top of stripe" that I've seen (I've seen a lot).
I'm not sure of your target market but the best advice I can give is to make a WordPress plugin to go with this. Website integration (easy for us, I know) is probably daunting for most people. That's why SquareSpace is so attractive–it's all built in. But if you went after the WordPress market with this, it could be huge.
From a purely usability point of view I don't see the advantage of having the choice of payment (credit card via stripe vs. paypal) be offered after the user clicks on the payment button.
The more efficient option is to show pay with credit card and pay with paypal right off the bat.
This implementation means the user clicks PAY, then is shown a modal window and from there clicks, paypal and is then redirected to paypal.
Instead the user could click pay with paypal from the payment page and be taken to paypal with the unnecessary intermediary step.
Same goes for credit card payment: click pay with credit card and the modal window opens up and they enter cc details.
I know, it is just one click or interaction but still, this is the stuff that UX cares about!
This is especially true for check out processes. If you aren't extremely critical of your check out process from a UX/UI view you're leaving lots of easy money on the table.
The implementation is nice and I don't mean to offend but I just don't understand what benefit it can offer. Especially when it has this usability failing outlined above
Apart from Paypal support, what does Snappycheckout provide over just using Stripe directly? And for the extras it does offer, are those likely features on Stripe's roadmap?
Just trying to wrap my mind around your service.
It allows people to setup a checkout without knowing how to use the Stripe API. And, for those that do know how, not everyone wants to invest the time to do so.
I don't think most of what Snappy Checkout does is on Stripe's roadmap. Unless they are planning on building a full-featured checkout system.
I've been waiting for stripe + paypal, as half my payments come from paypal, stripe is such a simple checkout process, and needed one admin for both. Fantastic!
Questions:
1) Will metered billing on subscription services be supported?
2) Not sure if this is feasible, but any plans to allow PayPal payments through PayPal Payments Pro, so they fill in their details in the form on our site instead of being redirected to PayPal?
I'm in the same boat -- the payments I collect for my products are split pretty evenly between Stripe & PayPal.
Answers:
1) As in being able to change the subscription price each month? Snappy Checkout does allow you to manually change the subscription price. But, I suppose making that change via the API would be the better way to go. If you're interested in digging into this some more, please send me an email with some more details on how you envision this working.
2) I've thought about this, but haven't tried it yet. If I could integrate it into the checkout window, then I agree it would offer the best flow. And, there is always the question of how many people are using PayPal Payments Pro and have the need for something like Snappy Checkout.
This looks great. I've already signed up as I've been looking for a replacement for Gumroad for awhile now. Their UI just isn't suited to physical subscriptions. This looks much better.
Found an error: My login date under sessions is "Sat, Dec 30, 1899 @"
Mike, I signed up and the admin area looks great. I don't see any info/docs on how to actually sell product though. I'm currently using SpaceBox.io for hosted checkout. Do you offer something similar or do I have to host the checkout page on my site?
After adding a product in the "Products" section of the admin, click the link icon to the right of your product to see the available linking options. You can add a link to your website or link your customers to your checkout at snappycheckout.com.
I love the pricing - only 50¢ on top of Stripe/PayPal fees.
From the quick look, digital download protection based on IP address and storing files in Dropbox? That makes me uncomfortable and I see tons of potential issues here.
Also what does automatic fraudulent payment detection involves?
What kind of issues do you see with the downloads?
My system keeps track of failed payment attempts (e.g. a declined credit card OR invalid card code). When a successful payment is made, I look through the history of failed payments to look for patterns that can determine a possible fraudulent transaction. An example of a pattern would be an IP address that tried to use X number of credit cards over the past X hours.
The messaging on the site reiterates that you can accept payments and sell product any time "day or night". Is this a problem with existing solutions? Or is this geared towards people who currently have a fully manual fulfillment process?
Could it do things like offer a yearly subscription with a starting price of $x and a recurring price of $y? Basically, like an ongoing maintenance - buy the product at $x and then pay $y for yearly upgrades/support.
This would only work if paying with Stripe though. When paying with Stripe, I create a Stripe customer via their API. So, I can come back later and charge that customer again whenever.
Edit: With some manual work, you could really do this as-is right now. After a subscription is created in Snappy Checkout, you can edit the subscription price, next payment date, or customer's name/email. This certainly would not be a good temporary workaround if you're selling these subscriptions like hotcakes right now though :)
Interesting choice of an IE preview for the home page. Is it by accident or is this something online stores are looking to validate in terms of features? (IE compatibility)
I would think anyone who has an online store would want their checkout to work in all web browsers. IE just happens to have a pretty plain looking window that works best for screenshots where the window is not important :)
I just see it as removing a layer of complexity... I don't really care for having PayPal functionality, and not having to worry about the monthly fee paid to you makes it easier on me and you. You get paid quickly, and I don't have to account for another fee. The 50 cents just becomes part of COGS.
Makes sense. I'm all for making things easier. There is no reason why I could not charge the 50 cents for Stripe charges immediately. And, then come back and charge 50 cents for any PayPal transactions (if any) at the end of the month.
Looks awesome. A great checkout experience is always a delight to use. Even Amazon's feels kind of clunky if you have to enter credit card information.
One question I had was "what is my customer's experience?"
You went into great detail about what features it had that would be convienent for me as an owner, and there seemed to be a hint at some of the customer features, but what is their online shopping experience like? Do they have search, navigation, categories, pictures, images, reviews, etc?
I feel as though you are only explaining the benefits of using it for half of the equation. Does this assume that you've already "sold" your product and you are not truly an online retailer? Or a simple product company?
What target "check-out" scenarios does this cover? Maybe that's why the customer story is absent.
Good questions. Snappy Checkout is not a shopping cart. It'll only work in situations where a purchase involves buying a single product (e.g. an eBook).
Reviews, pictures, etc. are things that fall outside of the scope of Snappy Checkout.
You can use Stripe only, PayPal only, or Stripe + PayPal. When using PayPal only, you cannot collect subscription payments -- due to the limitations of the way I'm using PayPal.
Snappy Checkout shows prices in USD no matter which of the 3 above pricing options you choose. So, it is currently limited in that way.
LLC protects your personal finances and is always a good idea once you reach the stage of a 'serious business' that might be sued by its customers. [e.g. $1000 or more MRR]
how does this differ from stripe? does it charge extra on top of stripe? What is the justification for the price increase? I don't see what else this offers besides stripe does. For me, I focus on subscriptions.
What is the template being used on the website and where can I get it?
It looks like it charges $.50 on top of Stripe. When you work with Stripe you still have to write a little bit of code to request the charge from your backend. SnappyCheckout looks to be a wrapper around Stripe (and Paypal) that takes care of that extra code you would normally have to write.
And it's more convenient than trying to use Stripe & PayPal separately. There are also features (like fraud detection, digital delivery, etc.) that Stripe & PayPal do not offer -- and probably never will.
I named my payment system "Snappy Checkout". Here's an example of how I use it on one of my websites:
https://www.snappycheckout.com/pay?E13DZ319DJ1SJCNDH2JDP1
After adding a few lines of JavaScript, the checkout can also be launched directly from any website that uses HTTPS.
Here are some differences from other checkouts I've used:
- Both Stripe and PayPal payments can be accepted. I prefer Stripe over PayPal (API-wise), but I didn't want to switch soley to Stripe because a lot of people still like paying with PayPal.
- When a payment is received, a number of checks are run to determine if it's possibly fraudulent. I'm using the term "possibly" because it's hard to programatically determine a payment is fraudulent at 100% accuracy. So far though, I've found Snappy Checkout's detection to be accurate when scanning payments that I've received.
- If selling digital products, files are stored in your own Dropbox account. I suppose there could be pluses and minuses here. But, I prefer to allow people to control their own files.
- Snappy Checkout offers a variety of payments -- including one-time payments, discounted payments, subscriptions, subscriptions with a trial period prior to the first payment, and the option to split a payment over several months.
- Both Stripe and PayPal payments can be viewed, searched, and refunded from the Snappy Checkout dashboard.
- The cost is 2.9% + 80¢ per sale. Most people are charging a percentage of the sale price on top of the credit card processing fee.
I think others will find this can work for their business too. What do you think?