Deep Dive
Of late, this blog and its sister publications on Medium have been feeling a little neglected. Where I used to try to write a long form post every day, my output had tapered off to a sporadic post here and there.
The reason for this is that I have been on a hacking tear which was a long time coming. Since last September (2017), I had let my coding chops rust because I felt burnt out. I quit my job, relocated back home, and used my computer for ...not coding.
All this came to a head some time around the middle of May when certain life events forced me to take a break from blogging and writing. I had had every intention of continuing to write during that time but I just couldn't find the energy.
So, instead of write blog, I wrote code. This is a rundown of all the stuff I learnt in the past 3 weeks.
Problem Statement
India has very high levels of cellphone penetration but the outcome is that (a) everyone has multiple cellphone numbers (b) actually getting through to someone is a hit or a miss.
My first thought was to try and solve this problem.
Telephony
Since, in my head, telephony means Twilio, I turned to first to the reigning champion of cloud based telephony. I discovered that alas, Twilio doesn't sell Indian mobile numbers. So I shelved Twilio and turned to Plivo which promised to sell Indian numbers but for a hefty $45/month price. Before you rush off to join Plivo, know that while it claims to sell Indian numbers, their site does not actually return any results when you filter by India.
Anyway, since they were giving me $5 credit - without requiring a credit card (!) - just to play around, I created a Plivo account and quickly verified my two personal Indian mobile numbers in their sandbox.
This allowed me to call and message one sandbox number from the other through Plivo. It didn't hurt that Plivo's per minute call rates are less than Twilio's. Their SMS rates are higher but I didn't really care abour SMS since my use case was mostly voice focused. Later, I'll have more to share on Plivo's published rates.
Once validated, it proved painless and straightforward to call one number from another using cURL. One handy feature (bug?) in Plivo is that you can impersonate any number you want as the outbound caller ID. I have only tested this in the sandbox. I'm not sure if trying to spoof someone's caller. ID in a live account is going to work or not.
Plivo also officially allows bulk calls where you can queue up a set of numbers to ring simultaneously. As soon as one number is picked up, the rest are dropped. This feature is easily implemented but needs your Plivo account manager to turn on a "ALlow Bulk Calls" flag in your account. After this, tech support has to do some work to allow bulk calls from your account. As of this writing, it's been 3-4 business days since my account manager enabled "Bulk Calls" on my account and tech support said he'd put a ticket in for it but I haven't yet been notified that the feature is now live.
Here's the catch - Plivo's official rate for outbound calls is 3.2c/minute but they want your calls, on average, to last at least 90 seconds. If your completed calls don't last 90 seconds on average over one month, they will impose a 1.2c surcharge on all the calls below the average. They also have a upper bound of 20% on the call abandonment rate percentage. An abandoned call is one where a call made through Plivo never gets completed. Every abandoned call above the 20% threshold costs your 1c. Twilio doesn't have such rules in their Fair Use Policy.
AWS
The next area which I dove into in the past 3 week was AWS. I was a little scared of getting back into AWS because in 2014-15 (I think), I had signed up for AWS on what I thought was their Free Tier but ended up paying upwards of $60-70/month for a few months because I ended that experiment. Back then, the number of choices in the AWS console seemed overwhelming.
Yet, after hearing so much buzz about Lambda functions and serverless, I decided to integrate AWS with Plivo.
I'm happy to report that this time, my experience was much better. I think I have a better handle on what behaviors on AWS cost me money and what dont. E.g., running anything other than a t2.micro EC2 instance costs money. Shoving things into S3 costs money but it's not a lot.
This time around, I learnt how
- to create a static website using S3,
- serve the site over https using CloudFront
- POST forms to API gateway
- which passes along the form-data using Lambda Proxy integration to my Lambda functions
- upload and sync my S3 bucket using the aws-cli
- implement server side access control to prevent randoms from calling my API gateway
- create IAM users with fine grained permissions on Lambda functions (Zapier)
- read CloudWatch logs
- manage async/await calls in Nodejs 8.10 runtime
- I also learnt the limits of t2.micro while trying to implement a Ghost blog on AWS using the AWS Marketplace (Bitnami). This is where I learnt the difference between free tier EC2 and paid EC2 instances.
If I gained nothing else from these 3 weeks, I gained a deeper appreciation of AWS. I like so many aspects of it that I have asked this kid I am mentoring to start getting his hands dirty with AWS instead of doing assignments on his laptop. I feel confident that if he gets stuck somewhere, I will be able to help him get unblocked.
My next goal with AWS is to get my this and other blogs off Linode on to a stable t2.medim instance - costs be damned.
Payment Gateways
These 3 weeks also exposed me to a series of payment gateways and options.
As some of you may know, I have a US LLC and I want to start using it to process payments. For this, my first order of business was to get a US bank account created.
Transferwise Borderless Accounts
I had been trawling Quora on the subject of creating a US bank account while being physically outside the US when I heard mention of Transferwise Borderless Accounts. Since I had had a positive experience working with the company in 2016, I decided to explore Borderless Accounts with TW. My initial reading of their documentation led me to assume that I had found a solution for my US bank account travails. Unfortunately, it was too good to be true.
Transferwise's Borderless Accounts are great and work as advertised but only for GBP and EUR among the major currencies. For these two currencies, you get local bank accounts in the UK and somewhere in Europe which you can use as-is on Stripe and Paypal if you are so inclined.
They work to an extent for AUD as well but certainly not for USD. US banking rules apparently prevent them from offering customer US borderless accounts. The silver lining is that if you want, you can accept payment in EUR or GBP and convert it to USD.
So this was a bit of a dead end from US bank perspective. The search continued.
Silicon Valley Bank
..has some crazy minimum balance. Screw than noise.
Capital One Spark
...doesn't actually let you set up the account because it ultimately asks for a US proof of address.
BVBA
I forget what BVBA stands for but it's one of those credit union type banks which supposedly offer accounts to non-US residents but ultimately didn't work for me because they asked for a mailing address in one of a handful of states like Texas and California. If you have trusted counterparties in those states, more power to you.
Fidelity
Ultimately, I opened a new bank account under my own name with Fidelity with whom I have a prior banking relationship. I am using this account as my LLCs bank account since my LLC is a "disregarded entity" anyway. Not sure about the advisability of this. Your tax advisor or CPA is the right person to discuss this with.
Stripe
I attached my LLC with EIN and my Fidelity bank account with Stripe and was all set.
Stripe Atlas
I also applied for Stripe Atlas in India to see that process through and got accepted within 1-2 days. They must be gearing up to exit private beta. Stripe Atlas in India allows you to set up a US LLC or Corp with a US bank account for a fixed upfront and a fixed yearly fee. I haven't gone through the process of creating an LLC through Stripe so I can't say how good it is.
PayUMoney
I selected PayUMoney as my Indian payment processor to accept payments from Indian customers. In India, you can act as a sole proprietor without needing extra documents or a legal structure. Of course, you want to have a separate bank account to avoid co-mingling your business income with personal income.
In this regard, an Indian sole proprietor and a "disregarded entity" LLC are basically the same.
With PayUMoney, once I verified my bank account and my identity - which took a couple of days including my website verification by a PayUMoney employee - I was ready to accept payments on my website using a PayUMoney button.
If I wanted programmatic access to create invoices, i.e. to create invoices on my own page without sending users first to PayUMoney's website to submit payment details, I would have had to submit a few more pieces of information including my Aadhar card copy for address verification and a bank account letter to let PayUMoney know that my account is in good standing with the bank.
API
The PayUMoney API broadly works but the documentation is abysmal. The only good thing is that PayUMoney tech support is very responsive to emails, tickets, and tweets.
Word to the wise - your sandbox API credentials and your live API credentials are the same. Be aware of this and avoid leaking your sandbox credentials because any smart hacker can put two and two together to use them to masquerade as you when you go live.
Word to the wise2 - PayUMoney's sandbox environment is broken. You will have to test on live with real payments. You have the option of refunds so you don't end up losing lots of money just to test the systems.
Exotel, Knowlarity, MyOperator, Reliance, PRI
My last port of call was exploring "virtual" phone number providers like Exotel and Knowlarity.
I just want to point one thing out - I don't like that Knowlarity does not mention prices anywhere on their site. The buttons are titled "Try Now" with nary a mention of how much money I can expect to spend.
On the other hand, Exotel came as a breath of fresh air. Clear pricing, easy to understand terms, smooth on-boarding and trial.
With Exotel, I was able to set up a "virtual" number and connect with with my CRM to route calls to specific numbers using their "Switch-Case" logic. The website is a little hard to grok. For instance, if you want to edit your call flow, you have to go to App Bazar - where Exotel vendors hawk their own flows - then click on "Edit Flow App". I also wasn't happy about how difficult it was to know where to look for my logs.
In the end, logs are inside Inbox (!!) but the logs aren't raw logs or text. They are English like descriptions of whatever Exotel imagines happened with the call. Here's an example:
Here is what happened:
Missed Call from 09100000000 at Sat, 02 Jun 2018 09:38:24. Customer may have cut the call The number 08vvvvvvvvv received a call from Shye(09100000000) at Sat, 02 Jun 2018 09:38:24 An HTTP Call was made on the url: https://xxxxxxxxxx.execute-api.xx-yy-5555.amazonaws.com/beta?CallSid=cccccccccc&CallFrom=09100000000&CallTo=08vvvvvvvvv&Direction=incoming&Created=Sat%2C+02+Jun+2018+09%3A38%3A24&DialCallDuration=0&StartTime=2018-06-02+09%3A38%3A24&EndTime=1970-01-01+05%3A30%3A00&CallType=call-attempt&DialWhomNumber=&flowid=ggggggg&tenantid=ggrtrrt&From=09100000000&To=08vvvvvvvvv&CurrentTime=2018-06-02+09%3A38%3A24 The call was routed to the following members of the group 'Sales' testmom momtest (09222222222), when the caller hung up before the call could be picked
I'd rather read raw files but this isn't totally unusable.
Anyway, since I couldn't use Exotel for the use case I had in mind, I went off to research call forwarding rules in India - turns out that TRAI prohibits the masking of caller IDs - and how Exotel was even able to offer virtual phone numbers in India.
Well, Exotel and others in the space have built a business and a cloud centric mythology around virtual phone numbers on the back of a very legacy, very well understood product called PRI.
PRI stands for Primary Rate Interface. Primary telcos like BSNL, Tata Teleservices, and Reliance lease ISDN lines to provides like Exotel. Each ISDN line supports a block of 100 telephone numbers and 32 channels - 30 data channels and 2 control channels. This setup is called PRI.
What Exotel and friends do is to buy PRIs from Reliance and others which lands on their data center over ISDN lines. These numbers are fed into an ePBX like Asterisk. The hundred available numbers are sold to customers as "virtual" numbers with Asterisk taking care of call routing.
Conclusion
So, in these three weeks, I didn't write a lot of blog posts but I wrote a lot of code, spoke to a lot of sales and tech support, read a lot of log files, ignored a lot of social responsibilities, and in the end, realized that while the Indian government is killing innovation in the telephony space by annointing winners, namely, the huge telcos, they are also making life a bit easier for wantrepreneurs like me to start accepting payments online.