Hashr.io

Dead simple, free & secure hashing API.

No Employees
Founders Code
Solo Founder
APIs
Programming
Utilities

Weekend project challenge. Simple API. Simple Pricing. Site built in one single weekend. SaaS structure built on the second weekend.

January 15, 2020 Help: Payment Flow + VAT + Price Display (EU corp)

Heads up: this will be a rather long post. And I am looking for your honest feedback, suggestions and experience.

I have had to delay Hashr.io for the second time now, due to unresolved, missing or wrong payment flows. To be honest, I am sick and tired of this regulatory BS that is put on EU companies for SaaS business models.

What I want to achieve:

  • User visits the pricing page
  • User sees the price
  • User clicks on the button of the plan he wants
  • User steps through onboarding and payment
  • User receives invoice according to his/her chosen plan

What hinders me right now

  1. Regulation states: I need to show prices including VAT. This is no real biggie, but not complying could lead to hefty fines. I see other sites (from within the EU and the same country as me) just showing prices excluding VAT with an asterisk that states: "excluding EU VAT". Not quite sure why they do this and they just cope with the occasional fine by some random other company suing them? Right now, I show my prices including VAT and just substract the added VAT if the buyer is from a non-VAT country or a B2B customer from another EU country. This seems the most sensible approach, but could lead to prices being actually higher for B2C customers in EU countries with a higher VAT rate than mine.

How would you tackle this issue? From a conversion perspective and from a legal perspective?

  1. While onboarding my users I do ask where they are located. Based on that, I add another field to the onboarding form and ask for a VAT ID. If empty (B2C user) or non-valid (fakers), I charge my country's VAT rate. If valid (and from a EU VAT country) I charge 0% VAT (reverse charge).

MY COUNTRY == USER COUNTRY => 19% VAT
MY COUNTRY == EU COUNTRY => VALID VAT => 0% VAT (REVERSE CHARGE)
MY COUNTRY == EU COUNTRY => INVALID VAT => 19% VAT (MY COUNTRY'S VAT)
MY COUNTRY == NON-EU COUNTRY => NO VAT

Not quite sure about this though, references online state, that I actually have to charge my user's EU country's VAT rate instead of my country's VAT rate.

So Luxembourg 17%, Sweden 25%, Germany 19%, and so on. Some other SaaS players don't do this. At least I think they don't. I can't valide that.

Would love some more insight into this. How do you do it?

  1. It's tempting to just use a prepackaged payment provider to do this and just go for it, lean startup style. I have found none doing it right for EU SaaS businesses or they could theoretically do it with lots of API magic and coding on your end to be able to do it. Their main USP is gone, since implementing your own logic to Paddle, Chargebee or the many others isn't exactly faster or cheaper than just implementing the core Stripe API yourself.

So I have Chargebee a good hard look, and found that doing what a EU business needs to do to actually use them legally, it would be far simpler to integrate Stripe itself. And that even saves my roughly 300$/month plus an additional 0.6% on top of what Stripe charges. I fail to see a reason why to implement them and be locked-in for no additional benefit?

Please enlighten me here. Maybe I am missing some very essential thing here... ?

  1. If I go the the route of implementing the core Stripe API, what do I absolute need to make sure to save/get/document to comply with the VAT rules within the EU? After all "I ask my users where they are from". If I have to charge VAT based on their country (which maybe higher than the one my business is from), what would prevent a user to just Google a valid VAT ID (from any EU business Imprint page) and just use that to validate for 0% reverse charge? Would I be responsible for such a criminal act? There is no way for me to validate if used VAT ID REALLY BELONGS to the user or not.

It's a complete mess or I fail to understand it or I am missing something essential here. What is your take on this? How would you solve this?

  1. Regulation states I need to show prices in EURO. Well fuck. I want to show prices in US DOLLARS. The world uses USD, and I want to show and charge in US Dollars. Do you just use USD, charge in USD dollars and write on the Invoices the corresponding Euro values? What happens if conversion rates change? Do your users get different Euro values on each invoice? Do you charge in Euro instead and charge the same flat Euro value at time of onboarding? Or do you charge Euro values corresponding to the USD value at the time of charge?

Thanks, rant out.

December 25, 2019 Soft Launch (IndieHackers only!). Please Feedback!

So, I basically finished just now. A couple hours late to the Christmas Launch Deadline, but anyway.

It's .htaccess protected for now, because it's still not quite ready for prime time yet.

Design, functionally and overall site are ready though, and i would love your feedback on it.

https://hashr.io
Username: ih2020
Password: letmein

EDIT: Needs some additional work. Will have to revoke access to Hashr.io for now. Another 24-48 hours and I’ll regrant access. Better safe than sorry! Mea maxima culpa!

December 22, 2019 Subscription Naming Struggle

Reposting this due to timezone difference ;(

I am setting up Hashr.io's subscription plans at Stripe, and am struggling with how to name it. It's essentially just a single subscription plan for when you want some additional extras not available with our free API.

What you get with a paid plan:

  • Full history of all hashes made with timestamps
  • 10 Hashes/Second (free API gives 1 Hash/Second)
  • Add custom Salts (and Peppers)
  • Multi-Hashing: Double, Triple and Quadruple Hashing (counts as one hash)
  • Mix & Match of different Hashing Algorithms for Multi-Hashing

I am planning to price this on the ultra-cheap side. Let's say for now about 2-4 $/month, or 19-39 $/year.

How should I call this account plan? Usually I go for "Starter/Startup, Pro, Enterprise", but since I only have one single plan for Hashr.io I am kind of lost right now.

What I came up with already:

Currently I settled with Hashr.io Pro, but don't really fancy it very much.

Anyone have any ideas? All of the above don't really click with me... ;(

December 21, 2019 Subscription Product Name struggle

I am setting up Hashr.io's subscription plans at Stripe, and am struggling with how to name it. It's essentially just a single subscription plan for when you want some additional extras not available with our free API.

What you get with a paid plan:

  • Full history of all hashes made with timestamps
  • 10 Hashes/Second (free API gives 1 Hash/Second)
  • Add custom Salts (and Peppers)
  • Multi-Hashing: Double, Triple and Quadruple Hashing (counts as one hash)
  • Mix & Match of different Hashing Algorithms for Multi-Hashing

I am planning to price this on the ultra-cheap side. Let's say for now about 2-4 $/month, or 19-39 $/year.

How should I call this account plan? Usually I go for "Starter/Startup, Pro, Enterprise", but since I only have one single plan for Hashr.io I am kind of lost right now.

What I came up with already:

Anyone have any ideas? All of the above don't really click with me... ;(

December 19, 2019 Status Hashr.io

Sneak peek

https://imgur.com/SigKpKw

Finished

✅ Domain purchase completed

✅ Hosting setup completed (3core, 8gb, 256gb NVMe, 2x GTX Titan, fully autoscaling to up to 4 additional same-spec machines) -> omfg, this is expensive!

✅ SSL completed

✅ Hash API completed

✅ Verification API completed (for Argon2, BCRYPT, etc.)

✅ Output in JSON and JSONP completed

✅ API documentation completed

✅ Legal content completed (Legal notice, privacy policy, cookie notice)

✅ Stresstest completed (it can handle about a gazillion hashes per second ;) )

✅ MailChimp newsletter setup completed

Unfinished

🔳 Output in XML and plain dump

🔳 Developer kit with composer

🔳 Pre-hashed verification API

SaaS specific unfinished

🔳 Login area

🔳 User specific salts/peppers

🔳 User hashing history

🔳 Payment model

🔳 Stripe integration

Finalization

🔳 Launch

For this project, I will deliberately not have any form of tracking in place due to the sensitive material that could be hashed. So no Google Analytics, Remarketing tags, GTM, Facebook Pixels, etc. Not even server logs! The only measurement being tracked is revenue in form of subscribed accounts and the total amount of hashes/verifications being made on the Hashr.io platform as a number. That's it.

About

Weekend project challenge. Simple API. Simple Pricing. Site built in one single weekend. SaaS structure built on the second weekend.