API design: How and why we created Shop with Rewards

Picture this: You’re preparing for an upcoming camping trip and are shopping for a new pair of hiking boots. You find the right pair and proceed to checkout. Instead of having to wonder if you have rewards available to help with your purchase, your available rewards appear on the screen. Woah. They’re covered by your Capital One rewards. This is the kind of experience we work so hard to create, and we build and use cutting-edge tech to make it possible. 

While people are most familiar with our consumer credit card business, we also work with retail partners to provide credit card services and use our tech to create moments like this for customers. 

Instead of designing tech for a specific partner, though, we build partner-agnostic tech. An example of this is our Shop with Rewards API. It’s a point-of-sale API  that makes it easier for our customers to redeem their cardmember benefits when purchasing from our retail partners online and in-store, and it’s a universal API experience that’s scalable to both current and new partners.

We built it because our team saw an opportunity to create tech that could extend to additional partners and add value not just for one business relationship but for customers of any card partner. It has 3 distinct endpoints that sit between our rewards platform and our partners’ rewards platforms to enable the POS functionality and is available on our DevExchange to approved partners.

We’re part of the team behind the API that makes redeeming rewards at point-of-sale possible. It works across multiple partners with low latency in the cloud and can handle secure transactions per second at a level of scale that we hadn’t experienced before.

We set out to create an application for the organizations we have co-branded partnerships with that would drive more value for every party involved. Here’s how Shop with Rewards API achieves this:

• It’s easier for our customers to use their rewards at checkout, whether they’re shopping online or in a brick and mortar store
• Partners can more easily integrate with our services by calling the API
• It helps our internal teams operate our services at scale more easily, too

We created an easy-to-use API with 3 endpoints that any approved card partner can access online. While you can see it for yourself on our DevExchange, there are many components working under the hood. Here’s the whole picture of everything we built.

We designed a point-of-sale API that’s a plug-and-play solution for partners. It enables the interaction between our services and partners’ services.

We built an abstraction layer our partners can call to check a customer’s balance, redeem rewards or issue a refund at point-of-sale. We designed the abstraction layer to be flexible enough to work across partners with minimum impact to the tech side and support any partner with their specific needs. 

For instance, when a partner makes a call to get a customer’s reward balance, the response will show the rewards in dollars. We know that our card partners don’t want to just show the balance, so there are other types and categories of rewards they can use. They might also want to show consumers the type of reward available or what the conversion ratio is, for example. The abstraction layer is designed to support these types of needs.

We also created a wrapper around the core functionality of the existing application that handles the rewards calculation and redemption in the backend. It serves as a gateway between our core rewards functionality and our partners’ rewards platforms.

We built an automated settlement process that reconciles rewards activity and account balances with our partners each day. To offer multiple integration patterns to our partners, we built solutions to support Capital One being the system of record but also extending support for partners who want to own their rewards activity.

With so many moving parts, it was essential to work closely during the entire development process. We met with our partners at REI regularly and brought everybody, developers included, to every meeting. Here’s how we built it—together.

You can probably imagine how many transactions per second a retailer like REI processes—it’s a lot! And we built the API to allow multiple partners to interact with it at the same time.

It was clear that we needed to design all of the front-end and underlying technologies for scalability and latency. We set a very high target of transactions per second and started building.

We created a lightweight application because of our low latency requirements and developed the application’s code using Go language. When designing the infrastructure, we chose serverless technology because of its ability to:

• Reduce maintenance requirements 
• Increase high availability
• Scale performance as needed

Specifically, we use AWS Lambda to maintain the serverless infrastructure while

Capital One’s application gateway routes partners’ requests to the underlying servers. We’re also interacting with the external gateways from our partners and follow Capital One’s standard for third-party application interaction. Requests are handled by the Lambda function where the instances are kept warm to begin serving requests more quickly. 

We had to explore solutions to find ways to reach our high target of transactions per second with minimum latency, as it’s a customer-facing application. There wasn’t a definitive standard in place that supported such a high level of authorized transactions per second from a serverless standpoint. 

To avoid making the calls to some of the downstream APIs for every invocation of the Lambda function and bombarding them, we implemented logic that helps reuse the data between multiple requests. This solution helps the API to accommodate the high volume of transactions and requests it receives.

We built our core application using a generic, partner-agnostic design. As part of this, we created a standard template that partners use to make requests and for us to make the relevant calls and return the appropriate response. This helps give our partners a consistent experience when we’re talking with other developers and they're integrating with our tool. 

Since the core application is generic, we created an API wrapper to give us the flexibility we need to accommodate our partners’ unique needs. We added all the flexibility in the wrapper so that, for example, if partner A wants to use the API one way and partner B wants to use it a different way, we can do both without impacting core functionalities. Whenever we make changes to our service to accommodate partners, the wrapper is impacted instead of the core application—that’s the beauty of this design.

We incorporated the Shop with Rewards API when we launched the new REI Co-op® Mastercard® program in 2022. Since the REI launch, millions of dollars in rewards have been redeemed by REI customers. That’s a lot of surprise and delight moments because of the API. Even with the huge success of REI, we believe the API has the potential to drive a lot more value.

So we’ve continued to expand its functionality to more new partners. The application was built for it.

Now, we’re listening to our partners’ feedback and are excited about the future of the Shop with Rewards API.

At Capital One, we build, use, and sell leading-edge technology, like our Shop with Rewards API. See for yourself—you can visit our our DevExchange for the Shop with Rewards API today.