Here at Pay Theory, our entire company ethos is based on inclusivity and helping usher the roughly 30 percent of families in the US who are un- or underbanked get onboarded to digital payment platforms and alleviate stress when it comes time to pay for school-related payments such as proms or AP tests. 

For all parties involved, whether families, schools, or school districts, the Pay Theory platform brings a new level of security and convenience. The tool allows for a cashless school environment that’s welcoming to students of all socioeconomic backgrounds and circumstances. But during a recent conversation with Aron Price, our lead developer, I learned our inclusive roots run in the very fabric of our tech. 

The Pay Theory platform runs on the WebSockets protocol, a programming method that allows for two-way communication between servers and clients, making for a more seamless connection with our users. It sounds good, to be sure. But how does it  bring our platform to that many more users? It means that we’re built to run on varying speeds of Web connections. Whether tethering off a feature phone or using the latest in wireless, our WebSockets backbone aids in user connectivity on many levels. 

Read on in our conversation with Aron to learn more about WebSockets can be more than a protocol: It’s a way to leverage software and programming to do social good. What’s more: We’re the only payment platform to use this technology, meaning our tech stack is adaptable to help transactions happen across an array of Internet speeds. 

For the uninitiated: What exactly is WebSockets?

WebSockets are related to, but not exactly the same as, HTTP. It’s a slightly different protocol that piggybacks on HTTP to generate a different type of connection from an HTTP session. WebSockets changes it to a longer continuous session so that you can avoid the initial handshake and certificate validation. 

Gotcha. So how exactly is Pay Theory using WebSockets, and how does this tool play into helping provide for equity in reaching underserved communities?

We feel that there’s a large portion of the population that is underserved by the digital payments segment. People who have banking issues such as poor credit — if they even have bank accounts at all — are often the same customers who have weak Internet connections. 

They might not be able to afford at-home Internet installation or in the case of the underbanked, might have difficulties setting up the account in the first place. Their Internet connections might be via older phones or pay-as-you-go platforms, which might tap out on monthly bandwidth extremely quickly when a family of four needs to tether to get school and work done for the day. 

With all of these points considered, we wanted to try and make sure that our payment system was usable by people who are working with less capable technology.

In terms of the technology itself, we’re using WebSockets inside of our payments software development kit so that we can proxy all of the different API calls that have to happen for a payment to take place. 

At least three or four have to happen —sometimes as much as seven. That can introduce a lot of problems, especially on a connection with high latency; that is one that suffers from long delays. 

Because these are not cacheable API calls, it has to actually run against the server, so you can’t pull it off a content delivery network. 

But when we pass them through WebSockets, since we don’t have to do the handshake over and over again for each call, we’re able to see a great performance improvement on high-latency connections. 

Instead, we at Pay Theory run the calls from both our server and Amazon’s cloud, which has very good and very fast network connections. You’ll find that tools such as Google Drive and Google Classroom do leverage these technologies. It’s just not something that’s typically been used in the payment space.

In all, as Pay Theory’s lead developer, I think that WebSockets is a great way to help serve a community that’s underserved right now and at the same time, potentially increase revenue for school districts by streamlining payments and helping to bring that family segment online to payments platforms. 

How does WebSockets impact security safety and privacy? 

WebSockets lets us track the interaction with our inputs and our software development kit much more closely. Before, Web pages like this would require a lot of API calls, which impacts performance. But with WebSockets, we can just throw in the data. The system will pop it into the database independent of the performance of the client application; i.e. the program that’s running in your browser. We’re able to send real-time information about our inputs and the spacing between the characters. That information will help us to build artificial intelligence models to help us do fraud detection. 

You can do that stuff with HTTP — and people do — but a lot of that’s actually being blocked right now in attempts to prevent tracking. WebSockets helps us get around any of those kinds of blocks as well. 

Additionally, we’re using a process where each step can only happen once with the initial token that’s generated when you start a payment session. At each interaction with the socket, it knows the given step of the payment based off of the call made to the socket, as well as when and if it’s appropriate to use the token.

Pay Theory’s payments processing partner, Finix, also believes our use of Websockets is unique and beneficial to customers. Using Websockets alongside Finix’s gateway to enhance transaction flow increases the speed of tokenization, boosting overall ease of operation. 

“Their Websockets connectivity approach is progressive. It enhances user flow and the overall experience,” says Kenny Horn, Sales Engineer at Finix.

We’re also able to add rate limiting to the API, so if we detect activity that looks suspicious, we can prevent a lot of subsequent requests. At the same time, we are helping our partners to provide this kind of fraud detection for their clients and their merchants. 

How can WebSockets be a tool for inclusivity across cities, socioeconomic classes, and regions? How can that help reach rural areas as well as maybe urban, suburban families that might not have access to or be able to afford reliable Internet? 

We’ve been doing throttling on our Internet connections. Following these tests, we’ve seen performance improvements in a single payment for up to eight seconds. And when you see a delay of multiple seconds on something you’re trying to do on the Internet — especially when you start pushing past five seconds — you’re going to have a concern that it’s not working. 

The process could make your payment process not viable at all. With Websockets we make it happen just as fast as if you were on a connection on a cable modem. That’s because we’re running all of that through our server instead of through your browser.

Recently, there’s been a big push in web design to have dynamic clients, rather than static Web pages. They sometimes call it the “JAMstack”: React and Angular work this way. Basically, this consists of running an application in your browser, which in turn are powered using the APIs. That introduces a lot of the same kind of congestion that we’re seeing in our processing of payments.

There’s a lot of space to improve the user experience in rural areas and places where people are limited by their Internet bandwidth. In some places where it’s happening today, I think some of the GraphQL stuff, such as improving WebSockets’ library, is happening specifically because of these kinds of benefits. Overall however, I think it’s not really caught on quite yet. Sometimes these things take a few years to really get into their groove.

Coinsmart. Beste Bitcoin-Börse in Europa
Source: https://hackernoon.com/websockets-plugging-more-people-into-payments-xkp35hi?source=rss