Card-Linked Offers (CLOs) are offers, such as cash-back or discounts, that consumers automatically receive after they link their debit or credit cards to a website, or app, enrolling in loyalty programs.

Several companies are using our APIs to build CLO programs in their app. In this article, I want to share a success story of a customer of ours.

Historically, software companies built their CLOs apps via Payment Networks (PNs), working either directly with them, or with a third-party company that could get them connected to the PN. As anybody who’s investigated this option knows, it is a lengthy and expensive process.

Our APIs instead are designed to encourage companies to build leaner, more agile solutions. Because we already work directly with multiple financial institutions that give us secure access to consumer data, it is possible to replace the old CLO workflow with a novel, better experience for your team as well as for your customers.

Let’s look more deeply at the details. Consumers (your customers) can enroll their program debit and credit cards in the CLO by verifying the ownership of a bank account and choosing which card (or account) they want to use. This authentication and card-linking model via bank is now a standard procedure: Consumers are accustomed to it and if they come to your app with the intention to give you access to their card, asking them to verify their bank information will not cause any hurdles.

Additionally (and a good selling point for you) it is important to know that Pentadata does not store the bank credentials (neither should you). We take a one-time usage approach, in an encrypted communication with the financial institution. This brings peace-of-mind to all involved, especially consumers.

GET YOUR APP CONNECTED TO OUR API

The diagram above depicts the simple steps that our customers take to integrate their app into our API and build the CLO workflows that help their customers (consumers) take advantage of the money-saving offers available to them.

For every consumer who wants to enroll in your CLO program:

• Add the consumer profile (“Person” object, documentation here).
• Link bank and/or card (“Account” object, see docs).

Two steps in total. Done.

Our API is built around the REST paradigm, so we talk about “Resources.” The “Person” is a resource type that identifies the consumers (your customers). The “Account” is a resource that identifies any bank account or debit/credit card which you need to get data from. In fact, we internally refer to this use-case as Account-Linked Offers.

This is enough to set up the CLO workflow. With the Account added, you can start fetching payment data (the “Transactions”), and analyze those to provide the consumers with rewards.

Here is where it gets incredibly easy. To demonstrate, I’ll share a real-life example from the customer of ours referenced in the introduction of this post: The customer was running a cash-back program for Jack in the Box. We were working closely with them, and found that our API returned data as below:

{  "datetime": "20201014123743",  "amount": -20.95,  "description": "JACK IN THE BOX 0324 09/29 PURCH",  "category": [    "Fast Food"  ],  "currency": "USD"}

This was enough to trigger their rewards system calls, and make their customers happy.

Basically, what they needed to do was as simple as¹

if [[ $str == *"JACK IN THE BOX"* ]] && [[ $str == *0324* ]]; then doReward(); fiLOOKING AT IT LIKE A MERCHANT

What is magic about the “0324” part of the Transaction description, and how did they know that it’d be there? Simple: they didn’t. The customer simply tested it, by making a real purchase at that merchant with an Account of theirs. This way, they realized the “0324” uniquely identifies that store. Now they run the same program with multiple stores of the same merchant, simply by checking different numerical codes.

We also recommended them to start thinking about growth and engineer a more scalable, automated solution. For example, because the merchants partner with them, they could ask these partners to add an Account themselves. The merchant, in this case, would be the “Person” resource, and by checking the Account they add, they can:

• Eliminate the toil (i.e. there’s no need to be physically present at the store to execute the payment).
• Open an entire world of possibilities to expand the partnership, once full Transaction history is available. (How many more things can you build for them once you have this new data?)

LOOKING AT IT LIKE A CONSUMER

In principle your consumers will be happy to simply get the promised rewards. However, with the Account-Linked Offers (ALO) program you get to know them very well, and can therefore build additional products on top of the program.

With the old CLO workflow, you got notification only for payment transactions of enrolled consumers at enrolled merchants. On the one hand this simplifies the problem of matching the merchant to the transaction. On the other hand, the ALO workflow gives you broader, better insight into what consumers like.

In fact, once you have the consumer’s permission and they add an Account in the system for you to get data from, you can get a very good overview of their spending habits – i.e. their favorite merchants and types of goods. You can also use our off-the-shelf API endpoints, included in Transactionz^TM, to see the consumer’s favorite spending categories.

You can easily improve the offers’ targeting, when you have this data. How many more things can you build with it?

ADVANCED USAGE

This customer’s story is interesting because they grew rapidly and not everything was straightforward. Thus, some of the challenges they met and solved are worth knowing for your benefit going forward.

As their own customers and merchants list got larger, they started having difficulty manually identifying the merchant stores. The original system still worked well, it was just less than easy to manage as a process because the number of people needed to run it grew with the number of merchants — not something you want as part of your business model.

It was then that we realized this was a recurring need and hence focused our efforts on engineering a solution for it – which resulted in MerchantSight^TM.

MerchantSight^TM is our API product that takes in a Transaction description and identifies the merchant store down to the GPS coordinate and Google Maps ID. The Transaction description can come from anywhere, not necessarily from our API.

Our customer, the same I’ve been referencing so far in this post, uses MerchantSight^TM in a very creative way. At fixed intervals they run a batch of Transaction descriptions through the API and identify the merchant stores. For each store, if they already have it among their partners, they then verify (or adjust) their lookup logic to make sure it catches it. If they don’t, then they reach out to the merchant. When they contact the merchant and say “Hey, we have a lot of people who already use our app, and we found that they spend some money at your stores,” that makes a compelling argument to start a new partnership – and they come on board readily.

Additionally, this usage of our API is very inexpensive. The cost is based on the number of requests sent (Pay-Per-Use model), and therefore it’s easy to keep it low by using the API at fixed intervals and for text descriptors of interest that do not already match.

CONCLUSIONS

The novel way to build a Card-Linked Offers app is to let consumers verify and add debit and credit cards via their bank. This is the new standard for accessing payment data.

We have a solution that enables companies to build CLO programs in minutes. And, it’s not only faster and smoother than the old model, but also much cheaper. If that isn’t enough, it also gives a comprehensive view into consumers’ activity to enable the tailoring of offers that they’ll appreciate.

The solution is Transactionz^TM, and it’s built around industry-standard technology and with the support of the largest financial institutions in the world. You can sign-up and test it for free here.

^[1] While I doubt they are using Bash for their web services, you get the gist.