Payment Apps Chaos and how to stop it

Payment Apps offer new ways to complete transactions. In some countries, this is very powerful as having the ability to accept credit cards is not something easy to do as it requires having a formal business, paying monthly fees, and depending on a new piece of equipment. There are a lot of benefits but also disadvantages that I want to discuss.

Connectivity is now a must-have

A common issue with payment apps is the constant dependency on connectivity to complete a transaction. From a process point of view, when talking about achieving an exchange between two parties, payment apps set us back from what we had available before:

• Cash payment: Neither of the two parties requires to be online to complete the transaction.
• Card Payment: The owner of the card doesn’t require to be online, only the one who receives the payment does.
• Digital Payment: Most of the time (I don’t know how all the payment apps work but I do on the most famous ones) both parties need to be online in a synchronous way.

Payment apps are based on the last type of payment described here, so we will center the discussion on digital payments/transactions that are done on-site, like walking into a store and paying them with an app.

So, what is the issue with the need of having both parties online at the same time?

This is, without doubt, an increase in failure points. Also, there are some logistic issues that we will discuss, that increase the cost of operating in some markets by using this model. This is increased by the fact that the bigger the share on digital channels, the use of cash and cards is reduced.

Oligopoly essence of payment apps

Thinking about cash, all businesses are used to taking it, not much to say about it as it is widely known how it works.

On card payments, a business will have a payment terminal known as Point Of Sale (POS) that can take all types of cards from all banks.

Before I continue with digital payments, I have two questions:

-Would you like a payment card that is not accepted by businesses?
Probably not, you most likely will go for the ones that are widely accepted.

-Wouldn’t it be silly for a business to have one single POS for each bank?
I’m sure businesses wouldn’t like that. If there are 20 banks they will need 20 terminals and you will have to know which one you need to swipe your card on.

So thinking about these questions, aren’t payment apps this way already?

If you have a payment app you don’t know if the business you are going to will take it. That’s why you probably have the one with the biggest share on the market, or you will try that. If a new app is released the biggest question you have is: Who is going to take it?

Then, why businesses don’t take them all? Well, most of the payment apps work by having a QR code by the counter so when it’s time to pay you scan it and proceed with the transaction. If there are 20 payment apps in the future, and it is mandatory for a business to have them all, then you will see 20 QR codes by the counter and you will need to find the one for your app and that’s a challenge, isn’t it?

I’m aware some participants(like Apple or Google) can do an integration with the POS and use NFC to complete transactions, just like a credit card would do(basically they turn your phone into a credit card using the secure element but that needs a phone with charge), but there aren’t many participants that can do that, as the bureaucracy and cost of doing so are high. But of course, these actors are aware that the way to go is using a standard.

This article aims at other applications, the ones coming from startups trying to do something disruptive and offering business owners the ability to accept payments right after they enroll without the need of a terminal.

This will turn the market into an oligopoly as only a few, after big investments, will be able to stay in business. For every new participant, it will get harder to get into the market and that’s the opposite we would expect when we think of smartphone applications. In the long run, this is also impacting the final consumer, as they need more participants to benefit from the competition.

This is chaos.

How to stop it

How is this solved in the card payment industry? That’s easy to answer: they are using a framework. When there is a new bank coming into play, the bank has to adopt the framework so they can do an integration between them and the payment terminal. This allows the integrations to be international keeping the standard around the world.

Payment apps work as a channel that connects your bank card or a digital wallet with someone(usually a business) to send/receive payments, but there is no framework in between to have as a standard, this is causing unique solutions that are not aligned one to another.

Transactional framework proposal

With this proposal I will try to accomplish two things:

1- Allow transactions without the need for online connectivity between two parties at the same time. Note that this doesn’t have to apply to all transactions, it depends on the risk the business wants to take.

2-Make a universal framework so a business doesn’t need a new integration on their end to accept transactions.

I don’t want to limit this to payments so instead, I will explain an approach that tries to cover all types of transactions, being this an exchange of goods between two parties.

The first thing to know is the transaction will happen asynchronously and it is a must that only the part sending the payment is online at one point but the part receiving doesn’t need to be online unless the nature of the business requires that as I will explain later with some limitations.

I also will use examples of transactions using QR codes since it is more common, but in theory, you could use any way to transmit information, like Bluetooth, NFC, an Aztec code, etc. All the examples will have two participants: a client and a business, as they are the most common parties involved in a transaction but it can be more than that.

In summary, we require three steps to complete a transaction and one post-transaction step:

• Step 1 Capture Business information. Both parties can be offline.
• Step 2 Obtain transaction block. Only the Customer needs to be online.
• Step 3 Transaction block validation. Both participants can be offline.
• Step 4 Post-Transaction.

Capture Business information

To start a transaction we need to know who we are dealing with. To do this the business needs to share an identifier. This is common across applications but here we find the first issue: the identifier is not the same.

The easy fix here is to have a central authority, we can call it the Framework Authority (FA) to enroll a business/person, and assign a unique identifier. One more thing we want is to sign the message as we want to make sure the identifier we are capturing belongs to the FA. The certificate to verify the signature has to be distributed with the solution.

The final result should look like this:

Note here that Branch appears as one business can have more than one location. If this was a person the Business ID becomes the person ID and Branch stays by default with a default value.

Obtain transaction block

Step 1 needs to be already done.
The Customer needs to be online.
The customer will start the request using an application UI. In there, It will input the amount of the transaction.
The Application backend will access the payment type registered by the user. For example, it can trigger a credit card transaction or it can be a balance stored in a digital wallet.
After the transaction amount is approved and rules validated (for example the business ID needs to be validated using the signature and checking that is registered also by the backend owner).
Finally, a transaction block signed by the App provider is returned.

A transaction block structure is the following:https://medium.com/media/63f182e043e6cb3aaa92fd3e97ca614b/href

The final result should look like this:

There is no identifier for the person who wants to trigger the transaction. This is because, in theory, we could transfer one of these after it is generated, like sending it via WhatsApp for example so the one who is triggering the transaction is not the same person that generated the QR.

The provider is part of the block, this is because the same structure can be used by different providers but the entity receiving the token needs to identify who it is to see first if it accepts payments from them and second to know which certificate to use to check the signature.

The Token concept comes up. We want to leave the structure open not to just handle currency but something with its rules like a Token, which could be a ticket for a concert, payment for the bus, or even an item to exchange.

Transaction block validation

After receiving the transaction block the business should check if:

• Business and Branch ID matches its own.
• Transaction is not already stored in a database.
• Type is matching accepted type.
• Timestamp matches business rules.*
• Block provider is accepted.**
• Signature is valid.

All transaction blocks have to be stored so there are no duplicates trying to get a benefit on the system.

*The business rules on the dates could be a couple of hours or 24 hours for a vending machine or a store where but some other scenarios, like the ticket for a concert that could be obtained months before the date, should have a threshold much bigger than that.

**A block provider not accepted by a business should not be generating a transaction block for a Business ID not registered in their platform. This means, that if I go with an application to capture the business information, immediately the block provider (Payment App) should reject that transaction if the business identifier is unknown. There should be no collision on the identifiers because they are generated by a central framework authority

Post-Transaction

The block provider should already have a complete ledger of transactions to pay the business its share.
Even with that since the business accepted all the transaction blocks if something is missing it will have proof of it.
There is one dispute scenario where the payment app will require the transaction list from the business. Let’s say a customer walks into a store, generates a ticket, and then claims he didn’t use it (maybe there was any stock for an item), this opens a dispute over the block. If the business can show the block, that means the transaction went through and the customer won’t get its money back, in the other case where the business doesn’t have the transaction block, that means the customer can get his money back.
Some scenarios may require a blacklist.

Vulnerability analysis

• A valid transaction block for business A is used over business B.
  This should not cause an issue as business B will check the Business ID and realize is not valid for them.
• An attacker tries to use a valid transaction block more than once.
  The transaction ID of that block should be stored in the business database, therefore before validating it should check it doesn’t already exist.
• An attacker tries to use an old transaction block.
  The timestamp on the block should be checked. The rules for a valid threshold for dates should match the retention policy of the database so a transaction never gets deleted before it expires.
• The Business claims more money than what is registered on the transaction block provider.
  In this case, the business should provide evidence of the transaction blocks that are not being paid for. The same rules and validations apply to the transaction block provider. The business won’t be able to generate fake transaction blocks as they don’t have the private key to sign the blocks.
• A valid identifier of a business replaces the one that belongs to the place you are trying to generate a transaction for.
  We can think of a vending machine and someone replacing the identifier while there was no one looking. This can be fixed by the UI on the Payment App. When the identifier is collected, a picture of the place can be shown so the customer can make sure it’s the same place he is in.

Limitations

There are some cases where an offline implementation does not cover the business needs.
Consider a concert where multiple entities are validating tickets and also there are multiple entrances. A customer obtained a valid transaction block and shows that to a validator in door “A”. If that person shares the block with a friend, then that friend goes through door B, if the implementation is offline it will validate the transaction as successful.

For this example, there are other ways to prevent this from happening. One could be to generate a Token within the transaction block with some rules for example saying which door the token is valid for. The Branch ID can also be used for this purpose as that is already part of the framework to generate rules over the door that it can be used.

Another limitation in the case of depending on full online capability is the risk of losing or damaging the database. This will cause an issue if there is a dispute over a block.

It has to be known by the business that these risks exist so additional measures can be implemented to mitigate them.

Some use cases

The framework already supports synchronous transactions like most applications do today but it also helps on:

• Vending Machines, as they don’t need to be online to validate a transaction.
• Places with poor connectivity.
• Events. They can’t depend on internet connection and speed is a big factor in not generating queues
• Transport system. Same reason as above.
• Giving money to a third party.

I want to mention how the last item works. Let’s think of this use case: You have a son, they need to do a payment of 10 USD and they ask you for money. With regular applications, they would need to have access to it to complete a transaction. If they don’t own a bank account with a card, you can’t transfer money. In this case, the third party acts as a proxy to trigger a transaction and they can benefit from that. The third-party scans the identifier and sends a message with it to you, you generate the QR code and send it back to them so they can do the payment. This also applies to other scenarios like the worker of a company trying to get some money for lunch, pay for something at the store, or even lending money to a friend for a specific use.

This is my first article on this network. I hope you like it and I would love to discuss this topic or other tech-related topics in the future.