- 163comments
- 20comments
- 38comments
- 101comments
- 59comments
- 225comments
- 128comments
- 13comments
- 10comments
- 129comments
- 189comments
- 10comments
- 602comments
- 77comments
- 11comments
- —discuss
- 24comments
- 71comments
- 8comments
- 13comments
- 171comments
- 5comments
- 18comments
- 80comments
- 81comments
- 49comments
- 224comments
- 2comments
- 63comments
- 684comments
Solution – using the SQRL protocol which was designed as a password replacement for website authentication see - https://www.grc.com/sqrl/sqrl.htm and turn it into a new secure payment system where authentication/authorizations are done on the customer’s device. Since the merchant never has access to the credit card information this will remove the merchant as a target for fraud and eliminate the need for expensive PCI compliance. For brick and mortar merchants since authorizations are performed on the customer side no internet access would be needed on the point of sales reducing monthly expense and system complexity. This system would also enable digital payments that have so far been out of reach of most for things like vending machines and laundromats that currently have high threshold to entry and being unmonitored can be easily compromised by credit card skimmers.
How does this differ from Apple Pay/Android Pay, which is already making headway in this space?
It is a similar concept but Apple Pay requires your bank to opt-in which increases the banks per transaction cost because it utilizes the Visa Token Service. This system wouldn't require the banks to opt-in you would just be adding your credit card number to your PaySQR account.
Can you provide more information about how fraud prevention would work? One specific example, a fraudster using a stolen credit card.
I think one way to prevent the use of stolen credit cards in the system is through validating the card with two small test transactions on account creation. You could also allow the linking of checking accounts as a secondary method of verification and to reduce per transaction fee's through the use ach deposits i.e put $20 in your paysqr account for vending machine use.
This seems like an interesting idea
So the user will install your app and link their credit card, and every site that uses your service will just show a QR code?
It sounds like you suffer from a pretty bad chicken-and-egg problem. A merchant would have to accept both SQRL payments and regular payments if they wanted to make money. Merchants are not in the business of pushing a preferred payment method if it means they don't get paid. Every step between a shopping cart and a payment decreases the likelihood of a successful conversion. How will you address this?
I would start by targeting under served merchants that currently don't offer the credit card option like vending, laundromats, etc. I could also see this working to give websites another way to monetize ad blocked sites with micropayments(i.e wired throws the hey stop using adblock banner or click this qrcode and give us $.25) Another benefit to the customer would be privacy since the merchant would never see their personal info this could fuel adoption,
Who would pay the fees in this system, the vendor or the customer? And what kind of fees are we looking at, ~2% like other payment processors?
I would shoot to be the lowest cost option starting with freemium to tiered monthly fee paid by the merchants. Banks are getting hammered with constant card reissues costs due to merchant compromises and along with the savings from not having to use visas tokenization(apple/android pay) which increases per transaction fees think we could score some pricing concessions from banks.
Can you talk about your team? How many people are working on this full time, what are their skill sets, how long have they been working together, and previous accomplishments and work experience?
We are not the typical startup group the 3 of us are in our mid 30's senior level information security consultants for banks and other financial institutions. While we don’t have any startup experience we all have been in IT working together for the past 15 years and implemented multiple complex payment systems used by many Fortune 500 companies.
1. Do you have any competitors? Doing something very similar?
2. There is an insane amount of startups in this space. who would be your first customers, and why them?
There are no shortage of competitors in the payments space because most are profitable very early. My first customers would probably be in the vending machine space the few companies that provide this service overcharge and require expensive cellular internet connections per machine. I believe that lowering fees, dropping internet connection requirement and possibly adding value by capturing vending inventory stats will convince a large regional vending company that we have an existing relationship with to pilot and eventually switch it's entire fleet to our system.
For what it's worth, I don't know a lot of practitioners in software security, the payments industry, or cryptography who take SQR particularly seriously.
Since getting adoption for yet another payments system is a boil-the-ocean problem at this point, if you're going to go down that road, you might want to pick a more conventional cryptosystem to do it with.
Most people in the groups you mention are not known to be early adopters of anything. SQRL is still early days and is not rolling its own encryption its just a novel implementation of and existing one EdDSA. One notable innovative payment network uses the same encryption standard is Bitcoin and to my knowledge has never been successfully compromised. The reason there are so many different payment systems out there is because they all make money from the first day even the crappy ones which most are.
Ok, then. Best of luck.
I consider EdDSA to meet the TLS 1.1 or higher requirement in PCI-DSS besides the lack of industry adoption do you see any potential problems with it?