Thinking about Payments

I’ve been doing a lot of thinking about how awkward, broken and balkanized payments are of late – I went as far as to build a few prototypes of slightly different takes…but time & money were a concern and left them alone. But a few recent things made me revisit this:

  • A few articles about the new, smaller credit-card skimmers now appearing.
  • A frustrating experience waiting for an available debit machine to pay at a restaurant
  • A frustrating experience waiting for a debit machine to dial backup lines and failing multiple times.
  • Experience setting up a Stripe account, a Square account & a Beanstream account for clients & friends.

There’s a common thread through many of these experiences which were:

  • overly dependent on potentially unknown third-parties & intermediaries
  • Handing control to an unknown person
  • slowness
  • physical machines that aren’t mine.
  • trust issues.

And so, here’s my point about payments, and where we should aim to move to (at least in the connected, western world – where my experience is. Call it my “manifesto for modern payments“, to be grandiose:

  1. Physical cards are dangerous. All hardware is on a slower upgrade cycle than software. This means that security breaches are slower to be resolved. Also, a physical card must be read by a physical device, which opens it to tampering. Physical payment mechanisms (apart from cash), should be avoided.
  2. Payment should be on my terms. The act of waiting for a machine, paying while the server hovers over you, and then handing it back is awkward and slow: It slows table turn over at restaurants, you’re touching something 100s of others have, it creates tension if around money availability, it doesn’t always work. Also, why always only pay at the end of a meal? Why not upfront? Or During? Or, even, a few hours later to make sure my decision to eat those funky-smelling oysters didn’t cause a hospital visit? Or to prevent dine-and-dashers because they’ve already “registered”
  3. I should choose who I want to pay with. Every different store uses a different merchant provider, with different hardware. None are identical. All, in my experience, are poorly designed, UI-wise (part of this is simply the numerous minor variants, which is detrimental to all the others by their “nearness”, which can lead to muscle-memory errors). We should reverse this relationship to merchant providers. I should pay via my merchant provider of choice. Paypal is already nearly an example of this – I create a Paypal account as a customer, hook it up to my personal banking info, and use it where I can. Where the problem lies is that the merchant ALSO needs a Paypal account. & this needs to change. WHO I pay with should be my choice, who you get paid by should be yours. Like your bank vs my bank.
  4. I should be able to automate this. For many things, payments are standard, predictable: I’m going to get a coffee every day. My lunch at the same restaurant is going to be similar. There should be a way for how I pay to learn what I pay, and offer to automate that as I go. So next time, I don’t even need to pull out my phone to pay. It just happens in the background – perhaps when I order, or when I leave, or batched, later on. An invisible transaction, but trackable through reporting.
  5. I should be able to geo-fence/technology-fence rules & limits. I use 1 card online. Another at “questionable” places, another is my “normal” card. But if I had a system that knew an online payment from an offline one, knew that I shop here regularly, or this place is new, that could ask for an immediate confirmation when I’m somewhere new, or suddenly travelled 2000 km in 10 minutes, or whatnot – that adds security. And this fencing should be simple, and again, personalized.

There’s likely others. I’ve spent a fair bit of time toiling away on items 1,3 & 4. Item 3 occurred to me only after I got nervous when a local convenience store got a new debit machine from a company I didn’t recognize, with a merchant provider listed in a language I didn’t read, and the payment took 3 (load) dial-attempts before it connected. & likely I haven’t thought this all through. But – here’s the thing. With current technology & connectivity, all of this is already possible. I should be able to have this right now. So where is it? Let’s build it.

Installing root Certificates for ColdFusion

This another one of those post-this-here-so-I-don’t-have-to-google-forever items.

In May of this year, Verisign introduced a new intermediate root certificate. This september, Paypal renewed their own, forcing API users to be using this new root certificate on their end for all API calls. So that’s all fine and dandy, the solution is pretty easy:

  1. Go to Verisign & download the new root certificates
  2. For me, the critical one is the ‘Class 3 Public Primary Certification Authority – G2’ – to be used with the Paypal Payflow API
  3. Install it. For installation to IIS, this is straightforward – simply click on the .cer file and follow the instructions. However, for Coldfusion, this process is a little more involved:

All of the following instructions can be found on Talkingtree.com – I’m rewriting them here for clarity and how I had to do it:

  1. Grab the newly downloaded .cer file and copy it to your {CFROOT}/runtime/jre/lib/security folder (or the equivalent location if you’re using a different JRE).
  2. Run the Keytool function to install it. Keytool exists in {CFROOT}/runtime/jre/bin, using the following path:
    keytool -import -keystore cacerts -alias {UniqueName} -file {filename.cer}
    the  Uniquename can be anything – I recommend something that references what the cert is for. The filename from above is “Class 3 Public Primary Certification Authority – G2.cer”
  3. The keytool will ask for a password. By default, in CFMX7, the password is “changeit”
  4. restart CF server

Happy connecting!

UPDATE 2009-10-23: Sarah Kelly has a great post about why doing this is important, beyond just the how, so read that too.

%d bloggers like this: