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?
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.
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.
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.
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.
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 :)
[+] [-] singer|12 years ago|reply
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?
[+] [-] the_watcher|12 years ago|reply
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?
[+] [-] marcomassaro|12 years ago|reply
For physical products - is there a custom form to collect shipping & billing?
Nice work!
[+] [-] TuxLyn|12 years ago|reply
[+] [-] patio11|12 years ago|reply
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.
[+] [-] singer|12 years ago|reply
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.
[+] [-] the_watcher|12 years ago|reply
[+] [-] cpher|12 years ago|reply
BTW, OP this looks awesome and I'm hoping to try it out soon. didn't mean to snark.
[+] [-] notwhyships|12 years ago|reply
For the typical $5/mo SaaS subscription, that's a full 10% just to pay for your checkout system (not including the payment system).
That said, our team is likely not Snappy Checkout's audience as we're devs who can integrate Stripe/Paypal ourselves.
[+] [-] qeorge|12 years ago|reply
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.
[+] [-] singer|12 years ago|reply
[+] [-] uladzislau|12 years ago|reply
[+] [-] mpclark|12 years ago|reply
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.
[+] [-] nclx|12 years ago|reply
Totally agree with this!
[+] [-] singer|12 years ago|reply
[+] [-] bhouston|12 years ago|reply
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?
[+] [-] singer|12 years ago|reply
[+] [-] jusben1369|12 years ago|reply
(Congrats Mike and sorry to chime in on your thread)
[+] [-] owenversteeg|12 years ago|reply
- 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.
[+] [-] singer|12 years ago|reply
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.
[+] [-] stickhandle|12 years ago|reply
[+] [-] callmeed|12 years ago|reply
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.
[+] [-] singer|12 years ago|reply
[+] [-] lingben|12 years ago|reply
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
:/
[+] [-] notwhyships|12 years ago|reply
[+] [-] singer|12 years ago|reply
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.
[+] [-] gotrythis|12 years ago|reply
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?
Thanks!
[+] [-] singer|12 years ago|reply
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.
[+] [-] ktrgardiner|12 years ago|reply
Found an error: My login date under sessions is "Sat, Dec 30, 1899 @"
Feature request: product variants ie. shirt sizes, phone types, colors, etc.
[+] [-] singer|12 years ago|reply
[+] [-] mperham|12 years ago|reply
[+] [-] singer|12 years ago|reply
[+] [-] uladzislau|12 years ago|reply
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?
[+] [-] singer|12 years ago|reply
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.
[+] [-] eriktrautman|12 years ago|reply
[+] [-] singer|12 years ago|reply
[+] [-] quaffapint|12 years ago|reply
[+] [-] singer|12 years ago|reply
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 :)
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] patja|12 years ago|reply
[+] [-] singer|12 years ago|reply
[+] [-] eliteraspberrie|12 years ago|reply
[+] [-] Dwolb|12 years ago|reply
My friend could use this because her 'digital storefront' is literally Facebook and there's no way for her to sell things.
[+] [-] singer|12 years ago|reply