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?
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?
For physical products - is there a custom form to collect shipping & billing?
Nice work!
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.
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.
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.
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.
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.
BTW, OP this looks awesome and I'm hoping to try it out soon. didn't mean to snark.
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?
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?
(Congrats Mike and sorry to chime in on your thread)
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'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.
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.
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.
My friend could use this because her 'digital storefront' is literally Facebook and there's no way for her to sell things.
For her: take product image > apply price > put on Facebook; For user: see product image > click link to buy > purchase
Quick question, though... Do you use Stripe's Connect API for the 50 cent transaction fee you're taking (application_fee)?
I thought of using Stripe's API to remove the 50 cents right away, but that's not possible since it wouldn't work for PayPal payments.
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.
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.
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.
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!
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.
Found an error: My login date under sessions is "Sat, Dec 30, 1899 @"
Feature request: product variants ie. shirt sizes, phone types, colors, etc.
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?
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.
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 :)
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.
"Straight-forward pricing. You only pay 2.9% + 80� per sale*"
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
:/
