CHRISTINA MOORE

historical perspective of computer technology

05 – PayPal

by

Listen to Podcast on Your Favorite Service

Transcript

Not only did I hold the wrong position, I adhered to it for six months. We knew from the first minutes of working with PayPal they eased themselves comfortably into a legacy position, as rusty as Western Union. Once upon a time, PayPal forged ahead. They guided a granite-build industry into a more fluid digital one. The pedantic amongst us eschew the definition of PayPal as a bank. But they are right, or close enough.

Podcast Flow identified the following needs. First, a means of capturing payment for subscriptions to our software. Second, a smooth interface for a digital connector. Third, a trusted household name. Fourth, a partner for sharing the challenges of regulatory compliance

For the best part of two decades, PayPal stood as the touchstone for digital commerce. And with a long association with Elon Musk, the guy who tossed a Tesla into space, it seemed the appropriate means of managing our financial front end and integrating into our registration process. With the pomp of an executive in the 1980s, I adorned myself with the attitude: “You don’t get fired for buying IBM,” or PayPal in this case. Oopsy.

This integration balances on a three-part scale with trust in the second pan and regulatory compliance in the third pan. I’ll examine them in reverse order.

Mugshot

In my younger days, I occasionally feared wearing a cop car on my cheek. If this happened, I likely wore handcuffs on my wrists. Never happened, never even close, in case you wondered. These fears serve a purpose. For you, the viral mugshot that spikes your blood with fear serves as a deterrent.

Weekly, an IT firm’s name makes the news for a breach or mistake that costs people their security. That pop in the news triggers fears likened to handcuffs and a mug shot. My frustration with IT security breaches stems the patterns of victimization.

The IT firm that undergoes a security breach passes the victimization on to their customers. The bad actors steal from the corporation, in the most common narrative. The bad actors committed a crime. The corporation breached their duty. Yet, it is the consumer who feels robbed.

Normal human beings with credit card debt and housing expenses that are too high: these people suffer at the hands of corporate mistakes. Every year dozens of corporations make mistakes with data that harm people.

If I were to pontificate, I’d lament two matters.

First, justice skips the middleman in the credit card and identity theft crime. The middleman faces public shaming, and a possible fine. Justice rarely gets the thief. The victim stands numbly with financial identity tittering.

The second matter involves the architecture of the retail purchase process.

Let’s study the architecture of the retail purchase process. Competing forces confound the solution. The credit card once upon a time substituted for cash as a convenience. Carrying cash can be risky, though I do know a rich fellow in Puerto Rico who walked the streets with $500,000 in a backpack. His armed security detail abandoned him at the bank because it took so long to count the twenty-dollar bills. Bored or thinking they lost track of him, they drove back to his house without him.

A secure transaction involves multiple steps related to confirming identity and authorization. Are you really you? That defines authentication. This takes a lot of steps and effort – and can be fooled.

Not everyone wants a secure transaction. Anonymity is impossible with strict authentication. If you want a package in a plain-brown wrapper, you’ll need cash and a face-to-face transaction. With perfect security around a purchase, you’ve yielded all privacy.

Between these extremes sits the entire economy, from buying fuel at a pump to subscription-based software that supports your growing business.

Turn the knob too far one way, then procurement becomes cumbersome and secure. Turn the knob the other way, we enable identity and credit theft.

I should not tell either of the two following stories. They illustrate these challenges, and they are true.

I arrived in San Juan Puerto Rico on the first day of October 2017, about 10 days after Hurricane Maria cleared the island. I flew on one of the first commercial jets carrying passengers to San Juan. In first class with me was a famous actor from the island and his brother, a surgeon living in New York City. We came in low down the length of the north side of the island. My fellow travelers wept surveying the damage below us.

At work the next day, my chair rested at plastic folding table on the third floor of the Puerto Rico Convention Center. We were in the center of the room because we represented the governor and the government of Puerto Rico. Ricky, the then governor, had a private office in a meeting room nearby. As U.S. federal agencies poured in, security ticked up a bit. Everyone had to have a badge. The guards at the doors dressed in full battle kit with M-4 rifles and sidearms. The government of Puerto Rico was exceedingly slow to make badges – and at paying us; that’s a different story. The Puerto Rico badge making machine was chronically broken – or as I learned, without a knowledgeable operator.

I never got hassled. I wore the uniform-of-the-day: khaki military-style trousers called BDUs and a dark polo shirt with an embroidered logo. I wore the same or similar at Cisco System when I embedded with the military. I wore something very similar when in Iraq for a year – similar trousers from the same company.

I also wore my U.S. Army badge holder. I got it back in 2002 with I got my military ID. It is black nylon with a clear front for an ID. US Army logo show prominently. In this badge holder I put my U.S. passport card.

A U.S. Passport card is an optional credential for limited border crossings, yet very official looking. Let’s be clear, any U.S. Citizen can buy one for $40 from the U.S. State Department. While it accurately identifies me as me, it says nothing about whether I am authorized to be in the convention center.

The guards, most of whom worked for Hacienda (the PR financial agency), saw the red, white and blue, the UNITED STATES OF AMERICA with a very official photo. On through I went.

The Convention Center lacked any means of knowing good-guy from bad-guy, but they guarded it with weapons and flak jackets. I did, eventually, get a Puerto Rico government issued ID card authorizing my access to the facility.

By that time, FEMA started asserting itself. FEMA calls any facility that they share with a state, or territorial, government a “joint” facility. It’s a phony label. They tell their hosts what the rules are then demand their host follow them.

Now we all needed FEMA ID cards to gain access to the joint facility.

This is early 2018 and we’d move to a new location en masse. Getting a FEMA ID required just paperwork and more paperwork plus U.S. citizenship and a cleanish criminal record.

In the spring of 2018, I got yet another federal identification card, this one issued by the Department of Homeland Security and FEMA. The U.S. Department of Defense issued my last such card. Like the DOD card, it holds a digital memory chip. It identifies me as me on a computer system and when entering facilities. It holds my fingerprints. The card can be inserted into a reader to confirm the identification card has not be revoked.

And for me to use it, I need to call to mind the six-digit personal identification number. Long gone from my memory. As a non-federal person, we don’t use the ID card to log into computer systems.

The number faded from my memory the day they fingerprinted me.  Of course, I did not write it down. The only way available to me to fix this now involves me driving for hours to a major city then supplicating myself on a security office floor.

Ergo, useless! Fingerprints, security certificates, photograph, a brief digital biography, all useless because I can’t recall a six-digit number I gave to someone in a noisy security office in San Juan, Puerto Rico.

This episode echoes a problem from 2005 when training at Fort Hood in Texas. I took all sorts of classes while preparing for a one-year deployment to Iraq. Courses such as “advancing against direct fire”, “advancing against indirect fire”, and sessions on convoy protocols. I took quizzes on the difference between “concealment” and “cover”. Instructions included what to do when captured. No, I did not take the fancy course dealing with evasion from capture and interrogation, called SERE. I had a half-day or shorter thing. I forgot it all, immediately.

During the session, we were each videotaped and I picked my personal distress word. Forgot that too. If in trouble, my phrase indicated I was either: me, or fine, or in distress. All foolish. There I’ll be: bound in front of the enemy’s flag. My phrase informs the Army that I was either under duress, or not under duress. I am on an enemy video; the answer should be obvious. Washed out of my brain as quickly as the FEMA identification number.

Authenticating I am me; you are you – is an interesting challenge. A poor memory, or contempt of process, corrupts expensive government ID cards. I’ve illustrated how that fails. In this second example, I examine sincere effort to buy mobile phones in the aftermath of a catastrophic natural disaster.

The mobile phone bill following my first month in Puerto Rico was $2,500. My carrier informed me that I was roaming internationally.

We needed mobile phones that worked and were reasonably priced for operations in Puerto Rico. We lived in a hotel with the AT&T crew who rebuilt big chunks of that infrastructure. Sadly, no one could buy an AT&T phone on the island, or toothpaste. I arrived in San Juan the day after AT&T distributed free phones to many of my peers. Starting in March 2018, I tried to buy a handful of phones with my corporate American Express card. And failed.

Try number one: buy phones and ship them. Shipping reliability was so low, AT&T would not do that. Furthermore, I needed to be present to prove I was me.

Try number two: buy phones and have someone else pick them up. Three weeks of effort, and that failed. The person picking up the phone had to be me.

Try number three failed immediately. If a staff member buys phones, the accounts become attached to their social security number, their financial history, and requires AT&T to do a credit check on that staff member.

AT&T requires more paperwork and authentication than it takes to buy either a house or a car. I have bought both remotely with digital paper exchange, but not a mobile phone from AT&T.

Try number four: after flying to New England from San Juan, I walked into the first AT&T store I found. I bought five phones. Tired, grouchy, and a bit mean, I demonstrated a lack of patience and a fair dose of arrogance. No, don’t set them up. No, just give me the damn boxes and recognize that this is a simple transactional deal. I give you money, you give me a box with a phone in it and a service contract.

To my complete misery, we have two AT&T accounts. One for me personally. One for the corporation. AT&T can only authenticate me by texting crap to my phone. At my home office in rural Vermont, the AT&T phone does not work except via Wifi. I can’t do squat with AT&T. I can’t consolidate the accounts. If I want service, I must drive to Hatfield, Massachusetts, an hour away, to sit in a storefront. I can’t even log into their website because their authentication process is stricter than my technology and location will tolerate.

As a result, we will close our AT&T accounts and walk away from them (or run).

That’s the impact of tight authentication and strict rules during procurement. Too tight and it will result in the loss of business and complete frustration from customers. Too lose then customers face risks with theft.

It is difficult to get the security knob set to the right tick on the dial.

Let’s return to PayPal, the central player in this story.

Don’t Collect Their Data

The simplest solution to avoiding the proverbial mug shot involves never collecting data the bad guys want. John and I strive to create a system that meets good security practices, similar to those used by the military and financial service firms.

We acknowledge the risks and face the problem with humility. Who is best suited to safeguard the customer’s financial and personal data? Us or a firm dedicated to that process? Are John and I better than American Express, PayPal, or Visa? We’re not.

We are professionals in our realm and that includes securing data. But capturing, holding, managing, storing personal financial data sits in an adjacent specialty. We’ll not do that.

We won’t ever know your mother’s maiden name, nor your birthdate.

That means we depend on a trusted partner whom others will trust too.

PayPal’s logo appears ubiquitously on websites through the lands of internet commerce.

PayPal buys that liability from us while taking a financial slice of every transaction, nearly four percent.

Digital Connector

The architecture of an internet machine places the cogs, axles, and sprockets within the matrix of the internet. The concept of machine has abstracted as the materials, media, and methods of computing change, but it still a machine. We do not immediately recognize a mobile phone as a machine. That’s your fault, not the computer’s. A mobile phone remains a computer, at the core a CPU, memory, and a human interface. 

The terms “engine” and “machine” always obscured the complexity of technology – and yes, they once always included moving parts.

The architecture of internet-based software, cloud software, replaces cogs with digital connectors sharing data at light speed within the Center of the Internet (The Cloud). I witnessed an evolutionary process. Modern software now also employs the internet as a backbone to exchange data.

Our machine, Podcast-Flow, presents itself as a node on the global network, connected.

To link our software to PayPal, we write a digital connector. PayPal provides details, definitions, and examples for us. They also provide a sandbox to play with. The early technical steps require we inventory the tasks our machine does – what buttons we need to put on this internet machine of ours.

Let’s go through that for Podcast-Flow…

We sell subscriptions. Therefore, we need to exchange subscription data. We’ll need to get some details that confirm payment, customer’s name, and an email address. We’ll need to provide people the ability to cancel a subscription. Each exchange of data requires us to write code.

We write in Oracle’s PL/SQL. The data exchange is made via the hypertext transfer protocol (HTTP). The data travels in the JSON format – JavaScript Object Notation – squiggle brackets, text, colons, commas, and a few square brackets.

Our technical team names the programs descriptively such as: “subscription get”, and “product get”. The language of moving data to and fro became get, push, post, patch, and delete. We push data to the other side. We get data from them. When we push data, we send a payload formatted in the proscribed format. Our program that gets subscription data is 50 lines long, less than 2000 characters. A fast typist is done in 30 minutes. A good programmer, likely done in 10 minutes or less because she would copy then paste from something similar.

Not That Simple

The team dug into the documentation from PayPal working through the primary steps. We quickly discovered that their online documentation contained errors and inconsistency. We spent hours and days reconciling their documentation with code that worked. The process resulted in frustration and anger. Additionally, working through their errors cost us money. We paid wages for our staff wasting time un-messing PayPal stuff.

After days and weeks of frustration, we identified a big black hole in the process. I failed, we failed to see that PayPal does not offer ability to list all subscriptions. The only way to get subscription data is to give PayPal the subscription ID that PayPal assigns. Thereby creating a Catch-22 situation. We can’t get subscription data, including the subscription ID without the subscription ID.

The only way for us to get the subscription ID requires that we use their tiny, old-looking payment window.

When we use their ugly, tiny, old-looking payment window, we can offer no variation to the pricing. We cannot easily do bundles or add-ons or discounts or coupons. At the end of the process, PayPal flashes a hidden message containing the subscription ID for us to grab. We must fetch it then or we sink into muddy mess of manual research.

The second option then involves us capturing the name, address, credit card information, expiry date, etc. on our system. We format the data before sending to PayPal.

Oops, if we collect it, we own the liability for safeguarding those data. Not part of the deal, PayPal. We pay you as much as 4% of every transaction for the management of financial compliance but on step one, we violate the rules. Not going to happen, PayPal. No thank you please.

The process unraveled in December of 2019 when we learned from our accounting staff that we must collect sales tax in the United States. That broke PayPal.

In June of 2018, the United States Supreme Court issued its ruling in “South Dakota v. Wayfair”. This changed the digital commerce process forever. 18 months later, PayPal remained non-compliant.

There slips PayPal into history. Bye, Bye, PayPal. You’re now a faded sticker in a store window.

We need a partner who aids with authentication of customer, securely executing the financial transaction, while giving us the ability to focus on the complexities of our business.

Time to find a new solution and write an entirely new digital connector.