Sonar allows customers to communicate with companies on more effective channels. From SMS to WeChat, our vision is to allow customers to reach companies on the channels they are use to, not forced to use old-school channels like email and phone calls. We're growing very quickly and our customers love us. Come change customer communication with us.
Multiple Roles ---
- Customer Success Lead (Content writing, onboarding, account management, SEO, email marketing etc)
- Sales Lead (Help us define our sales process and close the many inbound leads we have)
Thanks for the comment. We believe the potential for abuse on SMS is the same as any channel.
If a crook spoofed a phone number (pretending to be a company), the customer would still need to initiate the order. Meaning, if they received a text out of the blue from a company saying "thanks for ordering pizza now put your credit card in" without having actually asked for pizza, it would be quite weird for them to put their CC info in.
If a user's phone was lost/stolen, there's a chance someone could text in an order and at that point it is up to the company to do things like verifying information for orders over a certain price point (along with other security hurdles).
As for unsolicited messages, it is illegal for a company to do that (it still happens, I get spam phone calls on a daily basis) and we give an easy way to opt-out (simply reply back any of our unsubscribe keywords like "stop") and they wont' be able to message you anymore through Sonar.
Hope that helps! Would love to hear your thoughts.
Exactly...unnecessary statement and makes the writer look amateur. There are plenty of great accelerators out there that aren't YC. Sure, YC is the "Harvard of Accelerators" but there are plenty of other great colleges out there with successful alumni.
The $500/month short codes were for unique. That is the actual CSCA pricing. When I do mobile banking projects, we typically pay that directly to CSCA and then we pay our SMS Gateway provider (commonly used Syniverse in the past) separately for usage.
I'm a pretty risk-averse person and I can't imagine in any way the FCC cracking down on the use of long codes for legitimate two way communication with an existing customer. On the other hand, using long codes for mass marketing campaigns and you'll probably be shut down by the carriers and possibly sued, no FCC action required.
I don't know how they're doing payments exactly but if I had to guess they are recording a customer's credit card info to stripe and associate to a phone number somewhere.
Since Magic says you need to send them your credit card and address info the first time you use their service, my guess is that they would have to record that info so next time you text message, they just look up your credit card by your phone number (probably not in stripe, most likely in a separate database they keep). They can associate your stripe customer id with your phone number so they don't have to store raw credit card numbers (let stripe handle that!).
I would think existing businesses would already have a payment processing relationship in place and so the challenge would be hooking it up to many of those choices (if they didn't have one then Stripe is a good default) The question is how is that card data getting from the text message into the payment processor in a PCI compliant manner? Once they get it from their SMS app into Stripe then Stripe will give them a token and they can map the token and phone number for future charges. But I wonder how it gets there in the first place. Again, due to PCI compliance, I expect the Magic guys are never seeing the actual card numbers. So they must be paying for services on their own cards and charging your card against their Stripe account. So there's some double CC processing fees happening and chargeback exposure. I suspect though the Magic guys just hacked this together (in a great way) and given the interest I hope they can raise and solve for some of the unscalable parts like this.