Standardizing transactions using Click to Pay
(Dev Talk: Click to Pay Product Development comes from an interview Royce Hall with Level 12 developer Matt Lewellyn. You can hear the full interview below.)
The point of Click to Pay (aka Secure Remote Commerce) is that it wants to standardize, in a sense, the way that all of the card brands work together, so that a single merchant application can talk to all of the card brands the same exact way without having to worry about all the differences between them.
Traditionally, if you're putting together a merchant website, and you have a shopping cart or a checkout of some kind, and you want to work with credit cards you've had to design your own system of working with MasterCard or working with Visa or American Express. And your code would have to be able to work with all of those card brands in some way or another.
The way SRC works is the merchant gets loaded up onto each card brand as a profile. And then there's a single secure remote commerce or click to pay application that sits between the merchant and the cards, and handles all of the details of the transaction.
The program will talk to each card brand as necessary or present the list of all of the cards that a consumer has registered on the system for all the card brands, and they get to pick the one that they want and the the interface that the user is working with stays consistent throughout the whole workflow.
Secure Remote Commerce app development
Each card brand has developed a library of sorts, that is designed according to a particular spec that they've all agreed upon as the click to pay construct.Our job is to put in a system that's in the middle that serves up some of the webpages like user sign in or listing credit cards to choose from, or if I'm returning to a system after having registered somewhere else, it lets me get a one time passcode to log back into the system.
Our app also deals with all of the transaction details and ships them off to the correct card brand and then takes the information that comes back and gives it to the merchant application so they can do what they need to with it - recording orders, setting up shipping, what have you. Our program sits in the middle and is able to talk to all of those card brand libraries.
Seamless transactions with Click to Pay
The main point is to have a consistent workflow for a user so they're not looking at different screens for MasterCard or Visa.They're not trying to step through the process differently. For the end user, if enough merchants put together integration with SRC or Click to Pay, when they use the merchant sites they will go through checkout the exact same way every single time. They'll have their card already registered on the SRC system. Then when they go to another site that uses SRC, that card will already be there and they can just one click pay and be done.
The various shopping carts themselves may look different, but the checkout process will be the same from end to end.
Developing encryption and automated tests
Currently there's a few things we are working on.One is that the the transaction payload itself has to be encrypted. And that encryption has to work with each card brand. Specifically, we've been working on some of the details to get that working properly so that we have a complete transaction.
The card brands also supply sandbox environments so you can test the SRC program within their system and run test transactions through with more live responses to them. We've been working on the the MasterCard angle of that.
We've also been working on test coverage in that when you're dealing with transaction details, you want to make sure that all of the pieces of your code have tests that actually run that code and make sure that the results are correct.
We are also looking at putting in a way within the program for merchants to be registered onto the card brands.
SRCi - merchant on-boarding
We're not building the system that's processing the card, but we're building a system that allows our merchant acquiring client to board merchants onto each card brand for the SRC. Each card brand would be available to the merchant only if they have a profile on that. That card brands system. And our program will be the one putting that profile in place so that the merchants' checkout page can then say I've got MasterCard, or I've got MasterCard and Visa. And the user just has that smooth, consistent UI throughout.An additional complication to this project is that each card processor may handle each edge case differently.
About a month ago, we did a UI demo with some MasterCard people on the line so they could see the workflow a user would step through as a new user, or as a returning user who already has some cards to list on the page. We were able to show them most of that with a connection to their sandbox environment. At that point they provide some feedback as far as pointers on how the workflow could be improved, from their perspective.
There are various edge cases that have to be considered like what if a user ends up somehow with more than one profile on the card? And they have cards listed for each profile. What do we do with that?
Each card brand has to give us some instructions as to how to handle each one of those cases. There's always a possibility that when we ask the same questions to Visa, they may want those cases handled differently. So when we get to that point, we'll have to figure that out.
Hiring trusted software consultants to accelerate development
So for this client, they have a lot of internal resources that could be used for this project. But based on their existing priorities and internal bandwidth they were not in a position to deliver the solution in a timely manner. A company like that just has enough projects going on internally and they don't have the resources to add on to that. So this project was a little more of a priority, but wouldn't figure into those resources as they were currently allocated.It's not a complex project when it comes to the the architecture of it. The bulk of it is taking all the documentation from all the sources like MasterCard, like Visa, and like the organization that put together the SRC protocol to begin with, and putting all that together and taking those code libraries and trying to interact with them. Finding all the edge cases and it's more of a puzzle than a software architecture piece.
The SRC spec is fairly new. I don't think there are a lot of solutions out there at this point if there are any, so its a fairly unique project.
If you need help designing and building custom software, please contact us.
If you want to learn more about custom software projects we have undertaken, take a look at our projects page.